[jira] Resolved: (DIRMINA-467) IoFilter has to filter a setTrafficMask call.

["Trustin Lee (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DIRMINA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee resolved DIRMINA-467.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0.0-M1

> IoFilter has to filter a setTrafficMask call.
> ---------------------------------------------
>
>                 Key: DIRMINA-467
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-467
>             Project: MINA
>          Issue Type: New Feature
>          Components: Core
>    Affects Versions: 2.0.0-M1
>            Reporter: Trustin Lee
>            Assignee: Trustin Lee
>             Fix For: 2.0.0-M1
>
>
> So far, setTrafficMask operation (such as suspend/resume Read/Write) was treated differently from other session operations such as close and write.  It simply bypassed IoFilterChain, so no IoFilter implementation was able to override the operation.  An IoFilter can suspend and resume traffic by calling IoSession.setTrafficMask(), but it can be simply overridden by a user request, which subverts the filter implementation.
> For example, ReadThrottleFilter will not work as expected if a user changes the traffic mask randomly.
> Another reason for supporting setTrafficMask filtering is that it makes more than one traffic-controlling filters harmonize with each other instead of breaking each other.  For example, TrafficShapingFilter and ReadThrottleFilter could be added to one filter chain, and both filters will want to suspend incoming traffic if any condition doesn't meet and resume if all conditions meet.  Without setTrafficMask filtering, two filters will have to be tightly coupled to adjust the traffic mask carefully.  With proper setTrafficMasek filtering support, such a tight coupling is unnecessary because any filter can override the traffic mask in a filter chain.  An IoFilter which is placed in front of other filters will have precedence in traffic control.
> Adding this feature means that we have to add some facility like we did for write operations (IoFilter.filterWrite, WriteFuture and WriteRequest), which breaks backward compatibility of an IoFilter.  I think it's OK because we have broken the backward compatibility of IoFilter long time ago. ;)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.