Re: session timeout handling bugs (was Re: Session Timeout Page)
Re: session timeout handling bugs (was Re: Session Timeout Page)
- Subject: Re: session timeout handling bugs (was Re: Session Timeout Page)
- From: Chuck Hill <email@hidden>
- Date: Fri, 08 Aug 2003 11:25:56 -0700
- Organization: Global Village Consulting, Inc.
Now that you say this, I think this is where I saw it too. I can't
imagine why this situation would be any different than a regular
request with an expired session.
I also thought that the adaptor redirecting a component action another
instance was a bug. Then I recalled that it is possible to have
sessions stored externally to an app for failover. If this was done
the other instance could handle the request. I'll guess that is the
explanation of this behavior despite the infrequency of anyone
implementing such a session store. It seems like something that
should be a woadaptor setting (-WOUsesDistributedSessions true?) for
more intelligent error handling.
Chuck
Jonathan Rochkind wrote:
I never use cookies, and I've run into the bug, so it's not solely
related to cookies. Like I said, I never investigated it thoroughly.
But, if memory serves, the condition I observed it in was:
The WO app times out on a request, becuase it does not handle concurrent
requests, and some other request took an awfully long time to process.
So the adaptor decides, okay, I'm going to load balance, and send this
request to another instance. Of course, this is a component action
request, so can not be handled by any other instance. [This could be
considered a bug or mis-design in the adaptor load balancing to begin
with; I consider it so; but I'm not talking about that bug here]. So the
other instance gets this request, which has a sessionID in the URL that
in fact does not exist in this instance.
Yet for some reason, handlePageRestorationError is called, instead of
handleSessionRestorationError.
If memory serves, this is where I've seen the bug. However, I don't know
what makes this situation special. One would think it would be the same
as any other session restoration error, and if this condition is causing
the wrong handle() method to be called, one would think that ANY session
restoration error would cause the wrong handle() method to be called.
But I don't know if this is the case or not, I haven't investigated. I
would think that if handleSessionRestorationError were never called,
people would be making more noise about it, and we would all know about
it by now. But who knows, I haven't investigated.
Chuck's general understanding of the situation makes sense to me: that
handlePageRestoration is erroneously called when WO, for some reason,
creates a new session and then tries to handle a component action that
really belonged to some other session, in that newly created session.
When it shouldn't have created a new session, it should have called
handleSessionRestorationError. However, what conditions cause WO to do
this, instead of calling handleSessionRestorationError... remains a
mystery to me.
At 11:04 AM 8/7/2003 -0700, Chuck Hill wrote:
Yes, I've run into this before too and also forget the details. I
*think*
this only happens when the session ID is stored in cookies. In this case
WO silently creates a new session and then, using the contextID from the
URL, attempts to restore the page in the newly created session. That is
when handlePageRestorationErrorInContext is called when what really
happened as a session restoration error.
I recall some code to try to and detect this, but I can't place my
hands on
it. I think it just compared the wosid cookie value from the request
with
the current session ID in handlePageRestorationErrorInContext. If there
were not the same it would then return the result of
handleSessionRestorationErrorInContext. Otherwise it would treat it as a
real page restoration error (backtracking or URL hacking).
Chuck
At 11:18 AM 07/08/2003 -0500, Jonathan Rochkind wrote:
>WOApplication.handleSessionRestorationErrorInContext(WOContext c)
>
>is what you're looking for.
>
>Although I've noticed some bugs regarding when this method is called,
and
>when handlePageRestorationErrorInContext is called. It has seemed in the
>past that sometimes one of these is called when the other should be
called
>instead. I forget which direction the problem went, and exactly the
nature
>of it---I never really fully investigated it, it may be gone in the most
>recent versions. But be careful and make sure it's working the way it's
>supposed to, test it. But handleSessionRestorationErrorInContext is
>supposed to do what you want.
>
>--Jonathan
>
>At 11:48 AM 8/7/2003 -0400, Goodbye Bill wrote:
>>The page that is displayed by default when a session times out is
horrible!
>>Is there any way to display a customized page OR, better still, to
bounce
>>the user automatically back into a starting point?
>>
>>Thanx,
>>"Bill"
>>_______________________________________________
>>webobjects-dev mailing list | email@hidden
>>Help/Unsubscribe/Archives:
>>http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>>Do not post admin requests to the list. They will be ignored.
>_______________________________________________
>webobjects-dev mailing list | email@hidden
>Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>Do not post admin requests to the list. They will be ignored.
>
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.