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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
