[Bug 56580] el-api.jar memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=56580 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Mark Thomas ma...@apache.org --- Hmm. The specification is completely silent on this. There is the odd hint that caching may take place within the EL implementation but no details are provided as to what might be cached or how and, importantly, no API is provided to clear any cache that may exist. The Glassfish solution was to use SoftReferences for the cache entries. That only sort of fixes the problem in that the web app class loader could remain in memory until long after the web application is reloaded. We have seen cases in the past where this behavior causes problems for some libraries (and is why we added closeMethod support to resources). If the cache was static then we could add a method to clear the cache for a given class loader and call that via reflection when the web application stops. However, making the cache static is going to have all sorts of side-effects - some of which may well be unpleasant. The most obvious of these is a guaranteed memory leak unless you call the clear cache method which most clients won't do. The other pure Tomcat solutions are don't cache or to place the Mojarra JARs in the web application rather than $CATALINA_BASE/lib. Mojarra could use per web application instances of BeanELResolver rather than a single static instance. Mojarra should also have the necessary hooks to remove those instances when the web application stops (e.g. ServletContextListener). In short, I don't see a way to fix this safely in Tomcat. I think it could be fixed in Mojarra but I don't know that code base so I might be completely wrong. There are a couple of work-arounds: disable the cache, move the Mojarra JARs to WEB=INF/lib. I agree that there is a problem here and I'd like to fix it in Tomcat if I could but I don't see a way to do that. Given that there are workarounds available I am going to resolve this as WONTFIX. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56580] el-api.jar memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=56580 --- Comment #6 from cos...@prodinf.ro --- I think that I will store in WEB-INF/lib all my jars for now -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56580] el-api.jar memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=56580 --- Comment #4 from cos...@prodinf.ro --- If you need some help do not hesitate to contact me. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56580] el-api.jar memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=56580
--- Comment #5 from Konstantin Kolinko knst.koli...@gmail.com ---
My look at javax.el.BeanELResolver#cache is that a BeanELResolver that it would
be bad to share such cache between web applications.
The cache keys BeanProperties instances by class name, and not by {class name,
class loader}. This creates an ambiguity that is resolved by comparing class
references in BeanELResolver#property(...)
if (props == null || type != props.getType()) {
Sharing the same BeanELResolver among applications also means that its cache is
also shared, so you cache only 1000 classes globally, instead of 1000 per each.
I may suggest you to apply either one the following work-arounds:
a) Put mojarra into your own WEB-INF/lib directory, instead of sharing those
libs among web applications. This should provide you with better performance,
as your static copy of BeanELReolver will have cache scoped to your web
application.
Generally it is a bad idea to share libraries between web applications. (You
are tied to a specific version of the library. You are more likely to see
memory leak issues, such as this one.)
b) Set system property org.apache.el.BeanELResolver.CACHE_SIZE to the value
of 0. I think that would disable the cache.
Regarding a possible way to improve Tomcat's BeanELResolver, to both avoid a
leak and to reduce clash of same class name between class loaders:
- Use 2-level cache, with first level being WeakHashMapClassLoader, Cache.
That is if you want to cache 1000 classes per class loader as opposed to 1000
classes globally.
I can say that it would have some negative effect on performance.
Is it a valid use case to share EL classes such as BeanELResolver between web
applications?
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56580] el-api.jar memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=56580 --- Comment #2 from cos...@prodinf.ro --- There is no Class in ELUtils but there is BeanELResolver(in el-api.jar). The ELUtils is in (JSF MOjarra https://github.com/bleathem/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/el/ELUtils.java ). The problem is that Jsf jars and el-api jar are stored in tomcat_dir\lib directory (shared classloader) and after a while BeanELResolver stores classes for the war classloader and never unloads them on war redeploy. The issue is in line 142 from ELUtils.java .The guys from mojarra are saying that the BeanELResolver must be reimplemented so that after redeploy no references to the classes from the war classloader must be holded. I have analyzed this source code (http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/javax/el/BeanELResolver.java) and I think that if the member cache will hold SoftReferences everything will be unloaded . In my perspective I think that it will be ok if you redesign the inner class ConcurrentCache from ELResolver. They say that this issue was fixed in Glassfish in their el-api implementation. If you like we could talk by Skype and give you more information -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56580] el-api.jar memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=56580 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #3 from Mark Thomas ma...@apache.org --- Remove the NEEDINFO status. This report and the linked Mojarra issue has all the required information. I am wondering at this point if this is a Tomcat bug or not. The cache implementation can certainly be changed to avoid this issue but Mojarra using a static instance of BeanELResolver looks suspicious. I need to look into what - if any - guidance there is in the EL spec about this sort of usage. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56580] el-api.jar memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=56580 Christopher Schultz ch...@christopherschultz.net changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Christopher Schultz ch...@christopherschultz.net --- There is no class ELUtils in Tomcat. Can you give more information? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
