qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: [RFC][java] Additional Broker Logging
Date Wed, 08 Jul 2009 11:04:15 GMT
Martin Ritchie wrote:
> 2009/7/8 Rafael Schloming <rafaels@redhat.com>:
>> Martin Ritchie wrote:
>>>> 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 :)
>> Using facades and delegates makes sense on the implementation side, but it
>> doesn't seem like a good idea to need to understand how they're all wired
>> together in order to actually log a message. I might be getting the wrong
>> end of the stick though. Maybe you could post a more detailed example of the
>> API portion as you see it being used to perform logging?
>>
>> --Rafael
> 
> Hi,
> The developer writting the log shouldn't need to understand how
> everything is wired together.
> On construction the Channel/Connection objects would retrieve a logger:
> 
> _statusLogger = StatusLoggerFactory.createLogger(this); //Where this
> is a Channel object
> 
> Then when it is used it would be very similar to log4j. The only
> difference being that we provide details of what is requesting the
> logging.
> 
> if (_statusLogger.isInfoEnabled(connectonLogActor))
> {
>     _statusLogger.info(connectonLogActor, LogMessages.QUEUE_DECLARE(queue));
> }

A few random questions...

   - how would this work if you're outside the Channel or Connection 
object and don't have access to _statusLogger?
   - how exactly does isInfoEnabled(...) make an intelligent choice on 
what to log, e.g. wouldn't it need access to the queue in order to know 
if logging is enabled for that queue?
   - where does connectionLogActor come from?

--Rafael


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


Mime
View raw message