----- Original Message ----- From: "Costin Manolache" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
