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 <[EMAIL PROTECTED]> for <[EMAIL PROTECTED]>; 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 [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:[EMAIL PROTECTED]> List-Subscribe: <mailto:[EMAIL PROTECTED]> List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Id: "Tomcat Developers List" <tomcat-dev.jakarta.apache.org> Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]> Delivered-To: mailing list [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>; 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 <[EMAIL PROTECTED]>; 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 <[EMAIL PROTECTED]>; Mon Feb 9 02:06:14 2004 X-Injected-Via-Gmane: http://gmane.org/ To: [EMAIL PROTECTED] From: Costin Manolache <[EMAIL PROTECTED]> Subject: Re: Mod_Jk2 - Default Worker Date: Sun, 08 Feb 2004 18:06:10 -0800 Lines: 81 Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: [EMAIL PROTECTED] 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: <[EMAIL PROTECTED]> Sender: news <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
