Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 38624 invoked from network); 6 Feb 2004 07:45:33 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 6 Feb 2004 07:45:33 -0000 Received: (qmail 97905 invoked by uid 500); 6 Feb 2004 07:44:56 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 97874 invoked by uid 500); 6 Feb 2004 07:44:56 -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 97846 invoked from network); 6 Feb 2004 07:44:56 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by daedalus.apache.org with SMTP; 6 Feb 2004 07:44:56 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Ap0fj-0001g5-00 for ; Fri, 06 Feb 2004 08:45:07 +0100 Received: from adsl-63-202-82-219.dsl.snfc21.pacbell.net ([63.202.82.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri Feb 6 07:45:07 2004 Received: from cmanolache by adsl-63-202-82-219.dsl.snfc21.pacbell.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri Feb 6 07:45:07 2004 X-Injected-Via-Gmane: http://gmane.org/ To: tomcat-dev@jakarta.apache.org From: cmanolache@yahoo.com Subject: Re: Mod_Jk2 - Default Worker Date: Thu, 05 Feb 2004 23:45:23 -0800 Lines: 109 Message-ID: References: <015101c3ec47$3557b740$b441ca0a@nwinc.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: adsl-63-202-82-219.dsl.snfc21.pacbell.net User-Agent: KNode/0.7.6 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N NormW wrote: > Good morning All. > The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and > is, for most users I believe, a wrong guess at best, since the majority of > users are probably not using mod_jk2 in load-balancing mode. The 'guess' > means that mod_jk2 creates uri objects assigned to either a load-balancer > that doesn't exist , a load-balancer that is not hooked into anything or a > load-balancer that is not even wanted. For example, the following uri's > are created automatically: :-) I agree that "lb" is a missleading name, as is the whole "worker" concept. The real intent is for "lb" to represent one tomcat cluster ( of one or many servers ), and for routing to be directed to different clusters instead of individual machines. Even if you have a single tomcat - I think it is still better to make the mapping based on the tomcat instance, and not on the various protocols used to connect. The overhead of having lb is very small, and IMO it's well worth it given the simplification in code and the extra features. I also think the right direction is to decouple the "worker" ( as a particular protcol to connect to a tomcat instance ) from the notion of routing requests to a particular instance or cluster, which may use multipe protocols and workers. > > name uri group context > * null null null > */ / lb:lb / > > There is no means to determine the existence of the 'lb:lb' worker, but > suffice to say, my setup doesn't want or need it anyway. (As an aside, > perhaps this might be an extension to /jkstatus/ ?) I think the code created the lb:lb automatically unless one is defined exeplicitely. The goal was to have each tomcat instance ( or cluster ) associated with an lb, with a reasonable default to minimize trivial configuration. Then each lb would have one or multiple protocols pointing at different tomcat instances. > A more valid approach would be to identify, via the workers2.properties > file, which worker of those configured is to be considered the 'default'. > It would also become the 'default' worker/group for [uri] sections not > having a worker/group entry when created, and a variation of the JkUriSet > parameter could also allow use of the 'default' worker, for example: > > JkUriSet worker default > > The existing code makes allowance for a defaultWorker property in the > [workerEnv] section of memory, and I would like to submit the attached > [patch > as a step in such an arrangement. If this option isn't used within the > workers2.properties file, then the module reverts to current operation. > The parameter proposed would look as follows and retain the current > default for wEnv->defaultWorker: I'm not very comfortable with this ( I'm close to -1, but if other people think it's a good idea I can change it to -0). It kinds of moves us backwards, to the mess of protocols and load balancers. I'm ok with any renaming or clarification or defaults - as long as we keep or increase the current separation between "protocols" ( i.e. ajp-like workers ) and "clusters"/"instances" - or however you want to call the lb-like workers. All mapping should be made between URIs and lb ( clusters/instances ), and each lb can have multiple protocols ( ajp ) associated. It would be great if we just create a separate interface to make it clear that those are distinct. Costin > > [workerEnv] > defaultWorker= > > For your consideration and comment, > Norm > > --- jk_workerEnv.c.orig Fri Sep 26 07:00:51 2003 > +++ jk_workerEnv.c Thu Feb 5 18:36:39 2004 > @@ -93,6 +93,8 @@ > wEnv->ssl_enable = JK_TRUE; > } else if( strcmp( name, "timing" )==0 ) { > wEnv->timing= atoi( value ); > + } else if( strcmp( name, "defaultWorker" )==0 ) { > + wEnv->defaultWorker = value ; > } else if( strcmp( name, "httpsIndicator" )==0 ) { > wEnv->https_indicator = value; > } else if( strcmp( name, "certsIndicator" )==0 ) { --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org