Hi Chris,
In our production environment we have 3 Xserves, all running apache2 ,
mod+jk and Tomcat. There are about 5-6 web applications running on
these 3 servers standalone, -non-clustered - and there will be more.
The there Xserves are doing other things too, not just web serving.
That is the reason I cannot reduce the number of apache2 instances.
They grandfathered in themselves :)
This CassetteLabeler app is our first application that needs to be up
all the time and that is why we turned to clustering, using the
existing setups on these servers and hoping that just by small config
changes here and there we can get our clustered app runing without
worrying about the non-clustered apps. You know, the goat has to have
a full stomach and the cabbage had to remain too :) . Not to destroy
accidently anything in the production environment, I created a small
test environment, simulating our production environment. Because I do
not have 3 machines, I used the VmWare Fussion on my Mac with Windows
XP to create the third machine, and to simplify things I do not run
mod_jk and Tomcat on it just Apache2.
The four Tomcats are forming a Tomcat Cluster. Because the individual
Apaches have to communicate to their own Tomcats via their own mod_jk
for the non-clustered webapps /non-clustered because they cannot be
serialized/ to reach those apps, the users connect via:
http://balancemember1.yalepath.org/Standalone1
kind of URL and it goes through port 80 to mod_jk and mod_jk passes it
via ajp to to the appropriate tomcat. We need to preserve this
behavior for the clustered app, that is why in the reversed proxy
configuration the default port 80 is used. I do not think that I can
changed that one.
The reason for the reverse proxy is, that two of the machines in
production are behind a Pix firewall and the users of the clustered
app can get to it by hitting the reverse proxy.
So in theory a user would hit a url like:
http://reverse_proxy.yalepath.org/tc/CassetteLabeler
The reverse proxy using mod_proxy, mod_proxy_balancer, mod_proxy_http
would transfer it to one of the balancemembers via port 80 by the
selected lbmethod. It would arrive there as:
http://balancememberX.yalepath.org/CassetteLabeler
The selected balance member seeing that there is a JkMount for that
request would involve mod_jk and mod_jk would forward it via the ajp
connector to one of the selected tomcats from the cluster. /Or that
is how I imagine it :)/
Looks like the initial request is received by the reverse proxy. It
selects a balance member and sends the request to it correctly, that
is stripping off the /tc. Tha balancemember involves mod_jk and
mod_jk forwards it to one of the clustered tomcats. Looking the debug
info tomcat is doing its job and even asks for the body and receives
it. Then tomcat is closing the connection to the balance member.
That is where things get out of control. Then the selected balance
member instead of continue with the earlier selected tomcat instance -
although stickiness is specified - selects another tomcat node and
sends the SAME info to it. This second tomcat does exactly as the
first one did and it closes the connection. At that point the
balancemember /or the reverse proxy/ sends the non-formated URL from
the reverse proxy to the Apache of the second tomcat node and of
course that cannot be resolved so I get a 404 error.
So, I am looking why stickiness is not working, why the selected
balancemember is not satisfied with the firstly selected tomcat node
and just finishing the whole session with it, so the right info can
flow back on the chain to the clients browser and paint the first form
of the web app.
Now I configured stickyness even in ProxyPass on the reverse proxy,
but no cigar.
ProxyRequests Off
<Proxy balancer://pathCluster>
BalancerMember http://bml0039.yalepath.org loadfactor=10
BalancerMember http://bml0073.yalepath.org loadfactor=10
ProxySet lbmethod=bytraffic
</Proxy>
ProxyPass /tc/ balancer://pathCluster/ stickysession=JSESSIONID
ProxyPassReverse /tc/ balancer://pathCluster/
#ProxyHTMLLogVerbose On
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Allow from .yalepath.org
</Location>
I would like to emphasize that when I request the web app from the
individual balance members using of course port 80, like:
http://balancemember1.yalepath.org/CassetteLabeler
or
http://balancemember2.yalepath.org/Cassettelabeler
, everything is working right. The problem is somewhere as the info
is flowing back in the chain to the reverse proxy.
Thanks ahead,
János
On Mar 25, 2009, at 9:33 AM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
János,
On 3/20/2009 1:48 PM, János Löbb wrote:
<Connector port="8280" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8643" />
<Connector port="8209" protocol="AJP/1.3" redirectPort="8643" />
[snip]
ProxyRequests Off
<Proxy balancer://pathCluster>
BalancerMember http://bml0039.yalepath.org loadfactor=10
BalancerMember http://bml0073.yalepath.org loadfactor=10
Note that you have configured your Tomcat to listen for HTTP on port
8280, but your <Proxy> configuration points to port 80. This isn't
going
to work.
Here is the workers.property file:
<snip>
bml0073:local janos$ cat apache2/conf/workers.properties
worker.list = lb,jkstatus
This looks like workers.properties, which is a mod_jk thing. You are
using mod_proxy_http. This isn't going to work for two reasons:
1. mod_proxy_http uses HTTP as the protocol and mod_jk uses AJP
2. mod_proxy_http doesn't read workers.properties, so the file
is not relevant
Similar workers.properies on the XP machine but the hosts are
logically
different
If your Windows XP machine runs Tomcat only, then the presence of a
workers.properties file is not relevant.
Well, this setup worked in December.
Very unlikely.
The request from the reverse proxy did go to the XP machine:
Here are the log entries from the access log:
<snip>
10.84.2.195 - - [20/Mar/2009:12:09:49 -0400] "GET /CassetteLabeler
HTTP/1.1" 302 -
</snip>
Wait... are you running 3 copies of Apache httpd? No wonder there's
tons
and tons configuration. You only need one single httpd instance: the
one
doing the load-balancing. Configure /all/ of the TC instances that are
part of the balancing setup in that one httpd. What you've done is set
up load balancing across two httpd instances that then load-balance
to a
set of webapp servers. I can only think of a single reason to ever do
that (you want lopsided load balancing) but it still doesn't make
any sense.
Lose the additional httpd instances and simplify your life, man. Then
there won't be so much confusion over port numbers, forwarding,
proxying, etc.
Here are the entries from mod_jk.log of this XP machine:
<snip>
[Fri Mar 20 12:09:49.254 2009] [852:1808] [debug] jk_uri_worker_map.c
(682): Attempting to map URI '/CassetteLabeler' from 5 maps
Ugh. Okay, so you are using mod_proxy_http for the main httpd and
mod_jk
from the other ones. That's not confusing at all.
I would highly recommend that you simplify your configuration unless
you
have a real need to complicate it.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAknKMrUACgkQ9CaO5/Lv0PBjrACgvAP1zKwFa2wYlx7O4cvPx7DC
JhAAoLd4B7HnrjSX+8f7IcoivwJcpiDs
=/8Rs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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
