Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 41865 invoked from network); 16 May 2006 22:57:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 May 2006 22:57:56 -0000 Received: (qmail 83183 invoked by uid 500); 16 May 2006 22:57:51 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 83142 invoked by uid 500); 16 May 2006 22:57:51 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 83130 invoked by uid 99); 16 May 2006 22:57:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 May 2006 15:57:50 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [195.227.30.246] (HELO datura.kippdata.de) (195.227.30.246) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 May 2006 15:57:47 -0700 Received: from [192.168.2.113] ([192.168.2.113]) by datura.kippdata.de (8.13.5/8.13.5) with ESMTP id k4GMvOp6003829 for ; Wed, 17 May 2006 00:57:24 +0200 (CEST) Message-ID: <446A5934.5040102@apache.org> Date: Wed, 17 May 2006 00:59:00 +0200 From: Rainer Jung User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: JKStatus Bug? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi David, done ;) It would be nice, if you could test SVN trunk. I also added some small documentation parts. The new attribute is called "jvm_route" and it also has been included into the status worker. If you've never built mod_jk from the repository: there is no "configure" in the repository. You need to call buildconf.sh first, which uses autoconf to generate "configure" from "configure.in". Cheers, Rainer dhay@lexmark.com wrote: > Actually that's the other way my colleague and I came up with. It seems a > little clumsier, but will work for us. > >> I'll see, what I can do ... > Thanks. What kind of timeframe are we looking at? > > cheers, > > David > > > > |---------+----------------------------> > | | Rainer Jung | > | | | | > | > | | | > | | 05/16/2006 02:34 | > | | PM | > | | Please respond to| > | | "Tomcat | > | | Developers List" | > | | | > |---------+----------------------------> > >------------------------------------------------------------------------------------------------------------------------------| > | | > | To: Tomcat Developers List | > | cc: | > | Subject: Re: JKStatus Bug? | > >------------------------------------------------------------------------------------------------------------------------------| > > > > Hi David, > > no internally it works like that: an lb worker has an internal > representation of the status of it's balanced workers. This is created > during initialization, so each lb worker has his own view of the > balanced workers. They don't share any information, like disable/stop, > error or usage counters/load (and that's something I want to keep). > > The alternative approach I was thinking about is giving each (non-lb) > worker an optional attribute "jvmroute". The attribute is never used > except when the worker is being configured as a balanced worker for a > load balancer. > > If a load balancer looks for the config of it's balanced workers, it > checks for the attribute "jvmroute". If it exists, it uses this name for > stickyness. If it does not exist, it uses the name of the worker. > > The change is completely compatible with existing configs. In your case, > you would configure one worker pr tomcat target *and* per lb. Say you've > got TC1 and TC2 as tomcats and LB1 and LB2 as lbs. Then you configure 4 > workers: > > worker.lb1tc1.type=ajp13 > worker.lb1tc1.host=HOST_OF_TC1 > ... > worker.lb1tc1.jvmroute=TC1 > worker.lb1tc1.disabled=WHATEVER > > ... 2 further workers ... > > worker.lb2tc2.type=ajp13 > worker.lb2tc2.host=HOST_OF_TC1 > ... > worker.lb2tc2.jvmroute=TC2 > worker.lb2tc2.disabled=WHATEVER > > and two lb workers: > > worker.lb1.type=lb > worker.lb1.balanced_workers=lb1tc1,lb1tc2 > > worker.lb2.type=lb > worker.lb2.balanced_workers=lb2tc1,lb2tc2 > > That way you can configure all attributes of the balanced workers per lb > and the implementation changes are far less risky. I'll see, what I can > do ... > > Rainer > > dhay@lexmark.com wrote: >> Hi Rainer, >> >> Thanks for the reply. >> >> As far as configuration change suggestions, how about making things more >> fine-grained, so you can specify the worker within the balancer - eg: >> >> worker.adminloadbalancer.BLUFF.disabled=1 >> >> Presumably something like that is happening within jkstatus? >> >> cheers, >> >> David >> x54680 >> >> >> |---------+----------------------------> >> | | Rainer Jung | >> | | > | | > | >> | | | >> | | 05/16/2006 01:36 | >> | | PM | >> | | Please respond to| >> | | "Tomcat | >> | | Developers List" | >> | | | >> |---------+----------------------------> >> >> ------------------------------------------------------------------------------------------------------------------------------| > >> | > | >> | To: Tomcat Developers List > | >> | cc: > | >> | Subject: Re: JKStatus Bug? > | >> ------------------------------------------------------------------------------------------------------------------------------| > >> >> >> Hi, >> >> it's true, that jkstatus doesn't persist changes. There is no >> functionality there to write a workers.properties (it's somewhere near >> the end of the TODO). >> >> Concerning disabled: Yes, disabled at the moment is an attribute >> belonging to a worker and when using stickyness for any jvmRoute you can >> only have one worker. >> >> So if you want to use a worker in several balancers with different >> enable/disable or start/stop values, the workers.properties gives you no >> way to configure that. >> >> Any ideas how such a configuration could look like? If the idea looks >> good, i might implement :) >> >> In case you only have further user questions, please proceed on >> users@tomcat.apache.org. >> >> Concerning improvment of configuration syntax in workers.properties this >> thread is right. >> >> Regards, >> >> Rainer >> >> P.S.: local_worker and local_worker_only does no longer exist since some >> thime before 1.2.15. The attributes are being ignored. >> >> dhay@lexmark.com wrote: >>> Hi, >>> >>> We're using 3 load-balancers to seperate our requests up (client and >> admin >>> etc.) and numerous tomcat servers (we're running Apache in front). >>> >>> We need to be able to disable servers on a load-balancer level - so I >> need >>> to disable 2 of the 3 load balancers on a particular server, say. We > can >>> do this fine using the jkstatus page, but when the machines are >> restarted, >>> the changes don't seem to have been persisted. >>> >>> And it seems that workers.properties is not fine-grained enough to > handle >>> this? >>> >>> Our setup is below... >>> >>> Any ideas how to get around this? >>> >>> cheers, >>> >>> David --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org