Timing of incrementing the messages written/read counters

["W.B. Garvelink" <ba...@gmail.com>]

Hi,



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.


WDYT?

Thanks,
Barend


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.

Re: Timing of incrementing the messages written/read counters

["W.B. Garvelink" <ba...@gmail.com>]

Here's the one:
https://issues.apache.org/jira/browse/DIRMINA-631



Barend



On Thu, Oct 23, 2008 at 12:16 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> W.B. Garvelink wrote:
>>
>> Hi,
>> The fix itself should be fairly simple. If you guys agree I can enter
>> a JIRA issue for this.
>>
>
> Sure ! Most certainly a better way to be sure that your proposal is
> addressed sooner or later :)
>

Re: Timing of incrementing the messages written/read counters

[Emmanuel Lecharny <el...@gmail.com>]

W.B. Garvelink wrote:
> Hi,
> The fix itself should be fairly simple. If you guys agree I can enter
> a JIRA issue for this.
>   
Sure ! Most certainly a better way to be sure that your proposal is 
addressed sooner or later :)
>
> WDYT?
>
> Thanks,
> Barend
>
>
> 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.
>   
Well, I think that those Tail and Head filter are pretty much useless. 
IMHO, they should simply be removed.


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org