Re: Instance ID wrong?
Re: Instance ID wrong?
- Subject: Re: Instance ID wrong?
- From: Chuck Hill <email@hidden>
- Date: Tue, 2 Dec 2008 11:08:13 -0800
On Dec 2, 2008, at 4:54 AM, Anjo Krank wrote:
Am 02.12.2008 um 12:09 schrieb Patrick Middleton:
I too have encountered the problem where a stateful request is
redirected to a different instance because the requested instance
did not respond, and I would strongly welcome an HTTP header or
headers being added to indicate to instance the instances which
have already not responded to this request.
First of all, as this is a real deployment error, it should be
monitor-able somewhere. Probably at the WOAdaptorInfo page or a log
file.
Or on the instance page the same way that deaths are shown? Maybe an
icon for "Unresponsive", a count of "Assumed Death".
Also, I'd have guessed that the only reason an app doesn't respond
is that has maxed out the thread pool or sth? When IS it marked
dead? By the Adaptor or wotaskd?
IIRC, the woadaptor first marks it as "unresponsive" and then waits.
Later it will try it again. If that fails (or maybe it is the third
time), it gets marked as dead. I don't recall if it bothers to tell
this to wotaskd. That would certainly be a useful thing for it to
do. wotaskd could then restart it the same as when an instance stops
responding to the heartbeat. Or am I just imaging that it does that?
That this happens at our sites may also be a network issue that I'm
not aware of.
Or it could just be your bad code. ;-)
The requested instance (or instances) usually doesn't respond
because it's doing a very big database fetch; enabling concurrent
request handling usually won't help much as other sessions will
likely block waiting for access to the database. lifeabeat
interaction with wotaskd should continue unimpeded.
When is the lifebeat sent? I thought it was sent regardless of app
state?
I was going to guess at the end of an RR loop.
How would an instance receiving a stateful request whose URL
indicates it should be sent to a different instance make use of
some X-WOInstanceDidNotRespond header then? How would the instance
know whether the other instance(s) are busy but not dysfunctional,
have hung, or have crashed?
This would be the next step. Maybe it could simply redirect the
request with some counter attached. Only if it reaches a max, the
request is indeed handled by the other instance.
In the meantime, the user could be shown a page stating that there is
a problem and to be patient. Granted, they probably won't be patient...
If we really wanted to sort this out, we might be looking at
persistent session state shared over all instances, so that any
instance could respond to any request, whether stateless or
stateful. I would not welcome being asked to implement that myself.
Me neither, and I'm not sure this is possible at all - at least if
you are using WO like it's supposed to be, meaning component actions
and a lot of new ECs. Otherwise, you could simply write a DA app and
only use basic types to store in the session. In that case it should
be halfway easy to implement, but then why use WO in the first place.
It is fairly easy in the naive way: just serialize the entire session
and write it to the database at the end of every request. This will,
of course, totally kill performance and is generally unworkable. If
you could do this in deltas, it might be better. I have heard of at
least one implementation of session failover for WO, but it is
private. So it is possible, but I don't know what restrictions were
in place.
Chuck
--
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
_______________________________________________
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