qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ritchie <ritch...@apache.org>
Subject Re: [RFC][java] Additional Broker Logging
Date Wed, 08 Jul 2009 08:23:53 GMT
2009/7/7 Rafael Schloming <rafaels@redhat.com>:
> 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 :)


> --Rafael
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

Martin Ritchie

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message