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 <fredk2@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.Geldenhuis@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Locked
