[
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
