Peter, Emmanuel, I understand your point. So this is a "cosmetic" change where all those methods will move to another class which will contain more or less the same methods and vars. Your intention is to get a smaller IoService class.
As those values are update all the time (each send, receive, ...), they will still be updated from IoService through this new class. I did not read carefully the source code (I may try) but I just want to point that it could be not so simple as first though. If there is no problem to introduce a new class without breaking the statistics then why not ? BTW, why not do the same thing to IoSession in this case ? Is it just about the same... ? On the JMX part, I did not take a long run on JMX up to now, but as far as I read the API, it still depends on the IoService and IoSession, so on the current implementation or the next one with the new class on statistics. Except the way one can access to this information (through the JMX service or directly from MINA), it seems not different. Am I correct ? Frederic ----- Original Message ----- From: "peter royal" On Mar 19, 2008, at 3:23 PM, Frédéric Brégier wrote: > Those numbers are useful in production... (at least for my case) > I know, it's only about statistics but some people want them... > > If I follow your idea, what will return IoService.getStatistics() ? > What will you propose instead of those methods in IoService? > Also, those numbers are there, not elsewhere, so moving out > of IoService, how could you do the same service ? > > I 'm not an expert as you on Mina, so I probably miss something there. i was thinking of taking all the methods, and making: IoServiceStatistics getStatistics() .. they'll all still be available, just as methods on the statistics object. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
