[
https://issues.apache.org/jira/browse/DIRMINA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trustin Lee updated DIRMINA-467:
--------------------------------
Description:
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. ;)
was:
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 not 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. ;)
> 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.
