Martin Ritchie wrote:
2009/7/8 Rafael Schloming <[email protected]>:
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.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
