Tomcat ThreadLocal memory leak warning about owlapi HOT 6 CLOSED

I found some info on page 23 of this:
http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

It looks like the web application should call remove() on the thread local at the end of a request - but this cannot be done with the current OWL API code. Whether it would be convenient to do so, I think not, because the cache would then be renewed after each request - if parsing of the same or similar ontologies is done in separate requests, this would reduce the cache hits and complicate the architecture.

I think the best short term solution to this is to revert to your synchronized map solution; this is not ideal, as the synchronized weak cache is potentially a bottleneck for all threads parsing ontologies at the same time, but I cannot figure out a better one, at the moment.

from owlapi.

I have reverted this and deployed a new snapshot on Sonatype. If you reckon this is urgent, I could make a new release in a week or so.

from owlapi.

I don't know if it is urgent as I am not sure how often threads would be
reused by the ServletContainer in practice and how often people will be
reloading webapps without restarting the servlet container, if that was
part of the cause.

In production I rarely reload webapps without restarting the servlet
container, as there is typically a scheduled downtime so you can have the
luxury of a cold reboot. In testing however I can't be restarting Tomcat
each time so I tend to just rely on Tomcat redeploying the servlet and that
is where the warnings came up.

According to that presentation, Tomcat has a few different viable
strategies for some of the bugs and it mentioned configurable behaviour for
ThreadLocal clearing but didn't mention how to do that there.

You could try reusing this Public Domain ConcurrentWeakHashMap solution by
Doug Lea and Jason Greene that has adjustable concurrency:

http://www.java2s.com/Code/Java/Collections-Data-Structure/Ahashtablewithemweakkeysemfullconcurrencyofretrievalsandadjustableexpectedconcurrencyforupdates.htm

It appears to support concurrent retrievals based on its Javadoc, which
would be the main application of it in WeakCache, as puts should be very
rare in practice after a small warmup phase.

On 20 May 2013 17:43, ignazio1977 [email protected] wrote:

I have reverted this and deployed a new snapshot on Sonatype. If you
reckon this is urgent, I could make a new release in a week or so.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-18135684
.

from owlapi.

It seems that ConcurrentWeakHashMap was later redesigned to be ConcurrentReferenceHashMap (again Public Domain by the same authors) which supports different types of References for different purposes.

http://grepcode.com/file/repo1.maven.org/maven2/org.jboss/jboss-common-core/2.2.19.GA/org/jboss/util/collection/ConcurrentReferenceHashMap.java

from owlapi.

Something along those lines is a good plan - long term, we want to replace
these in house utilities with something better Apache or guava. This last
one has configurable collections to achieve the same purpose.
On 20 May 2013 12:33, "Peter Ansell" [email protected] wrote:

It seems that ConcurrentWeakHashMap was later redesigned to be
ConcurrentReferenceHashMap (again Public Domain by the same authors) which
supports different types of References for different purposes.

http://grepcode.com/file/repo1.maven.org/maven2/org.jboss/jboss-common-core/2.2.19.GA/org/jboss/util/collection/ConcurrentReferenceHashMap.java

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-18143026
.

from owlapi.

Threads are going to be renewed over time to try and avoid a probable memory leak

from owlapi.