Am 11.12.2008 16:46, schrieb Nuno Manuel Martins:
Sorry to come up in the middle of a discussion, but how does the
worker recover after the 500 error? Does it have to be reset manually
or does it recheck from time to time (how long?) if the server is
available again?
During so called global maintenance mod_jk flags an erroneous worker
that is in error state for longer than 60 seconds (configurable) to be
"in recovery" (REC). The next request, that would get balanced to a
worker "in recovery" then actually gets sent to it and the worker is
immediately flagged as being "probed" (PRB).
If the probe succeeds, it goes into OK state, if not back to ERROR.
Global maintenance runs roughly every 60 seconds (the first request that
comes in at most 60 seconds after the last global maintenance triggers
the next one).
Since we now have a separate watchdog thread, we will likely allow a
concurrent probing with a configurable test URL in a future mod_jk version.
Caution: by default http status 500 does *not* put a worker into ERROR.
Only if configured using fail_on_status as was assumed earlier in this
discussion.
Regards,
Rainer
-----Original Message----- From: Rainer Jung
[mailto:[EMAIL PROTECTED] Sent: terça-feira, 9 de Dezembro de
2008 13:45 To: Tomcat Users List Subject: Re: Can not fail over a web
service call using mod_jk
[EMAIL PROTECTED] schrieb:
From a design point of view do you feel that this is beyond the
scope of mod_jk to buffer request bodies? From one point of view it
does make sense to have the retry logic completely in mod_jk, but I
can certainly understand the point of view to have retry logic on
the client.
Not completely, but it would be a serious problem to buffer the full
request bodies by default. Imagine someone who does upload a DVD iso
image. So it's much safer (with respect to ressource consumption) to
only buffer a first chunk for the usual case, that a problem is
detected early.
It could be an option though, to buffer requests with a configurable
limit depending on the URL. It would not be to hard to implement
that, but the whole thing gets more and more complex. It might make
more sense to extract a thing like this into a separate httpd module
(mod_replay) (I'm just speculating).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
