[
https://issues.apache.org/jira/browse/DIRMINA-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14124323#comment-14124323
]
Emmanuel Lecharny commented on DIRMINA-885:
-------------------------------------------
I have pushed this issue to 3.0.
Fixing the way we process session removal when we have reached the
end-of-stream (ie, when the client has closed the channel on its side) would
lead to heavy refactoring in the handling of the session removal method.
In 3.0, what we should do is to first try to flush all the pending messages
before closing the session, as the socket might be still opened even if the
client->remote channel is closed. If both ways are closed, anyway, the write
would fail and we would be able to close 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
> Fix For: 3.0.0-M3
>
>
> 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)
