Thanks a ton. I guess that was the problem. I have moved it to the last, my decoder is not expensive either in terms of processing or expected data size.
I remember adding Executor was done because I read somewhere... to solve the problem to support more than 16 (noOfProcessor x 8) concurrent connections, prior to which it was putting the connections in queue(wait state) and not allowing till any one of 16 is free. Also while on the help mode, getting little greedy here and looking for quick help without searching. While I shutdown my MINA using KILL(SIGTERM) few client connection remains in TIME-WAIT state, how can I set SO_REUSEADDR option in MINA so that kernel allows to start even if there are connections in WAIT state. I am aware that there is a graceful way of shutdown where I manage the sessions and send them shutdown kind notification, but not planning to do it for 2 reasons...one this will not be required in production scenario as server restart is rare occurrence(frequently reqd for testing though)..second since it's that rare I do not want to add overhead of managing the session list. Thanks again :-) -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Thursday, October 13, 2011 2:57 PM To: [email protected] Subject: Re: Strange problem in reading the data on socket in ProtocolDecoder On 10/13/11 10:18 AM, Vishal Gupta wrote: > Dear Emmanuel, > > Thanks for prompt reply. Please see my comments inline. > > > Best Regards, > Vishal > > -----Original Message----- > From: Emmanuel Lecharny [mailto:[email protected]] > Sent: Thursday, October 13, 2011 12:07 PM > To: [email protected] > Subject: Re: Strange problem in reading the data on socket in ProtocolDecoder > > > On 10/13/11 6:58 AM, Vishal Gupta wrote: >> ==================== >> Scenraio: >> ==================== >> - A server is sending data to the MINA server which has implemented >> "CumulativeProtocolDecoder" >> - Server is sending x bytes >> - While getting data first thread is getting data from position m instead of >> position 0 > In the decoder ? If the data has just been received, then the data > should be at position 0. If it's not the case, then somewhere in your > code, you are reading the IoBuffer, moving the position. >> - Second thread picks the data from 0 to m > Probably because the first buffer has been fully read. >> - Either of the thread doesn't get the complete data and that's why protocol >> decoding is failed > Without the complete decoder code, it's hard to tell what's going wrong. > > In any case, there is something wrong in your code. > > [Vishal] Decoder code can sure be suspected, but the logs what I have sent is > indicating the data received in decode function at entry(before decoding has > even started) and there are two threads picking up the data (partially > each)....this is the main problem for which decoder has not yet in picture. > > (2011-10-12 > 14:18:01,039)(pool-3-thread-44)(DEBUG)(IoFilterEvent.java)(fire)(118)--Event > MESSAGE_RECEIVED has been fired for session 35 > (2011-10-12 > 14:18:04,589)(pool-3-thread-45)(DEBUG)(IoFilterEvent.java)(fire)(69)--Firing > a MESSAGE_RECEIVED event for session 35 > (2011-10-12 > 14:18:04,590)(pool-3-thread-44)(INFO)(LoggingFilter.java)(log)(141)--RECEIVED: > HeapBuffer[pos=0 lim=86 cap=256: 10 09 00 00 10 10 00 00 10 11 00 00 10 12 > 00 00...] > (2011-10-12 > 14:18:04,589)(pool-3-thread-45)(INFO)(LoggingFilter.java)(log)(141)--RECEIVED: > HeapBuffer[pos=0 lim=128 cap=128: 00 D4 60 07 92 80 88 00 CD 01 01 60 07 92 > 00 00...] Ok. You have inserted an ExecutorFilter at first position in your chain (I have missed this from your first mail) : ... IoAcceptor acceptor = new NioSocketAcceptor(); acceptor.getFilterChain().addLast("threadPool", new ExecutorFilter(Executors.newCachedThreadPool())); ... This is the guarantee that you will have different threads processing the incoming messages. First, try to avoid using an executor, to see if your code is working. It should. Then when you have proved that yoru code is working, ask yourself if you need to add an executor in your chain. If so, then add it at the end of the chain, not at the beginning. Unless the decoding is an expensive operation, then you should use an OrderedThreadPoolExecutor, which will push any messages arriving on a session to the same thread. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
