Sessions not being collected
Sessions not being collected
- Subject: Sessions not being collected
- From: John Larson <email@hidden>
- Date: Wed, 17 Nov 2010 09:24:22 -0600
I'm looking for help finding places that sessions can get stuck in thread local storage. To give a little background, I come upon this problem only during deployment and sporadically. This is an app that runs all day and at the end of the day I let all the sessions die out so the active sessions in monitor is zero. I then run a gc with a direct action. I can see that the full gc is run in the gc logfile. I then do a heap dump that comes out being 250-300 meg. (this all started in a quest for memory leaks.). Looking at the heap dump I see two sessions and can see from the page replacement cache that they were real sessions that people were using. In the component state (where I store the user login as a dictionary entry) I can see the users who logged in. I can also see that both threads were created in worker threads.
Though jhat gets stuck finding paths from the root, I can look through the references and see that one session is in two threads' local thread stores. In last night's dump I can see a WOPageRestorationError also. That could lead me to believe that I threw an exception in a direct action, but I'm using all the Wonder stuff so I thought that would make sure it was checked back in. ? There are two threads with this session in their threadlocalmap. One is sun.java2D.disposer and the other is com.sun.imageio.stream.StreamCloser.
The other session is also in thread local storage, but it is tied to the ERMailSender thread?? I've double checked that components I'm mailing don't accidentally create a session, but even if they did it wouldn't be able to get the context cache info, like login, that I'm seeing. I am using ERXApplication.instantiatePage to make the component and I check the returned page's context after the mail is sent to make sure it doesn't have a session, and it doesn't. Also both threads have _terminating and _wasTimedOut marked as true.
Lastly, running jstack shows two threads as untraceable. Unfortunately, I quit the instance before checking the thread ids against these threads.
I understand that there is no way anyone can diagnose my exact problem given that this is an email about a 300 meg heap, but is there someplace I can hook into to look for clues?
I'm assuming also that these references are strong and therefore are reason enough to keep the sessions from being collected so I think I'm looking at the right thing. ?
Thanks,
John
John A. Larson
President
Precision Instruments, Inc.
Ph: 847-824-4194
Fax: 866-240-7104
Sent from my iPhone _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden