Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 14912 invoked from network); 2 May 2002 19:00:00 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 May 2002 19:00:00 -0000 Received: (qmail 4763 invoked by uid 97); 2 May 2002 18:59:59 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@nagoya.betaversion.org Received: (qmail 4653 invoked by alias); 2 May 2002 18:59:58 -0000 Delivered-To: jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 4639 invoked by uid 97); 2 May 2002 18:59:58 -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 4627 invoked by uid 98); 2 May 2002 18:59:57 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) From: "Hans Schmid" To: "Tomcat Developers List" Subject: AW: PROPOSAL: mod_jk2: new lb values Date: Thu, 2 May 2002 21:01:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > -----Ursprungliche Nachricht----- > Von: costinm@covalent.net [mailto:costinm@covalent.net] > Gesendet: Donnerstag, 2. Mai 2002 20:15 > An: Tomcat Developers List > Betreff: PROPOSAL: mod_jk2: new lb values > > > Based on the previous discussion: > > - change lbfactor from float to int ( maybe rename it to avoid confusion) Int is definately the way to go for lbfactor. > > - 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. OK, I would do it the other way around (greater value = more work) but this is a matter of taste. > > - 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 ). > OK > - 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. I would seperate the active/inactive state (the manually set inactivity not the one resulting from error states) from the lbfactor value (see my other reply about the 'active' flag') So only apply the round robin logic to channels with active=1 Note: This Active flag would be configured at runtime. -> Mark one Tomcat to shutdown graceful means set active=0 -> Startup Tomcat would set active=1 and use the assigned lbfactor This way you know what to do with a worker that has reached MAX either - it's counter has to be reset if active = 1 or - it must stay at MAX, because it was deactivated (set to active=0) Hans > > In addition, I'm in process of moving the lb properties to channel, > since that's what the user should configure in jk2. > > Costin > > > > -- > To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: