tomcat-dev mailing list archives

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

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

Please contact us via http://www.directxtras.com/ContactUS.asp

We apology for the inconvenience.

Best Regards,
--
The DirectXtras Team
---------------------------------------------------------------------
DirectXtras - Xtra Power for Director and Authorware -
              http://www.directxtras.com
Sites with something to say - http://www.SpeaksForItself.com
---------------------------------------------------------------------


Your message reads:

Received: from mail.apache.org (unverified [208.185.179.12]) by mail2.intermedia.net
 (Rockliffe SMTPRA 4.5.6) with SMTP id <B0293203924@mail2.intermedia.net> for <postmaster@directxtras.com>;
 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 tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:tomcat-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:tomcat-dev-help@jakarta.apache.org>
List-Post: <mailto:tomcat-dev@jakarta.apache.org>
List-Id: "Tomcat Developers List" <tomcat-dev.jakarta.apache.org>
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 73040 invoked from network); 9 Feb 2004 02:06:06 -0000
Received: from unknown (HELO main.gmane.org) (80.91.224.249)
  by daedalus.apache.org with SMTP; 9 Feb 2004 02:06:06 -0000
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1Aq0oQ-0000Su-00
	for <tomcat-dev@jakarta.apache.org>; Mon, 09 Feb 2004 03:06:14 +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 <tomcat-dev@jakarta.apache.org>; Mon Feb  9 02:06:14 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 <tomcat-dev@jakarta.apache.org>; Mon Feb  9 02:06:14 2004
X-Injected-Via-Gmane: http://gmane.org/
To: tomcat-dev@jakarta.apache.org
From: Costin Manolache <cmanolache@yahoo.com>
Subject: Re: Mod_Jk2 - Default Worker
Date: Sun, 08 Feb 2004 18:06:10 -0800
Lines: 81
Message-ID: <c06puk$o4k$1@sea.gmane.org>
References: <015101c3ec47$3557b740$b441ca0a@nwinc.org.au> <bvvgm1$nd6$1@sea.gmane.org>
<012c01c3edda$80f81020$b441ca0a@nwinc.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
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: 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$b441ca0a@nwinc.org.au>
Sender: news <news@sea.gmane.org>
X-Spam-Rating: daedalus.apache.org 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.


Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message