On 7/26/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
At least concerning thi spoint we devs had no confusion. The docs under
dist have been updated when 1.2.18 has been put on dev:
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/config/workers.html
Yes, it appears that I am the one confused! I think that perhaps some
real-live examples of what happens would be useful.
Let's see if I understand recover_time and worker.maintain now by
reading the docs. By default worker.maintain and recover_time are both
set to 60. This means that a minimum of 60 seconds must pass before a
worker even has it's recover_time checked. If the recover_time has
elapsed, the worker is put into recovery mode and new connection
attempts are tried. If the new connection attempt is successful, OK,
if not, recover_time is reset and you need to wait until the next
worker.maintain interval.
During my testing, what I found interesting is that when a worker went
into error state, the worker.maintain time seemed to get reset, as if
I had recover_time set to 10s and worker.maintain set to 60s,
depending on when in the maintain cycle the worker went into error
state, I should see the worker put into recovery mode as early as 10s
and as late as 60s depending on timing. Is that true?
Do not set recover_time to a very short time unless you understand the
implications. Every recovery attempt for a worker in error is done by a
real request!
I still fail to see the problem with significantly lowering
recover_time (which is mostly not used because of the apparent
worker.maintain reset when an error errors), especially if you have
appropriate connect/prepost timeouts. What am I missing?
Thanks,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
