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.