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 18:16:07 -0400
On Oct 22, 2008, at 4:49 PM, Mike Schrag wrote:
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?
So the "depending on how you're sending" is pretty crucial there :)
We actually send our emails out in a background thread, which
generates the component output in another thread, which would be
really dangerous if you're sharing a session. It's just a red flag
to look out for. I honestly have no idea about sending D2W-
generated emails or how to do that sans-sessions ... Not my
department on that one.
ERJavamail defaults to sending mail on the background thread,
correct? This is good to know. I don't think any of my session
values are going to cause major issues with how I'm sending
currently. I think at worst, I might get an email that goes out half
in one language, half in another because the user switched language in
the middle of a send... Unlikely, and even then, not a huge issue,
but it's a good thing to keep in mind. Thanks for pointing it out (^_^)
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?
? no? It's generating the response but that's totally independent
of a session. It's not a request-response loop, so there's no
savePage step of this process. There's only a session involved if
you do something that triggers a session to be created. That said,
I suspect you could ask your context for its session (if it has one)
and .sleep() it yourself and terminate it.
Ohh, I see what you're getting at... if the page has no session,
generateResponse obviously won't be trying to set cookies or backtrack
caches. That's basically what my patch does, but for those of us
using pages with sessions (^_^) So the cloned context in the patch
really doesn't matter at that point, because we're already in the
thread. At that point, if the thread is going to bork the session, it
can do it with the context just as easily as it can with a clone?
http://wiki.objectstyle.org/confluence/display/WO/Project+WONDER-Frameworks-ERJavaMail
Which I wrote :) I actually don't send with this method anymore,
but if you're sending from within your RR loop, this will work. I
believe our code creates a new request, cloning all the attributes
we care about on the way into the thread, creates a new context off
of that, and sends with that (without triggering session creation).
I tried the session free thing for a while. It felt like I was
fighting the framework everywhere I turned. After giving it more
thought, I decided I liked sessions (^_^) Then I started using D2W
and now I wonder how you guys can do without them.
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?
I'll have to look more at what exactly you're running into ...
You're clearly using this differently than we are, as I don't run
into any of these problems. D2W probably throws a crazy monkey
wrench into things.
ms
It has a lot to do with keeping the d2wContext current. I have to
have sessions with D2W, hence generateResponse is bad for the reasons
mentioned. But I can't just call appendToResponse because the context
of the D2W factory created page is just the current context and does
not contain the factory page's d2wContext. Just calling
appendToResponse on the page with the page.context() gives me the
wrong values out of the d2wContext.
Anyway, back to the original question... was the zombie thread issue
caused by the session being duplicated and then never put to sleep, or
does it arise from the generateResponse mucking things up? And if
it's generateResponse, does it happen before, during or after the
appendToResponse phase. Inquiring minds would like to know. I'll
have to keep an eye on my next deployment to see if my patched
ERJavamail fixes my zombie issues (^_^)
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