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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to