RFR: 7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration
Mandy Chung
mandy.chung at oracle.com
Tue Oct 30 00:18:25 UTC 2012
What I mean is when multiple threads are using j.u.logging and one calls
Logger.getGlobal() but the LogManager class initialization is calling
Logger.getGlobal(), what will happen? similar to what the
LoggingDeadlock.java test does [1]. This is the code in LogManager I'm
referring to.
// Adding the global Logger. Doing so in the Logger.<clinit>
// would deadlock with the LogManager.<clinit>.
Logger.getGlobal().setLogManager(manager);
manager.addLogger(Logger.getGlobal());
Also, the logging initialization is fragile. I would suggest to verify
if logging using the global logger by multiple threads print all log
messages correctly.
There are several test/java/util/logging/LoggingDeadlock* tests that you
should check out if they adequately verify your fix.
Mandy
[1]
http://hg.openjdk.java.net/jdk8/tl/jdk/file/00cd9dc3c2b5/test/java/util/logging/LoggingDeadlock.java
On 10/29/2012 3:30 PM, Jim Gish wrote:
> Hi Mandy,
>
> I don't understand your second sentence. Could you please clarify?
>
>
> Thanks,
> Jim
>
> On 10/29/2012 06:05 PM, Mandy Chung wrote:
>> Jim,
>>
>> The logging deadlock issue is subtle and complex. Do we have a test
>> case that verifies your fix that is deadlock-free?
>>
>> I can't tell for sure but looks like it smells the potential deadlock
>> if Logger.getGlobal() triggers the LogManager class initialization
>> but LogManager.<clinit> calls Logger.getLogger().setLogManager().
>>
>> Maybe you already see this - 4994705 may give you some idea of the
>> deadlock problem.
>>
>> Hope this helps.
>> Mandy
>>
>> On 10/24/2012 4:13 PM, Jim Gish wrote:
>>> Please review
>>> http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/
>>>
>>> In JDK7, Logger.global was deprecated because of potential deadlock
>>> problems. The method getGlobal() was introduced as a convenience
>>> method to get the global logger in lieu of this or calling
>>> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME). Unfortunately, this was
>>> broken out of the gate. getGlobal() simply used the deprecated
>>> static variable global, but this had the result of returning the
>>> global logger without initializing the logging system. As a result,
>>> simply calling Logger.getGlobal().INFO("msg") does nothing. So much
>>> for the convenience of a simple global logger for devs to use ootb
>>> without any setup required.
>>>
>>> This simple fix simply returns
>>> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) when getGlobal() is
>>> called and hence results in proper setup of the logging sytem /and
>>> /a working global logger with no "assembly" required :-)
>>>
>>> Thanks,
>>> Jim
>>>
>
More information about the core-libs-dev
mailing list