Hi Trustin,
Thanks for your rapid response. I guess my confusion stems from passing a
processorCount and Executor to SocketAcceptor. If you want a fixed number of
IO processors shouldn't you either:
1) Pass only a processorCount parameter and let SocketAcceptor use the most
appropriate Executor internally. Even better, maybe not use an executor at all
and just create a thread dedicated to each processorCount. Why bother with the
overhead of a pool if the thread is basically dedicated to the IO processor?
or
2) Pass only an Executor and if you want a fixed number of IO processors use
Executor.newFixedThreadPool(nThreads).
My thought is someone could do something like this:
new SocketAcceptor(10, Executor.newFixedThreadPool(3));
And that's probably really a bad idea.
If instead the constructors were changed to:
public SocketAcceptor(){
this(1);
}
public SocketAcceptor(int processorCount){
this(processorCount, Executor.newFixedThreadPool(processorCount));
}
private SocketAcceptor(int processorCount, Executor executor){
// existing code of constructor here.
// or refactor code into SocketAcceptor(int processorCount) constructor
}
Things would be more bullet proof and prevent someone from making a mistake
like I've shown above. Since the Executor (actually ExecutorService) is
internal to the SocketAcceptor it would be responsible for calling
ExecutorServiceImpl.shutdown(). This could be done in the doUnbind() method of
SocketAcceptor.
Failing such modifications, the default constructor for SocketAcceptor uses
NewThreadExecutor(). Wouldn't it be more efficient to use
Executor.newFixedThreadPool(1)?
Thanks again,
Rob
----- Original Message ----
From: Trustin Lee <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, May 15, 2007 10:54:33 PM
Subject: Re: SocketAcceptor processorCount?
Hi Rob,
On 5/16/07, Rob Butler <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I'm a bit confused with SocketAcceptor( int processorCount, Executor executor
> ).
>
> Internally this creates a new SocketIoProcessor for each processorCount. But
> the SocketIoProcessors all share the same Executor. What's the advantage of
> having multiple instances of SocketIoProcessor?
It will perform much better with multi-core CPUs.
> If you use a pooling Executor like Executors.newCachedThreadPool() or
> Executors.newFixedThreadPool(int nThreads) is this creating a new thread for
> each connection?
Never. The 'processor' here means a SocketIoProcessor, which performs
I/O for you. It doesn't have any relationship with business logic or
event thread pool.
> How does this relate to an ExecutorFilter in the IoHandlerChain?
No relationship. They are different things.
> If I want a few IO processing threads, which re-use threads from a pool, and
> worker threads which use a separate pool what is the best way to do this? I
> don't want a thread per connection.
* A few I/O processing threads: can be specified as a SocketAcceptor
constructor parameter.
* worker thread pool: add an executor filter.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
____________________________________________________________________________________Be
a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
