Simon, Thanks for responding!
I didn't know about the ConversationManagerSessionListener, after poking at it for a little, I think I understand how it all works now. Unfortunately I'm still experiencing the leak. I see in the Listener that it removes the ConversationManager objects in the method attributeRemoved. Is it required for an HttpSession to remove it's attributes and therefore cause attributeRemoved to be called? I believe the web container we are using does not cause attributeRemoved to be called. Inside of the container we use when the session is invalidating the attributes are searched for instances of HttpSessionBindingListener. Each instance that is found has its valueUnbound method called. If I'm interpreting this correctly, that means that for ConversationManager objects not to leak in my container, they will need to implement this HttpSessionBindingListener interface and remove themselves from the ConversationWiperThread in the valueUnbound method. Or the container would have to call removeAttribute when the session times out. Does this sound correct? At this point do you think it is an issue with my web container that I should file with the vendor? Or is this something that needs to change in Orchestra to accommodate the container. Thanks, Steve Ronderos From: Simon Kitching <[email protected]> To: MyFaces Discussion <[email protected]> Date: 12/27/2008 03:59 AM Subject: Re: Possible Leak in MyFaces Orchestrea On Tue, 2008-12-23 at 10:30 -0600, Steve Ronderos wrote: > > Hello Orchestra Users, > > I posted the following message to the developers mailing list a few > weeks ago and had no response. > > I was wondering if anyone has any information on a potential memory > leak that I see in Orchestra 1.2. > > It appears to me that conversationManagers in > ConversationWiperThread.java gets new ConversationManager objects > added to it but they are only removed through some serialization > method (I don't fully understand the distributed serialization stuff > since I have never used it). I think that this leak is pretty > small... on the order of 10s of bytes per ConversationManager, but for > long lasting high traffic apps that could eventually become a problem. > Is there something that I have overlooked that ensures that these are > cleaned up? Is this an accepted shortcoming of Orchestra? Should I > file a JIRA issue? Hi Steve, I don't believe there is a problem here. There is one ConversationManager instance per http-session. It gets created when needed (when something calls ConversationManager.getInstance) and is deleted when the http-session gets deleted. There is one ConversationWiperThread instance per webapp. It never creates or destroys ConversationManager instances. However it does peek inside them in order to destroy Conversation and ConversationContext objects that timeout. Unfortunately, there is no javax.servlet api for getting a list of all the HttpSession objects. Therefore in order for the ConversationWiperThread to know what ConversationManager objects exist, the ConversationManagerSessionListener class registers itself as a SessionListener object on the webapp, and detects when a ConversationManager object is added to an HttpSession. The ConversationWiperThread does add these references into a non-weak map, so if they were never removed from the map that would indeed be a leak - when the http session is destroyed there would still be a reference to the ConversationManager. However if you look at ConversationManagerSessionListener you will see that when an http session is destroyed, the ConversationManager instance (if any) in that session is removed from the wiper-thread's map. So as far as I know, there is no leak. There is also one other issue: the container can "passivate" a session (write it out to disk to free up memory). In this case, we also need to remove the ConversationManager from the wiper-thread. The sessionWillPassivate and sessionDidActivate methods in ConversationManagerSessionListener should handle that case too. If you see any other way in which a memory leak can occur, please let us know. Regards, Simon
