Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Message-ID: <019701c34a55$643d7250$b441ca0a@nwinc.org.au>
From: "NormW" <normw@bocnet.com.au>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
References: <5.2.1.1.0.20030714223108.00c51168@imap.web.de>
Subject: Re: mod_jk round robin problem & stateless session beans
Date: Tue, 15 Jul 2003 08:15:10 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Good morning Simon.
'RoundRobin' is less likely the more Tomcat's you add I suspect. The
balanced worker program always searches for a new worker by starting
pointers from 1 rather than the last successful worker used, (AFAICT), and
if a worker is free for the task it makes for muddy water indeed if you
bypass it in the hope of finding something better... You need to remember
which one was used 'last', which is a 'state' not remembered if/once session
ID's are used (which go to the worker that handled it the last time). If you
think about 'balancing' it is 'mindgame' to decide how a 'load' might be
distributed... based on session counts? based on request handling time? and
what 'integration' period would you use? ... and then there are preferences
based on load, server grunt, network traffic, background tasks...  at the
end of the day, the idea is to handle user requests, so if they're getting
processed in a 'timely' manner perhaps you can put the 'unused' Tomcat's
behind another Apache? ... or start a new thread here on how balancing might
be better handled in different situations...

Another 'possible' might be to add more balance workers and split your url's
to these, in turn connected to more ajp13 workers using some of the Tomcat's
currently sitting idle.
Norm


----- Original Message ----- 
From: "Simon Pabst" <simon.pabst@web.de>
To: <tomcat-user@jakarta.apache.org>
Sent: Tuesday, July 15, 2003 7:17 AM
Subject: mod_jk round robin problem & stateless session beans


> We have the following setup:
> One Apache with HTTPS/SSL with mod_jk (one load balancer, sticky sessions
> on) in front
> Eight Tomcats in back
>
> Round Robin doesn't work, but instead the Users are distributed on the
> Tomcats like this:
>
> Tomcat No.| User Count (approx. daily)
> T1 70
> T2 30
> T3 15
> T4 6
> T5 1
> T6 0
> T7 0
> T8 0
>
> This occurs both with Apache1.3.27/mod_jk1.2.x and Apache2.0.45/mod_jk2.x
> (mod_jk 1 and 2 built from source of jakarta-tomcat-connectors-4.1.24-src
> and later also of tomcat-connectors-1.1M1-src).
>
> Anyone ever experienced something similar or has any insight in this?
>
> According to the application developer the application is using stateless
> session beans.
> (Since i'm just a stupid server admin and no Java Programmer i don't
really
> now what that is :-)
>
> I tested the Load Balancing with the Tomcat SessionExample and round robin
> seemed to work fine.
> If i switch of sticky session round robin also works fine, but not the
> application :-)
>
> Do stateless session beans even work with mod_jk's sticky session stuff?
> (in this discussion
> http://www.theserverside.com/discussion/thread.jsp?thread_id=409
> somebody said:
> "if the application stores the stateless session bean in the httpsession,
> the application risks having all of the workload to only one of the nodes
> in the cluster")
>
> If anyone knows how sticky sessions of mod_jk(2) work, please enlighten me
:-)
> Is it IP based in any way, are Cookies involved or JSESSIONID or anything
else?
> Could it be a problem that all Tomcats are on the same machine? (i tested
> this with pseudo network addresses 127.0.0.1-8 for each Tomcat too, but
> didn't help either)
> Could HTTPS cause any troubles for this?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>


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