[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] Ales Justin reassigned JBAS-8424: --------------------------------- Assignee: Bill Burke (was: Ales Justin) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] David Allen commented on JBAS-8424: ----------------------------------- As far as I can see, the FilterDispatcher will indirectly setup a new ResteasyProviderFactory for the application. This eventually is added to a ThreadLocalResteasyProviderFactory which keeps a static reference to thread locals (indirect). Later when an app is undeployed, the filter's destroy() method is called, but there is no code in this filter method. So it appears that no code is ever executed to remove the ResteasyProviderFactory from the thread local variable. Since it is a static ref, and the ThreadLocalResteasyProviderFactory is still loaded by a CL, it's references are never freed. The BeanManager is leaked through the CdiInjectorFactory used by the ResteasyProviderFactory for Weld applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] Stan Silvert commented on JBAS-8424: ------------------------------------ I just fixed the leak that I was talking about yesterday. Archive.java and ArchiveInfo.java both were using a WeakHashMap with the classloader as a key. But WeakHashMap will not work if the value holds a reference to its key. See javadoc for WeakHashMap. Anyway, I just wrapped the value in a WeakReference and that fixed the problem. However, I only know that it fixed the problem I saw with the four leaking classes I mentioned. I don't know if this is the solution for your original problem. Also, I'm wondering why you would need to use WeakHashMap in the first place. You should be able to use strong references and just clean everything up during undeploy. But I don't know this code well enough to say for sure. Please check over what I've done. Again, I'm not familiar with this code but I know that my fix does stop the leak of the four classes I mentioned. Unfortunately, it does not fix my JSF undeploy leak. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] Stan Silvert commented on JBAS-8424: ------------------------------------ It absolutely does (or did) cause a memory leak because the value could not be removed from the WeakHashMap. A value in a WeakHashMap will not be removed if the value holds an instance of its own key. In the case of Archive and ArchiveInfo, both had a WeakHashMap that was using the classloader instance as a key. But the mapped value held that classloader as an instance variable so it would not be removed from the WeakHashMap by the garbage collector. I have fixed the problem by wrapping the value in a WeakReference. I still question the use of WeakHashMap in this case. It will work as long as you wrap the value with the WeakReference before inserting it. But is seems much cleaner to use a regular HashMap and clean up the strong references yourself on undeploy. Perhaps it's just a matter of style but this bug does illuminate the pitfalls of reliance on GC behavior to do this kind of cleanup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] David Allen commented on JBAS-8424: ----------------------------------- I am confused by these additional comments about a WeakHashMap. This issue is specific for a problem in RestEasy regarding the design around the ThreadLocalResteasyProviderFactory which results in a hard reference to a BeanManagerImpl from Weld. It is not a WeakHashMap leak of any sort, but due to a lack of cleanup code to remove the thread local hard reference maintained for each deployment in JBoss AS. If there is some other code causing an issue regarding a WeakHashMap or weak references, can we file another JIRA issue for that one and copy the comments here to it? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] Bill Burke commented on JBAS-8424: ---------------------------------- Can you provide the object graph? Is an instance of a ThreadLocalResteasyProviderFactory holding the CDI factory? or is the field ThreadLocalResteasyProviderFactory.defaultFactory holding the reference? Or is it one of the delegates within the ThreadLocal map? The ThreadLocalResteasyProviderFactory is supposed to be just a shell. A ResteasyProviderFactory is created per WAR deployment. It is pushed/popped onto the ThreadLocal within ThreadLocalResteasyProviderFactory *PER REQUEST*. The filter destroy method should have nothing to do with ThreadLocalResteasyProviderFactory. Problems and leaks occur when new methods are added to ResteasyProviderFactory and not overridden and delegated within the ThreadLocalResteasyProviderFactory class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] Bill Burke commented on JBAS-8424: ---------------------------------- ThreadLocalResteasyProviderFactory.push() .pop() It is called within the ServletContainerDispatcher class in a try/finally block. If this is a Seam issue, then I know Seam bypasses a lot of my dispatching code, so it may be their problem. I don't know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] David Allen commented on JBAS-8424: ----------------------------------- It is the defaultFactory which holds the reference to a ResteasyProviderFactory which through its injectorFactory has a CdiInjectorFactory (which always contains a BeanManager). So this is not leaked through the thread local stack of delegates. There are actually 3 BeanManagers being leaked, so I need to investigate further to figure out why there are 3 for an AS with only one external app deployed. But this Resteasy instance should have been the correct one for the app which was undeployed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] David Allen commented on JBAS-8424: ----------------------------------- OK, so all 3 BeanManagers were related...2 are children of one, and the one parent is held by RestEasy. So somehow this needs to be fixed. I am not sure if CdiInjectorFactory is improperly implemented, or if there is some other design problem within RestEasy. This is the only leak I see in JBAS with Weld at the moment for a JSF web application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] Stan Silvert commented on JBAS-8424: ------------------------------------ For sanity sake, you might try replacing jsf.deployer/Mojarra-2.0/jsf-libs/jsf-impl-2.0.3.jar with the jsf-impl.jar I have attached. This jar contains the fix for an undeploy memory leak. This fix will be in Mojarra 2.1.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on JBAS-8424: --------------------------------------- Since the CdiInjectorFactory is referenced from various locations, it cannot cleanup itself. This must be fixed in RESTEasy. Bill, the object graph follows: javax.ws.rs.RuntimeDelegate -> ThreadLocalResteasyProviderFactory -> ResteasyProviderFactory -> CdiInjectorFactory -> BeanManagerImpl The problem is that RuntimeDelegate caches the provider factory in a static field. On undeploy, the field should be cleared (if it had not been replaced by another deployment's provider factory in the meantime) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] Shelly McGowan commented on JBAS-8424: -------------------------------------- RESTEasy 2.1-beta-1 was integrated into jbossas/trunk earlier today which should fix this issue. David/Jozef can you confirm? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8424?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on JBAS-8424: --------------------------------------- (was verified on r109265) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira