tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Koecke>
Subject Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Date Mon, 13 May 2002 09:30:35 GMT
Mathias Herberts wrote:
 > wrote:
 >> costin      02/05/09 14:06:48
 >> Modified:    jk/native2/common jk_worker_lb.c Log: That's the big one.
 >> Please review !
 >> It changes the handling of lb_value to int. I also cleaned up the logic so
 >> it's easier ( I hope ) to understand what's happening. "Levels" replace the
 >> 'local worker', I thing I got the logic straight for those.
 >> I started to add a 'introspection' data, to validate and better report the
 >> config.
 >> We use one table per level. At the moment the maximum number of workers is
 >> hardcoded ( to 255 ), we could make it dynamic but that would make things
 >> pretty complex when we add workers dynamically ( it won't work without a CS
 >> or atomic operations )
 > Hi Costin,
 > I read your code throughly and found no problem in get_most_suitable_worker,
 > I think your approach to prioritizing workers is the best. What bernd and I
 > had done was mainly driven by the need to have a frontal load balancer detect
 > the failure of the local worker(s). Since my last patch and having read yours
 > I think I found a better way to make the load balancer detect failures.
 > Configure all Apache instances so they see all Tomcat instances, assign a
 > higher priority to local workers on each Apache, therefore local workers will
 > be chosen first. On each Apache, the load balancing worker is called lb.
 > Another load balancing worker, balancing only the local workers, is called
 > hwlb. The hardware load balancer checks the health of the Apache servers
 > using a URI which is served by hwlb instead of lb, therefore if there are no
 > more local workers left alive, the requests the hardware load balancer
 > dispatches to the associated Apache before it can detect the local workers
 > failure will be rerouted to the other non local workers and the client will
 > only loose its session information, she will not get any errors. When the
 > hardware load balancer ends up detecting the local workers failure (because
 > the hwlb worker rejected the request due to the lack of available worker), it
 > will declare the Apache inactive and will only use the other ones.
 > This setup solves my use cases at least, I don't know for Bernd's.

Sorry, I must say it again, for my environment it is an error, if a _switched
off_ tomcat got a request without a sessionid or with a session from another 
node. Its not necessary that this tomact-apache tandem is
shut down. We switch off a port on this node and than the balancer wouldn't send
a request to it. And than no mod_jk is allowed to send a request to it without a
session for this node. It is normal that some nodes are _switched off_. We need
this for a a graceful update. We switch off some nodes, wait till there are no 
active sessions (all timed out) and then we shutdown apache + tomcat, make an 
update and start them up again. If there are no local/main worker I need an 
error response and no routing to a switched off tomcat. Its possible that this 
happens once per day.

I know this might be a special environment. I spent some time in jk1 to
build a working patch. Than I started looking in jk2. I'm not a good C
developer, so I needed some time for looking into jk2. Now I think I understand
the internal structure. I don't want to send untested patches or patches which
build more problems than it solves. The last patch I sent for jk1 solved my
problem, I tested it here on a testcluster and I hope it broke no prior
functionality. But it will take some time till I could send a patch for jk2. My 
boss give me some deadlines for other projects, one is next Wednesday. I would 
be happy if jk2 make it possible to use local/main-worker with sticky sessions 
(need only one per node/mod_jk). And if all local/main-worker are down the 
request gets an error-response. I will do my best to install a jk2 on my test 
cluster and try to play around with it.

May be I misunderstood Mathias suggestion for jk2, than delete the whole mail 
:). I hope I could send a patch for jk2 or look into the new code shortly.

Again, I think its a very good idea to use ints for lb_value, set a maximum and 
correct the value if one reaches this upper bound. And its a good idea to make 
the local/main-worker a more general thing. For a cluster environment it is a 
nice feature :).



 > There remains a related problem in jk_requtil in jk2_requtil_getCookieByName,
 > as I mentioned several months ago on the list, the cookie extraction does not
 > work for cookies whose format conforms to RFC 2169, that is the cookie value
 > is enclosed in double quotes. Such cookie format is used by lynx for example.
 > I had submitted a patch into the bug database but cannot find it anymore,
 > I'll have to look up my archives.
 > Good job on the lb worker Costin,
 > Mathias.

Dipl.-Inform. Bernd Koecke
Schlund+Partner AG
Fon: +49-721-91374-0

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message