Re: Lifebeat
Re: Lifebeat
- Subject: Re: Lifebeat
- From: Chuck Hill <email@hidden>
- Date: Tue, 4 Mar 2008 13:44:53 -0800
On Mar 4, 2008, at 1:18 PM, Valerio Luccio wrote:
Chuck Hill wrote:
Are you running with concurrent request handling turned off? Which
version of WO?
Chuck
WO 5.3.3. This is a Tiger machine, going to migrate to a Leopard and
WO 5.4 in a few weeks.
I'd hold off until at least 5.4.2 is out. Don't be in a rush to
migrate a server.
As for concurrent request handling ... you're testing the limit of
my knowledge, how do I control that ?
-WOAllowsConcurrentRequestHandling or the WOApplication method:
public void setAllowsConcurrentRequestHandling(boolean aValue)
The default is for this to be off. Note that turning it on can cause
problems in your application if you are not handling locking correctly.
Miguel Arroz wrote:
Hi!
You are trying to solve the problem in the wrong way. If you have
a long operation, you should do it on a separate thread, and use
WOLongResponse or the Ajax similar to handle the user interface.
That way, you won't have any problem with lifebeat.
Of course you're right Miguel, but this is an exceptional case, that
operation usually takes between 1 and 4 seconds and I didn't think
it was worth separate threads. I don't feel like making the changes
for something that has happened once in 3 years. If it happens more
often I'll have to do some re-design.
Chuck Hill wrote:
Hold on there, Valerio said:
That is wotaskd killing an unresponsive app, IIRC. The adaptor
timeouts should not affect this. I thought that the lifebeat came
through on a different request handler, but if it gets blocked by
having concurrent request handling off, that could explain this.
Valerio: WOLifebeatInterval controls how often the app is checked,
not how long wotaskd waits for a response.
I think we need more information: which version of WO, is
concurrent request handling on or off, what do you see in the app
log when it shuts down? Is the app running out of memory?
Chuck
OK, the WO version is above. I was under the impression that the
WOLifeBeatInterval was supposed to control how long to wait between
checks.
Yes, _between_ pinging wotasd. I don't recall what controls how
wotaskd waits before it kills the app.
Ah, here:
http://developer.apple.com/documentation/WebObjects/WOAppProperties/Articles/WotaskdProperties.html#/
/apple_ref/doc/uid/TP40004904
WOAssumeApplicationIsDeadMultiplier
integer
A multiplier used to calculate the number of seconds that the
wotaskd process waits without receiving a status message from an
instance before considering it dead.
This property is multiplied by the WOLifebeatInterval property to
calculate the total number of seconds wotaskd waits. For example, if
WOLifebeatInterval is 30, a wotaskd process waits 120 seconds from
the last status message before concluding that an instance is dead.
The default value is 4.
Note that this is set in the wotaskd properties:
/System/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/
Resources/Properties
That said, did it really take > 120 seconds to get a response?
The message in the log is:
Exception while sending response: java.net.SocketException:
Broken pipe
The program would shut down after exactly 30 seconds .... of course
today the operation is taking only 3 seconds so I cannot duplicate
the error. In case you're wondering about the disparity in response
time, the database is on a server that, over the years, has taken on
more and more tasks. I've already ordered another server to offload
all the file serving operations, but for the moment this baby had to
endure and yesterday it was very busy.
From http://developer.apple.com/DOCUMENTATION/LegacyTechnologies/WebObjects/WebObjects_5/DeploymentAdditions/monitorwotaskd.html
The lifebeat mechanism has been changed to improve reliability and
response times to changes of instance state. Lifebeats from
WebObjects applications are now sent over TCP sockets with a default
period of 30 seconds. 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. Lifebeats are of four types: has
started, lifebeat, will stop, and will crash. These types allow
wotaskd to be notified quickly of changes and enable the web server
adaptor to respond quickly. For example, if an application is
exiting normally, the 'will stop' lifebeat is sent from the
application to wotaskd. This is especially useful when scheduling is
used. See the Adaptor documentation for information on changes to
the web server adaptor since WebObjects 4.5.
Also
http://developer.apple.com/documentation/WebObjects/Deployment/Deploying_Applications/DeploymentElements/chapter_5_section_3.html
Unless it is going to cause a problem, launching with -
WOAllowsConcurrentRequestHandling true
Might be a quick and painless fix.
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
| References: | |
| | >Lifebeat (From: Valerio Luccio <email@hidden>) |
| | >Re: Lifebeat (From: Miguel Arroz <email@hidden>) |
| | >Re: Lifebeat (From: Valerio Luccio <email@hidden>) |