tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: More needed connector refactoring
Date Wed, 29 Sep 2004 21:12:49 GMT
Bill Barker wrote:
> ----- Original Message -----
> From: "Costin Manolache" <cmanolache@yahoo.com>
> To: <tomcat-dev@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


Mime
View raw message