Depends on what aspect of asynchronous you are looking for. The sockets are always async. If you have a bunch of ioprocessors then you have concurrency where more than one message can be processed at any given time. On Sep 25, 2013 6:15 AM, "Christian Hammers" <[email protected]> wrote:
> Hello > > On Tue, 24 Sep 2013 11:51:04 -0700 > Emmanuel Lécharny <[email protected]> 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- >
