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
