Mohit Anchlia wrote:
Sorry I am little confused about couple of things:
1. Based on what I read it looks like workers.properties is not loaded
dynamically. And JkMountFileReload doesn't work for worker.properties
but it works for uriworkermap.properties.
Correct, that is what was said.
In clear it means that you can to a certain extent dynamically change
the URI's that will be redirected to Tomcat, but you cannot change the
kind of properties that are in workers.properties (the address of the
back-end Tomcats etc..)
2. Wouldn't setting prepost timeout ensure that a check is made to see
if remote machine is up before forwarding the request?
Yes.
But if you have only one Tomcat to send requests to, then all this tells
you is that this Tomcat is not responding. So now what do you do ?
I'll use an image : finding out that the back-end Tomcat does not even
respond to a ping, rather than sending the whole request and getting an
error then (which is more time-consuming), is a way to know faster that
there is a problem. But you still have this hot client request in your
lap, so now what do you do with it ?
If you have 2 or more Tomcats, then it really helps, because mod_jk can
redirect the request to a Tomcat which still works. But if there is
only one anyway, you're cooked.
On Fri, Feb 6, 2009 at 11:01 AM, fredk2 <fre...@gmail.com> wrote:
Hi Rainer,
your comment about the watchdog sounds interesting. When you load balance
it would seem useful to get feedback from Tomcat itself about its load so
that the module can adjust dynamically its load (lbfactor) based on the
Tomcat's performance rather than a session/socket count. One can wonder if
such added complexity would be detrimental to the mod_jk stability.
Rgds - Fred
Rainer Jung-3 wrote:
On 06.02.2009 18:23, André Warnier wrote:
gerhardus.geldenh...@gta-travel.com wrote:
1) As far as I know, no, mod_jk does not read workers.properties
dynamically.
2) Yes and no, it will not send a request unless communication has
been
established with the worker, it may happen that the worker fails, or
someone shut it down. Depending on how you configure the workers and
the
number of workers, it can retry the request and/or try a different
worker. Mod_jk will mark the worker on error when it does not respond,
and it will try again after a configurable time -but it tries again
with
an actual request-.
It would be really nice if you could test availability of a node with a
configurable request instead of a live production request... (hint,
hint)
Isn't that what "ping" is about ?
Ping tests, whether there is something able to still process AJP on the
other side of the connection. A configurable request would be able to
talk to the application, so one could detect, whether it is still
deployed, and if the request would be handled by an intelligent servlet
it could respond with some sort of application layer health status.
Worth filing an enhancement request, since Mladen put the Watchdog
thread into 1.2.27, we can easily add more logic of that type.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
View this message in context:
http://www.nabble.com/mod_jk-tp21856049p21878692.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
