You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Sorin S." <ss...@gmail.com> on 2010/08/27 13:28:05 UTC
Operational Logging for 0-10 code path
Hi,
I am working to extend the operational logging framework to apply to
0-10 code path as well.
In doing so I would like to:
- modify the LogSubject toString method to read toLogString so I can
implement the interface in the 0-10 objects
- log via a generic actor as the current actor model is generating a
log subject which is pre 0-10 specific
- implement the LogSubject interface in 0-10 objects (eg
ServerSession, Subscription_0_10, ServerConnection, etc) in order to
log CON,SUB,CHN type operational log messages, the rest of the
messages remain as they are.
- the logging to be done via a custom instance of the generic actor
using the messages generated from the object itself
- add the necessary to the test suite to address the new changes
Any suggestions,/objections/ideas on the above would be greatly appreciated
Thanks,
--
Sorin S
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Operational Logging for 0-10 code path
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Sorin,
Thanks for the info.
I've had a read through of the JIRAs, I think the interface/implementation
changes look good with an eye on 1-0 introduction too.
Thanks,
Marnie
On Fri, Aug 27, 2010 at 12:28 PM, Sorin S. <ss...@gmail.com> wrote:
> Hi,
> I am working to extend the operational logging framework to apply to
> 0-10 code path as well.
> In doing so I would like to:
> - modify the LogSubject toString method to read toLogString so I can
> implement the interface in the 0-10 objects
> - log via a generic actor as the current actor model is generating a
> log subject which is pre 0-10 specific
> - implement the LogSubject interface in 0-10 objects (eg
> ServerSession, Subscription_0_10, ServerConnection, etc) in order to
> log CON,SUB,CHN type operational log messages, the rest of the
> messages remain as they are.
> - the logging to be done via a custom instance of the generic actor
> using the messages generated from the object itself
> - add the necessary to the test suite to address the new changes
>
> Any suggestions,/objections/ideas on the above would be greatly
> appreciated
>
> Thanks,
> --
> Sorin S
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Operational Logging for 0-10 code path
Posted by "Sorin S." <ss...@gmail.com>.
Hi Andrew,
Thanks for your mail, I really appreciate your insight. Will try and
make it work on 0-10 in the first step with the GenericActor, then
will be more than happy to implement your suggestions. If anyone has
any objections to this plan, I would be more than happy
to learn about them.
Cheers,
Sorin
On Fri, Aug 27, 2010 at 10:03 PM, Andrew Kennedy
<an...@gmail.com> wrote:
> On 27 Aug 2010, at 12:28, Sorin S. wrote:
>
>> Hi,
>> I am working to extend the operational logging framework to apply to
>> 0-10 code path as well.
>> In doing so I would like to:
>> - modify the LogSubject toString method to read toLogString so I can
>> implement the interface in the 0-10 objects
>> - log via a generic actor as the current actor model is generating a
>> log subject which is pre 0-10 specific
>> - implement the LogSubject interface in 0-10 objects (eg
>> ServerSession, Subscription_0_10, ServerConnection, etc) in order to
>> log CON,SUB,CHN type operational log messages, the rest of the
>> messages remain as they are.
>> - the logging to be done via a custom instance of the generic actor
>> using the messages generated from the object itself
>> - add the necessary to the test suite to address the new changes
>>
>> Any suggestions,/objections/ideas on the above would be greatly
>> appreciated
>
> Sorin,
>
> Sounds good. Of course, the nice thing to do after all this is to remove all
> the other 'BlahActor' classes and make 0-8/0-9/0-91 logging use the
> 'GenericActor', now renamed to 'LogActor' simply, since you won't need a
> class hierarchy anymore. That way, you can go:
>
> private static final ThreadLocal<LogActor> actor = new
> ThreadLocal<LogActor>() {
> protected Integer initialValue() {
> return new LogActor();
> }
> };
>
> And get rid of the stack of actors. I think this would work, since the actor
> is changed on a per-thread basis, and anywhere you do a 'push' you just do a
> 'set'. Not sure how you handle the 'pop' though, would need to think about
> that?
>
> Another part of the broker that seems superfluous is the
> 'o.a.q.transport.util.Logger' class, which is simply syntactic sugar for a
> suite of 'log.info(String.format(msg, args...))' methods. I don't remember
> how prevalent it is, but I'd prefer the logging to use a consistent API.
> This means that we should enforce log4j vs. slf4j in different modules.
>
> The code uses four different logging mechanisms (that I know of). These are
> listed below, and some judicious application of
> 'find/grep/cut/sort/uniq/tr/sed' to all the Qpid '*.java' source files gives
> us the following results. For each logging mechanism, per module, I show
> counts of usage (based on imports of a representative class) first
> excluding, then including any test classes:
>
> ORG.APACHE.COMMONS.LOGGING.LOG
> ------------------------------
> 24 26 management
>
> ORG.APACHE.LOG4J.LOGGER
> -----------------------
> 88 95 broker
> 6 6 broker-plugins
> 11 15 client
> 0 1 common
> 12 12 integrationtests
> 11 11 junit-toolkit
> 1 1 management
> 10 11 perftests
> 5 42 systests
> 1 1 testkit
>
> ORG.APACHE.QPID.TRANSPORT.UTIL.LOGGER
> -------------------------------------
> 16 17 common
> 33 33 management
> 1 1 systests
>
> ORG.SLF4J.LOGGER
> ----------------
> 6 6 broker
> 6 6 build
> 133 139 client
> 41 49 common
> 2 2 junit-toolkit
> 10 10 management
> 0 84 systests
>
> I admit this methodology can lead to false positives, where classes are
> imported and not used, but the results are informative. As you can see, the
> 'systests' module uses log4j, slf4j and the Qpid logger, 'common' also uses
> these three, the 'client' module uses both log4j and slf4j too. Note that
> this is not just the tests using a different logging mechanism, this is
> actual client and broker code. I recall a decision being made regarding log
> mechanism usage for the broker and client, but can't remember the outcome?
> There doesn't seem to have been any progress, regardless, as these numbers
> show...
>
> Cheers,
> Andrew.
> --
> -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
> -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7941 197 134 ;
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Sorin S
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Operational Logging for 0-10 code path
Posted by Andrew Kennedy <an...@gmail.com>.
On 27 Aug 2010, at 12:28, Sorin S. wrote:
> Hi,
> I am working to extend the operational logging framework to apply to
> 0-10 code path as well.
> In doing so I would like to:
> - modify the LogSubject toString method to read toLogString so I can
> implement the interface in the 0-10 objects
> - log via a generic actor as the current actor model is generating a
> log subject which is pre 0-10 specific
> - implement the LogSubject interface in 0-10 objects (eg
> ServerSession, Subscription_0_10, ServerConnection, etc) in order to
> log CON,SUB,CHN type operational log messages, the rest of the
> messages remain as they are.
> - the logging to be done via a custom instance of the generic actor
> using the messages generated from the object itself
> - add the necessary to the test suite to address the new changes
>
> Any suggestions,/objections/ideas on the above would be greatly
> appreciated
Sorin,
Sounds good. Of course, the nice thing to do after all this is to
remove all the other 'BlahActor' classes and make 0-8/0-9/0-91
logging use the 'GenericActor', now renamed to 'LogActor' simply,
since you won't need a class hierarchy anymore. That way, you can go:
private static final ThreadLocal<LogActor> actor = new
ThreadLocal<LogActor>() {
protected Integer initialValue() {
return new LogActor();
}
};
And get rid of the stack of actors. I think this would work, since
the actor is changed on a per-thread basis, and anywhere you do a
'push' you just do a 'set'. Not sure how you handle the 'pop' though,
would need to think about that?
Another part of the broker that seems superfluous is the
'o.a.q.transport.util.Logger' class, which is simply syntactic sugar
for a suite of 'log.info(String.format(msg, args...))' methods. I
don't remember how prevalent it is, but I'd prefer the logging to use
a consistent API. This means that we should enforce log4j vs. slf4j
in different modules.
The code uses four different logging mechanisms (that I know of).
These are listed below, and some judicious application of 'find/grep/
cut/sort/uniq/tr/sed' to all the Qpid '*.java' source files gives us
the following results. For each logging mechanism, per module, I show
counts of usage (based on imports of a representative class) first
excluding, then including any test classes:
ORG.APACHE.COMMONS.LOGGING.LOG
------------------------------
24 26 management
ORG.APACHE.LOG4J.LOGGER
-----------------------
88 95 broker
6 6 broker-plugins
11 15 client
0 1 common
12 12 integrationtests
11 11 junit-toolkit
1 1 management
10 11 perftests
5 42 systests
1 1 testkit
ORG.APACHE.QPID.TRANSPORT.UTIL.LOGGER
-------------------------------------
16 17 common
33 33 management
1 1 systests
ORG.SLF4J.LOGGER
----------------
6 6 broker
6 6 build
133 139 client
41 49 common
2 2 junit-toolkit
10 10 management
0 84 systests
I admit this methodology can lead to false positives, where classes
are imported and not used, but the results are informative. As you
can see, the 'systests' module uses log4j, slf4j and the Qpid logger,
'common' also uses these three, the 'client' module uses both log4j
and slf4j too. Note that this is not just the tests using a different
logging mechanism, this is actual client and broker code. I recall a
decision being made regarding log mechanism usage for the broker and
client, but can't remember the outcome? There doesn't seem to have
been any progress, regardless, as these numbers show...
Cheers,
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7941 197 134 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org