Just to quickly follow up on my own post, this is the alternative configuration
that I had come up with, but have not tested yet. I was hoping to get some
guidance here first. Which is better, the configuration in my first mail, or
this one, and why exactly:
ByteBuffer.setUseDirectBuffers(false);
ByteBuffer.setAllocator(new SimpleByteBufferAllocator());
acceptorExecutor = Executors.newCachedThreadPool();
log.debug("Starting SocketAcceptor with " +
(Runtime.getRuntime().availableProcessors() + 1) + " and a cached threadpool");
acceptor = new
SocketAcceptor(Runtime.getRuntime().availableProcessors() + 1,
acceptorExecutor);
SocketAcceptorConfig cfg = new SocketAcceptorConfig();
cfg.setThreadModel(ThreadModel.MANUAL);
cfg.getFilterChain().addLast("handshake", new HandshakeFilter());
cfg.getFilterChain().addLast("tunnel", new TunnelFilter());
ProtocolCodecFilter codec = new ProtocolCodecFilter(new
HttpServerProtocolCodecFactory());
cfg.getFilterChain().addLast("httpcodec", codec);
filterExecutor = Executors.newCachedThreadPool();
cfg.getFilterChain().addLast("executor", new
ExecutorFilter(filterExecutor));
ControlServerHandler handler = new ControlServerHandler();
handler.setApplicationContext(channelController.getApplicationContext());
handler.setChannelController(channelController);
handler.setControlChannelTimeout(ccTimeout);
InetAddress addr = InetAddress.getByName(csHostStr);
log.info("Starting control channel server socket on " + addr.toString()
+ ":" + port);
acceptor.bind(new InetSocketAddress(addr, port), handler, cfg);
Regards,
Darryl
________________________________
From: Darryl Pentz <[email protected]>
To: [email protected]
Sent: Fri, October 16, 2009 9:03:04 AM
Subject: Configuring MINA 1.1.7 Acceptor - best practise
Hi all,
We are busy upgrading our server product to use MINA 2.0 but that exercise is
part of a broader refactoring exercise that will take a while longer. In the
meantime I just want to check that we are using an acceptable initialization
strategy for our MINA 1.1.7 usage. In the docs, it says that one should never
use the default threading model but that in fact we should set it to manual. We
currently do not do this, and I wonder if anybody could indicate whether this
will be problematic for us:
...
ByteBuffer.setUseDirectBuffers(false);
ByteBuffer.setAllocator(new SimpleByteBufferAllocator());
acceptor = new SocketAcceptor();
SocketAcceptorConfig cfg = new SocketAcceptorConfig();
cfg.getFilterChain().addLast("handshake", new HandshakeFilter());
cfg.getFilterChain().addLast("tunnel", new TunnelFilter());
ProtocolCodecFilter codec = new ProtocolCodecFilter(new
HttpServerProtocolCodecFactory());
cfg.getFilterChain().addLast("httpcodec", codec);
ControlServerHandler handler = new ControlServerHandler();
handler.setApplicationContext(channelController.getApplicationContext());
handler.setChannelController(channelController);
handler.setControlChannelTimeout(ccTimeout);
log.info("Starting control channel server socket on port " + port);
acceptor.bind(new InetSocketAddress(port), handler, cfg);
...
Ignoring the stuff specific to our app, like the custom filters and that
ControlServerHandler.setChannelController() etc, when I look in the VM thread
list, I see the typical AnonymousIoService-1..16 but I read somewhere that this
could mean an unoptimal configuration (can't find where that was now unf.).
When I look at the threads in JVisualVM, I notice that the AnonymousIoService
threads are generally in WAIT state with only one or two showing 'green' blocks
(i.e. RUNNING) every now and again, even though there *should* be activity from
a number of remote socket connections. So I'm concerned that we're not setting
things up correctly. Is the above configuration appropriate for 1.1.7 usage?
Any feedback would be greatly appreciated.
Warm Regards,
Darryl Pentz
