Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <n1135940720.53756@list.dataviz.com>
From: "DataViz Sales Dept." <sales@list.dataviz.com>
Subject: DataViz Sales - Auto Response
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Date: Sat, 7 Feb 2004 19:22:55 -0500

Please note: Your e-mail to DataViz was NOT received!

Due to the increasing amount of SPAM and unsolicited e-mail received at this
address, we no longer accept inquires submitted directly to this e-mail
address. We ask that anyone wishing to contact us please do so through a form
on our website.

We apologize for the inconvenience, but this will benefit both you and our
sales and customer service representatives, as they can respond much more
quickly to your inquiry.

Please visit the link below to re-submit your request.  For your convenience,
your original post is listed below.

http://www.dataviz.com/contactdataviz                                         
                
                                                                              
Sincerely,                                                                    
                                                                              
                                        
The DataViz Sales Department


-------------------- Original Message Follows --------------------
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.

> 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      /
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.

> > 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).
As noted, the proposed patch subtracts nothing from the present position,
while allowing access to the parameter if required.

> It kinds of moves us backwards, to the mess of protocols and load
balancers.
Architecturally, Mod_Jk2 isn't a 'mess' by any description, it has mostly
been rendered incomprehensible by hiding it's few building blocks.

> 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.

> 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

Thanks again for the time and consideration given,
Norm

> >
> > [workerEnv]
> > defaultWorker=<workerName>
> >
> > 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
>
>


---------------------------------------------------------------------
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