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 14:01:29 GMT
Martin Ritchie wrote:
> 2009/7/8 Rafael Schloming <rafaels@redhat.com>:
>> Martin Ritchie wrote:
>>>> 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?
>> I thought the point of this logging was to be from a system perspective as
>> opposed to a developer perspective. It seems like there would be lots of
>> cross-sectional events that make sense to log against a given entity from
>> elsewhere in the system, e.g. I would expect a number of important
>> connection events to be logged from deep inside the I/O code.
> There was some discussion on the Network IO page about logging from
> deep inside the I/O code. However, there wasn't a good use case for
> something that would need to be logged that an group running a Java
> broker would need to know about IMHO. In terms of status updates what
> more than connection open, connnection close did you have in mind?

I was thinking primarily of connection open and close, however that's 
enough to be a problem. Where would you log open? Logging it from a high 
level connection object doesn't seem to work since you need to do 
version negotiation before you can construct a proper connection object, 
and you really don't want to wait until then in order to log the fact 
that a client has connected. Really when the connection open should be 
logged, you don't actually have a connection object yet, just a socket.

> Once we have the statistics in there the fact that a connection has
> gone idle can be reported in addtion to any rate statistics.
>> It also seems like something like flow-to-disk might involve a channel, a
>> queue, and the message store and so obviously couldn't log from inside all
>> three even though it might have relevant statements to make involving all of
>> them. How would something like that fit in?
> I agree that there may be plugins that have more requriements an
> earlier version of the design had a plugin logging interface such that
> a plugin could log about another entity as well as the actor. So the
> flow-to-disk could log about the queue as a result of the action of
> the connection or the vhost etc.
> That was dropped for now. Mainly as a result of there not being a
> flow-to-disk plugin or other plugin that would need that sort of
> access.
> If you have an alternative approach I'd be interested to hear what
> your thoughts were.

If the goal is logging from a system perspective, I'd probably start 
with a catalog of all the different system level log statements, and 
then work backwards from there to figure out how best to produce them.


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

View raw message