mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: IoSession throughput counters not working in MINA 2.0M6?
Date Sun, 26 Jul 2009 23:36:31 GMT
Matthew Phillips wrote:
> On 26/07/2009, at 10:19 PM, Emmanuel Lecharny wrote:
>> Matthew Phillips wrote:
>>> On 26/07/2009, at 6:29 PM, Emmanuel Lecharny wrote:
>>>> Matthew Phillips wrote:
>>>>> Hello,
>>>>> I'm using IoSession.getReadBytesThroughput () and 
>>>>> getWrittenBytesThroughput () to output stats from a MINA-based 
>>>>> application, and even under heavy load these are always 0.0. Is 
>>>>> there something I need to enable?
>>>> I'm not sure they are still active. We had some issues with 
>>>> concurrent updates of those counters.
>>> I can see that might be tricky with MINA's highly concurrent 
>>> architecture. I was planning to implement something like the 
>>> counters myself as part of a "bad client" throttling/disconnection 
>>> filter. Is it planned to fix the built-in counters before 2.0 final, 
>>> or should I proceed to do it myself?
>> IMO, such counters should be thought as a filter, not a base element 
>> of the MINA architecture.
>> Having them hard coded make them a bottleneck right now, and 
>> introduce some cost that is not generally wanted.
>> So if you think about building them as a filter, I must say that it's 
>> probably the best idea. We will probably do that some time in the 
>> future anyway...
> That would sound reasonable, especially given a filter in the right 
> place would (mostly) solve the concurrency problem. But it would be 
> problematic for the filter to just call IoSession.updateThroughput (), 
> because (a) the counts are long's and therefore not atomically updated 
> and (b) the AbstractIoSession.updateThroughput () method updates a 
> number of related counters with no sync block, which would mean that 
> other threads reading throughput numbers could see garbled results 
> (especially if they read a counter half way through it being updated).
> As an alternative, I could have the filter keep its own stats in an 
> AtomicLong.
This is what we used in the IoServiceStatistic class. It guarantees you 
that the value is not complete garbage in a concurrent env.
> I'm sure I'm not telling you anything new here, but it does seem that 
> any reasonable attempt at handling misbehaved clients would need such 
> stats, and handling DOS's (accidental or deliberate) is something 
> nearly every MINA-based app will need to do if it gets deployed in a 
> production environment.
Well, I would say that any decent production system would use another 
system to protect the server against DOS (at least, deliberate ones). 
Now, you are right, it's probably a good idea to have a good set of 
*valid* counters at some point. The only problem is to have them 
implemented correctly ;)

PS: This is an area where MINA can most certainly benefit from some 
large improvement...

cordialement, regards,
Emmanuel L├ęcharny

View raw message