You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2004/09/29 13:03:27 UTC
More needed connector refactoring
Hi,
- I'll add a thread pool similar to the one in Tomcat 4.0, as an
optional policy to the current one; the idea is that it's very dumb, and
could be more stable in some environments (that RH 9 thing ...), but is
not as efficient as the current one; I'll do some benchmarks to see if
for a single CPU computer there's any difference between the two, and I
propose that whichever is the fastest for that use case becomes the
default one (with a preference for the TC 4.0 one in case of a tie, as
it's simpler)
- I think conf/jk2.properties should go, since we can have arbitrary
properties on the Connector element, and additionally, it has an
extremely confusing name; any comments on that ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: More needed connector refactoring
Posted by Costin Manolache <cm...@yahoo.com>.
Bill Barker wrote:
> ----- Original Message -----
> From: "Costin Manolache" <cm...@yahoo.com>
> To: <to...@jakarta.apache.org>
> Sent: Wednesday, September 29, 2004 9:01 AM
> Subject: Re: More needed connector refactoring
>
>
>
>>Remy Maucherat wrote:
>>
>>>Hi,
>>>
>>>- I'll add a thread pool similar to the one in Tomcat 4.0, as an
>>>optional policy to the current one; the idea is that it's very dumb, and
>>>could be more stable in some environments (that RH 9 thing ...), but is
>>>not as efficient as the current one; I'll do some benchmarks to see if
>>>for a single CPU computer there's any difference between the two, and I
>>>propose that whichever is the fastest for that use case becomes the
>>>default one (with a preference for the TC 4.0 one in case of a tie, as
>>>it's simpler)
>>
>>I'm a bit confused - what happened with the thread pool and how did we
>>end up with 2 ? I missed this change.
>>
>>
>>
>>>- I think conf/jk2.properties should go, since we can have arbitrary
>>>properties on the Connector element, and additionally, it has an
>>>extremely confusing name; any comments on that ?
>>
>>+1 :-)
>
>
> It will make the Connector element in server.xml really hideous, and
> restrict component names to be valid XML attribute names (e.g.
> channelSocket.localhost:8009 is a no-no :). Other than that, I don't see a
> problem.
Maybe a better solution would be to introduce a new tag ( "mbean" or
"module" or similar ), so we can express the fact that jk is composed
from multiple components.
The intention of jk2.properties was to have a way to configure generic
components ( mbean-like ), with a simple way to parse/save the changes
from both java and C.
Since "C" is no longer an issue - there is no problem with using an xml
file, like server.xml. And a good "save changes" implementation
shouldn't be specific to jk.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: More needed connector refactoring
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, September 29, 2004 12:29 PM
Subject: Re: More needed connector refactoring
>Bill Barker wrote:
>
>>>Remy Maucherat wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>- I'll add a thread pool similar to the one in Tomcat 4.0, as an
>>>>optional policy to the current one; the idea is that it's very dumb, and
>>>>could be more stable in some environments (that RH 9 thing ...), but is
>>>>not as efficient as the current one; I'll do some benchmarks to see if
>>>>for a single CPU computer there's any difference between the two, and I
>>>>propose that whichever is the fastest for that use case becomes the
>>>>default one (with a preference for the TC 4.0 one in case of a tie, as
>>>>it's simpler)
>>>>
>>>>
>>>I'm a bit confused - what happened with the thread pool and how did we
>>>end up with 2 ? I missed this change.
>>>
>>>
>There was no change yet. I was proposing (re)introducing a more
>conventional policy as an option (where I would just copy code from TC
>4.1). At least, I'll do it to see without committing anything to see how
>it compares.
>
>>>>- I think conf/jk2.properties should go, since we can have arbitrary
>>>>properties on the Connector element, and additionally, it has an
>>>>extremely confusing name; any comments on that ?
>>>>
>>>>
>>>+1 :-)
>>>
>>>
>>It will make the Connector element in server.xml really hideous, and
>>restrict component names to be valid XML attribute names (e.g.
>>channelSocket.localhost:8009 is a no-no :). Other than that, I don't see
a
>>problem.
>>
>I'm ok to keep the file if it's the only way, but it needs at least to
>be renamed. Doesn't having a file restrict the AJP connector to
>one-per-server ? (or did I miss something ?)
>
Of course it is possible to get rid of the jk2.properties file. You just
get Connector elements like:
<Connector protocol="AJP/1.3"
channelSocket.host1.address="com.myfirm.myserver"
channelSocket.host1.port="8009"
channelSocket.host1.maxThreads="50"
channelSocket.host1.next="noauth"
channelSocket.host2.address="com.myfirm.myserver"
channelSocket.host2.port="8019"
channelSocket.host2.maxThreads="75"
channelSocket.host2.next="auth"
channelUnix.host3.file="/path/to/my/socket"
channelUnix.host3.maxThreads="100"
channelUnix.next="auth"
shm.file="/path/to/shm/file"
apr.nativeSo="/path/to/jkjni.so"
request.noauth.tomcatAuthentication="false"
request.auth.tomcatAuthentication="true"
/>
The AJP connector is designed to be one-per-server (because of the native
APR stuff). Of course, with mod_jk2 deprecated in TC 5.5, the need for the
one-per-server design is weaker. Personally, I prefer to configure multiple
JkChannels on one Connector, but it seems that tastes vary here ;-).
>From the user list, it seems that people are working around this now by
setting the jkHome attribute on the connectors, Making the config file
configurable (assuming that it stays at all :) is on the BZ wish-list (e.g.
#29780).
>Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: More needed connector refactoring
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
>>Remy Maucherat wrote:
>>
>>
>>>Hi,
>>>
>>>- I'll add a thread pool similar to the one in Tomcat 4.0, as an
>>>optional policy to the current one; the idea is that it's very dumb, and
>>>could be more stable in some environments (that RH 9 thing ...), but is
>>>not as efficient as the current one; I'll do some benchmarks to see if
>>>for a single CPU computer there's any difference between the two, and I
>>>propose that whichever is the fastest for that use case becomes the
>>>default one (with a preference for the TC 4.0 one in case of a tie, as
>>>it's simpler)
>>>
>>>
>>I'm a bit confused - what happened with the thread pool and how did we
>>end up with 2 ? I missed this change.
>>
>>
There was no change yet. I was proposing (re)introducing a more
conventional policy as an option (where I would just copy code from TC
4.1). At least, I'll do it to see without committing anything to see how
it compares.
>>>- I think conf/jk2.properties should go, since we can have arbitrary
>>>properties on the Connector element, and additionally, it has an
>>>extremely confusing name; any comments on that ?
>>>
>>>
>>+1 :-)
>>
>>
>It will make the Connector element in server.xml really hideous, and
>restrict component names to be valid XML attribute names (e.g.
>channelSocket.localhost:8009 is a no-no :). Other than that, I don't see a
>problem.
>
I'm ok to keep the file if it's the only way, but it needs at least to
be renamed. Doesn't having a file restrict the AJP connector to
one-per-server ? (or did I miss something ?)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: More needed connector refactoring
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Wednesday, September 29, 2004 9:01 AM
Subject: Re: More needed connector refactoring
> Remy Maucherat wrote:
> > Hi,
> >
> > - I'll add a thread pool similar to the one in Tomcat 4.0, as an
> > optional policy to the current one; the idea is that it's very dumb, and
> > could be more stable in some environments (that RH 9 thing ...), but is
> > not as efficient as the current one; I'll do some benchmarks to see if
> > for a single CPU computer there's any difference between the two, and I
> > propose that whichever is the fastest for that use case becomes the
> > default one (with a preference for the TC 4.0 one in case of a tie, as
> > it's simpler)
>
> I'm a bit confused - what happened with the thread pool and how did we
> end up with 2 ? I missed this change.
>
>
> > - I think conf/jk2.properties should go, since we can have arbitrary
> > properties on the Connector element, and additionally, it has an
> > extremely confusing name; any comments on that ?
>
> +1 :-)
It will make the Connector element in server.xml really hideous, and
restrict component names to be valid XML attribute names (e.g.
channelSocket.localhost:8009 is a no-no :). Other than that, I don't see a
problem.
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: More needed connector refactoring
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Hi,
>
> - I'll add a thread pool similar to the one in Tomcat 4.0, as an
> optional policy to the current one; the idea is that it's very dumb, and
> could be more stable in some environments (that RH 9 thing ...), but is
> not as efficient as the current one; I'll do some benchmarks to see if
> for a single CPU computer there's any difference between the two, and I
> propose that whichever is the fastest for that use case becomes the
> default one (with a preference for the TC 4.0 one in case of a tie, as
> it's simpler)
I'm a bit confused - what happened with the thread pool and how did we
end up with 2 ? I missed this change.
> - I think conf/jk2.properties should go, since we can have arbitrary
> properties on the Connector element, and additionally, it has an
> extremely confusing name; any comments on that ?
+1 :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org