[
https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244082#comment-16244082
]
Keith Wall edited comment on QPID-8017 at 11/8/17 4:43 PM:
-----------------------------------------------------------
The reason the JUL logging events that have severity lower than INFO emitted
from JE are not included in the broker's log is that the JUL
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only
{{java.util.logging.Logger#levelValue}}. It does not consult the JUL handlers,
so Broker's J logger providers never get to get a call. The INFO default comes
from the JVM {{$\{JAVA_HOME}/jre/lib/logging.properties}}
I suspect the change I suggested above would have unacceptable performance
implications. The JE implementation takes care to guard detailed logging
statements but the effect of the change would be to make the
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the
construction of the log message is paid even if logging is turned off.
For a general purpose solution the only solution I see is reflecting the logger
configuration from the Broker/VirtualHostLogger world into the JUL world every
time there is configuration change (or on first start-up). The algorithm own
each config change would look like this:
{code}
foreach registered JUL loggers available from
java.util.logging.LogManager#getLoggerNames
{
Get the SLF4J logger for the registered JUL logger name
// Test the logging level configured on the SLF4J logger and reflect on to
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
}
else if (SLF4JLogger.isInfoEnabled())
{
....
}
}
{code}
This would be general purpose code and would not need to know about JE. If
Qpid integrated any other component using JUL logging, this approach would work
unchanged.
Edit:
This idea above doesn't work for JUL loggers that don't yet exist (at the point
in time configuration is made). I suppose it could instead create a JUL
logger for the class or package specified by the inclusion rule with the
desired logging level. It would need to retain a reference to the JUL logger to
stop is falling out of scope and being garbage collected to guard the case
where the code that will use the logger has not yet been loaded.
was (Author: k-wall):
The reason the JUL logging events that have severity lower than INFO emitted
from JE are not included in the broker's log is that the JUL
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only
{{java.util.logging.Logger#levelValue}}. It does not consult the JUL handlers,
so Broker's J logger providers never get to get a call. The INFO default comes
from the JVM {{$\{JAVA_HOME}/jre/lib/logging.properties}}
I suspect the change I suggested above would have unacceptable performance
implications. The JE implementation takes care to guard detailed logging
statements but the effect of the change would be to make the
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the
construction of the log message is paid even if logging is turned off.
For a general purpose solution the only solution I see is reflecting the logger
configuration from the Broker/VirtualHostLogger world into the JUL world every
time there is configuration change (or on first start-up). The algorithm own
each config change would look like this:
{code}
foreach registered JUL loggers available from
java.util.logging.LogManager#getLoggerNames
{
Get the SLF4J logger for the registered JUL logger name
// Test the logging level configured on the SLF4J logger and reflect on to
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
}
else if (SLF4JLogger.isInfoEnabled())
{
....
}
}
{code}
This would be general purpose code and would not need to know about JE. If
Qpid integrated any other component using JUL logging, this approach would work
unchanged.
> [Broker-J] [BDB] JE log events written at JUL level FINE and below not
> included in the log produced by a BrokerLogger
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
> Reporter: Keith Wall
> Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour: verbose logging from JE. Actual behaviour: moderate
> logging only
> For instance, JE writes the following message at {{FINE}} which should be
> logged by the handler as {{TRACE}} but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) -
> [default] Clean file none: predicted min util is below minUtilization,
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}
> There is a workaround for the functional problem, albeit a restart is
> required and the ability to change the process's system properties. Use the
> normal JUL system property {{java.util.logging.config.file}}. Set this to
> the location of a logging.properties file with the {{com.sleepycat.je}}
> logger set to the desired level. Once the JVM is restarted, the Broker's log
> files will include the logging.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
