Sorry for joining this discussion late, it was held before I joined this list. Back in march/april, consensus was reached on this:
On Thu, Mar 20, 2008 at 12:54 AM, peter royal <[EMAIL PROTECTED]> wrote: > 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 was thinking of taking all the methods, and making: > > IoServiceStatistics getStatistics() > >.. they'll all still be available, just as methods on the statistics object. ...which I agree is the right thing to do. I have some concern though that we're just trading the massive IoService API for a massive statistics API. It's an improvement!, but please consider splitting off the statistics methods into *two* statistics objects: one that deals with throughput and message size, and one that deals with idle times. Furthermore: I think the statistics objects returned from the IoService should be defined as interfaces, not classes (this is just me stating the obvious, given how interfaces are used in the rest of MINA). The same interface can then be deployed into the JMX MBeanServer, and the method implementations can remain where they are inside AbstractIoService, which just implements the interfaces and returns its this-pointer from the getStatistics() methods. Regards, Barend
