[
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
