[JAVA-2766] DefaultServerMonitor catches Throwable and discards without logging Created: 01/Feb/18  Updated: 27/Oct/23  Resolved: 02/Feb/18

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

Type: Bug Priority: Minor - P4
Reporter: Steve Shabino Assignee: Unassigned
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This code ought to at least log subclasses of Error (OOMEs in particular). Without doing so, there is no way to know that the JVM "got sick" when executing this thread. Even though the thread itself likely (I didn't evaluate the control paths) continues to behave correctly, I like to know if my JVMs are having issues.

} catch (Throwable t) {
   averageRoundTripTime.reset();
   currentServerDescription = getConnectingServerDescription(t);
}



 Comments   
Comment by Lev [X] [ 17/May/18 ]

Jeff, thank you, I've got it. It seems that this problem indeed is out of the library scope, so you're right. Now I've realized that in my case the -XX:+ExitOnOutOfMemoryError flag will resolve all my problems.

 

Thank you. 

Comment by Jeffrey Yemin [ 17/May/18 ]

Khotov are no other threads throwing OutOfMemoryError?  As this try/catch runs in a background thread, there's no way for the driver to throw it to the application.

Comment by Lev [X] [ 17/May/18 ]

@jeff.yemin Hi, Jeff.

I've just found out an OutOfMemoryError entry in our microservice logs. Unfortunately, the microservice has been still functioning(but not correctly for obvious reasons). This makes me quite unhappy because our ecosystem is configured to restart automatically fallen services, so the expected behavior of the service when it's got any troubles is to fall. But since the piece of code pointed in the issue swallows the Error, the service doesn't know about the problem and doesn't fall.

 

I'm highly confident that exactly this catch block is the source of my problems since I've reproduced the OutOfMemoryError occurrence in debug mode.  

Comment by Jeffrey Yemin [ 02/Feb/18 ]

Closing this, but happy to re-open if you find an exception that's not actually logged.

Comment by Jeffrey Yemin [ 01/Feb/18 ]

Except for the one that just catches MongoSocketException in order to retry the connection attempt, the nested catch blocks all re-throw their exceptions.

Comment by Steve Shabino [ 01/Feb/18 ]

The logging you pointed out is great, but it only logs Throwables emitted from the two lines in the code block, and not any Throwables originating from the try/catch block immediately above the one you mentioned.

Obviously, this is a minor concern. I happened to be reading through this code and thought I'd report it.

Comment by Jeffrey Yemin [ 01/Feb/18 ]

The intention is that exceptions are logged in {{com.mongodb.connection.DefaultServerMonitor.ServerMonitorRunnable#logStateChange}]. Here's an example where a connect failure is logged:

13:19:03.266 [cluster-ClusterId{value='5a735a1390b78e75df9810da', description='null'}-localhost:27018] INFO  org.mongodb.driver.cluster - Exception in monitor thread while connecting to server localhost:27018
com.mongodb.MongoSocketOpenException: Exception opening socket
	at com.mongodb.connection.SocketChannelStream.open(SocketChannelStream.java:55) ~[mongodb-driver-core-3.7.0-SNAPSHOT.jar:na]
	at com.mongodb.connection.InternalStreamConnection.open(InternalStreamConnection.java:118) ~[mongodb-driver-core-3.7.0-SNAPSHOT.jar:na]
	at com.mongodb.connection.DefaultServerMonitor$ServerMonitorRunnable.run(DefaultServerMonitor.java:114) ~[mongodb-driver-core-3.7.0-SNAPSHOT.jar:na]
	at java.base/java.lang.Thread.run(Thread.java:844) [na:na]
Caused by: java.net.ConnectException: Connection refused
	at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:na]
	at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) ~[na:na]
	at java.base/sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111) ~[na:na]
	at com.mongodb.connection.SocketStreamHelper.initialize(SocketStreamHelper.java:59) ~[mongodb-driver-core-3.7.0-SNAPSHOT.jar:na]
	at com.mongodb.connection.SocketChannelStream.open(SocketChannelStream.java:52) ~[mongodb-driver-core-3.7.0-SNAPSHOT.jar:na]
	... 3 common frames omitted

Have you confirmed in practice that this is an issue for you?

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