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 12:47:10 GMT
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?
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.

Cheers
Martin

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


Mime
View raw message