Hi David Even though I dont know what kind of application you are trying to build, I would like to give you some idea...
Outgoing messages.... As you know that there is some part of your business logic creates outgoing messages. If you create an Executor filter between underlying transport layer and business logic, there is no way business logic will know about problems at transport layer unless you write some callbacks as well. Such as: Business thread 1 starts processing your business logic, and send message out. Executor Filter will buffer your outgoing message till a thread in executor becomes available to send/process it. So Now your application management issues can be buffer size, knowing whether you send message out successfully or not and whether you send message on time or not. Inbound Messages: Quick Question for you : What if codec fails decode incoming message, how are you planing to return a response? It wouldn't be a problem if sender side waits for async response... But if it waits for sync response, when are you planing to return the response? Assumption: Your application like any other network application needs communicate with requests, responses Thanks Erkin On Mon, Apr 20, 2009 at 10:00 PM, David Rosenstrauch <[email protected]>wrote: > Had a question about Mina thread pools. > > I posted a snippet of my filter chain building code on a bug report > recently: > > protocolAcceptor = new NioSocketAcceptor(); > protocolAcceptor.setDefaultLocalAddress(new > InetSocketAddress(protocolPort)); > protocolAcceptor.setReuseAddress(true); > DefaultIoFilterChainBuilder filterChainBuilder = > protocolAcceptor.getFilterChain(); > filterChainBuilder.addLast("logger", new > LoggingFilter(ProfileCacheServer.class)); > readerThreadPool = new OrderedThreadPoolExecutor(); > filterChainBuilder.addLast("readExecutor", new > ExecutorFilter(readerThreadPool, IoEventType.MESSAGE_RECEIVED)); > filterChainBuilder.addLast("codec", new ProtocolCodecFilter(new > TextLineCodecFactory(ParseConstants.UTF8_CHARSET))); > writerThreadPool = new OrderedThreadPoolExecutor(); > filterChainBuilder.addLast("writeExecutor", new > ExecutorFilter(writerThreadPool, IoEventType.WRITE)); > protocolAcceptor.setHandler(protocolHandler); > > > Someone commented back tangentially about what I had written that they > thought the filter chain code I was using was a mistake: > > "First of all, adding a (reading) thread pool/executor filter before codec > filter is a really bad idea! ... Try moving the reading executor behind the > codec and remove the writing one." > > > I didn't understand why this should be the case, and wrote the OP back > asking for clarification, but didn't hear back. Was hoping someone here > might be able to shed some light. > > > My intention by having 2 thread pools was to have a pool of threads on both > message input and message output processing, thereby avoiding bottlenecks > where handling incoming messages might delay outgoing messages and vice > versa. The idea is that I would read messages using one thread pool and > then feeding them to the codec filter for processing. Then, similarly, I > would have a pool of threads that handled writing message responses back out > to the socket. > > So why then would this setup be "a really bad idea"? > > TIA, > > DR >
