Question inlined.
On 1/27/2011 1:13 AM, Emmanuel Lecharny wrote:
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.
To help me understand the possibilities, can you suggest a use case for
this? What i was thinking quickly was, was it possible to have a secure
(ssl) and unsecure port serviced by the same acceptor?
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 !
