[jira] [Resolved] (DIRMINA-631) AbstractIoFilter: increment writen- and receivedMessages statistics on application end of filter chain

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

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

Emmanuel Lecharny resolved DIRMINA-631.
---------------------------------------
    Resolution: Fixed

Fixed with commit 81f55c8f6de1a73c2f999fd4cf20546fd54c09a0

The increaseWrittenMessages has been moved to the TailFilter, counting the real messages sent, after the Filters have been processed.

> AbstractIoFilter: increment writen- and receivedMessages statistics on application end of filter chain
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DIRMINA-631
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-631
>             Project: MINA
>          Issue Type: Improvement
>          Components: Filter
>    Affects Versions: 2.0.0-M3
>         Environment: MINA 2.0.0-M3
>            Reporter: Barend Garvelink
>             Fix For: 2.0.8
>
>
> This is the JIRA for the mina-dev mailing list discussion here:
> http://markmail.org/message/e7qw6k5tp52knpav
> To summarise:
> {quote}
> I would like to suggest that the invocations of increaseWrittenMessages() and increaseReceivedMessages() are moved from their current spot in AbstractIoFilter into the appropriate methods of TailFilter. The increaseWrittenBytes() and increaseReceivedBytes() invocations can stay where they are. 
> [...]
> I have an IoFilter chain in which a SegmentationFilter takes in a single application message to filterWrite() and splits it into multiple packets. On the way back, it filters the messageSent() events for every packet sent, collating them into a single call to nextFilter#messageSent() for each original application-level message. Further down the chain, I have an ARQ filter which can re-send packets that weren't acknowledged in time. Both filters can cause a different number of messages to come out at the IoService end than went into them at the Application end (and vice versa). 
> [...]
> In this scenario the writtenBytes/receivedBytes counters are fine as they are, but the writtenMessages/readMessages counters are basically useless in their current form. Their value depends on the size of the messages my application sends and on the quality of the network connection (i.e. if any retries were necessary) and even on whether the outgoing ACK packets can piggyback on a data packet or have to be sent out on their own. Compared to a message counter I keep at the application level, the messages sent/received values tracked in IoServiceStatistics diverge immediately. 
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)