Apr 14
2 / 5
Apr 20
4d ago
_N_A149Veeracholan Kalieswaran
13d

Hi Team,

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_A149Veeracholan Kalieswaran
7d

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_A149Veeracholan Kalieswaran
5d

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/!

alexbeviAlex BevilacquaMongoDB Employee
4d

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
4d

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)


Want to read more? Browse other topics in Drivers or view latest topics.