-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BeanELResolver cache causes Class Loader leaks in app servers #214
Comments
There is no way that I can think of to provide "automatic" scoping / cache invalidation. My conclusion is to keep |
@arjantijms My assumption is that this is an issue in GlassFish as well? I am sure that you guys would like to see a fix so you can start using "stock" version of EL at some point instead of needing to fork? Thank you |
@lprimak WildFly and JBoss EAP have long used our own variant of the EL API. We could likely stop doing that if our bean properties and factory finder caching use cases discussed in #218 were both handled in this project. That said, it sounds like the need for the bean properties pieces is because Faces is holding a static ref to a BeanELResolver. The WildFly project and the downstream Red Hat JBoss EAP product are produced independently of other EE implementations from IBM. So my comment here should not be interpreted as saying anything about IBM or any of its EE impls like Websphere, Liberty etc. |
Thanks, Brian, It sounds like Also sounds like Am I understanding things correctly? |
Currently, BeanELResolver caches
Class
elements in itsSoftReference
maps.This causes it's
ClassLoader
to be referenced in the cache.BeanELResolver
internalSoftReference
map only gets cleaned up viacleanup()
method,which doesn't necessarily get called often enough to prevent Out-Of-Memory errors.
The other issue is that, even when
cleanup()
is called enough to prevent OOMs,the 'danglng' ClassLoaders cause VM to run at it's max memory capacity,
causing unnecessary GC and memory allocation thrashing.
clearProperties()
method is needed to clear the cache from the ClassLoaders and thus prevent the leakThe text was updated successfully, but these errors were encountered: