Re: Lifebeat
Re: Lifebeat
- Subject: Re: Lifebeat
- From: Chuck Hill <email@hidden>
- Date: Tue, 4 Mar 2008 14:56:08 -0800
On Mar 4, 2008, at 2:47 PM, Art Isbell wrote:
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.
The documentation says:
If the application is multithreaded the lifebeats will be sent from
their own thread; otherwise, a timer in the main run loop will send
them.
See http://developer.apple.com/DOCUMENTATION/LegacyTechnologies/WebObjects/WebObjects_5/DeploymentAdditions/monitorwotaskd.html
I am too busy to check this out and I always run multi-threaded so I
don't know if the docs are accurate for 5.3.3 or not. If they are,
and Valerio is not running multi-threaded, that might explain what he
is seeing.
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.
Yes, that is what I see with multi-threading (concurrent dispatch).
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 :-)
That is another area in the docs that could use some expansion.
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).
I agree. I don't think that is directly related to the life beat issue.
Chuck
--
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