Patrick Hunt commented on ZOOKEEPER-816:

Typically log4j logs are expected to be consumed by users - i.e. debugging, 
here you're really talking about output that will be machine processed. Is this 
really logging in the log4j typical sense, perhaps a separate mechanism should 
be used? Another problem with log4j logging is that changes to the message 
format, say to make it more "readable", can cause problems for the down stream 
processor. Not to mention that a separate mechanism could be made much more 
efficient than the general log4j log mechanism. Perhaps ZK's own WAL could be 
used for this - reuse the WAL code or write the information directly to the ZK 
transaction log (might not be such a good idea, but should be considered as an 

Additionally you should consider something like Aspects for this project. This 
is a cross-cutting feature, something that aspects are well suited for. A 
benefit of this approach is that it would allow those interested in the feature 
to enable it while those uninterested would incur zero performance penalty.

> Detecting and diagnosing elusive bugs and faults in Zookeeper
> -------------------------------------------------------------
>                 Key: ZOOKEEPER-816
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-816
>             Project: Zookeeper
>          Issue Type: New Feature
>            Reporter: Miguel Correia
>            Priority: Minor
> Complex distributed systems like Zookeeper tend to fail in strange ways that 
> are hard to diagnose. The objective is to build a tool that helps understand 
> when and where these problems occurred based on Zookeeper's traces (i.e., 
> logs in TRACE level). Minor changes to the server code will be needed.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to