On 08/14/2009 10:48 AM, Costin Manolache wrote:
+1 - Executor seems the right interface, didn't exist when workers were
started - ifanyone needs the pool behavior it can probably be implemented as
an Executor.
I assume you'll have some way to configure what kind of executor ?
Yes we do, the NIO connector doesn't use workers anymore. It can use an
internal executor, or an external one. Both are configurable through
server.xml, and the config will not change at all. If you take a 6.0
config, it would still work.
Furthermore, there is some really cool stuff we can do with executors,
such as even with the BIO connector, we can do keep alives and and still
rotate the sockets among the available threads.
Costin
On Fri, Aug 14, 2009 at 1:30 AM, Mark Thomas<ma...@apache.org> wrote:
Filip Hanik - Dev Lists wrote:
Here is why I think its good
1. Current pools can't shrink, so when peak has been hit, that's where
were at
2. Current pools are unfair, synchronized (workers) { workers.wait() },
executors are a bit more fair since they only hold a lock for a short
period
3. Reduce duplicate code
4. Executors provide more flexibility
5. I have not found a performance difference anymore
6. Async implementation becomes much easier, since
AsyncContext.dispatch() is easily handed off to an executor and
releasing application thread. Otherwise we have to add an executor on
top of the existing thread pool, which is doable, just not pragmatic
If you mean give each connector it's own executor by default and the
option to use a shared executor then +1
For the record, it was point 6 that made the argument for me.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
