[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.
|
| 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:
Have you confirmed in practice that this is an issue for you? |