Re: Sessions not being collected
Re: Sessions not being collected
- Subject: Re: Sessions not being collected
- From: Chuck Hill <email@hidden>
- Date: Wed, 17 Nov 2010 09:31:48 -0800
My gut feel is that you are misinterpreting what you are seeing and that thread local is a Red Herring. It is more likely that some bug in your code is preventing the session from getting checked back in and hence from being removed from thread local storage. In other words, the thread local issue is a symptom, not a cause.
Which version of WO? Are session's awake, sleep, and terminate wrapped in a try...finally with super.* getting called in the finally block? Is session.terminate getting called in your or Wonder's code? If you log out the session id in your app, you can check back in the log to see what happened last to each session.
Chuck
On Nov 17, 2010, at 7:24 AM, John Larson wrote:
> 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
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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