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 /
>
> 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).
It kinds of moves us backwards, to the mess of protocols and load balancers.
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.
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
>
> [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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
