[
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
