You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by NormW <no...@bocnet.com.au> on 2004/02/06 01:21:47 UTC
Mod_Jk2 - Default Worker
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:
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/ ?)
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:
[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 ) {
Re: Mod_Jk2 - Default Worker
Posted by Guenter Knauf <ef...@gmx.net>.
Hi Costin,
>> Good morning Costin.
>> Apologies for the silence. I had hoped there might have been a little
>> more input from others on this topic.
I think it is also necessary to discuss a bit the proper configuration of mod_jk2.
The docu is all other but clear, mixed up with the docu for mod_jk, and I see that the jkstatus output differs heavily with only slight other configs; also I think we should add a minimal config to the binary distributions;
I want to have a config which is easy to change, and works without change in 98% of installations; and is just enough to connect to TC, access the docu, and execute the samples.
here's a sample which works without a workers2.properties file:
http://www.gknw.com/development/apache/docs/win32/mod_jk2/mod_jk2x.conf
and here a nearly mininal workers2.properties file:
http://www.gknw.com/development/apache/docs/win32/mod_jk2/min_w2.properties
common with both configs is that there's only one place where you have to change the host and port if necessary; and that's what I call user-friendly.
also would be nice to have some hints in the docu about where to put uri stuff, benefit of having them in mod_jk2.conf, and samples for lb mode.
if you have a few minutes please test both configs and check how the jkstatus differs...
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Mod_Jk2 - Default Worker
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> Henri Gomez wrote:
>
>> Well, if we didn't get the POST somewhere on the WebServer, and if the
>> tomcat failed to respond, we couldn't resent the whole POST to the
>> second one.
>
>
>
> If we get the first bytes ( but not the entire POST ), we can still save
> them, and if the first tomcat fails - resend it.
> When a tomcat responds - it can ask for more bytes.
>
> If a tomcat is failing in the middle of the processing - it's better to
> report the error and not try to recover.
>
>
>>
>> The strategy will be to keep, say up to 32kb on Apache pools, and if the
>> POST is larger save it to filesystem.
>
>
> I'm not sure I understand the problem with saving only the first part of
> the POST data. The request that is sent to tomcat only includes those
> bytes anyway - tomcat has to ask for more.
>
> The problem is that getting the entier body changes the processing model
> for POST fundamentally - the entire streaming is gone, servlets that may
> reject the POST ( because the size is too big for example ) will still
> have the entier body downloaded, etc.
>
> Are you sure this is absolutely needed ?
Not sure, I'm only an human.
BTW, I'll commit the POST recovery scheme used in jk to jk2, so it will
be available for 2.0.4 (together with ping/pong and others goodies from
latest jk).
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: New procrun binaries needed
Posted by Mladen Turk <mt...@apache.org>.
> > I'd need new procrun binaries for the new build (in j-t-c/procrun).
> > The old build isn't broken, so this is not critical, but it
> would be
> > nice (assuming there are updates).
>
> There _are_ updates. So someone will have to produce the binaries.
>
Should be in the CVS.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: New procrun binaries needed
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
> Hi,
>
> I'd need new procrun binaries for the new build (in j-t-c/procrun).
> The old build isn't broken, so this is not critical, but it would be
> nice (assuming there are updates).
There _are_ updates. So someone will have to produce the binaries.
>
> Thanks :)
>
> Rémy
>
>
> ---------------------------------------------------------------------
> 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
New procrun binaries needed
Posted by Remy Maucherat <re...@apache.org>.
Hi,
I'd need new procrun binaries for the new build (in j-t-c/procrun).
The old build isn't broken, so this is not critical, but it would be
nice (assuming there are updates).
Thanks :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Mod_Jk2 - Default Worker
Posted by Henri Gomez <hg...@apache.org>.
Bill Barker wrote:
> ----- Original Message -----
> From: "Costin Manolache" <cm...@yahoo.com>
> To: <to...@jakarta.apache.org>
> Sent: Thursday, February 12, 2004 11:03 AM
> Subject: Re: Mod_Jk2 - Default Worker
>
>
>
>>Henri Gomez wrote:
>>
>>
>>>Well, if we didn't get the POST somewhere on the WebServer, and if the
>>>tomcat failed to respond, we couldn't resent the whole POST to the
>>>second one.
>>
>>
>>If we get the first bytes ( but not the entire POST ), we can still save
>>them, and if the first tomcat fails - resend it.
>>When a tomcat responds - it can ask for more bytes.
>>
>>If a tomcat is failing in the middle of the processing - it's better to
>>report the error and not try to recover.
>>
>
>
> +1. If tomcat has already gotten the body, and then dies, if you attempt to
> recover you will have charged the user's credit card twice :).
Such problem should be handled at the application side, not by the
connector.
BTW, I hardcoded my boss credit card for the second request :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Mod_Jk2 - Default Worker
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Thursday, February 12, 2004 11:03 AM
Subject: Re: Mod_Jk2 - Default Worker
> Henri Gomez wrote:
>
> > Well, if we didn't get the POST somewhere on the WebServer, and if the
> > tomcat failed to respond, we couldn't resent the whole POST to the
> > second one.
>
>
> If we get the first bytes ( but not the entire POST ), we can still save
> them, and if the first tomcat fails - resend it.
> When a tomcat responds - it can ask for more bytes.
>
> If a tomcat is failing in the middle of the processing - it's better to
> report the error and not try to recover.
>
+1. If tomcat has already gotten the body, and then dies, if you attempt to
recover you will have charged the user's credit card twice :).
>
> >
> > The strategy will be to keep, say up to 32kb on Apache pools, and if the
> > POST is larger save it to filesystem.
>
> I'm not sure I understand the problem with saving only the first part of
> the POST data. The request that is sent to tomcat only includes those
> bytes anyway - tomcat has to ask for more.
>
> The problem is that getting the entier body changes the processing model
> for POST fundamentally - the entire streaming is gone, servlets that may
> reject the POST ( because the size is too big for example ) will still
> have the entier body downloaded, etc.
>
> Are you sure this is absolutely needed ?
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: Mod_Jk2 - Default Worker
Posted by Costin Manolache <cm...@yahoo.com>.
Henri Gomez wrote:
> Well, if we didn't get the POST somewhere on the WebServer, and if the
> tomcat failed to respond, we couldn't resent the whole POST to the
> second one.
If we get the first bytes ( but not the entire POST ), we can still save
them, and if the first tomcat fails - resend it.
When a tomcat responds - it can ask for more bytes.
If a tomcat is failing in the middle of the processing - it's better to
report the error and not try to recover.
>
> The strategy will be to keep, say up to 32kb on Apache pools, and if the
> POST is larger save it to filesystem.
I'm not sure I understand the problem with saving only the first part of
the POST data. The request that is sent to tomcat only includes those
bytes anyway - tomcat has to ask for more.
The problem is that getting the entier body changes the processing model
for POST fundamentally - the entire streaming is gone, servlets that may
reject the POST ( because the size is too big for example ) will still
have the entier body downloaded, etc.
Are you sure this is absolutely needed ?
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Mod_Jk2 - Default Worker
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> Henri Gomez wrote:
>
>> jean-frederic clere wrote:
>>
>>> Henri Gomez wrote:
>>>
>>>> Costin Manolache wrote:
>>>>
>>>>> NormW wrote:
>>>>>
>>>>>> Good morning Costin.
>>>>>> Apologies for the silence. I had hoped there might have been a
>>>>>> little more
>>>>>> input from others on this topic.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Same here :-)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so
>>>> new features should wait for 2.0.5.
>>>>
>>>> BTW, I add some ftix in jk 1.2.x to make POST recovery in LB mode
>>>> and I agree that the LB shouldn't be seen as a worker.
>>>>
>>>> What I like to see to make easier the LoadBalancing/Failover in jk2 :
>>>>
>>>> - in service, grab request HEADERS and POST datas and store BOTH
>>>> in the service land.
>>>
>>>
>>>
>>>
>>> POST data could be very big.
>>
>>
>>
>> I agree but we could still detect VERY BIG POST (not the usual case),
>> and save them on disk.
>>
>> The goal is to have in fine a bullet proof LB connector.
>
>
> We could save only some initial chunk - for example what is needed to
> fill the first Ajp packet. My understanding is that this is the current
> behavior - just obfuscated.
>
> I think the protocl would work even if you don't send any byte of the
> POST data in the first packet, the only reason we send post data is to
> avoid round-trips for very small posts.
>
> Keeping the entire POST can be dangerous ( out of memory on apache side,
> etc ). It is very possible the servlet will just reject the request and
> never read the IS.
Well, if we didn't get the POST somewhere on the WebServer, and if the
tomcat failed to respond, we couldn't resent the whole POST to the
second one.
The strategy will be to keep, say up to 32kb on Apache pools, and if the
POST is larger save it to filesystem.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Mod_Jk2 - Default Worker
Posted by Costin Manolache <cm...@yahoo.com>.
Henri Gomez wrote:
> jean-frederic clere wrote:
>
>> Henri Gomez wrote:
>>
>>> Costin Manolache wrote:
>>>
>>>> NormW wrote:
>>>>
>>>>> Good morning Costin.
>>>>> Apologies for the silence. I had hoped there might have been a
>>>>> little more
>>>>> input from others on this topic.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Same here :-)
>>>
>>>
>>>
>>>
>>> We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so
>>> new features should wait for 2.0.5.
>>>
>>> BTW, I add some ftix in jk 1.2.x to make POST recovery in LB mode and
>>> I agree that the LB shouldn't be seen as a worker.
>>>
>>> What I like to see to make easier the LoadBalancing/Failover in jk2 :
>>>
>>> - in service, grab request HEADERS and POST datas and store BOTH
>>> in the service land.
>>
>>
>>
>> POST data could be very big.
>
>
> I agree but we could still detect VERY BIG POST (not the usual case),
> and save them on disk.
>
> The goal is to have in fine a bullet proof LB connector.
We could save only some initial chunk - for example what is needed to
fill the first Ajp packet. My understanding is that this is the current
behavior - just obfuscated.
I think the protocl would work even if you don't send any byte of the
POST data in the first packet, the only reason we send post data is to
avoid round-trips for very small posts.
Keeping the entire POST can be dangerous ( out of memory on apache side,
etc ). It is very possible the servlet will just reject the request and
never read the IS.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Mod_Jk2 - Default Worker
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
> Henri Gomez wrote:
>
>> Costin Manolache wrote:
>>
>>> NormW wrote:
>>>
>>>> Good morning Costin.
>>>> Apologies for the silence. I had hoped there might have been a
>>>> little more
>>>> input from others on this topic.
>>>
>>>
>>>
>>>
>>> Same here :-)
>>
>>
>>
>> We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so
>> new features should wait for 2.0.5.
>>
>> BTW, I add some fix in jk 1.2.x to make POST recovery in LB mode and I
>> agree that the LB shouldn't be seen as a worker.
>>
>> What I like to see to make easier the LoadBalancing/Failover in jk2 :
>>
>> - in service, grab request HEADERS and POST datas and store BOTH
>> in the service land.
>
>
> POST data could be very big.
I agree but we could still detect VERY BIG POST (not the usual case),
and save them on disk.
The goal is to have in fine a bullet proof LB connector.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Mod_Jk2 - Default Worker
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
> Costin Manolache wrote:
>
>> NormW wrote:
>>
>>> Good morning Costin.
>>> Apologies for the silence. I had hoped there might have been a little
>>> more
>>> input from others on this topic.
>>
>>
>>
>> Same here :-)
>
>
> We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so new
> features should wait for 2.0.5.
>
> BTW, I add some fix in jk 1.2.x to make POST recovery in LB mode and I
> agree that the LB shouldn't be seen as a worker.
>
> What I like to see to make easier the LoadBalancing/Failover in jk2 :
>
> - in service, grab request HEADERS and POST datas and store BOTH
> in the service land.
POST data could be very big.
>
> - forward the HEADERS/POST datas to the first worker, and
> if transmission failed or no replies came after XXX seconds,
> forward the HEADERS/POST to another worker and so on.
>
>
> When I see how ajp13 works in jk (don't look at jk2 for now),
> the mix of buffers is a nightmare, since ajp13 mix send part of
> datas from webserver to tomcat, and reception of datas from tomcat to
> webserver.
>
> What I'd like to see is a more simpler communication system, where
> webserver will send ONE packet containing HEADERS and another with
> POST datas (if needed).
May be better to send an empty POST data packet.
>
>>>> 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.
>>>
>>>
>>>
>>> That mapping only exists now because it is implemented by the worker.
>>> The
>>> worker is the logical recipient if the functionality offered by the lb
>>> worker was not required. (There is enough for a worker to manage, even
>>> without the protocol, to justify its existence as an object.). All
>>> that is
>>> missing from the scenario is the protocol to be a part of the channel or
>>> perhaps an intermediate layer.
>>
>>
>>
>> Not sure what you mean - the "worker" name is very overloaded, there
>> are many ways to interpret.
>>
>> My point was that the mapping is done between a URI and a tomcat (
>> either a standalone instance or a group ). This is represented by "lb"
>> - which should be the only target for the mapping.
>>
>> The lb will then use a channel ( ajp object ) to connect to the
>> tomcat. The role of "lb" is to implement the forwarding of the request
>> via the "ajp" object, with load balancing or failover ( if multiple
>> channel/ajp objects exist ).
>>
>> The fact that both the channel ( ajp ) and the lb are implementing the
>> "worker" interface is IMO confusing. I think it's better to have an
>> "lb" that can dynamically be configured with more channels, does
>> retry, balancing and failover - as a separate entity- separated from
>> the channel ( that just forwards a request ).
>>
>>
>>>
>>>> IMO getting to this point requires removing some of the (arbitrary )
>>>> flexibility in naming workers or bypassing the lb.
>>>
>>>
>>>
>>>>> From an 'objects' perspective, it is inconsistent with current
>>>>> practice to
>>>
>>>
>>> 'parse' object names (CN in ldap parlence) for properties of the object,
>>> when those properties have unique identifiers such as port and host.
>>> Hence I
>>> support arbitrary naming.... ;-(
>>
>>
>>
>> CN ( and distinguished names in JNDI as well as jmx object names ) is
>> the source for the object names in jk2.
>>
>> I know it's a religious issue if the name should mean something or not
>> - and probably that's a reason we'll have to keep supporting the
>> arbitrary names.
>>
>> IMO we should deprecate the arbitrary names and only support JMX-like
>> object names, with using the properties to extract information like
>> host, etc.
>>
>>
>> In any case - it's Henri and the other people actively involved in
>> this release you need to convince :-)
>>
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Mod_Jk2 - Default Worker
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> NormW wrote:
>
>> Good morning Costin.
>> Apologies for the silence. I had hoped there might have been a little
>> more
>> input from others on this topic.
>
>
> Same here :-)
We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so new
features should wait for 2.0.5.
BTW, I add some fix in jk 1.2.x to make POST recovery in LB mode and I
agree that the LB shouldn't be seen as a worker.
What I like to see to make easier the LoadBalancing/Failover in jk2 :
- in service, grab request HEADERS and POST datas and store BOTH
in the service land.
- forward the HEADERS/POST datas to the first worker, and
if transmission failed or no replies came after XXX seconds,
forward the HEADERS/POST to another worker and so on.
When I see how ajp13 works in jk (don't look at jk2 for now),
the mix of buffers is a nightmare, since ajp13 mix send part of
datas from webserver to tomcat, and reception of datas from tomcat to
webserver.
What I'd like to see is a more simpler communication system, where
webserver will send ONE packet containing HEADERS and another with
POST datas (if needed).
>>> 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.
>>
>>
>> That mapping only exists now because it is implemented by the worker. The
>> worker is the logical recipient if the functionality offered by the lb
>> worker was not required. (There is enough for a worker to manage, even
>> without the protocol, to justify its existence as an object.). All
>> that is
>> missing from the scenario is the protocol to be a part of the channel or
>> perhaps an intermediate layer.
>
>
> Not sure what you mean - the "worker" name is very overloaded, there are
> many ways to interpret.
>
> My point was that the mapping is done between a URI and a tomcat (
> either a standalone instance or a group ). This is represented by "lb" -
> which should be the only target for the mapping.
>
> The lb will then use a channel ( ajp object ) to connect to the tomcat.
> The role of "lb" is to implement the forwarding of the request via the
> "ajp" object, with load balancing or failover ( if multiple channel/ajp
> objects exist ).
>
> The fact that both the channel ( ajp ) and the lb are implementing the
> "worker" interface is IMO confusing. I think it's better to have an "lb"
> that can dynamically be configured with more channels, does retry,
> balancing and failover - as a separate entity- separated from the
> channel ( that just forwards a request ).
>
>
>>
>>> IMO getting to this point requires removing some of the (arbitrary )
>>> flexibility in naming workers or bypassing the lb.
>>
>>
>>>> From an 'objects' perspective, it is inconsistent with current
>>>> practice to
>>
>> 'parse' object names (CN in ldap parlence) for properties of the object,
>> when those properties have unique identifiers such as port and host.
>> Hence I
>> support arbitrary naming.... ;-(
>
>
> CN ( and distinguished names in JNDI as well as jmx object names ) is
> the source for the object names in jk2.
>
> I know it's a religious issue if the name should mean something or not -
> and probably that's a reason we'll have to keep supporting the
> arbitrary names.
>
> IMO we should deprecate the arbitrary names and only support JMX-like
> object names, with using the properties to extract information like
> host, etc.
>
>
> In any case - it's Henri and the other people actively involved in this
> release you need to convince :-)
>
> 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
Re: Mod_Jk2 - Default Worker
Posted by NormW <no...@bocnet.com.au>.
Good morning Costin.
> NormW wrote:
> > Good morning Costin.
> > Apologies for the silence. I had hoped there might have been a little
more
> > input from others on this topic.
>
> Same here :-)
>
> >
> >>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.
> >
> > That mapping only exists now because it is implemented by the worker.
The
> > worker is the logical recipient if the functionality offered by the lb
> > worker was not required. (There is enough for a worker to manage, even
> > without the protocol, to justify its existence as an object.). All that
is
> > missing from the scenario is the protocol to be a part of the channel or
> > perhaps an intermediate layer.
>
> Not sure what you mean - the "worker" name is very overloaded, there are
> many ways to interpret.
* Apologies for the mixup.... I knew what I meant. I meant 'worker' in a
functional sense as an object/entity that accepts a URI request from Apache
and who's sole job is to do all the management processes required to deliver
that URI to a Tomcat and back to the client, except actually getting it
there. If this object is functionally tweaked for this role it more than
adequately meets a large number of user requirements. It is only when
features like fail-over, clustering and load-balancing are added to the
overall requirement, is an entity with the current 'skills' of an lb-type
'worker' required to decide which 'worker/object' gets the task of
processing the request. One doesn't have to stand back very far to discover
that is almost what exists now.
> My point was that the mapping is done between a URI and a tomcat (
> either a standalone instance or a group ). This is represented by "lb" -
> which should be the only target for the mapping.
>
> The lb will then use a channel ( ajp object ) to connect to the tomcat.
> The role of "lb" is to implement the forwarding of the request via the
> "ajp" object, with load balancing or failover ( if multiple channel/ajp
> objects exist ).
>
> The fact that both the channel ( ajp ) and the lb are implementing the
> "worker" interface is IMO confusing. I think it's better to have an "lb"
> that can dynamically be configured with more channels, does retry,
> balancing and failover - as a separate entity- separated from the
> channel ( that just forwards a request ).
* This dual interface to a single logical task is 'normal' in a lot of
things, for example, a one man business and an enterprise employing a number
of similarly skilled workers but fronted by a manager who decides which
worker gets the job. One should be able to scale the enterprise for the
overall task at hand rather than have a manager in front of a single person.
(Sounds like a government department.)
>
> >
> >>IMO getting to this point requires removing some of the (arbitrary )
> >>flexibility in naming workers or bypassing the lb.
> >
> >>From an 'objects' perspective, it is inconsistent with current practice
to
> > 'parse' object names (CN in ldap parlence) for properties of the object,
> > when those properties have unique identifiers such as port and host.
Hence I
> > support arbitrary naming.... ;-(
>
> CN ( and distinguished names in JNDI as well as jmx object names ) is
> the source for the object names in jk2.
>
> I know it's a religious issue if the name should mean something or not -
> and probably that's a reason we'll have to keep supporting the
> arbitrary names.
>
> IMO we should deprecate the arbitrary names and only support JMX-like
> object names, with using the properties to extract information like
> host, etc.
Acknowledge being unfamiliar with the JMX standard, but if it means not
parsing object names for properties then I'm a supporter.
>
> In any case - it's Henri and the other people actively involved in this
> release you need to convince :-)
* I don't have 'barrow' to push much beyond wanting to make mod_jk2 function
in what I perceive is a logical way and have it's modular design become
visible enough to remove a lot of the questions I see on user groups about
configuring it. If I convince anyone to re-evaluate past decisions it is a
by-product.
>
> Costin
>
Norm
>
> ---------------------------------------------------------------------
> 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
Re: Mod_Jk2 - Default Worker
Posted by Costin Manolache <cm...@yahoo.com>.
NormW wrote:
> Good morning Costin.
> Apologies for the silence. I had hoped there might have been a little more
> input from others on this topic.
Same here :-)
>
>>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.
>
> That mapping only exists now because it is implemented by the worker. The
> worker is the logical recipient if the functionality offered by the lb
> worker was not required. (There is enough for a worker to manage, even
> without the protocol, to justify its existence as an object.). All that is
> missing from the scenario is the protocol to be a part of the channel or
> perhaps an intermediate layer.
Not sure what you mean - the "worker" name is very overloaded, there are
many ways to interpret.
My point was that the mapping is done between a URI and a tomcat (
either a standalone instance or a group ). This is represented by "lb" -
which should be the only target for the mapping.
The lb will then use a channel ( ajp object ) to connect to the tomcat.
The role of "lb" is to implement the forwarding of the request via the
"ajp" object, with load balancing or failover ( if multiple channel/ajp
objects exist ).
The fact that both the channel ( ajp ) and the lb are implementing the
"worker" interface is IMO confusing. I think it's better to have an "lb"
that can dynamically be configured with more channels, does retry,
balancing and failover - as a separate entity- separated from the
channel ( that just forwards a request ).
>
>>IMO getting to this point requires removing some of the (arbitrary )
>>flexibility in naming workers or bypassing the lb.
>
>>>From an 'objects' perspective, it is inconsistent with current practice to
> 'parse' object names (CN in ldap parlence) for properties of the object,
> when those properties have unique identifiers such as port and host. Hence I
> support arbitrary naming.... ;-(
CN ( and distinguished names in JNDI as well as jmx object names ) is
the source for the object names in jk2.
I know it's a religious issue if the name should mean something or not -
and probably that's a reason we'll have to keep supporting the
arbitrary names.
IMO we should deprecate the arbitrary names and only support JMX-like
object names, with using the properties to extract information like
host, etc.
In any case - it's Henri and the other people actively involved in this
release you need to convince :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Mod_Jk2 - Default Worker
Posted by NormW <no...@bocnet.com.au>.
Good morning Costin.
Apologies for the silence. I had hoped there might have been a little more
input from others on this topic.
> 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.
* With a release of mod_jk2 imminent, someone might look at this perhaps?
> 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.
That mapping only exists now because it is implemented by the worker. The
worker is the logical recipient if the functionality offered by the lb
worker was not required. (There is enough for a worker to manage, even
without the protocol, to justify its existence as an object.). All that is
missing from the scenario is the protocol to be a part of the channel or
perhaps an intermediate layer.
> 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 )
Given the diversity of structures that mod_jk2 can implement, having a
default configuration only caters for a portion of them. Catering for none
forces 'exposure' of the few building blocks that mod_jk2 actually has
available, and would help to remove a lot of the mod_jk/jk2 mystique.
> IMO getting to this point requires removing some of the (arbitrary )
> flexibility in naming workers or bypassing the lb.
>>From an 'objects' perspective, it is inconsistent with current practice to
'parse' object names (CN in ldap parlence) for properties of the object,
when those properties have unique identifiers such as port and host. Hence I
support arbitrary naming.... ;-(
>
> >
> > 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.
Point taken. Equally, it's absence today shouldn't automatically mitigated
against its existence tomorrow. If 'mod_jk3' should evolve perhaps....
>
>
> >>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
Thanks again for the time, feedback and insight.
Norm
> ---------------------------------------------------------------------
> 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
Re: Mod_Jk2 - Default Worker
Posted by Costin Manolache <cm...@yahoo.com>.
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
Re: Mod_Jk2 - Default Worker
Posted by NormW <no...@bocnet.com.au>.
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
Re: Mod_Jk2 - Default Worker
Posted by cm...@yahoo.com.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org