Re: Lifebeat
Re: Lifebeat
- Subject: Re: Lifebeat
- From: Art Isbell <email@hidden>
- Date: Tue, 4 Mar 2008 12:47:17 -1000
On Mar 4, 2008, at 11:55 AM, Chuck Hill wrote:
On Mar 4, 2008, at 1:34 PM, Robert Walker wrote:
In the case that the delay is caused by the connection to the
database, would the instance lock waiting on the response? Isn't
the EOF stack essentially single threaded anyway?
Yes, unless the app has multiple EOF stacks and concurrent request
handling.
I'm guessing that even using a WOLongResponse page would not fix
this problem. Would that be correct?
WOLongResponse page would not fix blocking in the serialized EOF
access of the database, but it would provide user feedback that at
least something is happening and that the app probably isn't hung.
Same would go for concurrent request handling right?
Right, unless the app has multiple EOF stacks.
The WOLongResponse page would free up the request dispatch loop
which should result in the lifebeat getting sent.
I'm pretty certain that I have seen a lifebeat thread in WO app
thread dumps. If so, blockage in the request dispatch loop shouldn't
affect the timely sending of the lifebeat.
This might explain why a deadlocked WO instance (meaning the request
dispatch thread is deadlocked) continues to receive requests from the
WO HTTP adaptor which thinks the instance is still alive because the
instance is still sending lifebeats from its (not deadlocked) lifebeat
thread. As more requests are dispatched but not processed, the number
of adaptor threads increases to the maximum number configured before
the instance refuses new requests. This is good reason to set the
maximum number of adaptor threads to a low number since these requests
will never be processed.
A lifebeat is sent repeatedly by each instance to wotaskd. When
wotaskd realizes that it has not received X (defaults to 4, I believe)
lifebeats from an instance, it marks the instance as dead until it
starts receiving them again. The WO HTTP adaptor learns of the
instance death when it refreshes the WO configuration and quits
dispatching requests to the dead instance. (Something along those
lines, anyway :-)
I think it is the stall in the RR loop that is causing the problem.
Of course other user requests would get stalled so one problem may
get replaced by another.
The "Exception while sending response: java.net.SocketException:
Broken pipe" log entry suggests that an adaptor timeout has occurred
(although this log entry can also occur when the user cancels a
request before the response is received, I believe).
Aloha,
Art
_______________________________________________
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