On 1/27/11 9:13 AM, Francesco Vivoli wrote:
Hi everybody
Our application uses a number of NioSocketAcceptor, instantiated using the
default constructor. AFAIK this will create N acceptor thread pools (via
Executors.newCachedThreadPool()) and N processor pools
(SimpleIoProcessorPool), where N is the number of acceptors. Each processor
will then serve a session.
Do you know that you can use *one* single Acceptor and still accept
connections for many different ports ? The NioSocketAcceptor.bind()
method can accept a list of SocketAddress, not only one single address.
Resource-wise this doesn't seem to be very efficient and I'm thinking of
creating a single acceptor, as well a single processor thread pool, to be
shared by every IoService.
Now, is this the recommended pattern here?
One thing left is the size of the processor thread pool: why should it be
related to the number of cores, while ExecutorFilter's pool doesn't?
The acceptor uses one Selector per thread in the IoProcessor pool. If
you have only one, then all the incoming requests will be processed by
this IoProcessor, which may be a bottleneck up to a point. As the
Selector is using a system call under the hood to process the incoming
requests, it doe snot make a ot of sense to have more IoProcessor
running than the number of cores.
However, all of this is pretty much theoretical. The best would be to
conduct some stress tests to validate the number of IoProcessor to create.
Speaking of which, given that each acceptor in our app serve basically just
one session, would it make sense to use such a filter? I wouldn't think so.
In any case, would it be safe/desiderable to share executors between
ExecutorFilters and IoServices ?
I want to make it clear that an Acceptor does not serve sessions, but
incoming connections Sessions are managed by the IoProcessor, once the
connection has been established.
And, yes, challenging the usage of an ExecutorFilter is a valid
question. Basically, it depends on the typ of application you are using.
In some cases, it might be necessary to have a Execurot in the filter,
even if you manage one single session, for instance if your server
processes long tasks, and if the end user want to stop the execution of
a previous request he sent. In this case, an Executor can be necessary,
otherwise your second request won't be processed before the first one is
terminated.
Sorry for the maybe naive questions but I haven't found much on this topic
around and I'm fairly new here...
I'm running 2.0.0M6, on windows 2003 servers.
2.0.0-M6 is buggy up to a point you can't imagine. 2.0.2 has been
released last december, I urge you to switch to this version !
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
