mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [MINA 3.0] Debugging toolkit
Date Mon, 25 Jan 2010 16:29:10 GMT

On Jan 25, 2010, at 8:21 AM, Ashish wrote:

> On Mon, Jan 25, 2010 at 9:48 PM, Emmanuel Lecharny <elecharny@gmail.com 
> > wrote:
>> Alan D. Cabrera a écrit :
>>> On Jan 19, 2010, at 7:41 AM, Ashish wrote:
>>>> Had picked this form one the discussion threads and added to the  
>>>> MINA
>>>> 3.0 design page, so that we don't loose this.
>>>> had some initial thoughts around this, like we can some kind of
>>>> visualization tool build around MINA, which can help us see/debug
>>>> the MINA based System. One can view number of IoSession's,  
>>>> IoChain's,
>>>> configuration etc.
>>>> It could be build as an Eclipse plugin or a standalone UI talking  
>>>> to
>>>> MINA code via JMX.
>>>> I am not sure, but we can see if we can extend ProtoTiger as a
>>>> debugging/visualization tool.
>>>> These are just some initial thought, will refine the  
>>>> understanding as
>>>> we progress further with 3.0 design.
>>>> Any suggestion?
>>> I wouldn't classify these as debugging toolkit but a management  
>>> toolkit;
>>> very critical.
>>> I was also thinking about the logging discussion that we had  
>>> earlier and I
>>> think that I've come around to the thinking that it's important to  
>>> provide
>>> some kind of logging mechanism who's scope is narrowed to a  
>>> particular
>>> session.  (I'm still not sold on the usefulness of a general  
>>> logging filter
>>> such as the one that we have now).
>> With JMX, and a decent tool (something like MX4J :
>> http://mx4j.sourceforge.net/), providing some graphs should be a  
>> piece of
>> cake.
> Emm ! You read my mind. I had something similar in my mind :-)
> More like number of session, and if possible the chain associated with
> the same..
> there could be more such useful stuff on that UI

It would be good if we had some kind of conventions, e.g. naming and  
event, that other protocols would follow.

>> Being able to track down one single session is also something that  
>> a JMX
>> based tool can do. Logs ? That's for post-mortem debugging :/

We use logs extensively when working on production issues where  
sessions can have the lifetime of subatomic particles.  We should  
carefully consider the usefulness of logging in this toolkit.


View raw message