You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by davidmc <ar...@gmail.com> on 2007/04/13 12:04:23 UTC
Logging improvement proposal
Hello all,
We are interested in enhancing ActiveMQ's current logging functionality, to
help with debugging and profiling. This would be a contribution to ActiveMQ
source code.
Basically we would like to add the following features at the Transport
level:
-Allow different, customizable logging formats. For example, the current
format is human readable but not easily processed by a machine.
-Allow dynamic ON/OFF switching of logging (probably with JMX).
All this of course, without changing the current behavior so that people who
don't need this don't need to worry about anything.
Currently, Transport level logging works with the 'trace' flag. If the flag
is set to true (for example, <transportConnector
uri="tcpLog://localhost:61616"/> in activemq.xml), a “TransportLogger”
object gets added into the Transport stack by the corresponding
TransportFactory ).
We propose to enhance the functionality like this:
A. There would be 3 parameters instead of just “trace”:
*'loggingEnabled' flag, if set to true, would add a TransportLogger to the
Transport stack. If set to false, the stack bypasses the TransportLogger, so
no logging can take place, regardless of the other flags. Current 'trace'
flag would stay as an alias for this, so that people who do not care about
this, do not have to change their configuration files or strings. Defaults
to false.
*'initialLogging' flag, if set to true, means that the broker / client
starts outputting to the log file(s) as soon as the TransportLogger is
initialized. If set to false, initially the broker / client doesn't output
anything to the log.
This flag would set the initial value of a boolean who would be changeable
later by JMX.
Defaults to true (if people enable “trace”, alias “enableLogging”, most
probably they want logging from the beginning. Also to keep current
behavior).
*'logFormat' parameter: this parameter would take values such as “default”
(current TransportLogger), “detailed”, etc. Every value would be mapped to a
different class who would do the actual writing. Maybe TransportLogger could
become an interface that these classes have to implement, with a
TransportLoggerSupport abstract class doing a partial implementation and
that could be extended.
Or maybe TransportLogger could stay as a concrete class and its methods
would call methods from new classes implementing a “TransportLogWriter”
interface. Defaults to “default” which would use the current TransportLogger
format.
B. As for the dynamic switching with JMX part, there should be some 'global'
boolean value (probably on a per-broker or per-connector basis) used by all
the Loggers to decide if they write to the log or not. Any suggestions of
where to put this boolean value, or where to put a new Mbean, or how to
relay the information to the TransportLogger objects, are appreciated :)
We initially thought of dynamically removing / adding the Loggers from the
Transport stack, for efficiency when the logging would be disabled. But this
is impossible because the attribute TransportFilter.next is “final
protected”, so it cannot be changed. I guess there is a good reason for
this, which is it? :)
We would like to hear your feedback, be it suggestions or criticism,
especially from ActiveMQ developers :) Thanks in advance.
David
--
View this message in context: http://www.nabble.com/Logging-improvement-proposal-tf3570794s2354.html#a9976200
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Logging improvement proposal
Posted by Guillaume Nodet <gn...@gmail.com>.
What we now have in ServiceMix (thanks to Thomas) is something
that could be done in ActiveMQ as well. This is a small service
than you can configure and which expose a simple bean from JMX.
This mbean can be used to configure a timer and activate / deactivate
it so that the log4j configuration is reloaded. You can also manually
call an update if you have changed the configuration.
Note that this does not actually allow to change the log level using JMX,
as you still have to change the log4j configuration file.
On 4/13/07, Bruce Snyder <br...@gmail.com> wrote:
>
> On 4/13/07, davidmc <ar...@gmail.com> wrote:
> >
> > Hello all,
> >
> > We are interested in enhancing ActiveMQ's current logging functionality,
> to
> > help with debugging and profiling. This would be a contribution to
> ActiveMQ
> > source code.
> >
> > Basically we would like to add the following features at the Transport
> > level:
> > -Allow different, customizable logging formats. For example, the current
> > format is human readable but not easily processed by a machine.
>
> This already offered via Log4J configuration. See conf/log4j.properties.
>
> > -Allow dynamic ON/OFF switching of logging (probably with JMX).
>
> This isn't done currently but could easily be refactored to utilize
> the Log4J DOMConfigurator.configureAndWatch() method.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo - http://geronimo.apache.org/
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Castor - http://castor.org/
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: Logging improvement proposal
Posted by Bruce Snyder <br...@gmail.com>.
On 4/13/07, davidmc <ar...@gmail.com> wrote:
>
> Hello all,
>
> We are interested in enhancing ActiveMQ's current logging functionality, to
> help with debugging and profiling. This would be a contribution to ActiveMQ
> source code.
>
> Basically we would like to add the following features at the Transport
> level:
> -Allow different, customizable logging formats. For example, the current
> format is human readable but not easily processed by a machine.
This already offered via Log4J configuration. See conf/log4j.properties.
> -Allow dynamic ON/OFF switching of logging (probably with JMX).
This isn't done currently but could easily be refactored to utilize
the Log4J DOMConfigurator.configureAndWatch() method.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/
RE: Logging improvement proposal
Posted by "Fateev, Maxim" <fa...@amazon.com>.
IMHO logging should be enabled/disabled through standard Log4j
mechanisms. I found that it is much easier to switch log level of a
broker then change it on multiple clients. Transport level should log
all messages at trace level, preferably using subject name as a postfix
to the logger name allowing per subject specific configuration. It still
should be possible to override log level for a specific connection using
exising URI based mechanism.
-----Original Message-----
From: davidmc [mailto:aranmanoth@gmail.com]
Sent: Friday, April 13, 2007 3:04 AM
To: dev@activemq.apache.org
Subject: Logging improvement proposal
Hello all,
We are interested in enhancing ActiveMQ's current logging functionality,
to help with debugging and profiling. This would be a contribution to
ActiveMQ source code.
Basically we would like to add the following features at the Transport
level:
-Allow different, customizable logging formats. For example, the current
format is human readable but not easily processed by a machine.
-Allow dynamic ON/OFF switching of logging (probably with JMX).
All this of course, without changing the current behavior so that people
who don't need this don't need to worry about anything.
Currently, Transport level logging works with the 'trace' flag. If the
flag
is set to true (for example, <transportConnector
uri="tcpLog://localhost:61616"/> in activemq.xml), a "TransportLogger"
object gets added into the Transport stack by the corresponding
TransportFactory ).
We propose to enhance the functionality like this:
A. There would be 3 parameters instead of just "trace":
*'loggingEnabled' flag, if set to true, would add a TransportLogger to
the Transport stack. If set to false, the stack bypasses the
TransportLogger, so no logging can take place, regardless of the other
flags. Current 'trace'
flag would stay as an alias for this, so that people who do not care
about this, do not have to change their configuration files or strings.
Defaults to false.
*'initialLogging' flag, if set to true, means that the broker / client
starts outputting to the log file(s) as soon as the TransportLogger is
initialized. If set to false, initially the broker / client doesn't
output anything to the log.
This flag would set the initial value of a boolean who would be
changeable later by JMX.
Defaults to true (if people enable "trace", alias "enableLogging", most
probably they want logging from the beginning. Also to keep current
behavior).
*'logFormat' parameter: this parameter would take values such as
"default"
(current TransportLogger), "detailed", etc. Every value would be mapped
to a different class who would do the actual writing. Maybe
TransportLogger could become an interface that these classes have to
implement, with a TransportLoggerSupport abstract class doing a partial
implementation and that could be extended.
Or maybe TransportLogger could stay as a concrete class and its methods
would call methods from new classes implementing a "TransportLogWriter"
interface. Defaults to "default" which would use the current
TransportLogger format.
B. As for the dynamic switching with JMX part, there should be some
'global'
boolean value (probably on a per-broker or per-connector basis) used by
all the Loggers to decide if they write to the log or not. Any
suggestions of where to put this boolean value, or where to put a new
Mbean, or how to relay the information to the TransportLogger objects,
are appreciated :)
We initially thought of dynamically removing / adding the Loggers from
the Transport stack, for efficiency when the logging would be disabled.
But this is impossible because the attribute TransportFilter.next is
"final protected", so it cannot be changed. I guess there is a good
reason for this, which is it? :)
We would like to hear your feedback, be it suggestions or criticism,
especially from ActiveMQ developers :) Thanks in advance.
David
--
View this message in context:
http://www.nabble.com/Logging-improvement-proposal-tf3570794s2354.html#a
9976200
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.