You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Trustin Lee (JIRA)" <ji...@apache.org> on 2007/07/26 09:05:31 UTC
[jira] Resolved: (DIRMINA-405) IoSession.suspendRead() doesn't
suspend read operation immediately when ProtocolCodecFilter is used.
[ https://issues.apache.org/jira/browse/DIRMINA-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trustin Lee resolved DIRMINA-405.
---------------------------------
Resolution: Fixed
ProtocolCodecFilter's internal ProtocolDecoderOutput implementation now stops flushing events when read operation is suspended.
> IoSession.suspendRead() doesn't suspend read operation immediately when ProtocolCodecFilter is used.
> ----------------------------------------------------------------------------------------------------
>
> Key: DIRMINA-405
> URL: https://issues.apache.org/jira/browse/DIRMINA-405
> Project: MINA
> Issue Type: Bug
> Components: Filter
> Affects Versions: 1.0.4, 1.1.1
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 1.0.5, 1.1.2
>
>
> IoSession.suspendRead() changes the sessions's traffic mask and notifies the SocketIoProcessor. It is a normal behavior that the actual traffic control occurs asynchronously. For example, If a user calls IoSession.suspendRead() after receiving a message after ExecutorFilter doesn't assure he or she receives another message even after suspendRead() is called.
> However, it must guaranteed that no more messageReceived event is fired immediately after suspendRead() is called from the same thread that SocketIoProcessor runs for users who need precise traffic control.
> To resolve this issue, ProtocolCodecFilter should stop calling decoder as soon as the traffic mask is updated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.