You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "DataViz Sales Dept." <sa...@list.dataviz.com> on 2004/02/08 01:24:06 UTC
Your mail has been rejected
It appears that your message to DataViz, Inc. was "bouncing" between our
server and yours. Generally, this will happen because you have an
"out-of-office" e-mail reply activated or you submitted a form on our web site
multiple times.
Your e-mail address has been added to a bounce list. Any messages sent from
an e-mail address on this list will be digested for 24 hours to stop this
bouncing. At the end of the 24 hours, your e-mail address will be removed
from the bounce list automatically. Therefore no further action on your part
is necessary.
Please contact Shaun Berner at (203) 874-0085 x3037 if you have any additional
questions.
The DataViz Web Team
-------------------- Original Message Follows --------------------
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 --------------------
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 --------------------
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
---------------------------------------------------------------------
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