Good point concerning the id. I'm already thinking about a couple of changes to the status worker, especially the URLs it uses and the missing parameter validation. So it's not totally unlikely, that we will have a 1.2.20 release this year inclusing better support for automating status worker actions.
Missing answer: if there is no http body in the request, and the announced content length is bigger than zero, I can imagine three cases: 1) The connection is being closed by the tomcat side. This will be detected as an error. 2) You've got a reply_timeout and you run into the timeout. This will be detected as an error. 3) You've got no reply_timeout and the connection is kept alive, but no packet returned. I guess, this will just keep apache reading. I'm not sure, if the 300 seconds timeout of apache works in this case, and what will happen, after you run into this timeout. If your observations differ from my predictions, let me know :) Regards, Rainer Sharma, Siddharth schrieb: > Hi Rainer > Thx for the response. > > What does "missing answers" mean? > If there is no http body, will it be marked down? > > Yea, I figured that status is probably the best way to do it. > I already have status configured and I figured out the request parameters. > Only complication is the "id" parameter. > Even if I provide the "w" parameter as the worker name, it does not update > its status unless the 'correct' "id" value is provided. > "id" value seems to be a positional index of the worker in the configuration > or something. > This sort of sucks for me because my coding will not be straightforward and > I will have to maintain the mapping of worker name and id. > > > > -----Original Message----- > From: Rainer Jung [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 07, 2006 3:58 PM > To: Tomcat Users List > Subject: Re: Load balancing mark down question > > Hi, > > Sharma, Siddharth schrieb: >> Hi >> >> We have a cluster of Linux (RedHat) machines each housing an apache, 4 >> tomcat instances and 4 other jvms that run our custom servers. >> Each tomcat has a corresponding custom server that it delegates requests > to. >> In other words, there is one to one correspondence between a tomcat > instance >> and a custom server instance. >> Problem is that when a custom server crashes and its tomcat is still >> accepting, mod_jk does not mark it down. Consequently users continue to be >> directed to that tomcat even though they are experiencing errors. >> In mod_jk, we have defined a load balancing worker that fronts the 4 > tomcat >> workers. >> So questions are: >> >> 1. On what basis does mod_jk mark a tomcat worker down? Is it http return >> codes? > > Never http return code. jk detects communication failures betwenn apache > and tomcat: > > - timeouts > - connection problems > - missing answers > - client (browser) aborts > >> 2. Some load balancers allow scraping of the http body to see if there is > an >> error in addition to relying on http codes. Is that possible in mod_jk? Is >> it configurable? > > No. You need to do that externally. > >> 3. Is it possible to stop|start a mod_jk worker via an http call? Or some >> other programmable way? > > Yes. Configure a status worker: > > worker.list=admin > worker.admin.type=status > > The name of the worker (here: admin) is arbitrary. > Map the worker to a url in your web server, e.g. using JkMount in > Apache. Add access control to the URL (using web server methods). > > Then open the URL in your browser and get used to its features. You can > click on the individual worker members of a balancer and a form will pop > up, allowing to disable (no more new sessions) or stop (no more > requests) this worker. The request when sending the form is a GET > request, so you can learn the URL syntax easily. > > Be careful: these changes are not persistant. Apache restart, even > graceful, throws you back to your config file settings. > > Regards, > > Rainer > >> Any ideas on how to solve this problem? >> >> Thanks >> Sidd >> >> --------------------------------------------------------------------- >> To start a new topic, e-mail: users@tomcat.apache.org >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
