Re: mod_jk not working !!
Dear All, Thanks for your suggestions and your valuable time... next time i post questions,i ll take care of the proper things . i ll try to work on your suggestions and then come back to you people . Thanks Aman Arora
Re: mod_jk not working !!
That's strange. It's working fine for many other people, on thousands of websites. Maybe it is your configuration that is not working ? is not working !! is about the best subject that can be imagined, if your intention was to not get any response at all. The only missing parts are capitals and the word URGENT. And if you believe that anyone is going to walk through the hundreds of lines of your configuration files, trying to figure out what you did wrong, then you have a surprise coming. You really need to read this : http://www.catb.org/~esr/faqs/smart-questions.html When you have read it, post another message to the list, with a better subject and the /relevant/ parts of your configuration, and maybe someone will feel like helping. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk not working !!
From: Aman Arora aman.arora...@gmail.com To: users@tomcat.apache.org Sent: Thursday, May 24, 2012 10:25 PM Subject: mod_jk not working !! m trying to do a setup of tomcat clustering in which one tomcat is on port 8080 and other one is on 8081. i have downloaded the tomcat-connector in the modules folder of my apache.i built it using build-unix.sh by downloading the script from net as it was nt already there in the downloaded tomcat-connector. it buit mod_jk.so which i have placed inside modules folder as /usr/local/apache2/modules/mod_jk.so then i created workers.properties file and gave the description of workers there .and included it in httpd.cong file . still when i type http://localhost/jsp-pages which are in my webapps / it is not passing requast to tomcat which is holding the js pages. you may hav a look at the conf files to get a better fel of the problem ! the link is http://www.coderanch.com/t/581294/Tomcat/Tomcat-Clustering#2648034 OK, I've taken a brief look at your configuration files (httpd.conf, mod_jk.conf, server.xml, workers.properties). I've also taken a brief look at the Safari Books link you gave. As Andre said (sorry about the lack of accent, Andre), people are going to be a bit reluctant to wade through all of that material and provide pointers. Also as Andre has said, clustering Tomcat on the same machine works fine for many people. I routinely use a 3 or 4 node cluster as a test platform. I'll try to give a few general directions. As is my usual practice, this is going to be long. You have been warned. General thoughts In your Code Ranch postings, you state that you are new to Linux. Getting clustering to work on Linux involves Apache HTTPD configuration, Tomcat configuration, and Linux configuration. If this is your first time doing all of this, it's probably best to get a simple mod_jk connection working first. At each stage of the setup, I recommend testing and coming back to the mailing list with simple questions and the relevant portion(s) of the configuration file(s). Also, be prepared to do at least as much work as those people trying to help. Remember, this is a volunteer list, and we contribute in our spare time. Also, as another aside . . . there is a lot of misleading, incomplete, and just flat wrong information concerning Tomcat floating around on the 'net. The authoritative source for information is always: http://tomcat.apache.org/ The mailing list for questions is this mailing list. We try to give accurate information, and some people here have been working with Tomcat for a very long time. You might get accurate information elsewhere, but from what I've seen this is not very likely. Linux in General You'll find that Linux is a different beast than Windows (even Windows 7). In particular file permissions, file ownerships, and SELinux present quite a different security model than the typical Windows installation. It's best to be aware of this from the start. Purpose === What is the purpose of this setup? If you're running a pseudo-production development platform, then what you're setting up may be reasonable. If you're setting up a development platform with NetBeans or Eclipse, then you will run into a lot of file access problems with your setup. If you're setting up a development system, I recommend just creating a directory in your home directory to hold a single Tomcat, unpack Tomcat 7.0.27 in that directory, edit $CATALINA_HOME/conf/tomcat-users.xml per the instructions, and then use that installation. http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Configuring_Manager_Application_Access Once it's running and you can access the manager application, then associate the installation with your IDE. Now you can develop, debug, test, and deploy without running into permission issues. If you're setting up a pseudo-production environment, then it's probably a good idea to set up a service account, install (and control) all Tomcats from that account, and connect those Tomcats to Apache HTTPD (or not). Note that since this is a separate account, this is a bit less convenient for development. Apache HTTPD I noticed that you have a lot of /usr/local based directories in your Apache HTTPD configuration. This is quite unusual for Linux, since most (all?) Linux distributions package Apache HTTPD. Rather than building your own Apache HTTPD, I recommend that you get and install the distribution package for Apache HTTPD. This will place files in line with the rest of your system, and it will also have a serviceable default configuration. On Fedora, the Apache HTTPD packages include: apr apr-util apr-devel apr-util-devel httpd httpd-devel httpd-tools The -devel packages are very important, since you will be building mod_jk from source. Java I from your messages that you have Oracle's Java installed. Make sure
Re: mod_jk not working !!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aman, On 5/25/12 1:25 AM, Aman Arora wrote: I'm trying to do a setup of tomcat clustering in which one tomcat is on port 8080 and other one is on 8081. Sounds reasonable. i have downloaded the tomcat-connector in the modules folder of my apache.i built it using build-unix.sh by downloading the script from net as it was nt already there in the downloaded tomcat-connector. What is build-unix.sh and why did you have to download it from [the] net? Other than apxs (which implies you have the httpd dev tools available), you don't need anything else to build mod_jk for your environment. Read the README.txt file in the root of the tarball and follow the directions. it buit mod_jk.so That's good. Since I don't know what build-unix.sh does, I'm happy it didn't delete your kernel. which i have placed inside modules folder as /usr/local/apache2/modules/mod_jk.so then i created workers.properties file and gave the description of workers there What's in there (see below)? .and included it in httpd.cong file . How? still when i type http://localhost/jsp-pages which are in my webapps / it is not passing requast to tomcat which is holding the js pages. What do you get in the response instead? you may hav a look at the conf files to get a better fel of the problem ! the link is http://www.coderanch.com/t/581294/Tomcat/Tomcat-Clustering#2648034 So I have to follow one link to get to 4 other links? For those less-willing to put up with this kind of crap, here's the important part of httpd.conf: Include /usr/local/apache2/conf/mod_jk.conf (*Not inside a VirtualHost definition*) Here's the mod_jk.conf: LoadModule jk_module /usr/local/apache2/modules/mod_jk.so JkWorkersFile /usr/local/apache2/conf/workers.properties JkLogFile /usr/local/apache2/logs/mod_jk.log JkLogLevel info #JkMount /sample/* loadbalancer #JkMount /* loadbalancer JkMount /examples/*.jsp default And finally, here's the workers.properties: workers.tomcat_home=/usr/local/tomcat/apache-tomcat-7.0.27/ workers.java_home=/usr/java/jdk1.7.0_04/ ps=/ worker.list=tomcatnode1, tomcatnode2, loadbalancer worker.tomcatnode1.port=8009 worker.tomcatnode1.host=localhost worker.tomcatnode1.type=ajp13 worker.tomcatnode1.lbfactor=1 worker.tomcatnode2.port=8010 worker.tomcatnode2.host=localhost worker.tomcatnode2.type=ajp13 worker.tomcatnode2.lbfactor=1 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=tomcatnode1, tomcatnode2 worker.loadbalancer.sticky_session=1 So, I can see a bunch of problems. Let's start at the top. 1. You put your JkMount directives in your mod_jk.conf file, which is included in your the top-level httpd.conf file. Your JkMounts will not be copied into your VirtualHosts and so you essentially have no mappings at all. 2. You are mapping /examples/*.jsp and trying to access /jsp-pages, so that's not going to work. 3. You are mapping /examples/*.jsp to the default worker, which has not been defined. 4. You have an old mod_jk config that contains these irrelevant settings: workers.tomcat_home, workers.java_home, ps 5. You have defined your 2 node workers to be on ports 8009 and 8010 but you said that you have your Tomcats running on 8080 and 8081. Perhaps you have AJP/1.3 connectors defined for 8009 and 8010 but I'm not going to enter /yet another/ CAPTCHA just to see your configuration files which I'm sure are completely full of comments and other crap I don't feel like reading. I suspect that #1, #2, and #3 are your real problems. Fix those and try again. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+/tQIACgkQ9CaO5/Lv0PAqXQCeLCHjYQAtRJH8FQ78+x9e0xf4 v1gAoJLdYNCS/HErJbQr2bm47AUYSczC =y+SX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk not working !!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 5/25/12 12:26 PM, Mark Eggers wrote: . . . just my three cents (since this is long) More like twelve bucks: you should send this guy a bill for the message you just put together for him. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+/tT4ACgkQ9CaO5/Lv0PDYhQCcDgYU8IJzIwqd0toPoJPk+UMK 5lEAoJbcKTc3l4wl9UWBLyOVd9qhaczv =Ly2T -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: mod_jk not working !!
From: Mark Eggers [mailto:its_toas...@yahoo.com] Subject: Re: mod_jk not working !! I'll try to give a few general directions. much useful content snipped Again, start simply. 1. Stock Apache HTTPD installation (and verify) 2. Stock Apache Tomcat installation (and verify) 3. mod_jk installation (and verify) 4. Second Apache Tomcat installation (and verify both) 5. Cluster I'd suggest that your entire e-mail should be put in the Wiki. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk not working !!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 5/25/12 12:41 PM, Caldarale, Charles R wrote: From: Mark Eggers [mailto:its_toas...@yahoo.com] Subject: Re: mod_jk not working !! I'll try to give a few general directions. much useful content snipped Again, start simply. 1. Stock Apache HTTPD installation (and verify) 2. Stock Apache Tomcat installation (and verify) 3. mod_jk installation (and verify) 4. Second Apache Tomcat installation (and verify both) 5. Cluster I'd suggest that your entire e-mail should be put in the Wiki. +1, though maybe in smaller pieces linked by a top-level page. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+/ufQACgkQ9CaO5/Lv0PBvzQCeM/ugajKLsv3od//91wc3WcKP /X4AoJztvRXa1d6lMYdHSbPiiT5WDPIF =nBVy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk not working !!
From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2012 9:57 AM Subject: Re: mod_jk not working !! -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 5/25/12 12:41 PM, Caldarale, Charles R wrote: From: Mark Eggers [mailto:its_toas...@yahoo.com] Subject: Re: mod_jk not working !! I'll try to give a few general directions. much useful content snipped Again, start simply. 1. Stock Apache HTTPD installation (and verify) 2. Stock Apache Tomcat installation (and verify) 3. mod_jk installation (and verify) 4. Second Apache Tomcat installation (and verify both) 5. Cluster I'd suggest that your entire e-mail should be put in the Wiki. +1, though maybe in smaller pieces linked by a top-level page. - -chris If this goes up on the Wiki, then smaller pages organized by task would be good. It would probably help if the Wiki pages had a lot of detail, and cross-reference the appropriate documentation on the Tomcat web site as well. I've been meaning to write this up for some time, so maybe I'll get started on it this weekend. Since this is going to take a bit of time, is there a place on the Tomcat Wiki that I can write but not have it published (may be a developer list question). If not, then I'll write locally and then do a cut / paste. However, it would be nice to have feedback during the writing process. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk not working !!
On 25 May 2012, at 19:21, Mark Eggers its_toas...@yahoo.com wrote: From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2012 9:57 AM Subject: Re: mod_jk not working !! -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 5/25/12 12:41 PM, Caldarale, Charles R wrote: From: Mark Eggers [mailto:its_toas...@yahoo.com] Subject: Re: mod_jk not working !! I'll try to give a few general directions. much useful content snipped Again, start simply. 1. Stock Apache HTTPD installation (and verify) 2. Stock Apache Tomcat installation (and verify) 3. mod_jk installation (and verify) 4. Second Apache Tomcat installation (and verify both) 5. Cluster I'd suggest that your entire e-mail should be put in the Wiki. +1, though maybe in smaller pieces linked by a top-level page. - -chris If this goes up on the Wiki, then smaller pages organized by task would be good. It would probably help if the Wiki pages had a lot of detail, and cross-reference the appropriate documentation on the Tomcat web site as well. I've been meaning to write this up for some time, so maybe I'll get started on it this weekend. Since this is going to take a bit of time, is there a place on the Tomcat Wiki that I can write but not have it published (may be a developer list question). If not, then I'll write locally and then do a cut / paste. However, it would be nice to have feedback during the writing process. It's coherent. Just put it up, worry about the tweaking later. p /mde/ - 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
Re: mod_jk not working as expected - is there a bug??
Apache 2.11, mod_jk/1.2.28: There seems to be a problem with activation of status worker JkStatus. Even after explicitly saying stopped for one of the workers the Act keeps going back and forth. When I refresh that page it keeps switching between OK and STP. And I still see traffic being sent to that worker. Is this a known bug? Earlier when we were on previous version of mod_jk this On Fri, Mar 6, 2009 at 2:02 PM, Rainer Jung rainer.j...@kippdata.de wrote: On 06.03.2009 21:42, Mohit Anchlia wrote: In addition to questions that I have in below email, I have couple of question. 1. activation property disable - Does it first turn off new requests to that worker and then disable the worker after finishing old requests. So is this the best way to see 0 customer impact? 2. activation propery stopped - Does it throw away existing sessions and also stop taking new requests. Please read about activation on http://tomcat.apache.org/connectors-doc/reference/workers.html Stopped: do not allow any requests being send to the worker. Disabled: Only requests which carry a session, that is sticky on the worker will go the the worker. No other requests will be send there. Use disable to dry out a worker, use stoppped directly before you actually want to take it out of production. Also I couldn't find way to see how mod_jk is behaving in the log file. I turned tracing on for JkLogLevel. I don't know what you mean by behaving. 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
Re: mod_jk not working as expected - is there a bug??
Resending with more information and attachment: Apache 2.11, mod_jk/1.2.28: There seems to be a problem with activation of status worker JkStatus. Even after explicitly saying stopped for one of the workers the Act keeps going back and forth. When I refresh that page it keeps switching between OK and STP. I even tried using wget but that doesn't work either. And I still see traffic being sent to that worker. wget: http://host2535.pharos.in.com/JkStatus?cmd=updatefrom=listw=tcsw=host2532vwa=2wf=1wn=host2532wr=wc=wd=0mime=txt; I have even tried vwa=s. I also tried opening one browser session stopping the worker (jkStatus) and then opening a new session to check the status. The status still keeps going back and forth. It shows ACT and then you refresh it shows STP and then you refresh again it shows ACT. Nothing seems to be working. Is this a known bug? Earlier when we were on previous version of mod_jk this used to work fine. Attached is the screen shot On Sat, Oct 24, 2009 at 7:51 AM, Mohit Anchlia mohitanch...@gmail.com wrote: Apache 2.11, mod_jk/1.2.28: There seems to be a problem with activation of status worker JkStatus. Even after explicitly saying stopped for one of the workers the Act keeps going back and forth. When I refresh that page it keeps switching between OK and STP. And I still see traffic being sent to that worker. Is this a known bug? Earlier when we were on previous version of mod_jk this On Fri, Mar 6, 2009 at 2:02 PM, Rainer Jung rainer.j...@kippdata.de wrote: On 06.03.2009 21:42, Mohit Anchlia wrote: In addition to questions that I have in below email, I have couple of question. 1. activation property disable - Does it first turn off new requests to that worker and then disable the worker after finishing old requests. So is this the best way to see 0 customer impact? 2. activation propery stopped - Does it throw away existing sessions and also stop taking new requests. Please read about activation on http://tomcat.apache.org/connectors-doc/reference/workers.html Stopped: do not allow any requests being send to the worker. Disabled: Only requests which carry a session, that is sticky on the worker will go the the worker. No other requests will be send there. Use disable to dry out a worker, use stoppped directly before you actually want to take it out of production. Also I couldn't find way to see how mod_jk is behaving in the log file. I turned tracing on for JkLogLevel. I don't know what you mean by behaving. 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
Re: mod_jk not working as expected - is there a bug??
I am currently testing this. Hoping this will help us achieve 0 customer impact when we upgrade our system. Is it possible for mod_jk to check 2 ports to determine if that worker should be out of service? For eg: if 8010 is down but 8009 port is up then bring that worker out of service? But the data port will continue to be 8009. Here is the problem, to successfully receive the traffic we have 2 dependencies 1. App server (port 8009) and 2. Queue server (port 8010). If anyone of those servers are down then we can't receive the traffic. But mod_jk only knows about 8009. On Fri, Mar 6, 2009 at 2:02 PM, Rainer Jung rainer.j...@kippdata.de wrote: On 06.03.2009 21:42, Mohit Anchlia wrote: In addition to questions that I have in below email, I have couple of question. 1. activation property disable - Does it first turn off new requests to that worker and then disable the worker after finishing old requests. So is this the best way to see 0 customer impact? 2. activation propery stopped - Does it throw away existing sessions and also stop taking new requests. Please read about activation on http://tomcat.apache.org/connectors-doc/reference/workers.html Stopped: do not allow any requests being send to the worker. Disabled: Only requests which carry a session, that is sticky on the worker will go the the worker. No other requests will be send there. Use disable to dry out a worker, use stoppped directly before you actually want to take it out of production. Also I couldn't find way to see how mod_jk is behaving in the log file. I turned tracing on for JkLogLevel. I don't know what you mean by behaving. 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
Re: mod_jk not working as expected - is there a bug??
Hi, On 10.03.2009 19:47, Mohit Anchlia wrote: I am currently testing this. Hoping this will help us achieve 0 customer impact when we upgrade our system. Is it possible for mod_jk to check 2 ports to determine if that worker should be out of service? For eg: if 8010 is down but 8009 port is up then bring that worker out of service? But the data port will continue to be 8009. Here is the problem, to successfully receive the traffic we have 2 dependencies 1. App server (port 8009) and 2. Queue server (port 8010). If anyone of those servers are down then we can't receive the traffic. But mod_jk only knows about 8009. No, mod_jk only knows about Tomcat AJP connectors. If you wat to coordinate a bigger more complex system, you need to do this externally. mod_jk only provides you with information about the state of the part of the system it knows (the configured Tomcat AJP connectors, e.g. workers) and it provides entry points to change the configuration state, e.g. switching activation via status worker. The rest is up to you :) Regards, Rainer On Fri, Mar 6, 2009 at 2:02 PM, Rainer Jungrainer.j...@kippdata.de wrote: On 06.03.2009 21:42, Mohit Anchlia wrote: In addition to questions that I have in below email, I have couple of question. 1. activation property disable - Does it first turn off new requests to that worker and then disable the worker after finishing old requests. So is this the best way to see 0 customer impact? 2. activation propery stopped - Does it throw away existing sessions and also stop taking new requests. Please read about activation on http://tomcat.apache.org/connectors-doc/reference/workers.html Stopped: do not allow any requests being send to the worker. Disabled: Only requests which carry a session, that is sticky on the worker will go the the worker. No other requests will be send there. Use disable to dry out a worker, use stoppped directly before you actually want to take it out of production. Also I couldn't find way to see how mod_jk is behaving in the log file. I turned tracing on for JkLogLevel. I don't know what you mean by behaving. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
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. 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 Jungrainer.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 90 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 Jungrainer.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
Re: mod_jk not working as expected - is there a bug??
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 Jungrainer.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 Jungrainer.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 90 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 Jungrainer.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
Re: mod_jk not working as expected - is there a bug??
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 90 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 Jungrainer.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
Re: mod_jk not working as expected - is there a bug??
I am not sure the stickiness should be attached to the tc worker. I would rather do it for the the real workers level, that is at appfe[1234]. Consider also worker.appfe[1234].sticky_session_force = False for each appfe[1234] worker. János On Feb 24, 2009, at 8:47 PM, Mohit Anchlia wrote: In httpd conf I just see JkMount and no other directive. I searched for Jk. Here is workers.properties file: ## worker.list=status,tc ## Worker Configuration## # All entries in this section take the form: # worker.workername.directive=value # Worker names are defined in the worker.list directive above. # Configuration specifying the worker named status as a status worker. # This worker can be used to administer the other configured workers. worker.status.type=status # Configuration for the default load balancer worker. # Uncomment the configuration for the tc # worker, and the two node workers below to enable. # Also add lb to the workers.list directive # above. The default for the load balancer worker is # round-robin distribution of requests over # all active nodes. There are currently two nodes set # up for the load balanced worker, add more # to this list if required. Sticky sessions is defaulted to true. worker.tc.type=lb worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4 worker.tc.sticky_session=true # Two load balanced workers, called node1 and node2. # Copy the configurations and add to the # worker.tc.balanced_workers # list above to add more nodes to the Tomcat cluster. # appfe1 worker.appfe1.type=ajp13 worker.appfe1.port=8009 worker.appfe1.host=appfe1 worker.appfe1.socket_timeout=5 worker.appfe1.socket_keepalive=true worker.appfe1.prepost_timeout=5 worker.appfe1.connect_timeout=5000 worker.appfe1.retries=3 worker.appfe1.recycle_timeout=900 # Refererence BHP Apache tuning guide before uncomment the following line. The unit of reply_timeout is millisecond. #worker.appfe1.reply_timeout=0 # appfe2 worker.appfe2.type=ajp13 worker.appfe2.port=8009 worker.appfe2.host=appfe2 worker.appfe2.socket_timeout=5 worker.appfe2.socket_keepalive=true worker.appfe2.prepost_timeout=5 worker.appfe2.connect_timeout=5000 worker.appfe2.retries=3 worker.appfe2.recycle_timeout=900 # Refererence BHP Apache tuning guide before uncomment the following line. The unit of reply_timeout is millisecond. #worker.appfe2.reply_timeout=0 # appfe3 worker.appfe3.type=ajp13 worker.appfe3.port=8009 worker.appfe3.host=appfe3 worker.appfe3.socket_timeout=5 worker.appfe3.socket_keepalive=true worker.appfe3.prepost_timeout=5 worker.appfe3.connect_timeout=5000 worker.appfe3.retries=3 worker.appfe3.recycle_timeout=900 # Refererence BHP Apache tuning guide before uncomment the following line. The unit of reply_timeout is millisecond. #worker.appfe3.reply_timeout=0 # appfe4 worker.appfe4.type=ajp13 worker.appfe4.port=8009 worker.appfe4.host=appfe4 worker.appfe4.socket_timeout=5 worker.appfe4.socket_keepalive=true worker.appfe4.prepost_timeout=5 worker.appfe4.connect_timeout=5000 worker.appfe4.retries=3 worker.appfe4.recycle_timeout=900 # Refererence BHP Apache tuning guide before uncomment the following line. The unit of reply_timeout is millisecond. #worker.appfe4.reply_timeout=0 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
Re: mod_jk not working as expected - is there a bug??
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. 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 90 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 Jungrainer.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
Re: mod_jk not working as expected - is there a bug??
On 25.02.2009 16:50, János Löbb wrote: I am not sure the stickiness should be attached to the tc worker. I would rather do it for the the real workers level, that is at appfe[1234]. Consider also worker.appfe[1234].sticky_session_force = False for each appfe[1234] worker. The page http://tomcat.apache.org/connectors-doc/reference/workers.html specifies the properties. Both sticky_session and sticky_session_force are for lb workers. Setting sticky_session_force to false is the default (as is setting sticky_session to true). Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk not working as expected - is there a bug??
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 Jungrainer.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 90 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 Jungrainer.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
Re: mod_jk not working as expected - is there a bug??
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
Re: mod_jk not working as expected - is there a bug??
In httpd conf I just see JkMount and no other directive. I searched for Jk. Here is workers.properties file: ## worker.list=status,tc ## Worker Configuration## # All entries in this section take the form: # worker.workername.directive=value # Worker names are defined in the worker.list directive above. # Configuration specifying the worker named status as a status worker. # This worker can be used to administer the other configured workers. worker.status.type=status # Configuration for the default load balancer worker. # Uncomment the configuration for the tc # worker, and the two node workers below to enable. # Also add lb to the workers.list directive # above. The default for the load balancer worker is # round-robin distribution of requests over # all active nodes. There are currently two nodes set # up for the load balanced worker, add more # to this list if required. Sticky sessions is defaulted to true. worker.tc.type=lb worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4 worker.tc.sticky_session=true # Two load balanced workers, called node1 and node2. # Copy the configurations and add to the # worker.tc.balanced_workers # list above to add more nodes to the Tomcat cluster. # appfe1 worker.appfe1.type=ajp13 worker.appfe1.port=8009 worker.appfe1.host=appfe1 worker.appfe1.socket_timeout=5 worker.appfe1.socket_keepalive=true worker.appfe1.prepost_timeout=5 worker.appfe1.connect_timeout=5000 worker.appfe1.retries=3 worker.appfe1.recycle_timeout=900 # Refererence BHP Apache tuning guide before uncomment the following line. The unit of reply_timeout is millisecond. #worker.appfe1.reply_timeout=0 # appfe2 worker.appfe2.type=ajp13 worker.appfe2.port=8009 worker.appfe2.host=appfe2 worker.appfe2.socket_timeout=5 worker.appfe2.socket_keepalive=true worker.appfe2.prepost_timeout=5 worker.appfe2.connect_timeout=5000 worker.appfe2.retries=3 worker.appfe2.recycle_timeout=900 # Refererence BHP Apache tuning guide before uncomment the following line. The unit of reply_timeout is millisecond. #worker.appfe2.reply_timeout=0 # appfe3 worker.appfe3.type=ajp13 worker.appfe3.port=8009 worker.appfe3.host=appfe3 worker.appfe3.socket_timeout=5 worker.appfe3.socket_keepalive=true worker.appfe3.prepost_timeout=5 worker.appfe3.connect_timeout=5000 worker.appfe3.retries=3 worker.appfe3.recycle_timeout=900 # Refererence BHP Apache tuning guide before uncomment the following line. The unit of reply_timeout is millisecond. #worker.appfe3.reply_timeout=0 # appfe4 worker.appfe4.type=ajp13 worker.appfe4.port=8009 worker.appfe4.host=appfe4 worker.appfe4.socket_timeout=5 worker.appfe4.socket_keepalive=true worker.appfe4.prepost_timeout=5 worker.appfe4.connect_timeout=5000 worker.appfe4.retries=3 worker.appfe4.recycle_timeout=900 # Refererence BHP Apache tuning guide before uncomment the following line. The unit of reply_timeout is millisecond. #worker.appfe4.reply_timeout=0 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
