Hi,
On 10.03.2009 19:47, Mohit Anchlia wrote:
I am currently testing this. Hoping this will help us achieve 0
customer impact when we upgrade our system.
Is it possible for mod_jk to check 2 ports to determine if that worker
should be out of service? For eg: if 8010 is down but 8009 port is up
then bring that worker out of service? But the data port will continue
to be 8009. Here is the problem, to successfully receive the traffic
we have 2 dependencies 1. App server (port 8009) and 2. Queue server
(port 8010). If anyone of those servers are down then we can't receive
the traffic. But mod_jk only knows about 8009.
No, mod_jk only knows about Tomcat AJP connectors. If you wat to
coordinate a bigger more complex system, you need to do this externally.
mod_jk only provides you with information about the state of the part of
the system it knows (the configured Tomcat AJP connectors, e.g. workers)
and it provides entry points to change the configuration state, e.g.
switching activation via status worker.
The rest is up to you :)
Regards,
Rainer
On Fri, Mar 6, 2009 at 2:02 PM, Rainer Jung<rainer.j...@kippdata.de> wrote:
On 06.03.2009 21:42, Mohit Anchlia wrote:
In addition to questions that I have in below email, I have couple of
question.
1. activation property disable - Does it first turn off new requests
to that worker and then disable the worker after finishing old
requests. So is this the best way to see 0 customer impact?
2. activation propery stopped - Does it throw away existing sessions
and also stop taking new requests.
Please read about activation on
http://tomcat.apache.org/connectors-doc/reference/workers.html
Stopped: do not allow any requests being send to the worker.
Disabled: Only requests which carry a session, that is sticky on the worker
will go the the worker. No other requests will be send there.
Use "disable" to dry out a worker, use "stoppped" directly before you
actually want to take it out of production.
Also I couldn't find way to see how mod_jk is behaving in the log
file. I turned tracing on for JkLogLevel.
I don't know what you mean by "behaving".
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
