André, My "marching order" was to setup a four member tomcat cluster on two machines and have a fail over for minimum one of the apaches. Then I reduced the number tomcats to two, one on each machine.
My understanding is that although the user base for the app running on this setup will be relatively small - 20-30 users, but they will access it frequently. So they needed a solution where sessions are failing over nicely when they want do maintenance on one of the tomcats. Testing will show them if this solution is viable for their purpose or not. If not, then I probably will come to the list with other questions :-) (In 1986-1988 I was in Switzerland. The Swiss did the same, with the exception that they went home after 18:00 or 19:00 :-) I remember one time I went to work from St. Gallen to Rorschach , let say wednesday morning and I was able to get back to St. Gallen on Friday evening. By the way, the man I had to work was a German :-) I got my pay from him via the Swiss Red Cross, because just by himself he thought I was not deserving the money, because I did sleep 2 x 5hours from wednesday morning to friday evening .) Thanks a lot, János On Mar 24, 2011, at 4:46 AM, André Warnier wrote: > Hi. > > Glad that you resolved the problem, and that maybe something out of my > guessing helped you do so. > > This being said, I am still a bit curious about your setup, and what it > achieves. > > I understand the balancing bit to some extent. But you are aware that, while > the first front-end Apache is proxying to the second Apache (maybe itself), > and that second Apache is proxying to one of the Tomcats, all these > intermediate processes are waiting for their respective response, and > unavailable to process other requests, right ? > I mean, it is not like a re-direct, where the server tells the browser "wrong > address, go somehere else". When the first Apache (child) runs the mod_proxy > module to proxy the call to the second Apache, that first Apache actually has > to sit there, waiting for the response from the second Apache; and so on. > And when the whole chain happens to be on the first Apache server, then all > these resources are temporarily locked up on that same host. What I am > wondering about is if the overhead of what you are doing in terms of proxying > does not totally negate whatever advantage you may gain by the load-balancing > part. > > > (And I am at the moment in Germany, where people get to work at 8:00, go to > lunch at 11:30 for 1/2 hour max, and are tired and go home at 16:30. And > it's even worse : they expect foreigners like me to do the same.) > > > János Löbb wrote: >> André, >> What kind of "late afternoon" ?? I thought for folks in Western-Europe the >> day starts at late afternoon :-) The good folks of France just get out from >> the bed at that time, just like the "nyarleans" here in the States :-) >> Thanks a lot for the excellent explanation of the process below. I truly >> appreciate your effort. >> I checked on my cookies and found that the one associated with the >> bml0065.yalepath.org machine and with the path of /examples was changing >> its content all the time. So then I looked the bottom of your email and I >> saw this long named creatures from NewZeeLand christened >> ProxyPassReverseCoockieDomain. Punched it into Google and there came my >> solution right on the first page: >> http://www.experts-exchange.com/Software/Server_Software/Web_Servers/Q_22444213.html >> Old Hungarian proverb: "Even the blind hen is finding the corn" :-) >> After some scrolling, I found Nick Kew article at >> http://www.apachetutor.org/admin/reverseproxies >> /Thanks Nick !!!!/ >> Right now my very basic reverse proxy config looks like this: >> ProxyRequests Off >> <Proxy balancer://pathCluster> >> BalancerMember http://bml0065.yalepath.org loadfactor=10 route=tomcat3 >> BalancerMember http://bml0066.yalepath.org loadfactor=10 route=tomcat1 >> ProxySet lbmethod=bytraffic >> </Proxy> >> ProxyPass /tc/ balancer://pathCluster/ stickysession=JSESSIONID|jsessionid >> ProxyPassReverse /tc/ balancer://pathCluster/ >> ProxyPassReverseCookiePAth / / >> ProxyPassReverseCookieDomain / / >> and now everything works again like charm :-) Tomcats can fail over and >> Httpds can fail over and the session is still good and valid. There is a >> space between the two "/" character above. >> Now off to self signing some certificates, configure the ssl.conf file and I >> am almost done :-) >> Thanks again, >> János >> On Mar 23, 2011, at 1:01 PM, André Warnier wrote: >>> The setup with the first HTTP proxy and then the JK proxy is a bit >>> confusing, and on this late afternoon I am not in my best guessing mode, >>> but what I was thinking about was something like this : >>> (Oh, and I have to add that I am not quite clear at the moment as to when >>> Tomcat uses a cookie to return the session-id, or appends it to the URL; >>> but anyway..) >>> >>> 1) the browser sends a request, with ultimate goal Tomcat >>> 2) the request is picked up by the front-end Apache, which proxies it to >>> the back-end Apache via HTTP, after removing the /tc/ bit of the URL. >>> 3) the back-end Apache (maybe the same one as (2)) now examines the URL, >>> and decides that it has to be proxied to Tomcat via JK. So it does that. >>> 4) the back-back-end Tomcat receives the request, creates a new session, >>> etc, and returns a response which includes a JSESSIONID cookie. >>> Presumably, in the JSESSIONID cookie, there is a "cookie domain", which >>> says for which domain this cookie is valid. >>> 5) the response goes back through the chain and arrives at the browser. The >>> browser stores the cookie, associated to the cookie domain indicated in the >>> cookie. >>> 6) the browser now sends a second request. To retrieve the same session, >>> it should send that JSESSIONID cookie back with the second request. But is >>> does not, because the cookie domain does not match the server to which it >>> is talking now (the front-end Apache). >>> 7) so the request leaves the browser without the cookie, arrives at the >>> front-end Apache, is proxied again twice, and arrives at Tomcat without the >>> JSESSIONID cookie. >>> So Tomcat thinks this request does not have a session yet, and creates a >>> new one. >>> >>> In other words, somewhere in your chain of proxies, something happens to >>> the cookie (or does not happen), which causes the cookie domain to mismatch >>> the server to which the browser is talking. >>> >>> The rest is left as an exercise to the reader. >>> >>> Maybe you are just missing a ProxyPassReverseCookieDomain directive >>> somewhere. >>> >>> (but this is all just a late-afternoon guess, remember ?) >>> >>> >>> >>> János Löbb wrote: >>>> Hi André, >>>> Her is the content of one of the workers.properties file. On the other >>>> machine the names are changed accordingly: >>>> bml0065:local administrator$ cat apache2/conf/workers.properties >>>> worker.list = lb,jkstatus >>>> worker.lb.type=lb >>>> worker.lb.balance_workers=tomcat1,tomcat3 >>>> #,tomcat2,tomcat4 >>>> worker.lb.sticky_session = True >>>> worker.lb.sticky_session_force = False >>>> worker.jkstatus.type=status >>>> worker.tomcat1.type = ajp13 >>>> worker.tomcat1.host = bml0066.yalepath.org >>>> worker.tomcat1.port = 8109 >>>> worker.tomcat1.lbfactor = 1 >>>> worker.tomcat1.redirect=tomcat3 >>>> #worker.tomcat2.type = ajp13 >>>> #worker.tomcat2.host = bml0066.yalepath.org >>>> #worker.tomcat2.port = 8209 >>>> #worker.tomcat2.lbfactor = 1 >>>> #worker.tomcat2.redirect=tomcat4 >>>> worker.tomcat3.type = ajp13 >>>> worker.tomcat3.host = bml0065.yalepath.org >>>> worker.tomcat3.port = 8309 >>>> worker.tomcat3.lbfactor = 1 >>>> worker.tomcat3.redirect=tomcat1 >>>> #worker.tomcat4.type = ajp13 >>>> #worker.tomcat4.host = bml0065.yalepath.org >>>> #worker.tomcat4.port = 8409 >>>> #worker.tomcat4.lbfactor = 1 >>>> #worker.tomcat4.redirect=tomcat2 >>>> Originally planned 2 tomcats per machine but now I try to simplify as much >>>> as I can. >>>> My next step is to set logging to debug and try to split the atoms to see >>>> where do I have the disaster. Let me know if you see something wrong or >>>> suspicious. There was an occasion when for the worker on the actual >>>> machine I used localhost for host and that also worked when I just load >>>> balanced tomcats by selecting one or the other proxy balance members >>>> directly without using the reverse proxy. Then for the sake of clearness >>>> I specified the FQDN for hostnames. >>>> Thanks ahead, >>>> János >>>> On Mar 23, 2011, at 11:42 AM, André Warnier wrote: >>>>> Just a vague suspicion.. >>>>> >>>>> What are the hostnames which you use in your workers.properties, for the >>>>> Tomcats ? >>>>> >>>>> >>>>> >>>>> János Löbb wrote: >>>>>> Hi Igor, >>>>>> I use mod-proxy to balance the apaches/httpds. I use mod-jk t balance >>>>>> the tomcats. For the tomcats f course I also have the >>>>>> workers.properties files in the apache2/conf directory. When invoke the >>>>>> URL to the individual balance members, everything works fine. It is >>>>>> when I try to use the reverse proxy then every attempt to any of the >>>>>> tomcats creates a new session, so fail over does not work. >>>>>> Thanks, >>>>>> János >>>>>> On Mar 22, 2011, at 6:59 PM, Igor Cicimov wrote: >>>>>>> Interesting I had no idea you can mix mod_proxy and mod_jk, thought you >>>>>>> should use the one or the other. What I do I have workers.properties >>>>>>> file in >>>>>>> the Apache conf directory with load-balancer worker that takes care of >>>>>>> the >>>>>>> load balancing ans sticky sessions. >>>>>>> >>>>>>> On Wed, Mar 23, 2011 at 8:54 AM, János Löbb <janos.l...@yale.edu> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have two machines bml0065.yalepath.org and bml0066.yalepath.org. >>>>>>>> Both >>>>>>>> have OSX 10.6.6, apache 2.2.17 and mod_jk 1.2.31 installed. Tomcat is >>>>>>>> 7.0.10 on both. >>>>>>>> >>>>>>>> Apache was compiled on both machines with proxy, proxy-balancer, >>>>>>>> proxy-http >>>>>>>> and proxy-ajp enabled. >>>>>>>> >>>>>>>> The bml0065 machine is configured as a reverse proxy. >>>>>>>> >>>>>>>> The theory is, that users hit the bml0065 machine like >>>>>>>> >>>>>>>> http://bml0065.yalepath.org/tc/examples/servlets/servlet/SessionExample >>>>>>>> >>>>>>>> and using mod-proxy and mod-proxy-http it will select either bml0065 or >>>>>>>> bml0066 depending on the lbmethod configured. Then let say it selects >>>>>>>> bml0065. Then it comes to this machine as: >>>>>>>> >>>>>>>> http://bml0065.yalepath.org/examples/servlets/servlet/SessionExample >>>>>>>> >>>>>>>> From here, because there is a JkMount for examples in its httpd.conf, >>>>>>>> it >>>>>>>> connects via mod_jk to the Tomcat instance on this machine, in this >>>>>>>> case >>>>>>>> tomcat3. >>>>>>>> >>>>>>>> The problem is that as soon the reverse proxy is involved new sessions >>>>>>>> are >>>>>>>> created all the time, so session failover do not work. If I take the >>>>>>>> reverse proxy out from the picture, everything works. >>>>>>>> >>>>>>>> Here is the reverse proxy config from httpd.conf of the bml0065 machine >>>>>>>> >>>>>>>> JkLogLevel info >>>>>>>> JkMount /examples/* lb >>>>>>>> JkMount /examples/servlets/servlet/* lb >>>>>>>> JkMount /jkmanager/* jkstatus >>>>>>>> JkWorkersFile "/usr/local/apache2/conf/workers.properties" >>>>>>>> JkLogFile "/usr/local/apache2/logs/mod_jk.log >>>>>>>> >>>>>>>> ProxyRequests Off >>>>>>>> <Proxy balancer://pathCluster> >>>>>>>> BalancerMember http://bml0065.yalepath.org loadfactor=10 >>>>>>>> route=tomcat3 >>>>>>>> BalancerMember http://bml0066.yalepath.org loadfactor=10 >>>>>>>> route=tomcat1 >>>>>>>> ProxySet lbmethod=bytraffic >>>>>>>> </Proxy> >>>>>>>> ProxyPass /tc/ balancer://pathCluster/ >>>>>>>> stickysession=JSESSIONID|jsessionid >>>>>>>> ProxyPassReverse /tc/ balancer://pathCluster/ >>>>>>>> >>>>>>>> >>>>>>>> <Location /balancer-manager> >>>>>>>> SetHandler balancer-manager >>>>>>>> Order Deny,Allow >>>>>>>> Allow from .yalepath.org >>>>>>>> </Location> >>>>>>>> >>>>>>>> A very similar setup worked in 2009 with Tomcat 6.0.18 and httpd >>>>>>>> 2.2.11. >>>>>>>> >>>>>>>> Here are the snippets from both machine catalina.out file >>>>>>>> >>>>>>>> <snip bml0065> >>>>>>>> Mar 22, 2011 5:06:11 PM org.apache.catalina.core.ApplicationContext log >>>>>>>> INFO: SessionListener: >>>>>>>> sessionCreated('0409F29D221545DB0BB5F62205B24471.tomcat3') >>>>>>>> Mar 22, 2011 5:06:11 PM org.apache.catalina.core.ApplicationContext log >>>>>>>> INFO: SessionListener: >>>>>>>> attributeAdded('0409F29D221545DB0BB5F62205B24471.tomcat3', 's1', 't3') >>>>>>>> Mar 22, 2011 5:07:06 PM org.apache.catalina.core.ApplicationContext log >>>>>>>> INFO: SessionListener: >>>>>>>> sessionCreated('DE7A014A0F1659F0B777E0DF4A2355D4.tomcat3') >>>>>>>> Mar 22, 2011 5:07:06 PM org.apache.catalina.core.ApplicationContext log >>>>>>>> INFO: SessionListener: >>>>>>>> attributeAdded('DE7A014A0F1659F0B777E0DF4A2355D4.tomcat3', 's2', 't3') >>>>>>>> </snip> >>>>>>>> >>>>>>>> <snip bml0066> >>>>>>>> Mar 22, 2011 5:06:11 PM org.apache.catalina.core.ApplicationContext log >>>>>>>> INFO: SessionListener: >>>>>>>> sessionCreated('0409F29D221545DB0BB5F62205B24471.tomcat3') >>>>>>>> Mar 22, 2011 5:06:11 PM org.apache.catalina.core.ApplicationContext log >>>>>>>> INFO: SessionListener: >>>>>>>> attributeAdded('0409F29D221545DB0BB5F62205B24471.tomcat3', 's1', 't3') >>>>>>>> Mar 22, 2011 5:07:06 PM org.apache.catalina.core.ApplicationContext log >>>>>>>> INFO: SessionListener: >>>>>>>> sessionCreated('DE7A014A0F1659F0B777E0DF4A2355D4.tomcat3') >>>>>>>> Mar 22, 2011 5:07:06 PM org.apache.catalina.core.ApplicationContext log >>>>>>>> INFO: SessionListener: >>>>>>>> attributeAdded('DE7A014A0F1659F0B777E0DF4A2355D4.tomcat3', 's2', 't3') >>>>>>>> </snip> >>>>>>>> >>>>>>>> >>>>>>>> Here is the last access session from the access_log: >>>>>>>> <snip bml0065> >>>>>>>> 10.84.2.65 - - [22/Mar/2011:17:06:11 -0400] "POST >>>>>>>> /examples/servlets/servlet/SessionExample HTTP/1.1" 200 1114 >>>>>>>> 10.84.2.41 - - [22/Mar/2011:17:06:11 -0400] "POST >>>>>>>> /tc/examples/servlets/servlet/SessionExample HTTP/1.1" 200 1114 >>>>>>>> 10.84.2.65 - - [22/Mar/2011:17:06:11 -0400] "GET >>>>>>>> /examples/servlets/images/code.gif HTTP/1.1" 304 - >>>>>>>> 10.84.2.41 - - [22/Mar/2011:17:06:11 -0400] "GET >>>>>>>> /tc/examples/servlets/images/code.gif HTTP/1.1" 304 - >>>>>>>> 10.84.2.65 - - [22/Mar/2011:17:06:11 -0400] "GET >>>>>>>> /examples/servlets/images/return.gif HTTP/1.1" 304 - >>>>>>>> 10.84.2.41 - - [22/Mar/2011:17:06:11 -0400] "GET >>>>>>>> /tc/examples/servlets/images/return.gif HTTP/1.1" 304 - >>>>>>>> ::1 - - [22/Mar/2011:17:06:18 -0400] "OPTIONS * HTTP/1.0" 200 - >>>>>>>> ::1 - - [22/Mar/2011:17:06:19 -0400] "OPTIONS * HTTP/1.0" 200 - >>>>>>>> 10.84.2.65 - - [22/Mar/2011:17:07:06 -0400] "POST >>>>>>>> /examples/servlets/servlet/SessionExample HTTP/1.1" 200 1114 >>>>>>>> 10.84.2.41 - - [22/Mar/2011:17:07:06 -0400] "POST >>>>>>>> /tc/examples/servlets/servlet/SessionExample HTTP/1.1" 200 1114 >>>>>>>> </snip> >>>>>>>> >>>>>>>> The 10.84.2.41 is my machine. In the log above looks like the hit to >>>>>>>> the >>>>>>>> reverse proxy - with the /tc/ start - inserted later than the >>>>>>>> converted url >>>>>>>> for the given balance member. >>>>>>>> >>>>>>>> There is nothing interesting in the apache error_log. >>>>>>>> >>>>>>>> What am I doing wrong ? >>>>>>>> >>>>>>>> This is a test cluster. The application developer wants to test his >>>>>>>> app's >>>>>>>> failover by pulling the ethernet plug out from the non reverse proxy >>>>>>>> when >>>>>>>> the session is on that machine. >>>>>>>> >>>>>>>> Thanks ahead, >>>>>>>> >>>>>>>> János >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> 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 >>>> --------------------------------------------------------------------- >>>> 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 > > > --------------------------------------------------------------------- > 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
