Hi All,
The current out of the box performance for the java client is somewhat
impacted by the log4j issues.
The solution I provided (adding a log4j.xml) for the client jar is
totally wrong and no better than the previous solution.
Also the code base is littered with log4j.xml files, especially in the
management client.
So even if the client.jar does not contain a log4j.xml, one of those
files in the management (or even the broker.jar) would be picked if
they are in the classpath.
Robert Gordfrey had done some excellent work in introducing a logging
façade via sl4j.
Yet we ship the releases with log4j bindings with all sorts of
log4j.xml which really defeats the purpose of the logging façade.
Lets not force a logging mechanism on the client - which is indeed the
intention behind the logging façade.
Log4j defaults to "DEBUG" (if not configured properly) which results
in piss poor performance.
We also need to ship something - so that some basic logging works,
preferably at "WARN"
In order to fix these issues I suggest the following.
1. (a) Ship with slf4j-simple which defaults to "INFO" and prints to std err.
(b) Ship our own binding which defaults to "WARN" (or even
"ERROR") and prints to std out
(c) Ship nothing with clear docs on how to get a binding of their choice.
(*) Actually the README in the release should clearly indicate how
to configure the logging.
2. Get rid of all the log4j.xml (and log4j.properties) files in the
code base except in the test jars and the broker jar.
Please lets get rid of all log4j stuff from the common and client modules.
In the README file we should clearly indicate how to configure
logging and a special note that if log4j is used, an explicitly
configured log4j.xml should be used to avoid having some other
log4j.xml being accidentally loaded from the classpath.
3. From the next release we need to ship separate binaries for the
broker, client and management bits.
All though this is a topic of it's own, I'd like to take this
opportunity to mention that several customers/users have complained
above the excess number of jars and requests a list of absolute
minimum needed for the client.
Comments and suggestions are very welcome !
Regards,
Rajith
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
