> 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 ?
In this case, I want apache to treat the request as DECLINED by mod_jk, so that if we put some static content in apache at this place, it will be served at least until tomcat is ready again. Which means, if we can test tomcat's availability before sending it the actual request, we can DECLINE the request if necessary, and thereby apache will serve it if it can. awarnier wrote: > > 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 > > > -- View this message in context: http://www.nabble.com/mod_jk-tp21856049p22194805.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
