Re: Apache Tomcat unable to send the request. tomcat throwing 502 Gate Way error
You seem to have missed the "Please remove all of the commented parts.." part of the request. rakesh k wrote: Hi Thanks for replying for on my question. Please find the details below, you had requested. sorry for troubling you much , i ma hereby providing the details of server.xml below. Regards Rakesh On Fri, Aug 12, 2011 at 5:18 PM, Pid wrote: On 12/08/2011 12:31, rakesh k wrote: Hi Igor Cicimov Thank you very much for replying .. That doesn't answer the question. Please remove all of the commented parts of the server.xml and paste the whole thing, inline, into your next reply. I am heryby attaching the proxy pass which we used to connect tomcat through apache. (You're not attaching it.) p ProxyPass / balancer://msf/ stickysession=JSESSIONID|jsessionid BalancerMember http://localhost:8082 route=msf1 This is what we use in the produciton scenario, the above mentioned configuration is the exact executor configuration we used for this scenario. can you please help on this since we are running this on production which has to be resolved. Regards Rakesh On Fri, Aug 12, 2011 at 3:56 PM, Igor Cicimov wrote: I can't see the connection between the Connector you showed and port 8082. What is listening on port 8082? Also what is your "tomcatThreadPool" executor configuration? On Fri, Aug 12, 2011 at 7:56 PM, rakesh k wrote: Hi All I am using Apache tomcat 6.0.18 version I am not sure, why the tomcat is giving us this problem. While doing Load testing we are sending 5000 requests at a time, where we are getting 4-5 Bad gate way error. Please find the error details below [Wed Aug 10 01:00:50 2011] [error] (103)Software caused connection abort: proxy: pass request body failed to 127.0.0.3:8082 (localhost) [Wed Aug 10 01:00:50 2011] [error] proxy: pass request body failed to 127.0.0.3:8082 (localhost) from 72.163.25.205 () [Wed Aug 10 01:01:01 2011] [error] (103)Software caused connection abort: proxy: pass request body failed to 127.0.0.3:8082 (localhost) [Wed Aug 10 01:01:01 2011] [error] proxy: pass request body failed to 127.0.0.3:8082 (localhost) from 72.163.25.206 () [Wed Aug 10 01:28:04 2011] [error] (103)Software caused connection abort: proxy: pass request body failed to 127.0.0.3:8082 (localhost) [Wed Aug 10 01:28:04 2011] [error] proxy: pass request body failed to 127.0.0.3:8082 (localhost) from 72.163.25.205 () [Wed Aug 10 06:10:49 2011] [error] (103)Software caused connection abort: proxy: pass request body failed to 127.0.0.3:8082 (localhost) [Wed Aug 10 06:10:49 2011] [error] proxy: pass request body failed to 127.0.0.3:8082 (localhost) from 72.163.25.206 () [Wed Aug 10 19:01:18 2011] [error] (103)Software caused connection abort: proxy: pass request body failed to 127.0.0.3:8082 (localhost) [Wed Aug 10 19:01:18 2011] [error] proxy: pass request body failed to 127.0.0.3:8082 (localhost) from 72.163.5.38 () I am also attaching the tomcat configuration like server.xml with this question, can you please help how to get out this issue, if you require anything from me i can proivude the etire details. Please find the server.xml tomcat connector attribute portion. can you please help me ragarding this issue. Regards Rakesh - 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: Apache Tomcat unable to send the request. tomcat throwing 502 Gate Way error
Hi Thanks for replying for on my question. Please find the details below, you had requested. sorry for troubling you much , i ma hereby providing the details of server.xml below. Regards Rakesh On Fri, Aug 12, 2011 at 5:18 PM, Pid wrote: > On 12/08/2011 12:31, rakesh k wrote: > > Hi Igor Cicimov > > > > Thank you very much for replying .. > > >port="8082" protocol="HTTP/1.1" > >connectionTimeout="2" > >redirectPort="8443" /> > > > > That doesn't answer the question. > > Please remove all of the commented parts of the server.xml and paste the > whole thing, inline, into your next reply. > > > > > I am heryby attaching the proxy pass which we used to connect tomcat > through > > apache. > > (You're not attaching it.) > > > p > > > ProxyPass / balancer://msf/ stickysession=JSESSIONID|jsessionid > > > > > > BalancerMember http://localhost:8082 route=msf1 > > > > > > > > > > > > This is what we use in the produciton scenario, the above mentioned > > configuration is the exact executor configuration we used for this > scenario. > > > > > > can you please help on this since we are running this on production which > > has to be resolved. > > Regards > > Rakesh > > > > > > On Fri, Aug 12, 2011 at 3:56 PM, Igor Cicimov > wrote: > > > >> I can't see the connection between the Connector you showed and port > 8082. > >> What is listening on port 8082? Also what is your "tomcatThreadPool" > >> executor configuration? > >> > >> > >> On Fri, Aug 12, 2011 at 7:56 PM, rakesh k wrote: > >> > >>> Hi All > >>> > >>> I am using Apache tomcat 6.0.18 version > >>> > >>> I am not sure, why the tomcat is giving us this problem. While doing > Load > >>> testing we are sending 5000 requests at a time, where we are getting > 4-5 > >>> Bad > >>> gate way error. > >>> > >>> Please find the error details below > >>> > >>> [Wed Aug 10 01:00:50 2011] [error] (103)Software caused connection > abort: > >>> proxy: pass request body failed to 127.0.0.3:8082 (localhost) > >>> [Wed Aug 10 01:00:50 2011] [error] proxy: pass request body failed to > >>> 127.0.0.3:8082 (localhost) from 72.163.25.205 () > >>> [Wed Aug 10 01:01:01 2011] [error] (103)Software caused connection > abort: > >>> proxy: pass request body failed to 127.0.0.3:8082 (localhost) > >>> [Wed Aug 10 01:01:01 2011] [error] proxy: pass request body failed to > >>> 127.0.0.3:8082 (localhost) from 72.163.25.206 () > >>> [Wed Aug 10 01:28:04 2011] [error] (103)Software caused connection > abort: > >>> proxy: pass request body failed to 127.0.0.3:8082 (localhost) > >>> [Wed Aug 10 01:28:04 2011] [error] proxy: pass request body failed to > >>> 127.0.0.3:8082 (localhost) from 72.163.25.205 () > >>> [Wed Aug 10 06:10:49 2011] [error] (103)Software caused connection > abort: > >>> proxy: pass request body failed to 127.0.0.3:8082 (localhost) > >>> [Wed Aug 10 06:10:49 2011] [error] proxy: pass request body failed to > >>> 127.0.0.3:8082 (localhost) from 72.163.25.206 () > >>> [Wed Aug 10 19:01:18 2011] [error] (103)Software caused connection > abort: > >>> proxy: pass request body failed to 127.0.0.3:8082 (localhost) > >>> [Wed Aug 10 19:01:18 2011] [error] proxy: pass request body failed to > >>> 127.0.0.3:8082 (localhost) from 72.163.5.38 () > >>> > >>> > >>> I am also attaching the tomcat configuration like server.xml with this > >>> question, > >>> > >>> can you please help how to get out this issue, if you require anything > >> from > >>> me i can proivude the etire details. > >>> > >>> Please find the server.xml tomcat connector attribute portion. > >>> > >>> > >>> >>> port="8080" protocol="HTTP/1.1" > >>> connectionTimeout="2" > >>> redirectPort="8443" /> > >>> > >>> can you please help me ragarding this issue. > >>> > >>> > >>> Regards > >>> Rakesh > >>> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat war context path
Got it thanks! Will try that On Mon, Aug 15, 2011 at 12:54 PM, Mark Thomas wrote: > On 15/08/2011 20:39, Mohit Anchlia wrote: >> >> On Mon, Aug 15, 2011 at 12:17 PM, Pid wrote: >>> >>> On 15/08/2011 18:05, Mohit Anchlia wrote: Is this even possible with tomcat? >>> >>> In Tomcat 7.0: >>> >>> abc##SNAPSHOT-01.war >>> abc##SNAPSHOT-02.war >>> abc##SNAPSHOT-03.war >>> abc##SNAPSHOT-04.war >>> >>> etc >> >> Sorry I don't follow. > > Read Pid's e-mail again. Rename your WAR files as per his e-mail. > > Mark > > - > 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: Why is the tomcat welcome page showing?
Hi Charles, Thanks for taking the time to answer. I'm using Tomcat 6.0 on Solaris I understand it's not ideal, however, I have to work this way because of a framework built for a different platform. The deployment mechanisms are such that they don't deploy to ROOT. Anyway with you're inspiring words of " webapp isn't being deployed properly" got me going and rebuilding, killing the jdk and starting up again. Something got cleared and it's working again. Very much obliged, Carl Furst -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Monday, August 15, 2011 5:09 PM To: Tomcat Users List Subject: RE: Why is the tomcat welcome page showing? > From: Furst, Carl [mailto:carl.fu...@mlb.com] > Subject: Why is the tomcat welcome page showing? > In server.xml I have a Host section set up with a Context that > has a path set to "". Unfortunate that you choose to use the least desirable method of setting the default webapp. > I see in the logs that the webapp assigned to that path is indeed > executing when I hit '/'. However the browser shows the Tomcat homepage. Possibly browser caching, but also possible that your webapp isn't being deployed properly. > How do I disable the ROOT context? You can't - there must always be a ROOT context; you have just chosen a poor (and conflicting) way to specify it. What you should be doing: 1) Tell us the version of Tomcat you're using. 2) Stop Tomcat. 3) Remove the existing ROOT directory from the appBase directory. 4) Rename your webapp to ROOT (or ROOT.war, if appropriate). 5) Remove the element from server.xml. 6) Remove the contents of Tomcat's work and temp directories. 7) Remove the ROOT.xml file (if it exists) from conf/Catalina/[host]. 8) Restart Tomcat. - 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 smime.p7s Description: S/MIME cryptographic signature ** MLB.com: Where Baseball is Always On - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Why is the tomcat welcome page showing?
> From: Furst, Carl [mailto:carl.fu...@mlb.com] > Subject: Why is the tomcat welcome page showing? > In server.xml I have a Host section set up with a Context that > has a path set to "". Unfortunate that you choose to use the least desirable method of setting the default webapp. > I see in the logs that the webapp assigned to that path is indeed > executing when I hit '/'. However the browser shows the Tomcat homepage. Possibly browser caching, but also possible that your webapp isn't being deployed properly. > How do I disable the ROOT context? You can't - there must always be a ROOT context; you have just chosen a poor (and conflicting) way to specify it. What you should be doing: 1) Tell us the version of Tomcat you're using. 2) Stop Tomcat. 3) Remove the existing ROOT directory from the appBase directory. 4) Rename your webapp to ROOT (or ROOT.war, if appropriate). 5) Remove the element from server.xml. 6) Remove the contents of Tomcat's work and temp directories. 7) Remove the ROOT.xml file (if it exists) from conf/Catalina/[host]. 8) Restart Tomcat. - 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: Why is the tomcat welcome page showing?
To follow up on this.. I removed the ROOT folder from the webapps.. and it still shows up even when I have re-defined the default Context. Where does the welcome page get rendered? Thanks, Carl Furst -Original Message- From: Furst, Carl [mailto:carl.fu...@mlb.com] Sent: Monday, August 15, 2011 4:49 PM To: users@tomcat.apache.org Subject: Why is the tomcat welcome page showing? Hey all, In server.xml I have a Host section set up with a Context that has a path set to "". I see in the logs that the webapp assigned to that path is indeed executing when I hit '/'. However the browser shows the Tomcat homepage. "If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations!" Why is my webapp not showing in my browser? Do I have to set up a DocumentIndex type parameter like in Apache? How do I disable the ROOT context? Thanks, Carl Furst smime.p7s Description: S/MIME cryptographic signature ** MLB.com: Where Baseball is Always On - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Why is the tomcat welcome page showing?
Hey all, In server.xml I have a Host section set up with a Context that has a path set to "". I see in the logs that the webapp assigned to that path is indeed executing when I hit '/'. However the browser shows the Tomcat homepage. "If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations!" Why is my webapp not showing in my browser? Do I have to set up a DocumentIndex type parameter like in Apache? How do I disable the ROOT context? Thanks, Carl Furst smime.p7s Description: S/MIME cryptographic signature ** MLB.com: Where Baseball is Always On - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl, On 8/15/2011 2:09 PM, Lataxes, Karl wrote: > I wrote the code to generate the session id and add it as an HTTP > header at the recommendation of someone on the users list. Not to open a whole can of worms, but why are you generating your own session ids? You don't like the format of the existing ids? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Jfh8ACgkQ9CaO5/Lv0PD5UACgt4xmRqavb5Hk3gpZ+ihNxXV2 drgAn39ZqloIyCzBILV7Kw2hL8MTv/QJ =lq+C -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Get SSO ID on server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chema, On 8/12/2011 2:56 PM, Chema wrote: >> Why bother? >> >> " As soon as the user logs out of one web application (for example, >> by invalidating the corresponding session if form based login is >> used), the user's sessions in all web applications will be >> invalidated. Any subsequent attempt to access a protected resource >> in any application will require the user to authenticate himself or >> herself again. " > > Right. But the application requires than an administrator can expulse > an user. It's a client requirement. How do you accomplish that? By doing this SSO sniff-and-kill-session thing? It seems more straightforward to expire a particular webapp's session explicitly and let the SSO expire along with it. > So, I need to record all "SSO sessions" FYI, I made it using by > JSESSIONIDSSO cookie and works fine Doesn't that mean you'll have to re-run the same query just to expire the sessions in the other webapps? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5JfTcACgkQ9CaO5/Lv0PAKZQCgnsSH7kzt62gdYvj0T0qjc7ES mcMAoJI36IqOKM39o/iRXj7xRblzKlWa =L/z6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 21:20, Pid wrote: > On 15/08/2011 19:09, Lataxes, Karl wrote: >> I wrote the code to generate the session id and add it as an HTTP header at >> the recommendation of someone on the users list. The problem now is >> appending the jvmroute to the generated session id in order to get session >> stickiness to work. If there were some way for the servlet to retrieve the >> jvmRoute from server.xml, I could append it to the session id and get it to >> work. I have been looking online for a solution, but have been unable to >> find one. > > Try using JMX. > > Look up the appropriate object (there are clues in the source of the > Manager app) and then retrieve the value of the appropriate attribute. > > I would experiment with setting this value in the servlet.init() method. Or, since you don't really need a jvmRoute but just something to add to the session id which is known by mod_jk, you can set a system property "-DjvmRoute=tomcat7A" etc. Then retrieve the value as a system property and add it to the session id, separated with a dot. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat war context path
> From: Jesse Farinacci [mailto:jie...@gmail.com] > Subject: Re: Tomcat war context path > You could also bundle a META-INF/context.xml file which looks something akin > to: > > Pretty much wrong on all counts: 1) The path attribute is not allowed when the element is in META-INF/context.xml. 2) The path for the default webapp is not "/" (read the servlet spec or Tomcat doc). - 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: Tomcat war context path
On 15/08/2011 20:45, Jesse Farinacci wrote: Greetings, On Mon, Aug 15, 2011 at 3:39 PM, Mohit Anchlia wrote: Currently when I deploy abc-SNAPSHOT-01.war I access is something like http://localhost:8080/abc-SNAPSHOT-01.war How can I change the context root such that I can access it as http://localhost:8080/abc? Problem is that abc-SNAPSHOT-01.war name could change with the build version change. You could also bundle a META-INF/context.xml file which looks something akin to: No you can't. That config is invalid. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
On 15/08/2011 20:39, Mohit Anchlia wrote: On Mon, Aug 15, 2011 at 12:17 PM, Pid wrote: On 15/08/2011 18:05, Mohit Anchlia wrote: Is this even possible with tomcat? In Tomcat 7.0: abc##SNAPSHOT-01.war abc##SNAPSHOT-02.war abc##SNAPSHOT-03.war abc##SNAPSHOT-04.war etc Sorry I don't follow. Read Pid's e-mail again. Rename your WAR files as per his e-mail. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
Greetings, On Mon, Aug 15, 2011 at 3:39 PM, Mohit Anchlia wrote: Currently when I deploy abc-SNAPSHOT-01.war I access is something like http://localhost:8080/abc-SNAPSHOT-01.war How can I change the context root such that I can access it as http://localhost:8080/abc? Problem is that abc-SNAPSHOT-01.war name could change with the build version change. You could also bundle a META-INF/context.xml file which looks something akin to: -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
On Mon, Aug 15, 2011 at 12:17 PM, Pid wrote: > On 15/08/2011 18:05, Mohit Anchlia wrote: >> Is this even possible with tomcat? > > In Tomcat 7.0: > > abc##SNAPSHOT-01.war > abc##SNAPSHOT-02.war > abc##SNAPSHOT-03.war > abc##SNAPSHOT-04.war > > etc Sorry I don't follow. What do I need to do change such that I can use http://localhost:8080/abc/ instead of http://localhost:8080/abc-snapshort-.xx ? Currently you need to use the war file name in the context since that's how it gets deployed in webapps. > > >> On Thu, Aug 11, 2011 at 12:32 PM, Mohit Anchlia >> wrote: >>> Currently when I deploy abc-SNAPSHOT-01.war I access is something like >>> http://localhost:8080/abc-SNAPSHOT-01.war >>> >>> How can I change the context root such that I can access it as >>> http://localhost:8080/abc? >>> >>> Problem is that abc-SNAPSHOT-01.war name could change with the build >>> version change. >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15/08/2011 19:09, Lataxes, Karl wrote: > I wrote the code to generate the session id and add it as an HTTP header at > the recommendation of someone on the users list. The problem now is > appending the jvmroute to the generated session id in order to get session > stickiness to work. If there were some way for the servlet to retrieve the > jvmRoute from server.xml, I could append it to the session id and get it to > work. I have been looking online for a solution, but have been unable to > find one. Try using JMX. Look up the appropriate object (there are clues in the source of the Manager app) and then retrieve the value of the appropriate attribute. I would experiment with setting this value in the servlet.init() method. p > -Original Message- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Monday, August 15, 2011 12:52 PM > To: users@tomcat.apache.org > Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 > > On 15.08.2011 17:09, Lataxes, Karl wrote: >> Yes, the space before "servlet" is a copy/paste error. >> >> I made the LogFormat additions to httpd.conf, set the mod_jk logging level >> to "debug" and ran some additional tests. >> >> The session id did appear in the access_log I generated: >> >> 2000-1-200-ap-1313413815567 > > So the session ID is wrong, it does not contain the trailing ".tomcat7A" > to allow sticky routing. > > Whatever generates the session id doesn't generate a correct one which > supports stickyness. The session id doesn't look like a normal Tomcat session > id, so it seems something else is setting the JSESSIONID cookie, like a > custom sesion manager. You need to find that piece of code and fix it (to > append the jvmRoute to the id). > > Regards, > > Rainer > >> In the mod_jk.log, I also noted several references to the session id, >> which are included below. Please note that the original client >> request went to worker tomcat7A, but subsequent requests were routed >> to tomcat7C >> >> [Mon Aug 15 09:10:15.614 2011] [3275:1] [debug] >> ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie] >> = [JSESSIONID=2000-1-200-ap-1313413815567] >> [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c >> (1118): service sticky_session=1 id='2000-1-200-ap-1313413815567' >> [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] >> get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial >> sessionid 2000-1-200-ap-1313413815567 [Mon Aug 15 09:10:18.495 2011] >> [3275:1] [debug] get_most_suitable_worker::jk_lb_worker.c (1001): found best >> worker tomcat7C (tomcat7C) using method 'Request' >> >> You can see from the log snippets that "." is not being >> appended to the session as expected. >> >> -Original Message- >> From: Rainer Jung [mailto:rainer.j...@kippdata.de] >> Sent: Saturday, August 13, 2011 8:11 AM >> To: users@tomcat.apache.org >> Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat >> 7.0.8 >> >> On 12.08.2011 15:30, Lataxes, Karl wrote: >>> The jvmRoute's for both server.xmls are properly set to the worker names >>> and are not commented out. This was the first thing I verified. >>> >>> >>> >> jvmRoute="tomcat7C"> >>> >>> Here are the settings in workers.properties (worker tomcat7A identical to >>> tomcat7C except for port, since both are running on the same server for >>> testing. In production, we will probably install them on separate boxes): >>> >>> worker.list=loadbalancer,jkstatus >>> worker.tomcat7C.type=ajp13 >>> worker.tomcat7C.host= >>> worker.tomcat7C.port=4931 >>> worker.tomcat7C.lbfactor=1 >>> worker.loadbalancer.type=lb >>> worker.loadbalancer.balance_workers=tomcat7A,tomcat7C >>> worker.loadbalancer.sticky_session=1 >>> worker.jkstatus.type=status >> >> OK >> >>> Here are the JkMount settings in mod_jk.conf: >>> >>> JkMount /jkmanager/* jkstatus >>> JkMount / servlet/* loadbalancer >> >> I hope the space before "servlet" is a copy and paste error and not in the >> original config ... >> >>> Load balancing is working, but subsequent requests from a single client are >>> being routed to the other Tomcat instance despite sticky_session being set >>> to 1. >> >> OK, then maybe your cookie header is not OK. To debug: >> >> - Add %{Cookie}i to the LogFormat you are using in Apache. It will log all >> cookies. Check the values. >> >> - Add %{JSESSIONID}C to the same LogFormat. It will log the value of the >> JSESSIONID cookie found by the web server. Check the values. >> >> - Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the >> setting of the cookie (sending a cookie from the server to the client). >> Probably of no use for you, since you seem to parse that info in some other >> way. >> >> - Increase log level of mod_jk to debug or even trace (not in >> production) and look at the log lines written when your client sends a >> request, which isn't handled sticky. >> >> Rega
Re: Tomcat war context path
On 15/08/2011 18:05, Mohit Anchlia wrote: > Is this even possible with tomcat? In Tomcat 7.0: abc##SNAPSHOT-01.war abc##SNAPSHOT-02.war abc##SNAPSHOT-03.war abc##SNAPSHOT-04.war etc > On Thu, Aug 11, 2011 at 12:32 PM, Mohit Anchlia > wrote: >> Currently when I deploy abc-SNAPSHOT-01.war I access is something like >> http://localhost:8080/abc-SNAPSHOT-01.war >> >> How can I change the context root such that I can access it as >> http://localhost:8080/abc? >> >> Problem is that abc-SNAPSHOT-01.war name could change with the build >> version change. >> > > - > 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: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
I wrote the code to generate the session id and add it as an HTTP header at the recommendation of someone on the users list. The problem now is appending the jvmroute to the generated session id in order to get session stickiness to work. If there were some way for the servlet to retrieve the jvmRoute from server.xml, I could append it to the session id and get it to work. I have been looking online for a solution, but have been unable to find one. -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Monday, August 15, 2011 12:52 PM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.08.2011 17:09, Lataxes, Karl wrote: > Yes, the space before "servlet" is a copy/paste error. > > I made the LogFormat additions to httpd.conf, set the mod_jk logging level to > "debug" and ran some additional tests. > > The session id did appear in the access_log I generated: > > 2000-1-200-ap-1313413815567 So the session ID is wrong, it does not contain the trailing ".tomcat7A" to allow sticky routing. Whatever generates the session id doesn't generate a correct one which supports stickyness. The session id doesn't look like a normal Tomcat session id, so it seems something else is setting the JSESSIONID cookie, like a custom sesion manager. You need to find that piece of code and fix it (to append the jvmRoute to the id). Regards, Rainer > In the mod_jk.log, I also noted several references to the session id, > which are included below. Please note that the original client > request went to worker tomcat7A, but subsequent requests were routed > to tomcat7C > > [Mon Aug 15 09:10:15.614 2011] [3275:1] [debug] > ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie] > = [JSESSIONID=2000-1-200-ap-1313413815567] > [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c > (1118): service sticky_session=1 id='2000-1-200-ap-1313413815567' > [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] > get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial > sessionid 2000-1-200-ap-1313413815567 [Mon Aug 15 09:10:18.495 2011] [3275:1] > [debug] get_most_suitable_worker::jk_lb_worker.c (1001): found best worker > tomcat7C (tomcat7C) using method 'Request' > > You can see from the log snippets that "." is not being appended > to the session as expected. > > -Original Message- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Saturday, August 13, 2011 8:11 AM > To: users@tomcat.apache.org > Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat > 7.0.8 > > On 12.08.2011 15:30, Lataxes, Karl wrote: >> The jvmRoute's for both server.xmls are properly set to the worker names and >> are not commented out. This was the first thing I verified. >> >> >> > jvmRoute="tomcat7C"> >> >> Here are the settings in workers.properties (worker tomcat7A identical to >> tomcat7C except for port, since both are running on the same server for >> testing. In production, we will probably install them on separate boxes): >> >> worker.list=loadbalancer,jkstatus >> worker.tomcat7C.type=ajp13 >> worker.tomcat7C.host= >> worker.tomcat7C.port=4931 >> worker.tomcat7C.lbfactor=1 >> worker.loadbalancer.type=lb >> worker.loadbalancer.balance_workers=tomcat7A,tomcat7C >> worker.loadbalancer.sticky_session=1 >> worker.jkstatus.type=status > > OK > >> Here are the JkMount settings in mod_jk.conf: >> >> JkMount /jkmanager/* jkstatus >> JkMount / servlet/* loadbalancer > > I hope the space before "servlet" is a copy and paste error and not in the > original config ... > >> Load balancing is working, but subsequent requests from a single client are >> being routed to the other Tomcat instance despite sticky_session being set >> to 1. > > OK, then maybe your cookie header is not OK. To debug: > > - Add %{Cookie}i to the LogFormat you are using in Apache. It will log all > cookies. Check the values. > > - Add %{JSESSIONID}C to the same LogFormat. It will log the value of the > JSESSIONID cookie found by the web server. Check the values. > > - Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting > of the cookie (sending a cookie from the server to the client). > Probably of no use for you, since you seem to parse that info in some other > way. > > - Increase log level of mod_jk to debug or even trace (not in > production) and look at the log lines written when your client sends a > request, which isn't handled sticky. > > 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: Cannot make war file as default app
Thanks Chris, for your answers. My understanding was that tomcat figures out the changes in the re-deployed war file and starts to explode it in order to overwrite the existing exploded directories in order to serve the changes in war file. But it looks like it does not overwrite the exploded folders. I knew that deleting the work directory and webapps exploded directories before every deployment works without any problem. One easy solution i see is why not just use exploded directory structure for deployment instead of war file. Then it will solve my issue as i saw it working.. Just was curious to understand tomcat behavior with war files. Thanks to all for all your replies. -G From: Christopher Schultz To: Tomcat Users List Sent: Monday, August 15, 2011 8:21 AM Subject: Re: Cannot make war file as default app -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G, On 8/12/2011 4:59 PM, exquisite wrote: > Now when i renamed my war to ROOT.war and drop it in webapps folder > (without any context in server.xml), it deploys fine for the first > time as the root app (Creates a ROOT folder in webapps), but if i > make any change to any of my jsps and drop the new ROOT.war file, it > says its deploying ROOT.war but it does not pick the changes after > restart. It keeps showing me the old jsp when i run. I tried with > autoDeploy=true in Host config but there is no change. You shouldn't have to do anything strange to get this working. Tomcat's default configuration is to auto-deploy WARs and directories in the webapps/ directory and also to re-load them if they change. The only thing that can get out-of-sync is the Tomcat deployment descriptor (context.xml) that gets copied from the WAR file (or directory) into conf/[Service]/[Hostname]/[appname].xml. You will have to undeploy/deploy (or just delete the file) in order to update it. > Do i have to manually delete the ROOT folder that tomcat creates, > everytime before the fresh deployment? No, but it might be a good idea to completely shut-down Tomcat, delete the entire "work" directory as well as an exploded WAR directories in webapps/ and any files in conf/[Service]/[Host]. Then, start Tomcat normally and everything should run smoothly from there on out. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5JOWIACgkQ9CaO5/Lv0PAmsACgtCAzkxGLVfTIO9uQa552xpZd gQoAn2qOmcqxgc3WUSOTEp1MRIbvTCc+ =ASxn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple contexts pointing to same WAR
On 15/08/2011 17:49, Johannes Ernst wrote: > I will try that, thanks, and report back. > > If it works, will that create one ClassLoader for foo.war, or two (one per > context?) Two. Always. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
Is this even possible with tomcat? On Thu, Aug 11, 2011 at 12:32 PM, Mohit Anchlia wrote: > Currently when I deploy abc-SNAPSHOT-01.war I access is something like > http://localhost:8080/abc-SNAPSHOT-01.war > > How can I change the context root such that I can access it as > http://localhost:8080/abc? > > Problem is that abc-SNAPSHOT-01.war name could change with the build > version change. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 17:09, Lataxes, Karl wrote: > Yes, the space before "servlet" is a copy/paste error. > > I made the LogFormat additions to httpd.conf, set the mod_jk logging level to > "debug" and ran some additional tests. > > The session id did appear in the access_log I generated: > > 2000-1-200-ap-1313413815567 So the session ID is wrong, it does not contain the trailing ".tomcat7A" to allow sticky routing. Whatever generates the session id doesn't generate a correct one which supports stickyness. The session id doesn't look like a normal Tomcat session id, so it seems something else is setting the JSESSIONID cookie, like a custom sesion manager. You need to find that piece of code and fix it (to append the jvmRoute to the id). Regards, Rainer > In the mod_jk.log, I also noted several references to the session id, which > are included below. Please note that the original client request went to > worker tomcat7A, but subsequent requests were routed to tomcat7C > > [Mon Aug 15 09:10:15.614 2011] [3275:1] [debug] > ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie] = > [JSESSIONID=2000-1-200-ap-1313413815567] > [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c > (1118): service sticky_session=1 id='2000-1-200-ap-1313413815567' > [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] > get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial > sessionid 2000-1-200-ap-1313413815567 > [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] > get_most_suitable_worker::jk_lb_worker.c (1001): found best worker tomcat7C > (tomcat7C) using method 'Request' > > You can see from the log snippets that "." is not being appended > to the session as expected. > > -Original Message- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Saturday, August 13, 2011 8:11 AM > To: users@tomcat.apache.org > Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 > > On 12.08.2011 15:30, Lataxes, Karl wrote: >> The jvmRoute's for both server.xmls are properly set to the worker names and >> are not commented out. This was the first thing I verified. >> >> >> > jvmRoute="tomcat7C"> >> >> Here are the settings in workers.properties (worker tomcat7A identical to >> tomcat7C except for port, since both are running on the same server for >> testing. In production, we will probably install them on separate boxes): >> >> worker.list=loadbalancer,jkstatus >> worker.tomcat7C.type=ajp13 >> worker.tomcat7C.host= >> worker.tomcat7C.port=4931 >> worker.tomcat7C.lbfactor=1 >> worker.loadbalancer.type=lb >> worker.loadbalancer.balance_workers=tomcat7A,tomcat7C >> worker.loadbalancer.sticky_session=1 >> worker.jkstatus.type=status > > OK > >> Here are the JkMount settings in mod_jk.conf: >> >> JkMount /jkmanager/* jkstatus >> JkMount / servlet/* loadbalancer > > I hope the space before "servlet" is a copy and paste error and not in the > original config ... > >> Load balancing is working, but subsequent requests from a single client are >> being routed to the other Tomcat instance despite sticky_session being set >> to 1. > > OK, then maybe your cookie header is not OK. To debug: > > - Add %{Cookie}i to the LogFormat you are using in Apache. It will log all > cookies. Check the values. > > - Add %{JSESSIONID}C to the same LogFormat. It will log the value of the > JSESSIONID cookie found by the web server. Check the values. > > - Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting > of the cookie (sending a cookie from the server to the client). > Probably of no use for you, since you seem to parse that info in some other > way. > > - Increase log level of mod_jk to debug or even trace (not in > production) and look at the log lines written when your client sends a > request, which isn't handled sticky. > > Regards, > > Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple contexts pointing to same WAR
I will try that, thanks, and report back. If it works, will that create one ClassLoader for foo.war, or two (one per context?) On Aug 15, 2011, at 9:43, Mark Thomas wrote: > On 15/08/2011 17:38, Johannes Ernst wrote: >> I'd like to run the same web app at multiple paths in Tomcat 6, e.g. >> /foo1 -> foo.war >> /foo2 -> foo.war >> >> I was thinking of creating >> $CATALINA_BASE/conf/[enginename]/[hostname]/foo1.xml >> $CATALINA_BASE/conf/[enginename]/[hostname]/foo2.xml >> with different entries for database names etc. but having >> docBase >> point to the same war, e.g. >> /usr/share/foo/foo.war >> >> But documentation >> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html >> in the docBase section seems to say that this won't give me autoDeploy >> functionality. >> >> How can do I this so I can make updates to the app without restarting >> Tomcat? Do I have to duplicate the WAR into foo1.war and foo2.war? > > Try it an see what happens. If you don't get updates when the WAR > changes, you can almost certainly get it working by via watched resources. > > Mark > > - > 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: j_security_check and RequestDispatcher forward
2011/8/15 Chen Paz : > > Hi, > > I am using a servlet to intercept form based authentication in order to > insert attribute into the request What parameter do you want to insert into the request ? I don't know, but maybe you can do the same with a custom realm Or, using by Spring Security - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple contexts pointing to same WAR
On 15/08/2011 17:38, Johannes Ernst wrote: > I'd like to run the same web app at multiple paths in Tomcat 6, e.g. > /foo1 -> foo.war > /foo2 -> foo.war > > I was thinking of creating > $CATALINA_BASE/conf/[enginename]/[hostname]/foo1.xml > $CATALINA_BASE/conf/[enginename]/[hostname]/foo2.xml > with different entries for database names etc. but having > docBase > point to the same war, e.g. > /usr/share/foo/foo.war > > But documentation > http://tomcat.apache.org/tomcat-6.0-doc/config/context.html > in the docBase section seems to say that this won't give me autoDeploy > functionality. > > How can do I this so I can make updates to the app without restarting Tomcat? > Do I have to duplicate the WAR into foo1.war and foo2.war? Try it an see what happens. If you don't get updates when the WAR changes, you can almost certainly get it working by via watched resources. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Multiple contexts pointing to same WAR
I'd like to run the same web app at multiple paths in Tomcat 6, e.g. /foo1 -> foo.war /foo2 -> foo.war I was thinking of creating $CATALINA_BASE/conf/[enginename]/[hostname]/foo1.xml $CATALINA_BASE/conf/[enginename]/[hostname]/foo2.xml with different entries for database names etc. but having docBase point to the same war, e.g. /usr/share/foo/foo.war But documentation http://tomcat.apache.org/tomcat-6.0-doc/config/context.html in the docBase section seems to say that this won't give me autoDeploy functionality. How can do I this so I can make updates to the app without restarting Tomcat? Do I have to duplicate the WAR into foo1.war and foo2.war? Thanks, Johannes. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: j_security_check and RequestDispatcher forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 8/15/2011 9:49 AM, Caldarale, Charles R wrote: >> From: Chen Paz [mailto:chen@expand.com] Subject: >> j_security_check and RequestDispatcher forward > >> I am using a servlet to intercept form based authentication in >> order to insert attribute into the request and then to redirect the >> request to j_security_check using RequestDispatcher. > > I wouldn't expect that to work, due to the special handling > requirements of j_security_check, in particular that the container > remember the original request of the protected resource and replay it > automatically when authentication is successful. > > What you might want to try is a filter rather than a servlet, and > have the filter modify the j_security_check request when it comes > through. (Not completely sure that's possible, either.) Another > option is to use a ServletRequestListener to manipulate requests as > needed. This may have changed in 7.0.x, but IIRC you can't intercept a request to j_security_check using a Filter... you'll have to use a Valve and make sure it fires before the authentication valve. Otherwise, the authenticator will have processed the request before your filter (or valve) gets a chance to do anything with it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5JRbUACgkQ9CaO5/Lv0PDTpQCdH/QKcJ/Eh1a6siRy4IRmBVmW jF4An0DS/yoxiY/32En6xv8BhS2tRhlu =hKm2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot make war file as default app
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G, On 8/12/2011 4:59 PM, exquisite wrote: > Now when i renamed my war to ROOT.war and drop it in webapps folder > (without any context in server.xml), it deploys fine for the first > time as the root app (Creates a ROOT folder in webapps), but if i > make any change to any of my jsps and drop the new ROOT.war file, it > says its deploying ROOT.war but it does not pick the changes after > restart. It keeps showing me the old jsp when i run. I tried with > autoDeploy=true in Host config but there is no change. You shouldn't have to do anything strange to get this working. Tomcat's default configuration is to auto-deploy WARs and directories in the webapps/ directory and also to re-load them if they change. The only thing that can get out-of-sync is the Tomcat deployment descriptor (context.xml) that gets copied from the WAR file (or directory) into conf/[Service]/[Hostname]/[appname].xml. You will have to undeploy/deploy (or just delete the file) in order to update it. > Do i have to manually delete the ROOT folder that tomcat creates, > everytime before the fresh deployment? No, but it might be a good idea to completely shut-down Tomcat, delete the entire "work" directory as well as an exploded WAR directories in webapps/ and any files in conf/[Service]/[Host]. Then, start Tomcat normally and everything should run smoothly from there on out. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5JOWIACgkQ9CaO5/Lv0PAmsACgtCAzkxGLVfTIO9uQa552xpZd gQoAn2qOmcqxgc3WUSOTEp1MRIbvTCc+ =ASxn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Yes, the space before "servlet" is a copy/paste error. I made the LogFormat additions to httpd.conf, set the mod_jk logging level to "debug" and ran some additional tests. The session id did appear in the access_log I generated: 2000-1-200-ap-1313413815567 In the mod_jk.log, I also noted several references to the session id, which are included below. Please note that the original client request went to worker tomcat7A, but subsequent requests were routed to tomcat7C [Mon Aug 15 09:10:15.614 2011] [3275:1] [debug] ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie] = [JSESSIONID=2000-1-200-ap-1313413815567] [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c (1118): service sticky_session=1 id='2000-1-200-ap-1313413815567' [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial sessionid 2000-1-200-ap-1313413815567 [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] get_most_suitable_worker::jk_lb_worker.c (1001): found best worker tomcat7C (tomcat7C) using method 'Request' You can see from the log snippets that "." is not being appended to the session as expected. -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Saturday, August 13, 2011 8:11 AM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 12.08.2011 15:30, Lataxes, Karl wrote: > The jvmRoute's for both server.xmls are properly set to the worker names and > are not commented out. This was the first thing I verified. > > > jvmRoute="tomcat7C"> > > Here are the settings in workers.properties (worker tomcat7A identical to > tomcat7C except for port, since both are running on the same server for > testing. In production, we will probably install them on separate boxes): > > worker.list=loadbalancer,jkstatus > worker.tomcat7C.type=ajp13 > worker.tomcat7C.host= > worker.tomcat7C.port=4931 > worker.tomcat7C.lbfactor=1 > worker.loadbalancer.type=lb > worker.loadbalancer.balance_workers=tomcat7A,tomcat7C > worker.loadbalancer.sticky_session=1 > worker.jkstatus.type=status OK > Here are the JkMount settings in mod_jk.conf: > > JkMount /jkmanager/* jkstatus > JkMount / servlet/* loadbalancer I hope the space before "servlet" is a copy and paste error and not in the original config ... > Load balancing is working, but subsequent requests from a single client are > being routed to the other Tomcat instance despite sticky_session being set to > 1. OK, then maybe your cookie header is not OK. To debug: - Add %{Cookie}i to the LogFormat you are using in Apache. It will log all cookies. Check the values. - Add %{JSESSIONID}C to the same LogFormat. It will log the value of the JSESSIONID cookie found by the web server. Check the values. - Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting of the cookie (sending a cookie from the server to the client). Probably of no use for you, since you seem to parse that info in some other way. - Increase log level of mod_jk to debug or even trace (not in production) and look at the log lines written when your client sends a request, which isn't handled sticky. 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: j_security_check and RequestDispatcher forward
Filter is not possible. AFAIK you can not use filter before j_security_check in Tomcat... -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Monday, August 15, 2011 4:50 PM To: Tomcat Users List Subject: RE: j_security_check and RequestDispatcher forward > From: Chen Paz [mailto:chen@expand.com] > Subject: j_security_check and RequestDispatcher forward > I am using a servlet to intercept form based authentication in order > to insert attribute into the request and then to redirect the request > to j_security_check using RequestDispatcher. I wouldn't expect that to work, due to the special handling requirements of j_security_check, in particular that the container remember the original request of the protected resource and replay it automatically when authentication is successful. What you might want to try is a filter rather than a servlet, and have the filter modify the j_security_check request when it comes through. (Not completely sure that's possible, either.) Another option is to use a ServletRequestListener to manipulate requests as needed. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: j_security_check and RequestDispatcher forward
> From: Chen Paz [mailto:chen@expand.com] > Subject: j_security_check and RequestDispatcher forward > I am using a servlet to intercept form based authentication in order > to insert attribute into the request and then to redirect the request > to j_security_check using RequestDispatcher. I wouldn't expect that to work, due to the special handling requirements of j_security_check, in particular that the container remember the original request of the protected resource and replay it automatically when authentication is successful. What you might want to try is a filter rather than a servlet, and have the filter modify the j_security_check request when it comes through. (Not completely sure that's possible, either.) Another option is to use a ServletRequestListener to manipulate requests as needed. - 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
j_security_check and RequestDispatcher forward
Hi, I am using a servlet to intercept form based authentication in order to insert attribute into the request and then to redirect the request to j_security_check using RequestDispatcher. But I'm getting a 404 page with the following error: type Status report message /myApp/j_security_check description The requested resource (/MyApp/j_security_check) is not available. If I'm going directly to /MyApp/j_security_check using my browser - j_security_check is found Here is the code snippet: String params = "j_username=" + request.getParameter("j_username") + "&j_password=" + request.getParameter("j_password"); String encodedSecurityURL = response.encodeRedirectURL("/j_security_check?" + params); RequestDispatcher dispatcher ; dispatcher = getServletContext().getRequestDispatcher(encodedSecurityURL); dispatcher.forward( request, response); Does anyone know why the code does not work but the direct call using the browser does work? Regards, Chen Paz