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 11:31:50 GMT
2009/7/8 Rafael Schloming <rafaels@redhat.com>:
> 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?

There should be no need for access to Status logging messages outside
of the main broker entities:
    * VirtualHost
    * MessageStore
    * Connection
    * Channel
    * Queue
    * Exchange
    * Binding
Do you have a use case in mind?

>  - 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?

The logging engine would indeed need to have some sort of details of
what is enabled and what is not. This area will need more work as it
won't simply map to a log4j hierarchy as mentioned in the design. In
the first pass the logging will be a simple all on|off based on a
configuration value in the broker configuration, though it can be
switched via the management console.

The way I thought about it working is not presented clearly by the
above examples. In the case of the queue_declare having that logging
statement in both the Channel and Management code paths seems wrong.
It would be better to have a single log statement performed by the
queueStatus logger when the queue was created. Naturally that means
that the Queue constructor must therefore take a parameter in its
constructor that can be used to extract the Actor for logging
purposes. The queueStatus logger would then have all the details of
the queue to know if the queue has logging enabled but also has access
to the Actor to know if it or any of its connection related components
have logging enabled.

>  - where does connectionLogActor come from?

The connectionLogActor would be created as part of the connection
object and so retrievable via AMQProtocolSession. There will be a very
small number of actors in the system initially just the
connetionLogActor from the AMQProtocolSesion. Later actors for the
Recovery, Subscription, Management Console and VirtualHost
(housekeeping) can be added.


Martin Ritchie

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

View raw message