[infinispan-dev] More verbose logging

[Adrian Nistor]

What if we include that verbose info in toString() only if trace is 
enabled? :)

On 02/20/2013 02:36 PM, Dan Berindei wrote:
>
>
> On Wed, Feb 20, 2013 at 11:49 AM, Mircea Markus <mmarkus at redhat.com 
> <mailto:mmarkus at redhat.com>> wrote:
>
>     I always liked this idea of categories but never saw it at use.
>     Are there any projects that use this logging approach?
>
>     On 20 Feb 2013, at 09:57, Sanne Grinovero wrote:
>
>>     +1 for using categories
>>
>>     We could even experiment combining multiple categories, for
>>     example in
>>     this case you could have a "RPCDispatcher" category and also have a
>>     "RPCDispatcher.includeCacheEntries" which will make descriptions
>>     more/less verbose.
>
>     That's not what I understand by a category - "logical process" as
>     defined by David. I consider "Remoting" or "Rehashing" a category,
>     but RPCDIspatcher is just an entity (too fine grained)
>     and RPCDispatcher.includeCacheEntries even more so.
>
>     Also that wouldn't necessarily solve the problem Manik raised: in
>     this particular case the toString of StateResponseCommand is huge.
>     Adrian/Dan is this needed for debugging state transfer issues? If
>     so +1 for managing it with the verbose flag.
>
>
> Yeah, we couldn't introduce a RpcDispatcher.includeCacheEntries 
> category anyway because the cache entries are included in the 
> command's toString() - the logger can't do anything to filter them out.
>
> I think we could eliminate the cache entries from 
> StateResponseCommand.toString() (and the segment owners from 
> ConsistentHash.toString()), and only log them separately, under a 
> different category/class name.
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130220/1f9f4501/attachment.html