[ https://issues.apache.org/jira/browse/DIRMINA-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-631: -------------------------------------- Fix Version/s: 3.0.0-M1 I suggest a potspone to 3.0, as we will redesign the chain. > 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: 3.0.0-M1 > > > 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.