Is there a way to configure ping in workers.properties to also check for 503 in addition to cping/cpong? I am sure you are going to laugh at me. On Mon, Mar 2, 2009 at 1:26 PM, Rainer Jung <rainer.j...@kippdata.de> wrote: > On 02.03.2009 20:28, Mohit Anchlia wrote: >> >> I will change the JkLogLevel and post the results. I have a question >> though: Does prepost_timeout also detect if it received http code such >> as 503 from app server. > > prepost_timeout activates Cping/Cpong before each request. mod_jk will send > a tiny test packet to the ap server before each request, and the AJP > protocol stack of the app server will immediately respond with a tiny reply > packet, indicating that it is still alive and able to parse AJP messages. > The web application itself is not involved in this part of the processing, > neither is any http request or response (or their AJP equivalent). > > So prepose_timeout will detect, if it receives some garbage (anything > different from a Cpong packet), but http responses with http status codes > are only generated much later and will thus not influence the prepose > Cping/Cpong result. > > See also: > > http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html > > Regards, > > Rainer > >> On Wed, Feb 25, 2009 at 9:05 AM, Rainer Jung<rainer.j...@kippdata.de> >> wrote: >>> >>> On 25.02.2009 17:10, Mohit Anchlia wrote: >>>> >>>> you are right there is a mod-jk.conf. So given my workers.properties >>>> file what should I change so that mod_jk detects that app server is >>>> down before attempting to send the request. Shouldn't "retries" in >>>> workers.properties try to connect to some other app server instead. >>> >>> Just a wild guess: your prepost timeout of 5 milliseconds produces the >>> error >>> messages you cited. First correct this timeout, then do another clean >>> test >>> on your test system. You can even increase JkLogLevel to trace (not in >>> production) so we can see exactly what is going on. Do not send many >>> requests with JkLogLevel trace, just do a minimal test that shows the >>> problem. >>> >>> The early detection of a broken instance should be possible with your >>> configuration. >>> >>>> Here is mod-jk.conf >>>> >>>> # Where to find workers.properties >>>> JkWorkersFile conf/workers.properties >>>> >>>> # Where to put jk logs >>>> JkLogFile /var/log/apache2/mod_jk.log >>>> >>>> # Set the jk log level [debug/error/info] >>>> JkLogLevel error >>>> >>>> # Allow mod_jk worker status reports, with the URL of >>>> http://servername/JkStatus >>>> ## This is very helpful for monitoring purposes, but should be >>>> ## allowed from the local machine. >>>> <Location /JkStatus> >>>> Order deny,allow >>>> Deny from all >>>> Allow from localhost >>>> </Location> >>>> >>>> #JkMount /JkStatus status >>>> >>>> # Below line forward all requests to application server >>>> #JkMount /* local >>>> >>>> >>>> On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung<rainer.j...@kippdata.de> >>>> wrote: >>>>> >>>>> On 25.02.2009 02:47, Mohit Anchlia wrote: >>>>>> >>>>>> In httpd conf I just see JkMount and no other directive. I searched >>>>>> for >>>>>> Jk. >>>>> >>>>> There should be others as well, for instance JkWorkersFile to point to >>>>> your >>>>> workers.properties. The names of the directives are case insensitive, >>>>> they >>>>> can also be in files included to your main httpd configuration file via >>>>> include directives. >>>>> >>>>>> Here is workers.properties file: >>>>> >>>>> ... >>>>>> >>>>>> # appfe1 >>>>> >>>>> ... >>>>>> >>>>>> worker.appfe1.socket_timeout=5 >>>>> >>>>> I generally don't like socket_timeout. Others do :) >>>>> >>>>>> worker.appfe1.prepost_timeout=5 >>>>> >>>>> 5 milliseconds prepost timeout? You're kidding. I assume it should have >>>>> been >>>>> 5000. >>>>> >>>>>> worker.appfe1.recycle_timeout=900 >>>>> >>>>> This is deprecated. Use connection_pool_timeout instead. The value is >>>>> OK, >>>>> you should set connectionTimeout on the Tomcat AJP connector to 900000 >>>>> then. >>>>> >>>>> Since you are using prefork MPM, you might want to set >>>>> connection_pool_minsize to 0 if you want to keep the number of >>>>> established >>>>> connections low. >>>>> >>>>> And the same for the other members of the load balancer. >>>>> >>>>>> On Tue, Feb 24, 2009 at 4:50 PM, Rainer Jung<rainer.j...@kippdata.de> >>>>>> wrote: >>>>>>> >>>>>>> On 25.02.2009 00:00, Mohit Anchlia wrote: >>>>>>>> >>>>>>>> Reposting: >>>>>>>> >>>>>>>> Apache Server - 2.2 >>>>>>>> Tomcat server 6 >>>>>>>> Jboss - 4.2 >>>>>>>> >>>>>>>> We have Web Servers talking to Jboss App Servers over mod_jk. When >>>>>>>> we >>>>>>>> do our patch or upgrade of software we do it in rolling fashion so >>>>>>>> that there is "0" customer impact. But it looks like mod_jk load >>>>>>>> balancer on Web server doesn't detect it as soon as Jboss App Server >>>>>>>> goes down. Our goal is to have 0 customer impact. So my question is >>>>>>>> what can we do to overcome this problem. Web Server sees Http Error >>>>>>>> Code 503. >>>>>>>> >>>>>>>> Information from log file: >>>>>>>> >>>>>>>> [Mon Feb 23 13:39:42.146 2009] [31682:4143745888] [error] >>>>>>>> ajp_connection_tcp_get_message::jk_ajp_common.c (966): (appfe4) >>>>>>>> can't >>>>>>>> receive the response message from tomcat, network problems or tomcat >>>>>>>> (10.10.81.89:8009) is down (errno=104) >>>>>>>> [Mon Feb 23 13:39:42.147 2009] [31682:4143745888] [error] >>>>>>>> ajp_service::jk_ajp_common.c (2097): (appfe4) Connecting to tomcat >>>>>>>> failed. Tomcat is probably not started or is listening on the wrong >>>>>>>> port >>>>>>> >>>>>>> This means that mod_jk detected that your backend is down and thus >>>>>>> puts >>>>>>> it >>>>>>> into an error state. All following requests will no longer be sent to >>>>>>> this >>>>>>> backend. Once a minute it will send a request there and try, but as >>>>>>> long >>>>>>> as >>>>>>> it is down this test will not succeed and thus all requests will be >>>>>>> sent >>>>>>> to >>>>>>> other nodes. >>>>>>> >>>>>>> The first request that gets sent to the backend you stopped might get >>>>>>> an >>>>>>> error back. If you want to prevent that from happening, use >>>>>>> Cping/Cpong: >>>>>>> >>>>>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html >>>>>>> >>>>>>> so we will detect the broken node before actually sending a request >>>>>>> there. >>>>>>> More details are not possible to give without your JK configuration >>>>>>> (Jk >>>>>>> directive sin httpd configuration files, workers.properties and if >>>>>>> used >>>>>>> uriworkermap.properties). >>>>>>> >>>>>>> The line number of the above message tells me you are using mod_jk >>>>>>> 1.2.25. >>>>>>> Although there's nothing wrong in principal with 1.2.25, we always >>>>>>> try >>>>>>> to >>>>>>> improve and you might consider switching to 1.2.27. >>>>>>> >>>>>>> You should also increase your JkLogLevel to info. As long as only >>>>>>> occasional >>>>>>> info messages are in your log file everything is fine, but once error >>>>>>> messages show up, the additional info messages contain useful >>>>>>> formation. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Rainer > > --------------------------------------------------------------------- > 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
