ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-5395) Introduce Tomcat's JreMemoryLeakPreventionListener and why
Date Tue, 12 Jan 2016 11:30:39 GMT

    [ https://issues.apache.org/jira/browse/OFBIZ-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093765#comment-15093765

Jacques Le Roux commented on OFBIZ-5395:

Just an update about Java Regular Expression Library Benchmarks in 2015 at https://www.voxxed.com/blog/2016/01/java-regular-expression-library-benchmarks-2015
(http://tusker.org/regex/regex_benchmark.html used in this issue description was in 2010)

Also at http://www.javaadvent.com/2015/12/java-regular-expression-library-benchmarks-2015.html
(hopefully one of them will be available at long term...)

> Introduce Tomcat's JreMemoryLeakPreventionListener and why
> ----------------------------------------------------------
>                 Key: OFBIZ-5395
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5395
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>              Labels: JreMemoryLeakPreventionListener, ThreadLocal, leak
>             Fix For: Trunk
>         Attachments: OFBIZ-5395-CompilerMatcher.patch
> After reading few articles on possible memory leaks when using ThreadLocal variable with
custom classes in application server context where a thread pool is used, I checked OFBiz
code. There is only 2 custom classes  concerned: CompilerMatcher and RollbackOnlyCause (JDK
classes are not concerned by ThreadLocal memory leaks).
> First I must tell, that the memory leak problem is more clearly described in those articles
when you use an external Application Server (like Tomcat) and you deploy/undeploy applications.
It seems there are no major issues when you use OFBiz OOTB (with Tomcat embedded).  Nevertheless,
it's a concern by and large.
> I have not investigated RollbackOnlyCause, only CompilerMatcher. But, after some profiling,
I believe both should only generate small amouts of memory leaks, almost not noticeable even
after several deploy/undeploy cycles.
> Nevertheless I tried to find a good way to get rid of CompilerMatcher possible leaks.
I thought about 3 ways:
> # *Reverts [CompilerMatcher related changes|http://svn.apache.org/viewvc?view=revision&revision=1075322]*
done for OFBIZ-4107 (introduction of CompilerMatcher) by using Perl5Compiler.READ_ONLY_MASK
which guarantees thread safety
> ** Pros: no need to introduce ThreadLocal
> ** Cons: performance, local Perl5 variables creation removes the patterns-compiled-cache
CompilerMatcher introduced (note: [I found the origin of CompilerMatcher class here|http://mail-archives.apache.org/mod_mbox/jmeter-user/200212.mbox/%3Cse0ae21c.089@katun.com%3E])
> # *Uses ThreadLocal<CompilerMatcher> local variables* instead of private static
> ** Pros: no need to worry about thread safety
> ** Cons: performance, local ThreadLocal local variables creation removes the patterns-compiled-cache
ThreadLocal<CompilerMatcher> offers  when used as a private static member
> # *Introduces [Tomcat's JreMemoryLeakPreventionListener|http://wiki.apache.org/tomcat/MemoryLeakProtection].*
[What it does (in less than a minute)?|http://stackoverflow.com/questions/14882794/what-does-tomcats-threadlocalleakpreventionlistener-do-exactly]
[Why JreMemoryLeakPreventionListener was created?|http://www.tomcatexpert.com/blog/2010/04/06/tomcats-new-memory-leak-prevention-and-detection]
[History (29 pages presentation).|http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf]
 How it does it? [Read code!|http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?view=annotate]
> ** Pros: 
> *** no changes related to CompilerMatcher, performance enhancement the cache introduces
> *** prevents memory leaks when an external Application Server is used or at least warn
about them (Note: this can only be done in OFBiz internally, for app server the best is to
document with a section in the [related wiki page|https://cwiki.apache.org/confluence/display/OFBTECH/Run+OFBiz+under+outside+Application+Servers].
> ** Cons: none, this should had any noticeable effects when OFBiz is used OOTB (Tomcat
> I decided to go with the JreMemoryLeakPreventionListener solution. Another reason for
that is that when I profiled OFBiz trunk using the demo site I found that we were having a
large bloc of memory retained by [sun.awt.AppContext|http://www.docjar.com/docs/api/sun/awt/AppContext.html].
 I think we should not have such a thing, the web truk demo does not use AWT at all! Fortunately
jreMemoryLeakPreventionListener.setAppContextProtection prevents this, even if I have still
no ideas from where this comes (certainly something like explainded in page 14 of the link
from "History (29 pages presentation)" above)
> I'm also considering to replace the current uses of java.util.regex.Pattern by CompilerMatcher
in cases of a static pattern is used. When the CompilerMatcher cache makes sense (patterns
do not change). The interest is the better performance of the oro framework, at least so far
(Java 1.6, see below).
> Some interesting references I noted while analysing this issue:
> * [Oro is 6 times faster than regular Java regex|http://www.tusker.org/regex/regex_benchmark.html].
So, with its cache, CompilerMatcher is more than an interesting alternative to regular Java
> * Java regex Javadoc: [Compiler|https://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html],
> * Oro Javadoc: [Compiler|https://jakarta.apache.org/oro/api/org/apache/oro/text/regex/Perl5Compiler.html],

This message was sent by Atlassian JIRA

View raw message