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 15:10:42 GMT
2009/7/8 Rafael Schloming <rafaels@redhat.com>:
> 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.

In the Java broker Mina hides the Socket layer and it is the
AMQMinaProtocolSession that has all the Connection logic in it which
would lend itself ideally to the logging. The AMQMPS is created to
handle the new incomming socket so handles things such as version
negotiation. This is then used as the proper connection object,
perhaps this will change with the Network IO layer changes.

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

The list I currently have herer:
is rather generic but I'll convert them in to actual messages shortly.


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