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 !!
On 25 May 2012, at 19:21, Mark Eggers wrote: >> >> From: Christopher Schultz >> To: Tomcat Users List >> 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. >>> >>> >>> >>>> 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 !!
> > From: Christopher Schultz >To: Tomcat Users List >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. >> >> >> >>> 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 !!
-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. > > > >> 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: Mark Eggers [mailto:its_toas...@yahoo.com] > Subject: Re: mod_jk not working !! > I'll try to give a few general directions. > 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 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 !!
-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 !!
> > From: Aman Arora >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 you're
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 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=update&from=list&w=tc&sw=host2532&vwa=2&wf=1&wn=host2532&wr=&wc=&wd=0&mime=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 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 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??
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 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 Jung 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 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 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??
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??
On 06.03.2009 19:41, Mohit Anchlia wrote: Thanks ..I got following URL from the browser, which is different then what you suggested. Does this look ok? http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0 If it comes from the Browser, it is OK. I guess you are using a version before 1.2.27. The arguments have changed with 1.2.27, but will now be kept stable. My cmd=edit was wrong, of course it is cmd=update. "wa" is the previous way instead of "vwa", value "0" should mean active, you need "2" or "s" for stopped (at least with 1.2.27, but simply check it out, you can view the result again in the status worker display). You don't need the from when used from a script, it is just for the GUI redirect. wf, wn, wr, wc and wd you don't need, if you only want to edit activation. so it look like when I want one node out of service I do the following: Execute GET http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=2&wf=1&wn=appfe1&wr=&wc=&wd=0 or shorter: http://10.10.80.55/JkStatus?cmd=update&w=tc&sw=appfe1&wa=2 and when I want that node in service I do: http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0 or shorter http://10.10.80.55/JkStatus?cmd=update&w=tc&sw=appfe1&wa=0 I tried enabling JkLog to trace but couldn't see where the requests are being forwarded too? I see something like : [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 018048 50 01 02 85 15 30 24 D1 3E 54 09 54 4C C1 A1 - HP0$.>T.TL.. [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [debug] status_get_string::jk_status.c (702): retrieved string arg 'wd' as '0' [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01907A 09 40 B8 B0 82 EA 4A 9F 00 46 2A E5 28 B5 02 - z...@j..f*.(.. [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace] reset_lb_values::jk_lb_worker.c (257): enter [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01a015 08 40 09 2A A8 18 E2 09 47 28 01 62 C6 14 8A - @.*g(.b... [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace] reset_lb_values::jk_lb_worker.c (263): exit [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01b022 49 01 CE CF 52 91 12 E4 48 49 A4 2A E0 82 00 - "I...R...HI.*... Any change done by the status worker gets logged immediately with info log level. But I can't tell if the requests to appfe1 are no longer being directed to appfe1 node. You can check that more easily by looking at the request counts in the status worker display, whether they stil go up or are kept stable. The display also shows you the actual activation status, which should change from ACT to STP and back. You can also log the lb member which was chosen for a request in the Apache access log, by adding a log note to your LogFormat. Look for mod_log_config on the page http://tomcat.apache.org/connectors-doc/reference/apache.html Finally you can also activate the access log of your backend to track, whether they handle requests or not. 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 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. Also I couldn't find way to see how mod_jk is behaving in the log file. I turned tracing on for JkLogLevel. On Fri, Mar 6, 2009 at 10:41 AM, Mohit Anchlia wrote: > Thanks ..I got following URL from the browser, which is different then > what you suggested. Does this look ok? > > http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0 > > so it look like when I want one node out of service I do the following: > > Execute GET > http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=2&wf=1&wn=appfe1&wr=&wc=&wd=0 > > and when I want that node in service I do: > > http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0 > > I tried enabling JkLog to trace but couldn't see where the requests > are being forwarded too? I see something like : > > [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] > ajp_connection_tcp_send_message::jk_ajp_common.c (911): 0180 48 50 > 01 02 85 15 30 24 D1 3E 54 09 54 4C C1 A1 - HP0$.>T.TL.. > [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [debug] > status_get_string::jk_status.c (702): retrieved string arg 'wd' as '0' > [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] > ajp_connection_tcp_send_message::jk_ajp_common.c (911): 0190 7A 09 > 40 B8 B0 82 EA 4A 9F 00 46 2A E5 28 B5 02 - z...@j..f*.(.. > [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace] > reset_lb_values::jk_lb_worker.c (257): enter > [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] > ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01a0 15 08 > 40 09 2A A8 18 E2 09 47 28 01 62 C6 14 8A - @.*g(.b... > [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace] > reset_lb_values::jk_lb_worker.c (263): exit > [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] > ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01b0 22 49 > 01 CE CF 52 91 12 E4 48 49 A4 2A E0 82 00 - "I...R...HI.*... > > > But I can't tell if the requests to appfe1 are no longer being > directed to appfe1 node. > > On Fri, Mar 6, 2009 at 10:14 AM, Rainer Jung wrote: >> On 06.03.2009 18:57, Mohit Anchlia wrote: >>> >>> So I created new JkMount /JkStatus status under VirtualHost. Went to >>> the page and saw different properties, it looks like I need to change >>> the Activation on individual worker. When I click "E" in front of that >>> worker it takes me to the page where I can edit the activation >>> property. I think if I set it to "stopped" balancer will take it out >>> of service. Only question I have is how can I automatically do that. >> >>> Can I do something like: >> >>> >>> http://10.10.80.55/JkStatus?cmd=edit&from=list&w=tc&sw=appfe1&activation=stopped >> >> Yes you can. All requests to the status worker are GET requests, so >> everything you can do in the GUI you can also put into a script. Simply copy >> the URLs form your browser. >> >> The documentation page also lists all request attributes with their meaning. >> >> According to this page you need to use "vwa=s" instead of >> "activation=stopped" (at least for version 1.2.27; "s" instead of "stopped" >> is not important, but "vwa" instead of "activation" is). >> >> You can also add mime=txt so that your script gets back an easier to >> understand answer. >> >>> or something like that automatically will change the activiation as I >>> move servers in and out of service? >> >> You can write a script for this, that uses the above URLs with a tool like >> e.g. curl. >> >> Caution: >> >> 1) Secure the URL. Your web server has ways to do that, e.g. with a user and >> password. >> >> 2) Activation changes via the status worker are not persistent. When your >> web server is restarted, activation switches back to what is in your >> workers.proprties. If you want to change activation in a persistant way, you >> also have to change your workers.properties. >> >> 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??
Thanks ..I got following URL from the browser, which is different then what you suggested. Does this look ok? http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0 so it look like when I want one node out of service I do the following: Execute GET http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=2&wf=1&wn=appfe1&wr=&wc=&wd=0 and when I want that node in service I do: http://10.10.80.55/JkStatus?cmd=update&from=list&w=tc&sw=appfe1&wa=0&wf=1&wn=appfe1&wr=&wc=&wd=0 I tried enabling JkLog to trace but couldn't see where the requests are being forwarded too? I see something like : [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 018048 50 01 02 85 15 30 24 D1 3E 54 09 54 4C C1 A1 - HP0$.>T.TL.. [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [debug] status_get_string::jk_status.c (702): retrieved string arg 'wd' as '0' [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01907A 09 40 B8 B0 82 EA 4A 9F 00 46 2A E5 28 B5 02 - z...@j..f*.(.. [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace] reset_lb_values::jk_lb_worker.c (257): enter [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01a015 08 40 09 2A A8 18 E2 09 47 28 01 62 C6 14 8A - @.*g(.b... [Fri Mar 06 10:20:25.377 2009] [675:4143913824] [trace] reset_lb_values::jk_lb_worker.c (263): exit [Fri Mar 06 10:20:25.377 2009] [673:4143913824] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 01b022 49 01 CE CF 52 91 12 E4 48 49 A4 2A E0 82 00 - "I...R...HI.*... But I can't tell if the requests to appfe1 are no longer being directed to appfe1 node. On Fri, Mar 6, 2009 at 10:14 AM, Rainer Jung wrote: > On 06.03.2009 18:57, Mohit Anchlia wrote: >> >> So I created new JkMount /JkStatus status under VirtualHost. Went to >> the page and saw different properties, it looks like I need to change >> the Activation on individual worker. When I click "E" in front of that >> worker it takes me to the page where I can edit the activation >> property. I think if I set it to "stopped" balancer will take it out >> of service. Only question I have is how can I automatically do that. > >> Can I do something like: > >> >> http://10.10.80.55/JkStatus?cmd=edit&from=list&w=tc&sw=appfe1&activation=stopped > > Yes you can. All requests to the status worker are GET requests, so > everything you can do in the GUI you can also put into a script. Simply copy > the URLs form your browser. > > The documentation page also lists all request attributes with their meaning. > > According to this page you need to use "vwa=s" instead of > "activation=stopped" (at least for version 1.2.27; "s" instead of "stopped" > is not important, but "vwa" instead of "activation" is). > > You can also add mime=txt so that your script gets back an easier to > understand answer. > >> or something like that automatically will change the activiation as I >> move servers in and out of service? > > You can write a script for this, that uses the above URLs with a tool like > e.g. curl. > > Caution: > > 1) Secure the URL. Your web server has ways to do that, e.g. with a user and > password. > > 2) Activation changes via the status worker are not persistent. When your > web server is restarted, activation switches back to what is in your > workers.proprties. If you want to change activation in a persistant way, you > also have to change your workers.properties. > > 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 06.03.2009 18:57, Mohit Anchlia wrote: So I created new JkMount /JkStatus status under VirtualHost. Went to the page and saw different properties, it looks like I need to change the Activation on individual worker. When I click "E" in front of that worker it takes me to the page where I can edit the activation property. I think if I set it to "stopped" balancer will take it out of service. Only question I have is how can I automatically do that. Can I do something like: http://10.10.80.55/JkStatus?cmd=edit&from=list&w=tc&sw=appfe1&activation=stopped Yes you can. All requests to the status worker are GET requests, so everything you can do in the GUI you can also put into a script. Simply copy the URLs form your browser. The documentation page also lists all request attributes with their meaning. According to this page you need to use "vwa=s" instead of "activation=stopped" (at least for version 1.2.27; "s" instead of "stopped" is not important, but "vwa" instead of "activation" is). You can also add mime=txt so that your script gets back an easier to understand answer. or something like that automatically will change the activiation as I move servers in and out of service? You can write a script for this, that uses the above URLs with a tool like e.g. curl. Caution: 1) Secure the URL. Your web server has ways to do that, e.g. with a user and password. 2) Activation changes via the status worker are not persistent. When your web server is restarted, activation switches back to what is in your workers.proprties. If you want to change activation in a persistant way, you also have to change your workers.properties. 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??
So I created new JkMount /JkStatus status under VirtualHost. Went to the page and saw different properties, it looks like I need to change the Activation on individual worker. When I click "E" in front of that worker it takes me to the page where I can edit the activation property. I think if I set it to "stopped" balancer will take it out of service. Only question I have is how can I automatically do that. Can I do something like: http://10.10.80.55/JkStatus?cmd=edit&from=list&w=tc&sw=appfe1&activation=stopped or something like that automatically will change the activiation as I move servers in and out of service? On Fri, Mar 6, 2009 at 12:35 AM, Rainer Jung wrote: > On 06.03.2009 09:27, Mohit Anchlia wrote: >> >> Is there a way to dynamically move workers in and out of service using >> status worker. > > Please first have a look at the status worker and get some experience with > it before posting more basic questions. > > 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 was looking at the manual and didn't see a way to automatically set the worker to stop. I'll test it today with the way you suggested and post more questions .. On Fri, Mar 6, 2009 at 12:35 AM, Rainer Jung wrote: > On 06.03.2009 09:27, Mohit Anchlia wrote: >> >> Is there a way to dynamically move workers in and out of service using >> status worker. > > Please first have a look at the status worker and get some experience with > it before posting more basic questions. > > 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 06.03.2009 09:27, Mohit Anchlia wrote: Is there a way to dynamically move workers in and out of service using status worker. Please first have a look at the status worker and get some experience with it before posting more basic questions. 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??
Is there a way to dynamically move workers in and out of service using status worker. On Thu, Mar 5, 2009 at 10:34 PM, Rainer Jung wrote: > On 06.03.2009 01:44, Mohit Anchlia wrote: >> >> Thanks ..But how do I tie the status worker to the list of nodes that >> I have. For eg in below config how do I say that appfe1 is now >> "stopped" and still keep servicing appfe2,3 and 4 >> >> >> worker.status.type=status >> worker.tc.type=lb >> worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4 >> worker.tc.sticky_session=true > > mount the worker named status to a URL, e.g. > > JkMount /mystatus status > > and then point your browser to this URL. It will show you a GUI, where you > can edit the settings. E.g. there will be a block of data for the worker > "tc", and there you can see a drop down list of attributes to edt. Choose > activation then you get a page on which you can edit the activations of all > members of "tc". > > See: > > http://tomcat.apache.org/connectors-doc/reference/status.html > > 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 06.03.2009 01:44, Mohit Anchlia wrote: Thanks ..But how do I tie the status worker to the list of nodes that I have. For eg in below config how do I say that appfe1 is now "stopped" and still keep servicing appfe2,3 and 4 worker.status.type=status worker.tc.type=lb worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4 worker.tc.sticky_session=true mount the worker named status to a URL, e.g. JkMount /mystatus status and then point your browser to this URL. It will show you a GUI, where you can edit the settings. E.g. there will be a block of data for the worker "tc", and there you can see a drop down list of attributes to edt. Choose activation then you get a page on which you can edit the activations of all members of "tc". See: http://tomcat.apache.org/connectors-doc/reference/status.html 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??
Thanks ..But how do I tie the status worker to the list of nodes that I have. For eg in below config how do I say that appfe1 is now "stopped" and still keep servicing appfe2,3 and 4 worker.status.type=status worker.tc.type=lb worker.tc.balance_workers=appfe1,appfe2,appfe3,appfe4 worker.tc.sticky_session=true On Thu, Mar 5, 2009 at 4:07 PM, Rainer Jung wrote: > On 05.03.2009 23:57, Mohit Anchlia wrote: >> >> So I tested again and it looks like Jboss accepts new connection when >> it already undeployed the service. Do you have any advice of how I can >> handle this scenario. I need to cleanly take that node out of service >> from mod_jk with no customer impact. Is there anyway in apache to do >> that so that it detects below scenario ..any possible way? Thanks for >> your help. >> >> I see the following of http code 503: >> > ... > > Use the status worker and set the node to "stopped". All requests to the > status worker are GET requests, so you can easily script/automate them. > > That's the cleanest way. > > 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 05.03.2009 23:57, Mohit Anchlia wrote: So I tested again and it looks like Jboss accepts new connection when it already undeployed the service. Do you have any advice of how I can handle this scenario. I need to cleanly take that node out of service from mod_jk with no customer impact. Is there anyway in apache to do that so that it detects below scenario ..any possible way? Thanks for your help. I see the following of http code 503: ... Use the status worker and set the node to "stopped". All requests to the status worker are GET requests, so you can easily script/automate them. That's the cleanest way. 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??
So I tested again and it looks like Jboss accepts new connection when it already undeployed the service. Do you have any advice of how I can handle this scenario. I need to cleanly take that node out of service from mod_jk with no customer impact. Is there anyway in apache to do that so that it detects below scenario ..any possible way? Thanks for your help. I see the following of http code 503: JBossWeb/2.0.0.GA_CP01 - Error report HTTP Status 503 - This application is not currently availabletype Status reportmessage This application is not currently availabledescription The requested service (This application is not currently available) is not currently available.JBossWeb/2.0.0.GA_CP01 On Mon, Mar 2, 2009 at 5:01 PM, Rainer Jung wrote: > On 03.03.2009 01:45, Mohit Anchlia wrote: >> >> 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. > > No I'm not laughing, but as I wrote, at the time Tomcat returns the cpong, > there is no http status. There isn't yet a request. > > So this feature doesn't make sense. > > Regards, > > Rainer > >> On Mon, Mar 2, 2009 at 1:26 PM, Rainer Jung >> 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 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. >> >> Order deny,allow >> Deny from all >> Allow from localhost >> >> >> #JkMount /JkStatus status >> >> # Below line forward all requests to application server >> #JkMount /* local >> >> >> On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung >> 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 dir
Re: mod_jk not working as expected - is there a bug??
On 03.03.2009 01:45, Mohit Anchlia wrote: 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. No I'm not laughing, but as I wrote, at the time Tomcat returns the cpong, there is no http status. There isn't yet a request. So this feature doesn't make sense. Regards, Rainer On Mon, Mar 2, 2009 at 1:26 PM, Rainer Jung 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 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. Order deny,allow Deny from all Allow from localhost #JkMount /JkStatus status # Below line forward all requests to application server #JkMount /* local On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung 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 Jung 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 int
Re: mod_jk not working as expected - is there a bug??
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 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 >> 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. Order deny,allow Deny from all Allow from localhost #JkMount /JkStatus status # Below line forward all requests to application server #JkMount /* local On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung 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 Jung >> 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.
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 Jung 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. Order deny,allow Deny from all Allow from localhost #JkMount /JkStatus status # Below line forward all requests to application server #JkMount /* local On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung 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 Jung 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/connecto
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 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. >> >> Order deny,allow >> Deny from all >> Allow from localhost >> >> >> #JkMount /JkStatus status >> >> # Below line forward all requests to application server >> #JkMount /* local >> >> >> On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung >> 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 Jung 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,
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. Order deny,allow Deny from all Allow from localhost #JkMount /JkStatus status # Below line forward all requests to application server #JkMount /* local On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung 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 Jung 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 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??
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. Order deny,allow Deny from all Allow from localhost #JkMount /JkStatus status # Below line forward all requests to application server #JkMount /* local On Wed, Feb 25, 2009 at 2:55 AM, Rainer Jung 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 Jung >> 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??
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..= # 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 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 configur
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 Jung 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??
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..= # 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 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 an
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
