[JAVA-1620] 2.12.x breaks compatibility with mongoDB v1.8 Created: 15/Jan/15  Updated: 15/Jan/15  Resolved: 15/Jan/15

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Jens Rommel Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using the Java driver 2.12.x against a mongoDB version 1.8 fails at startup due to com.mongodb.MongoTimeoutException caused by java.lang.NullPointerException (see stack trace below).

The root cause seems to be the expected existence of "versionArray" in com.mongodb.ServerStateNotifier.getVersion(final CommandResult buildInfoResult) (v. 2.12.0, later moved to ServerMonitor.getVersion in 2.12.2)

Apparently, mongoDB v1.8 doesn't provide the version as array.

Is having a structured ServerVersion class really worth breaking backwards compatibility? Looks rather accidental to me.

com.mongodb.MongoTimeoutException: Timed out after 10000 ms while waiting to connect. Client view of cluster state is {type=Unknown, servers=[{address=127.0.0.1:27017, type=Unknown, state=Connecting, exception={java.lang.NullPointerException}}]
at com.mongodb.BaseCluster.getDescription(BaseCluster.java:128)
at com.mongodb.DBTCPConnector.getClusterDescription(DBTCPConnector.java:396)
at com.mongodb.DBTCPConnector.getType(DBTCPConnector.java:569)
at com.mongodb.DBTCPConnector.isMongosConnection(DBTCPConnector.java:370)
at com.mongodb.Mongo.isMongosConnection(Mongo.java:645)
at com.mongodb.DBCollection.findOne(DBCollection.java:865)
at com.mongodb.DBCollection.findOne(DBCollection.java:843)
at com.mongodb.DBCollection.findOne(DBCollection.java:789)
at com.sap.sse.security.userstore.mongodb.impl.DomainObjectFactoryImpl.loadSettingTypes(DomainObjectFactoryImpl.java:199)
at com.sap.sse.security.userstore.mongodb.UserStoreImpl.<init>(UserStoreImpl.java:55)
at com.sap.sse.security.userstore.mongodb.impl.Activator.start(Activator.java:30)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:936)
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:319)
at org.eclipse.osgi.container.Module.doStart(Module.java:571)
at org.eclipse.osgi.container.Module.start(Module.java:439)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)



 Comments   
Comment by Jens Rommel [ 15/Jan/15 ]

Thanks Jeff!

We're going to upgrade our mongodb anyway. We just came across this issue during migration and thought it might have just been accidental.

Comment by Jeffrey Yemin [ 15/Jan/15 ]

Hi Jens,

The 2.12 driver series is not tested with MongoDB 1.8, as that version is no longer supported, so you'll either have to use an older driver or upgrade to a more recent version of the server.

You can see from our test matrix that we test back to server version 2.2.

Generated at Thu Feb 08 08:55:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.