You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Carusyte (Created) (JIRA)" <ji...@apache.org> on 2012/02/07 13:59:00 UTC
[jira] [Created] (DIRMINA-885) session is closed before the server
writes back to the client
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Emmanuel Lecharny (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203391#comment-13203391 ]
Emmanuel Lecharny commented on DIRMINA-885:
-------------------------------------------
As I said, read() will return -1 for many reasons, one of them being that the remote peer has closed the Input side. The client is still able to received data. We don't support such a behavior atm, we simply close the channel.
The fact that your client receive some message before the session removal can be just an artefact : the channel has some data being sent (but not received by the client) and the session is not yet removed.
Right now, I don't see a simple way to workaround your issue, I need to think a bit more about it.
FTR, what tool are you using ?
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Emmanuel Lecharny (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203317#comment-13203317 ]
Emmanuel Lecharny commented on DIRMINA-885:
-------------------------------------------
If the client has closed the connection, it does not make any sense to try to flush something in the channel : it won't get sent anyway. This is why we don't inject the messages to the queue.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DIRMINA-885) session is closed
before the server writes back to the client
Posted by "Carusyte (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205235#comment-13205235 ]
Carusyte edited comment on DIRMINA-885 at 2/10/12 5:11 AM:
-----------------------------------------------------------
Thanks for the clarification. The load test I am conducting is casual, just in an attempt to confirm that my comprehension of the multi-IoProcessor model works as expected. Configuration is set to defaults, except for the bind address and number of processors (4 processors is set via the constructor method). The load generator is basically programmed using MINA's NioConnector (which is not the test tool I mentioned earlier which causes read() return -1 in the server side).
One more thing, if I decided to use this multi-IoProcessor model, I suspect that the potential efficiency of non-blocking nio might be undermined. Furthermore, the pool of processors does not assign idle processor effectively, as the following code in SimpleIoProcessorPool (line 323) reveals:
processor = pool[Math.abs((int) session.getId()) % pool.length];
In effect, sessions waiting for an idle processor might get a busy one even if there are plenty of idle ones available in the pool.
was (Author: carusyte):
Thanks for the clarification. The load test I am conducting is casual, just in an attempt to confirmed that my comprehension of the multi-IoProcessor model works as expected. Configuration is set to defaults, except for the bind address and number of processors (4 processors is set via the constructor method). The load generator is basically programmed using MINA's NioConnector (which is not the test tool I mentioned earlier which causes read() return -1 in the server side).
One more thing, if I decided to use this multi-IoProcessor model, I suspect that the potential efficiency of non-blocking nio might be undermined. Furthermore, the pool of processors does not assign idle processor effectively, as the following code in SimpleIoProcessorPool (line 323) reveals:
processor = pool[Math.abs((int) session.getId()) % pool.length];
In effect, sessions waiting for an idle processor might get a busy one even if there are plenty of idle ones available in the pool.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Carusyte (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203205#comment-13203205 ]
Carusyte commented on DIRMINA-885:
----------------------------------
channel.isOpen() always returns true, even if the client has closed the connection.
I think, according to AbstractPollingIoProcessor.Processor.run() method, pending response messages should have been flushed before the session is removed (line 1094 and 1097). However, flushingSessions.isEmpty() always returns true because selectionKey.isWritable() always returns false and thus the session never gets a chance to be added to the write queue (line 662). Why is this?
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Carusyte (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203582#comment-13203582 ]
Carusyte commented on DIRMINA-885:
----------------------------------
It seems that this issue is communication pattern dependent. The AbstractPollingIoProcessor relies on the read channel's return value to determine whether to close the connection, while in my case, a reply should be attempted before closing the connection, thus the control of connection is less dependent on the other side. I am thinking of implementing a more tailored IoProcessor, which realizes the aforementioned logic and monitors the session pool, disposing any sessions that has out-lived a user-configurable time.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Emmanuel Lecharny (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205283#comment-13205283 ]
Emmanuel Lecharny commented on DIRMINA-885:
-------------------------------------------
I understand. We know that MINA 2 has a big issue if the processing of a session takes a lot of time, as no other session associated with this IoProcessor will be processed until the current session is fully processed : https://issues.apache.org/jira/browse/DIRMINA-668.
Using an Executor in the chain might help here, but the thing is that if you do so, it may impacts the global performances, and makes thing a bit more complicated when t comes to close a session.
We are trying to find a better solution for MINA 3, and it could be to move the Executor to the Handler, instead of having it in the middle of the chain.
FYI, the decision to use an Executor in the middle of the chain was based on the idea that MINA should be an implementation of SEDA design (https://docs.google.com/viewer?a=v&q=cache:NV9FGoBV70UJ:www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf+&hl=en&pid=bl&srcid=ADGEEShsguHCITDbhaayiXhb_mrU3cHjbUnmeUB6giW-bpYuwLv7pgymWPc-qHN-VTEwAfUEWbLrVElp9VPV65C7i8m0JzXVecQSTe7LuYiXWamf43I5wjkd7dyLxSdzHL3_rpakKv9b&sig=AHIEtbS788RvV5kFICQCxJ7b4a4mwbns7w&pli=1), where each filter communictaes with the following filter using a queue, and each filter was supposed to use an Executor. We never went that far, but IMO, the current design could greatly be improved.
Nothing is esy when it comes to implement a NIO framework :)
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Carusyte (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203376#comment-13203376 ]
Carusyte commented on DIRMINA-885:
----------------------------------
Let's get back to the original issue. I think channel.read(Bytebuffer dst) == -1 does not necessarily indicates that the client has closed the connection. However, this might be a communication implementation difference. Since the test tool I am using is commonly used in our dev team and has no issue working with other server applications, I have to figure out a way to work around this...
Sometimes the tool can receive the response, it seems that the write request invoked in the handler is processed in the handler thread before the session is removed from the processor thread. There might be some way to intervene the order the queue events are processed. Is this a good idea?
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Emmanuel Lecharny (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204657#comment-13204657 ]
Emmanuel Lecharny commented on DIRMINA-885:
-------------------------------------------
At this point, having an ExecutorFilter in the chain is a real problem if you want to be able to handle half-closed channels. The big issue is that you won't know how many threads are being processed behind the executor, so you can't know when to close the session, if you decide not to close it when the read() return -1.
However, in your tests, I would question the need of an ExecutorFilter : if you have many processors, then it's probably a better idea to have more NioProcessor (each one of them have a dedicaced Selector) and no Executor in the chain. That could probably scale better.
Just let us know. Btw, we are interested by the bench you are conducting : what are you trying to measure ? What is the used config ? What is the purpose of this bench ? Which tool are you using?
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Emmanuel Lecharny (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202432#comment-13202432 ]
Emmanuel Lecharny commented on DIRMINA-885:
-------------------------------------------
We don't support partial closing of a channel (ie, if one side decide to close the output side, then the reader on the other side will get -1 when trying to read the channel.
Right now, we simply close the channel brutally, which is not the best possible option. We could have exposed the shutdownInput/shutdownOutput methods, and required that the server does not close the session, unless the sessions requires it.
One last thing : if we get a -1 when doing a read, we could also check that the channel is closed, and if so, remove the session.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Carusyte (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205235#comment-13205235 ]
Carusyte commented on DIRMINA-885:
----------------------------------
Thanks for the clarification. The load test I am conducting is casual, just in an attempt to confirmed that my comprehension of the multi-IoProcessor model works as expected. Configuration is set to defaults, except for the bind address and number of processors (4 processors is set via the constructor method). The load generator is basically programmed using MINA's NioConnector (which is not the test tool I mentioned earlier which causes read() return -1 in the server side).
One more thing, if I decided to use this multi-IoProcessor model, I suspect that the potential efficiency of non-blocking nio might be undermined. Furthermore, the pool of processors does not assign idle processor effectively, as the following code in SimpleIoProcessorPool (line 323) reveals:
processor = pool[Math.abs((int) session.getId()) % pool.length];
In effect, sessions waiting for an idle processor might get a busy one even if there are plenty of idle ones available in the pool.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Carusyte (Commented) (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 ]
Carusyte commented on DIRMINA-885:
----------------------------------
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-885) session is closed before the
server writes back to the client
Posted by "Carusyte (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203400#comment-13203400 ]
Carusyte commented on DIRMINA-885:
----------------------------------
The tool I am using is developed by another team and I don't have the source code. I guess it was coded by C++/.net or something.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira