ClusterDesctiprion value is not proper in MongoClientImpls, the updation of relica_set value is inconsistent in mongo-java-driver-3.12.9

_N_A149 · 2025-04-14T08:31:31.870Z

Hi Team,

Timed out after 30000 ms while waiting for a server that matches ReadPreferenceServerSelector Java Frameworks

Hello Team, We do face similar issue, we are working in a docker containers where as the Mongo Client driver connects to Mongo DB, and getting the below stack trace… We able to resolve this issue when restart the application or the containers. This issue seen randomly on any of the containers or some times in all the containers. for any use case restarting the application / containers resolving the issue. We use org.mongodb.Mongo-java_driver 3.12.9 & org.mongodb.driver-async 3.12.9 drivers… belo…

Post analysis on the above mentioned issue, we able to see that the ServerTuple value in the AbstractMultiServerCluster$ServerTuple object which is updated from isMaster result set has the correct cluster information, where as, the addressToServerTupleMap from MongoClientImpl object doesn’t have the correct info for the primary shard after ClusterDescriptionChangedEvent. the Secondary information was correctly populated as expected.

This behavior is inconsistent across all the shard members on the specific container.

Please let us know, how to get the implementation on ClusterListener.clusterDescriptionChanged(ClusterDescriptionChangedEvent) method.

Also we are not sure why this behaviour is consistent, which fails all the DB transaction towards this ReplicaSet.

Please Advice.!

Thanks,
Veera.

_N_A149 · 2025-04-21T05:59:42.495Z

Hi Team, Good Morning, on further analysis on the acquiring the primary during write operations, when primary is not available, the expectations is the clusterDescription.getPrimaries() should return empty list, but instead it returns TimeoutException

_N_A149 · 2025-04-23T04:47:32.694Z

Hi Team, Good Morning, Please let us know for any info on this specific behavior from Mongo Client Driver… this would be helpful for us on the identifying the root cause and handle it in our client side. Thanks in Advance/!

alexbevi · 2025-04-23T15:02:47.352Z

Hey @_N_A149,

If you believe there’s a bug here, the best course of action would be to double check this with the latest version of the Java driver first to see if it reproduces.

The version you’re using (3.12.9) is no longer maintained, so I’d recommend testing with at least 5.4.0. If the issue reproduces, we can file a bug report and start investigating this.

Venky_Chowdary · 2025-04-24T06:05:47.170Z

Alex,
Unfortunately we can’t upgrade the client driver immediately due to lot of dependencies. We are seeing that monitor thread is hanging on FutureAsyncCompletionHandler.get(), below is the complete trace of that thread. This is impacting our production… Any pointers will be helpful to narrow down this issue… Or any fixes provided in later versions
“cluster-ClusterId{value=‘68092f24594013714af69637’, description=‘null’}-XXXX:XXXX:XXXX:XXXX:27020” #67587 daemon prio=5 os_prio=0 tid=0x620108000000 nid=0xa906 [ JVM thread_state=_thread_blocked, locked by VM (w/poll advisory bit) waiting on VM lock ‘self_suspend_monitor for TID 43270’, polling bits: safep ]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- locked <0x000002009fea59c8> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:837)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:999)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1308)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at com.mongodb.internal.connection.AsynchronousChannelStream$FutureAsyncCompletionHandler.get(AsynchronousChannelStream.java:297)
at com.mongodb.internal.connection.AsynchronousChannelStream$FutureAsyncCompletionHandler.getOpen(AsynchronousChannelStream.java:284)
at com.mongodb.internal.connection.AsynchronousChannelStream.open(AsynchronousChannelStream.java:117)
at com.mongodb.internal.connection.InternalStreamConnection.open(InternalStreamConnection.java:128)
at com.mongodb.internal.connection.DefaultServerMonitor$ServerMonitorRunnable.run(DefaultServerMonitor.java:117)
- locked <0x000002007bb92940> (a com.mongodb.internal.connection.DefaultServerMonitor$ServerMonitorRunnable)
at java.lang.Thread.run(Thread.java:807)

_N_A149 · 2025-05-06T06:25:35.368Z

On the trail analysis for this particular issue, we narrow down the pattern as we are facing issue on the below combination of Ubuntu/Mongo DB server version along with same Mongo client driver.

Please find the below scenario:

Issue Seen:
Mongo DB Server: 4.4
Ubuntu: 20.04
Mongo Client Driver Version: 3.12.9

Issue Not seen on below combination:
Mongo DB Server: 4.4
Ubuntu: 18.04
Mongo Client Driver Version: 3.12.9

We just wanted some heads up that do we have any incompatibility on issue occurrence combination.

Thanks In Advance,