2009/7/7 Rafael Schloming <[email protected]>: > Martin Ritchie wrote: >> >> Java Broker Users, >> I have been working on designs for improving the logging from the Java >> Broker. The current logging is more aimed at developers so providing >> more operational focused log messages would be good. >> >> The design is up on the wiki here: >> >> http://cwiki.apache.org/confluence/display/qpid/Java+Broker+Design+-+Operational+Logging >> and will be proceeding under JIRA : >> https://issues.apache.org/jira/browse/QPID-1970 >> >> Comments greatly appreciated. At this stage I'm looking to get the >> ability to perform this type of logging started with some simple >> status updates. Refinement of the messages and other details will come >> later. > > I like the high level overview. How exactly do you see protocol level > logging fitting into things? Also, have you considered finer grained control > of logging? It might be useful to be able to enable or disable finer grained > logging for a specific connection.
I'd like to see the protocol logging being included as a debug/trace level event on a connection. Although at this stage we are looking purely at having on|off operational logging rather than a deeper hierarchy. I've had some initial thoughts on a finer grained approach but have parked that for now. Getting some improved status logging out of the broker is the first step. This of course is going to be in addition to the logging that is already available in the broker. It will just have a more operational focus rather than the current logging which tends to focus on information for developer. > Regarding the detailed design notes, I'm struggling a bit to understand the > purpose of the various interfaces you describe. Based on the high level > overview, I would have imagined something simpler, e.g. Channel.log(...), > and Connection.log(...). I was thinking that there would be concrete implementations of the interface that would look much as you point out: ChannelMessageStatusLogger , ConnectionMessageStatusLogger , etc. Keeping the logging separate from the Channel and Connection implementation gives the freedom to more easily change the way the loggers would work. The inital pass will simply wrap log4j but I have seen issues with log4j blocking on a full file system so there is potentailly a reason to replace log4j. Having the calls to log4j in a single place would make it much easier to replace. You also want to minimise the amount of processing and state a log statement requires. So ensuring any object creation is guarded with an isEnabled and giving an object that has cached the formated log string means we can do less processing on every log. This will be important when we start looking to log on the message delivery path where we really need to minimise any impact of the logging. Hope that answers your questions. If not let me know :) Martin > --Rafael > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
