Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 93187 invoked from network); 3 May 2002 08:42:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 May 2002 08:42:38 -0000 Received: (qmail 16429 invoked by uid 97); 3 May 2002 08:42:44 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@nagoya.betaversion.org Received: (qmail 16340 invoked by alias); 3 May 2002 08:42:44 -0000 Delivered-To: jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 16323 invoked by uid 97); 3 May 2002 08:42:43 -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 16293 invoked by uid 98); 3 May 2002 08:42:43 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3CD24D80.6010506@schlund.de> Date: Fri, 03 May 2002 10:42:40 +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: new lb values 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: > Based on the previous discussion: > > - change lbfactor from float to int ( maybe rename it to avoid confusion) > It would be less magic but you have to check if the value is 0. > - The value will be from 1 to MAX ( 100 ? ). > > - Smaller values will mean more work. The value '0' ( or a special > flag ? ) will mean the worker will be used allways ( as long as it is not > in_error state ). We can make sure the '0' is the first in the list, > and avoid looking for others. > > - A factor 2 will take 2 times fewer requests than factor 1, 3 will be > 1/3, etc. ( each worker uses a counter, and the counter is incremented on > each request with the factor value - that's how it works today to > implement the round roubin ). > > - When a worker reaches MAX, all workers will be reset to their > original values and error state reset. ( that means we'll reset the > error state based on number of requests, not time ) ( is this a good idea ?) > > - A value of MAX ( Or flag ? ) will mean the worker will take no > request, except those with a previous session id. That's the gracefull > shutdown. > > In addition, I'm in process of moving the lb properties to channel, > since that's what the user should configure in jk2. > > Costin I think this is a mutch better aproach then the magic zero lb_value :). I could check it for jk1 and I hope I get time to look deeper in jk2 to test it there too. Bernd -- 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: