[JAVA-400] ReplicaSetStatus does not interrupt the Updater thread on close Created: 25/Jul/11  Updated: 18/Jun/12  Resolved: 05/Apr/12

Status: Closed
Project: Java Driver
Component/s: Cluster Management
Affects Version/s: 2.6.3
Fix Version/s: 2.8.0

Type: Bug Priority: Major - P3
Reporter: Tomasz Nurkiewicz Assignee: Jeffrey Yemin
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on JAVA-458 with slaveOk, query distribution to s... Closed
Backwards Compatibility: Fully Compatible

 Description   

com.mongodb.ReplicaSetStatus.Updater thread should be interrupted and closed gracefully upon Mongo.close() call. I know it's a daemon thread, but in Tomcat, when redeploying I get:

SEVERE: The web application [/ssp] appears to have started a thread named [ReplicaSetStatus:Updater] but has failed to stop it. This is very likely to create a memory leak.

Also see: JAVA-191



 Comments   
Comment by Jeffrey Yemin [ 18/Jun/12 ]

Closing for 2.8.0 release.

Comment by Jeffrey Yemin [ 10/Mar/12 ]

I fixed this in the context of JAVA-458

Comment by Markus Tripp [ 08/Aug/11 ]

When you execute Mongo.close() this triggers ReplicaSetStatus.close() which updates the _close variable.

Unfortunately the ReplicaSetStatus Updater Thread sleeps for up to 5 sec. until it checks the _close variable again. In this time Tomcat already undeployed and deployed the application and detected the potential memory leak problems. You can easily verify this if you close Mongo and sleep for > 5 sec. in the destroy method of your Servlet. Then you won't experience the problem. But this is not a good workaround.

Better would be if the ReplicaSetStatus.close method interrupts the sleeping Thread so that it immediately closes safely. The problem is that the Tomcat classloader cannot cleanup correctly which results in a growth of the PermGen memory region, which in the end can result in an OutOfMemoryError.

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