Robert Greig wrote:
2009/1/2 Gordon Sim <g...@redhat.com>:
At present for example a warning is logged for every published message that
cannot be routed; every 'local' message dropped due to a 'no-local'
directive results in an info level log message etc. As these are per-message
events they could result in lots of log entries.
Yes, I can see this will be an issue.
Does your logging infrastructure have the concept of categories (like
log4j)? It may be useful to have a *small* set of categories (not like
log4j common usage which tends to map onto package namespaces) such as
"general", "message-delivery", "connection" etc. and these can have
levels controlled independently. The default for "general" would be
INFO (say) but for "message-delivery" it could be "error+".
I think having a small set of categories is a good idea and one that
would be nice to see in the Java world since the log level is hard to
tweak without detailed knowledge of the code structure (effectively).
Yes, I agree. Our log statements can be filtered by a substring match on
the file in which they occur. That is a bit tricky for those who don't
know the code and also does not take into account the frequency of the
event (per message, per connection or general etc).
One simple (though not very elegant) option would be to create separate
classes for logging message level events (and perhaps session- and
connection- level events also) with a name chosen to make it easy and
intuitive to turn on and off.
There is some overlap between diagnostic messages of this sort and
management events. So perhaps another approach is to treat them as
management events and have a separate 'dimension' of configuration for
determining how various management events are treated (E.g. log all info
events for exchange A, but only log warnings for exchange B etc).
Thats perhaps overly complex for now. Maybe a good first step would be
something in between these two, e.g. have the management object do the
logging for per-message events making the component to turn on/off in
filtering more consistent. (E.g. it would not be the particular exchange
subclass that logged a warning about inability to route a message but
the exchanges management object).
