Hello

On Tue, 24 Sep 2013 11:51:04 -0700
Emmanuel Lécharny <elecha...@gmail.com> wrote:

> Le 9/24/13 9:47 AM, Christian Hammers a écrit :
> > Hello
> >
> > I've written a server for a proprietary UDP protocol that needs to answer 
> > with
> > exactly one packet for every incoming packet. All packets are independent 
> > from
> > each other so that I like to have each one handled asynchronously by a
> > different thread from a pool with a certain maximum size.
> >
> > So far I used this:
> >
> >     FooCodec codec = new FooCodec(); // encoder and decoder in one class
> >         InetSocketAddress local = new InetSocketAddress(port);
> >
> >         acceptor = new NioDatagramAcceptor();
> >         acceptor.getFilterChain().addLast("executor", new 
> > ExecutorFilter(maxThreads));
> >         acceptor.getFilterChain().addLast("codec", new 
> > ProtocolCodecFilter(codec, codec));
> >         acceptor.setHandler(handler);
> >         acceptor.bind(local);
> >
> > At first it seemed that each incoming UDP package, due to its stateless 
> > nature,
> > creates a different Mina "session" and each Mina "session" runs in its own 
> > thread so that the default ExecutorFilter implementation 
> > OrderedThreadPoolExecutor is fine as I certainly don't want the session 
> > closed 
> > if there is still a response before it in the queue.
> 
> That's not what is currently happening. MINA creates a session for each
> IP address, so if all your UDP messages are issued by one single machine
> using one IP address, then all the UDP messages will be processed by the
> same thread.

Ah! They are indeed all coming from the same IP+Port.
(I used to do a "session.write(message); session.close()" in my 
messageReceived()
method so it seemed to be different sessions but that was probably a wrong
approach as well)


> Adding an executor in the chain just make it likely that a separate
> thread will process each UDP message, but the session remains shared.
> 
> That explains what you see.

OK

> Just get rid of the executor, and increase the number of IoProcessor,
> you will be able to spread the load on many threads, and each new UDP
> message will be completely processed before the next UDP message can
> start to be processed.

How can I increase the number of IoProcessor? Unlike the NioSocketAcceptor, the
NioDatagramAcceptor constructor has no processorCount argumment.

But regarding your last half sentence: Do I understand correctly that each 
IoProcessor 
thread processes one message after the other but as I can have several of the
IoProcessor threads, the whole application will still be able to handle
incoming request "asynchronously"?

Best Regards,

-christian-

Reply via email to