Uploaded image for project: 'Java Driver'
  1. Java Driver
  2. JAVA-1620

2.12.x breaks compatibility with mongoDB v1.8

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • None

    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)

      Attachments

        Activity

          People

            Unassigned Unassigned
            jens.rommel Jens Rommel
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: