Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 6038 invoked from network); 2 May 2002 16:37:47 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 May 2002 16:37:47 -0000 Received: (qmail 22619 invoked by uid 97); 2 May 2002 16:37:41 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@nagoya.betaversion.org Received: (qmail 22512 invoked by alias); 2 May 2002 16:37:41 -0000 Delivered-To: jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 22489 invoked by uid 97); 2 May 2002 16:37:40 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 22465 invoked by uid 98); 2 May 2002 16:37:39 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3CD16B4E.7010005@schlund.de> Date: Thu, 02 May 2002 18:37:34 +0200 From: Bernd Koecke Organization: Schlund+Partner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: de, en MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: PROPOSAL: mod_jk2: Group/Instance References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N costinm@covalent.net wrote: > On Thu, 2 May 2002, Amund Elstad wrote: > > >>(1) all requests without a session are routed to a specific tomcat instance >>(if that instance is working). > > > That has been added, and it should work in both jk1 and jk2 ( I don't > remember who sent the patch, but I remember adding it ). If it doesn't > work yet, is easy to fix. > Sorry, may be I'm stupid, but how does it work? I looked at jk and jk2. My understanding is the following: The worker which uses the jvm route is the lb_worker. The others don't use the SessionId extension. You could tweak this worker, but its buggy or I misunderstood it. After you said that my patch is included a had a closer look at mod_jk. I can't see anything of my code but I found the special meaning of the zero lb_factor/lb_value. It seems that I didn't understand it right at the first time. This could solve my problem but after a closer look and some testing I found another problem. When you set the lb_value in workers.properties to 1 for the local tomcat and 0 for the others, you get the desired behavior. But if you switch off the local tomcat for a short time you come into trouble. The problem is the 0 for the other workers. The calculation of lb_worker transforms the 0 to _inf_. Because 1/0 for a double is _inf_. This is greater than any other lb_value and greater than the lb_value of the local tomcat. But after a failure of the local tomcat he is in error_state. After some time its set to recovering and if the local tomcat is back again the function jk(2)_get_max_lb gets the highest lb_value. This is _inf_ from one of the other workers. The addition of a value to _inf_ is meaningless. You end up with an lb_value of _inf_ for the local worker. If this worker isn't the first in the worker list, it will never be choosen again. Because his lb_value will never be less than another lb_value, because all the other workers have _inf_ as theire lb_values. So every request without a session will be routed to the first of the other tomcats. The only way out is a restart of the local apache after tomcat is up and running. But I don't know when tomcat is finished with all his contexts and started the connectors. I didn't looked very deep into jk2, but I found the same get_most_suitable_worker and get_max_lb functions. The jk2_get_max_lb function will always return _inf_. In your answer to some other mails you said, that workers could be removed. Do I understand it right, that if my local tomcat goes down his worker is removed from the list and after he is comming up again added to the worker list with reseted lb_value (only for mod_jk2)? The next days I will look in the docu and code of jk2 and give it a try. May be all my problems gone away with the new module :). Sorry if I ask stupid questions, but I want to make it working for our new cluster. Thanks Bernd > This is essential for jk2's JNI worker, which fits perfectly this case > ( you don't want to send via TCP when you have a tomcat instance in the > same process ). > > > >>(2) Tomcat instances in standby or "soft shutdown" mode where they serve >>requests bound by established sessions, and requests without a session only >>if all non-standby instances have failed. > > > That's what the SHM scoreboard is going to do ( among other things ). > You can register tomcat instances ( which will be added automatically ), > or unregister - in which case no new requests ( except the old sessions ) > will go to the unregistered tomcat. > > > Costin > > >>costinm@covalent.net wrote: >> >> >>>On Tue, 30 Apr 2002, Bernd Koecke wrote: >>> >>> >>>>some weeks ago I send a patch for mod_jk for an only routing lb_worker. A >>> >>few >> >>>>days later I sent the docu. Henry Gomez said, that it should be commited. >>> >>But it >> >>>>I think it isn't in the repository. But its the same with me here, to >>> >>mutch >> >>>>work for to less time :). >>> >>>I think it is in mod_jk, I remember seeing the commit. >>> >>>And I think I commited it in jk2 as well ( after some modifications ). >>> >>> >>>>I need sticky sessions but no loadbalancing in the module. If a request >>> >>without >> >>>>a session comes in, it should be routed to the _local_ tomcat. >>> >>>Well, there is another use-case with the exact same behavior - Apache2 >>>with tomcat in JNI mode. All requests without session should be routed to >>>the _jni_ channel ( i.e. in-process, minimal overhead ). >>> >>>It's exacly the same - so be sure I do my best to handle this case :-) >>> >>>Apache2 acts like a 'natural' load-balancer/fail-over, with the parent >>>process monitoring for crashes and it starts/stop childs based on >>>load. >>> >>> >>> >>>>I think this could be possible with the associated instance of a channel >>> >>(item >> >>>>7). Then I have to configure all four nodes for the same group. Because >>> >>all >> >>>>nodes will serve the same webapps and associate the channel with this >>> >>group. But >> >>>>for this I need a non balancing group. I don't see if the default >>> >>behavior of a >> >>>>group is balancing and if this can be switched off. Is this right or do I >>> >>miss >> >>>>something? >>> >>>The default is balancing, but you can tune this using weithgs ( and I >>>think we use your code for making one instance 'top priority'). >>> >>>Please check the code, take a look and send additional comments/patches. >>> >>>It's not yet completely done, of course. >>> >>> >>>Thanks, >>>Costin >> >> >>-- >>To unsubscribe, e-mail: >>For additional commands, e-mail: >> >>-- >>To unsubscribe, e-mail: >>For additional commands, e-mail: >> >> > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: bk@schlund.de -- To unsubscribe, e-mail: For additional commands, e-mail: