[
https://issues.apache.org/jira/browse/DIRMINA-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491191#comment-13491191
]
Emmanuel Lecharny commented on DIRMINA-738:
-------------------------------------------
I'm looking at the IoEventQueueThrottle class, and there is something
embarrassing about it : the polled() and offered() method are incrementing and
decrementing the counter using an unreliable method : estimateSize().
The estimateSize() method tries to compute the size of the message using
reflection, but there is no guarantee whatsoever that the computed size
reflects the actual message size. This seems a very brittle implementation,
assuming that we could block the whole system if the threshold is reached.
The problem is that the IoEventQueueThrottle is always used after the codec
filter (there is no way we can efficiently use an Executor filter before the
codec filter : we might not be able to correctly decode messages otherwise if
the PDU is fragmented) so we never work on a IoBuffer...
What you propose (ie matching the polled estimated size with the polled
estimated size seems a better approach : at least, the size would be equals...
I also do think that the notify() call could be replaced by a notifyAll() call,
giving some room for more than a thread to be processed if a big chunk of
memory has been released, when a call to notify() will only allow one single
thread to proceed.
I can apply the suggested modifications, but I don't have a test to reproduce
the environment...
> Using IoEventQueueThrottler with a WriteRequestFilter can lead to hangs
> ------------------------------------------------------------------------
>
> Key: DIRMINA-738
> URL: https://issues.apache.org/jira/browse/DIRMINA-738
> Project: MINA
> Issue Type: Bug
> Components: Filter
> Affects Versions: 2.0.0-M6
> Reporter: Daniel John Debrunner
>
> The javadoc for WriteRequestFilter shows an example using
> IoEventQueueThrottler to throttle writes. First issue is that
> IoEventQueueThrottler is not well documented, I'd assumed it was throttling
> number of messages, instead its threshold is number of bytes. Second issue is
> that if a message estimated length is less than the threshold then the write
> hangs, even with an async executor in the chain.
> Emmanuel Lécharny also wrote:
> FYI, the counter (threshold) is *never* decreased.
> To be frank, this is not a piece of code I know, but from what I see, it's
> *extremely* dubious that it does something useful, and most likely to block
> forever.
> I would suggest not to use this
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
