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?
I'm guessing that even using a WOLongResponse page would not fix this
problem. Would that be correct? Same would go for concurrent request
handling right?
On Mar 4, 2008, at 4: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.
As for concurrent request handling ... you're testing the limit of
my knowledge, how do I control that ?
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. 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.
--
Valerio Luccio (212) 998-8736
Center for Brain Imaging 4 Washington Place, Room 156
New York University New York, NY 10003
"In an open world, who needs windows or gates?"
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/robert.walker%
40bennettig.com
This email sent to [EMAIL PROTECTED]
Robert Walker
[EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
