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 <djpe...@yahoo.com> To: users@mina.apache.org 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