[JAVA-732] Thread Locals not being freed in thread pool Created: 15/Jan/13  Updated: 10/Mar/13  Resolved: 10/Mar/13

Status: Closed
Project: Java Driver
Component/s: Connection Management
Affects Version/s: 2.10.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: David Taylor Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java


Issue Links:
Duplicate
duplicates JAVA-595 With redeploy web app created a Threa... Closed

 Description   

We are seeing thread local data being left on threads in the thread
pool of our application running in Tomcat 7 causing a memory leak.
This problem is not unique to us. The JIRA issues below are described
by your customers experiencing similar problems

https://jira.mongodb.org/browse/JAVA-596
https://jira.mongodb.org/browse/JAVA-130
https://jira.mongodb.org/browse/JAVA-236

In JAVA-236, the issue is closed but it does not address the issue.
The patch seems to miss the point: we want to free the TLS, not close
the connection.

Here is the patch we have introduced to your 2.9.10 distribution:

— src/main/com/mongodb/DBTCPConnector.java.orig 2012-12-03
12:39:49.000000000 -0700
+++ src/main/com/mongodb/DBTCPConnector.java 2012-12-11
08:04:11.000000000 -0700
@@ -608,6 +608,15 @@
}

/**
+ * Release thread local storage for invoking thread. This should
be called for threads
+ * in thread pools implemented as part of a web framework per
request. It is not required
+ * for the thread invoking close().
+ */
+ public void release()

{ + _myPort.remove(); + }

+
+ /**



 Comments   
Comment by Jeffrey Yemin [ 10/Mar/13 ]

Duplicate of JAVA-595

Comment by Olivier Allouch [ 05/Mar/13 ]

Reloading my webapp causes PermGen exceptions. It may be related to this issue.
Btw, for my local ThreadLocals (dealing with SimpleDateFormats), setting the references to null works.

Comment by David Taylor [ 17/Jan/13 ]

We have not yet experienced any side effects, though we are concerned with thread pool reused state. Tomcat tries to deal with this by killling the threads in the thread pool. We dont know how successful they are because we dont reload Tomcat (currently). Having SEVERE errors in the logs that we have to train others to ignore is not "correct behavior"

Comment by Jeffrey Yemin [ 17/Jan/13 ]

My question is really about whether you are seeing any actual problems in the behavior of your application, or is it only the Tomcat reports that are a concern? Either way it's a problem, but it's more serious if there is incorrect behavior in addition to the warnings from Tomcat.

Comment by David Taylor [ 15/Jan/13 ]

http://wiki.apache.org/tomcat/MemoryLeakProtection

Comment by David Taylor [ 15/Jan/13 ]

With no API available to clear the TLS state, TLS memory is left on the web request threads. In a pooled request thread environment, these can result in cross request state contamination. furthermore, web application reloading cannot complete properly as long as these threads hold onto these objects in unloaded applications. Tomcat reports these TLS leaks per thread on shutdown as a diagnositic tool to warn developers of these portential problems.

Comment by Jeffrey Yemin [ 15/Jan/13 ]

Hi David,

Can you characterize the seriousness of the problem? Is it that memory is being wasted, or that the application is behaving incorrectly as a result?

Are you calling this release method at the end of every request?

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