tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: reverse proxy and tomcat
Date Thu, 24 Mar 2011 08:46:50 GMT
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.lobb@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-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message