[
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
