Using sticky sessions will allow only requests without sessions to be
balanced freely. If you've either got many sessions, or your sessions
are relatively short, than load balancing will statistically still good.
Only in case of few long lasting sessions, you could experience the
problem, that some heavy-use sessions might go to the same node.
In case you've got only two nodes and you are building an HA
infrastructure, the optimality of the load balancing is not important,
because one node needs to be able to carry the full load anyhow.
Throughput oriented webapps balance best with method "Request".
Most installations I know observe a good load balancing although they
are using stickyness. I would rate a deviation of +/- 15% load
difference relative to the arithmetic mean over a 10 minute interval as
"good".
Periods of low load don't count at all.
Regards,
Rainer
ben short wrote:
So how does setting sticky sessions to true and the default value for
the Load Balancing Directive 'method' (defaults to request) interact
then?
On 7/30/07, Rainer Jung <[EMAIL PROTECTED]> wrote:
Apart from all the other things I wrote: don't turn off session
stickyness, even if you use replication. Turn it off only, if you've got
a really good reason. The fact that switching the backend between
requests is possible with replication should not lead to the assumption,
that it is a good idea to do this continuously.
ben short wrote:
Hi Rainer,
By shutdown I mean I have clicked the 'stop' link on the tomcat manager page.
Im also using session replication between the two tomcats.
I have just tried turning off firefoxes cache and I see the same result.
On 7/30/07, Rainer Jung <[EMAIL PROTECTED]> wrote:
Hi Ben,
I don't know what exactly you mean by "shutdown", but mod_jk has no
memory/cache/buffer for parts or all of an earlier response. It does
buffer parts of a request for reusing it during failover, but not with
responses and not between different requests.
If the webapp is not available on the target system, there is no way how
mod_jk could return with 50 lines of correct response. Those 50 lines
might either come from your backend (what is "shutdown"), or from some
other cache (browser, between browser and Apache, mod_cache_* inside
Apache, between Apache and Tomcat).
Nevertheless for production, I would always use a cleaner way of
disabling a context: before undeploying first set the activation of the
worker to stooped, which means it will no longer forward any requests
and the load balancer will transparantly choose another worker. No
recovery and errors.
If you use sessions without replication, you could also set a worker to
disabled before going into stopped. With disabled requests for existing
sessions will still be forwarded, but no requests without sessions.
Depending on your session timing the target might thus get slowly out of
use.
Also add timeouts to your config. We have a new docs page for 1.2.24
(which will go live tomorrow). You can have a look at it under
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs/jk-1.2.24/generic_howto/timeouts.html
and consider using the option recovery_options.
Regards,
Rainer
ben short wrote:
Hi,
I have a odd issue occurring with my tomcat cluster serving ~50 lines
of the page from a stopped webapp.
My setup is as follows...
Box 1
Apache running a jk mod loadbalancer. It loadbalances between an
instance of tomcat on this box and on box 2.
Box 2
Apache running a jk mod loadbalancer. It loadbalances between an
instance of tomcat on this box and on box 1.
Software...
OS RH 4
Tomcat 6.0.13
Java 1.6.0_01
Apache 2.2.4
Mod_jk 1.2.23
workers.properties (same on both boxes)
# JK Status worker config
worker.list=jkstatus
worker.jkstatus.type=status
# Presentaton Load Balancer Config
worker.list=preslb
worker.preslb.type=lb
worker.preslb.balance_workers=jcpres1,jcpres2
worker.preslb.sticky_session=0
worker.jcpres1.port=8009
worker.jcpres1.host=192.168.6.171
worker.jcpres1.type=ajp13
worker.jcpres1.lbfactor=1
worker.jcpres1.fail_on_status=503,400,500,909
worker.jcpres2.port=8009
worker.jcpres2.host=192.168.6.174
worker.jcpres2.type=ajp13
worker.jcpres2.lbfactor=1
worker.jcpres2.fail_on_status=503,400,500,909
My problem...
If i stop the webapp on box 2, wait for a while and make a request I
get about 50 lines of the expected page in my browser ( assuming the
request went to the shutdown webapp. On checking the jkstatus page I
then see that the lb has set that webapp to ERR. On refreshing the
browser the lb routes me to the running webapp and I get the expected
page.
After a while the jk lb will set the shutdown webapp into the REC
state. If I then make another request I see the same thing, about 50
lines of a page and then the lb kicks the lb member out of the lb
pool.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
