On 06.06.2010 03:52, Mohit Anchlia wrote:
On Sat, Jun 5, 2010 at 2:02 AM, Rainer Jung<rainer.j...@kippdata.de> wrote:
On 04.06.2010 01:30, Mohit Anchlia wrote:
In our present environment we have a WS and APP server. When request
comes in, WS sends it to APP server using mod_jk and then APP server
inserts it into JMS queue. So essentially APP server is also dependent
on JMS server which runs on the same box.
My question is can I use fail_on_status in worker.properties to take
one of the APP servers out of service from mod_jk(WS) by returning
some Http error code as a response to a request when JMS server is
down and a request comes in? Since cping and cpong will still return
success would this mechanism of fail_on_status work?
fail_on_status will trigger nevertheless. Otherwise it would be useless.
I didn't get this piece that fail_on_status will trigger nevertheless?
My understanding is that cping and cpong decide if to keep a worker in
error state or not. But http response code will be returned only when
http request comes in. To cping and cpong server is still up. So even
if app server return status same as configured for fail_on_status
cping and cpong will still not bring the worker in error state.
cping and cpong themselves don't bring the worker in error state. There
are several mechanism involved to detect feilure and each of those
mechanisms can bring worker into error state by itself. Once the worker
is in error state, it will not be used for 60 seconds and then retried
with the next request eligible for it. If that requests triggers some
error condition again, the worker will stay in error state, otherwise it
will be back to normal.
So if cping/cpong succeed, and later during processing of the same
request an error occurs, like e.g. triggered by fail_on_status or
reply_timeout or whatever else is configured, the worker will be put
into error state.
If you still doubt it: try it! Writing a simple servlet or JSP returning
some error status is easy and you can see what's happening.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
