tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DirectXtras <>
Subject Autoreply: Re: Mod_Jk2 - Default Worker
Date Mon, 09 Feb 2004 02:06:25 GMT

Due to the increased volume of SPAM this mailbox has been closed.

Please contact us via

We apology for the inconvenience.

Best Regards,
The DirectXtras Team
DirectXtras - Xtra Power for Director and Authorware -
Sites with something to say -

Your message reads:

Received: from (unverified []) by
 (Rockliffe SMTPRA 4.5.6) with SMTP id <> for <>;
 Sun, 8 Feb 2004 18:06:25 -0800
Received: (qmail 73079 invoked by uid 500); 9 Feb 2004 02:06:07 -0000
Mailing-List: contact; 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
Received: (qmail 73040 invoked from network); 9 Feb 2004 02:06:06 -0000
Received: from unknown (HELO (
  by with SMTP; 9 Feb 2004 02:06:06 -0000
Received: from list by with local (Exim 3.35 #1 (Debian))
	id 1Aq0oQ-0000Su-00
	for <>; Mon, 09 Feb 2004 03:06:14 +0100
Received: from ([])
        by with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <>; Mon Feb  9 02:06:14 2004
Received: from cmanolache by with local (Gmexim
0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <>; Mon Feb  9 02:06:14 2004
From: Costin Manolache <>
Subject: Re: Mod_Jk2 - Default Worker
Date: Sun, 08 Feb 2004 18:06:10 -0800
Lines: 81
Message-ID: <c06puk$o4k$>
References: <015101c3ec47$3557b740$> <bvvgm1$nd6$>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
In-Reply-To: <012c01c3edda$80f81020$>
Sender: news <>
X-Spam-Rating: 1.6.2 0/1000/N

NormW wrote:
> Good morning Costin.
> Thanks for the time given to replying.
> I agree with the ideas you have given, of decoupling URI's from workers
> explicitly tied to a communications protocol, but in reality this
> connectivity is supported and actually gives the minimum workable
> configuration. But given that a default architecture is but a 'guess', I see
> the programming to be 'cleaner' without such defaults and rather provide a
> 'default' configuration file that would achieve the same end. The present
> situation hides the basic building blocks of Mod_Jk2 and leads to the
> majority of questions in regard to how to reconfigure the module. Remove the
> ability of 'workers' to directly accept requests and force all URI's through
> an lb type, and the current default approach would be entirely appropriate.

Yes, it would be nice to make a clean cut and use a different interface 
for "protocol" workers ( channels ) and lb and similar request processors.

Lb is not only "load balancing" - it also implements fail over and can 
be used to accept registration for tomcat instances - i.e. a sort of 
zero config, with tomcat instance(s) announcing themself to lb.

>>>name    uri    group   context
>>> *         null   null       null
>>> */        /       lb:lb      /
> Given the present arrangement, I can understand (if not support) the lb:lb
> uri entry above but the one assigned to a 'null' group with a uri of 'null'
> seems to be a bug.

It is a bug. Even the second can be considered a bug - if no tomcat 
instance is present there is no need for an lb:lb.

However the most common case is to have at least one tomcat, and there 
is no real benefit in supporting an arbitrary name for the worker ( 
lb:lb ) or in mapping the request directly to the protocol. I think the 
goal should be to have the protocol ( ajp worker ) register itself 
automatically with the lb:lb.

In the advanced case, of multiple pools or instances handling different
webapps - there is no harm in having a default ( lb:lb ) and explicitely
mapping the webapps that don't fall into the default with lb:GROUP 
names. This case can be zero-configured by having each tomcat instance 
self-register with ajp URI and GROUP ( plus the webapps )

IMO getting to this point requires removing some of the (arbitrary ) 
flexibility in naming workers or bypassing the lb.

> As noted, the proposed patch subtracts nothing from the present position,
> while allowing access to the parameter if required.

That's a very common problem - having additional configuration 
flexibility, but without any immediate benefit. It doesn't substract 
anything, but it may prevent future simplifications.

>>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.
> That tie-up exists because the worker name was derived from the protocol.
> Ideally the protocol should have been in the channel, leaving the 'worker'
> to handle _a_ request, and lb to decide which worker to get it... assuming
> there is more than one Tomcat to receive it. However, it still doesn't make
> much sense to have a balancer capability in front of a single worker.

I think we discussed this a lot in the past - and my proposal was to 
stop using the term "worker" :-)  The request is mapped by a mapper that 
    decides if it's a servlet and to which group it should go ( with 
lb:lb as a clear default ), then the lb decides on a particular channel.

mod_jk1 does this using a single concept - worker, in jk2 I think a lot 
have changed to split things into mapper, group and channel, with some 
attempts to provide defaults for the common case.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message