Re: [Wonder-disc] SOLVED: Zombie sessions
Re: [Wonder-disc] SOLVED: Zombie sessions
- Subject: Re: [Wonder-disc] SOLVED: Zombie sessions
- From: Ramsey Gurley <email@hidden>
- Date: Wed, 22 Oct 2008 16:38:28 -0400
On Oct 22, 2008, at 3:55 PM, Mike Schrag wrote:
I don't think it's the context so much as what is happening in
generateResponse _after_ appendToResponse is called though. I say
that because I'm obviously using a cloned context, but no new
session is created... I just tested it, and my session constructor
is only logging one session created from launch to mail sent.... I'm
certain the pages are touching the session when generating their
content because they are mailed using whatever language is set in
the session's current localization. So unless the bug is borking
_that_ session, it shouldn't be an issue once patched. I'm
curious... did you witness/log a new session being created as the
result of the mailings?
If you're using a cloned context, it's cloning the session id, which
is potentially even worse, because you're going to muck with your
session from some other thread (depending on how you're sending out
these emails). The correct fix is definitely what Chuck was saying,
to change your components in your email to not touch the session.
ms
I'm using D2W, so I _have_ to have the session to generate the page
content. There's doesn't even appear to be a way to get a page from
the D2W factory without a session. So session isn't thread safe? No
mail from D2W?
But this is really a crucial question for everyone, because the call
to generateResponse that is in ERJavaMail currently is writing to the
session's page cache already... so we're still mucking with the
session from a separate thread anyway, no?
All I really did to arrive at my patch was step through
generateResponse with a debugger, and lop off the unwanted stuff that
happens after appendToResponse is called (page caching and cookie
setting). If the cloned context is bad.. well the patch method works
without the clone, but returning null still gives you the mail page
instead of the page you would expect. The only reason I cloned was
because of the advice presented here:
http://wiki.objectstyle.org/confluence/display/WO/Project+WONDER-Frameworks-ERJavaMail
How else would we go about returning the proper context in the case of
a null return value after generate response does what you see in that
method to the context? Perhaps instead of cloning the context, it
should store the context._pageElement() value and reset it after
append to response is called?
Ramsey
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