[jira] [Comment Edited] (DIRMINA-885) session is closed before the server writes back to the client

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204528#comment-13204528 ] 

Emmanuel Lecharny edited comment on DIRMINA-885 at 9/5/14 11:08 AM:
--------------------------------------------------------------------

It seems that a new implementation of IoProcessor involves a lot of work, so I'd decided to find another way...
I've re-read the code many a time, and confirmed that one of the reason for the issue is that the IoHandler.messageReceived() is invoked in the thread created in ExecutorFilter. Since it is executed in parallel (i.e. asynchronously) with the threads running AbstractPollingIoProcessor.Processor.run(), which basically performs channel read, message received event firing(kicking off IoHandler.messageReceived() ), flush, session-removal sequentially, IoHandler.messageReceived() can be performed before or after the session-removal.
My instinct is to make them run synchronously...which will definitely cause severe performance penalty. The number of request that can be simultaneously processed is limited to the number of IoProcessor.
So I ended up with this:
{code}
acceptor = new NioSocketAcceptor( new SimpleIoProcessorPool<NioSession>(NioProcessor.class, processorCount) );
{code}
The original issue is resolved, but it comes with worrying performance drop-down.
I deliberately coded a Thread.sleep(7000) in messageReceived(), and I set processorCount = 4, here's a brief load test result:
concurrent requests sent: 4
result: all replies received in 7 sec                                        

concurrent requests sent: 5
result: 3 replies received around 7 sec, 2 replies received around 14
question: Aren't 4 of 5 requests supposed to be processed concurrently?

concurrent requests sent: 8
result: all replies received in 14 sec

This is my newest progress I've made up to now...it seems that this is the mediocre solution I have to make do with for now.
Thanks for your help, Emma. If you have any progress, just let me know. Much appreciated! 



was (Author: carusyte):
It seems that a new implementation of IoProcessor involves a lot of work, so I'd decided to find another way...
I've re-read the code many a time, and confirmed that one of the reason for the issue is that the IoHandler.messageReceived() is invoked in the thread created in ExecutorFilter. Since it is executed in parallel (i.e. asynchronously) with the threads running AbstractPollingIoProcessor.Processor.run(), which basically performs channel read, message received event firing(kicking off IoHandler.messageReceived() ), flush, session-removal sequentially, IoHandler.messageReceived() can be performed before or after the session-removal.
My instinct is to make them run synchronously...which will definitely cause severe performance penalty. The number of request that can be simultaneously processed is limited to the number of IoProcessor.
So I ended up with this:
acceptor = new NioSocketAcceptor( new SimpleIoProcessorPool<NioSession>(NioProcessor.class, processorCount) );
The original issue is resolved, but it comes with worrying performance drop-down.
I deliberately coded a Thread.sleep(7000) in messageReceived(), and I set processorCount = 4, here's a brief load test result:
concurrent requests sent: 4
result: all replies received in 7 sec                                        

concurrent requests sent: 5
result: 3 replies received around 7 sec, 2 replies received around 14
question: Aren't 4 of 5 requests supposed to be processed concurrently?

concurrent requests sent: 8
result: all replies received in 14 sec

This is my newest progress I've made up to now...it seems that this is the mediocre solution I have to make do with for now.
Thanks for your help, Emma. If you have any progress, just let me know. Much appreciated! 


> session is closed before the server writes back to the client
> -------------------------------------------------------------
>
>                 Key: DIRMINA-885
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-885
>             Project: MINA
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.2
>         Environment: win XP, jdk 1.6.0_23
>            Reporter: Carusyte
>            Priority: Minor
>
> I am using some kind of test tool as client to send arbitrary data, my decoder and handler work correctly as expected, but MINA closes the session before my encoder is called. As I looked into the source code, AbstractPollingIoProcessor seems to schedule a session remove as long as the # of bytes read from the channel == -1 (line 673 and line 706). As per the documentation of java.nio.channels.ReadableByteChannel.read(ByteBuffer dst), this method returns -1 if the channel has reached end-of-stream, but is it really necessary to close the session even before the client receive any response? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)