tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Mod_jk balancing, session problem
Date Tue, 08 Aug 2006 15:08:58 GMT
Artur wrote:
> Hello,
> We have environment with Apache (2.2.0) + Tomcat (5.5.17) connected via
> mod_jk (1.2.18). Further tomcat makes some queries to databese through
> Tuxedo services (BEA).
> Everything works fine until heavy load when something stops responding
> (Service not available).
> We think it is tomcat or mod_jk. It occures when "Max busy connections" on
> mod_jk status manager shows about 200. Mod_jk is in error status then.

Understanding this situation would be helpful to decide, if adding 
another tomcat really helps (problem=database => more tomcats don't help 

> So we decided to use mod_jk load balancing feature and we installed another
> instance of tomcat (on the same machine).
> Now service is available even under heavy load but we are losing sessions.

What do you mean by "losing sessions"? I expect you mean users work in a 
session and then they send a request and get a response indicating, that 
the requested session has not been found?

If so:

- does it happen in times, when you get errors in the mod_jk-log? Does 
it happen at all times, or do you have peaks at special times?

Stickyness sends users to the correct node, except when the node is not 
reachable (error, stopped). In this case users will be sent to one of 
the remaining nodes and - of course - without session replication their 
session will not be there. Session repllication means to establish a 
tomcat clusster, something you need to carefully test and that might 
force changes in your app.

- if it happens even when there's no other problem at the same time:

make session IDs trackable. Either your app uses URL rewriting, then 
your session ID is part of every request and logged in the apache access 
log. Or you use Cookies, then add logging of incoming header "Cookie" to 
your mod_log_config LogFormat. If you also add outgoing header 
"Set-Cookie" you are able to follow the sessions, and you can decide, if 
the users really send the correct session ID. Sometimes what you may 
find is: the previous request produced an error in the app, which then 
decided to invalidate the session.

You can also add a request log to mod_jk, that logs, which worker has 
beend chosen for every request. That way you do not rely on your user 
feedback, but can measure the problem yourself (how many users/sessions, 
what time of day etc.).

> Of course sticky_session is set to "true".
> Below I paste our config files. Please help if you only can.
> Best regards
> Artur
> ###Jk status for one day:
> Name	Type	jvmRoute	Host	Addr	Stat	D	F	M	V	Acc	Err	Wr	Rd	Busy	Max	RR	Cd
> worker2	ajp13	worker2	localhost:8009	OK	0	1	1	2144	824825	512
> 480M	5.8G	6	138	worker3

worker3 is in the original output and has iĆ³nly been removed by your 

What was happening, when you got these 2144 Errors? The time stamps 
should be available from the mod_jk log.

> ###httpd.mpm section:
> # worker MPM
> # StartServers: initial number of server processes to start
> # MaxClients: maximum number of simultaneous client connections
> # MinSpareThreads: minimum number of worker threads which are kept spare
> # MaxSpareThreads: maximum number of worker threads which are kept spare
> # ThreadsPerChild: constant number of worker threads in each server process
> # MaxRequestsPerChild: maximum number of requests a server process serves
> <IfModule mpm_worker_module>
>     StartServers         5
>     MaxClients           448
>     MinSpareThreads      5
>     MaxSpareThreads      25 
>     ThreadsPerChild      7
>     MaxRequestsPerChild   0
> </IfModule>

Interesting, very few ThreadsPerChild. Not really a problem, but I 
wonder if this is efficient.

> # Define 3 workers, 2 real workers using ajp13 and the last one being a
> loadbalancing worker
>   worker.list=worker1,jkstatus
> # Set properties for worker2 (ajp13)
>   worker.worker2.type=ajp13
>   worker.worker2.port=8009
>   worker.worker2.lbfactor=1
>   worker.worker2.connection_pool_size=7

This should be set top the same value as ThreadsPerChild by mod_jk 

>   worker.worker2.connection_pool_timeout=300
>   worker.worker2.socket_timeout=60

Think about using connect_timeout and prepost_timeout. Maybe also set 
recovery_options to 3.

>   # Set properties for worker4 (lb) which use worker1 and worker2
>   worker.worker3.type=ajp13
>   worker.worker3.port=8019
>   worker.worker3.lbfactor=1
>   worker.worker3.connection_pool_size=7
>   worker.worker3.connection_pool_timeout=300
>   worker.worker3.socket_timeout=60
> # Define a 'jkstatus' worker using status
>   worker.jkstatus.type=status
>   worker.worker1.type=lb
>   worker.worker1.sticky_session=true
>   worker.worker1.method=R
>   worker.worker1.balance_workers=worker2,worker3
> ###server1.xml - connector section:
> <!-- Define an AJP 1.3 Connector on port 8009 -->
>     <Connector port="8009" 
>                enableLookups="false" redirectPort="8443" protocol="AJP/1.3"
> />
>     <Engine name="Catalina" defaultHost="localhost" jvmRoute="worker2">
> ###server2.xml - connector section
> <!-- Define an AJP 1.3 Connector on port 8009 -->
>    <Connector port="8019" 
>                enableLookups="false" redirectPort="8443" protocol="AJP/1.3"
> />
>     <Engine name="Catalina" defaultHost="localhost" jvmRoute="worker3">


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message