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
