|Subject:||Timing of incrementing the messages written/read counters|
|From:||W.B. Garvelink (bare...@gmail.com)|
|Date:||Oct 22, 2008 1:45:44 pm|
Kind of a long message, so I'll start with a summary:
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.
To elaborate on that:
In MINA 2.0-M3 the initiative for incrementing the readMessages/-Bytes and writtenMessages/-Bytes statistics is in DefaultIoFilterChain. All four of these counters are incremented at the IoService end of the filter chain. The received counters are both incremented just before firing the messageReceived() event into the chain and the written counters are both incremented before firing the messageSent() event into the chain.
I believe that the current approach in DefaultIoFilterChain is correct for the read/written Bytes counters, but not correct for the read/written Messages counters. I think the messages counters should be incremented at the Application end of the filter chain instead of at the IoService end.
To explain why: I have an IoFilter chain (on a datagram IoService) in which a SegmentationFilter takes in a single application message to filterWrite() and, depending on its size, splits it into multiple packets that are all written into the nextFilter in sequence. 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 and writes ACK packets to the network layer that may carry no payload data at all. Again, its messageSent() method takes great care to invoke the nextFilter only once for every writeRequest that entered #filterWrite(). In other words, 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.
The fix itself should be fairly simple. If you guys agree I can enter a JIRA issue for this.
P.S.: I think it would be a good idea to mention "Application end" and "IoService end" in the javadocs for the TailFilter and HeadFilter classes and the #addFirst()/#addLast() methods. I find them easier to understand.