Mathias Herberts wrote: > [EMAIL PROTECTED] 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 :). Thanks Bernd > > 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 UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
