RFR: JDK-8014045 - test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently

Daniel Fuchs daniel.fuchs at oracle.com
Thu Jun 20 10:50:22 UTC 2013

On 6/19/13 8:25 PM, Mandy Chung wrote:
> On 6/19/13 2:00 AM, Daniel Fuchs wrote:
>> On 6/13/13 10:05 PM, Mandy Chung wrote:
>>> Daniel,
>>> I wonder what the list of logger names (loggers1 and loggers2) returned
>>> by LoggingMXBean contains and that may include loggers in the running VM
>>> other than the ones created and kept a strong reference by the test. In
>>> other words,  would it be possible for the running VM that has loggers
>>> that are not created by the test and got GC'ed?
>> Hi Mandy,
>> I have added a System.out.println to print the list of logger names.
>> By running jtreg on my machine I could see that this list does contain
>> system logger names (mostly JMX loggers).
>> I believe those loggers are strongly referenced by JMX.
>> Other than those I could see "" and "global".
>> <http://cr.openjdk.java.net/~dfuchs/JDK-8014045/webrev.00/>
>> However - since this seems to be an intermittent failure - maybe the
>> logger that was causing the problem had already been gc'ed before
>> getLoggerNames() and therefore didn't appear in this list.
>> The test would fail when that 'transient' logger appears in the
>> list but is gc'ed before getLoggerLevel() is called.
>> Anyway - it's possible that some platform class
>> is calling:
>>    Logger log = Logger.getLogger(<some-name>);
>>    if (log.isLoggable(<some-leve>)) {...}
>> without keeping a strong reference to the logger in the class.
>> In that case I guess it would be possible for that <some-name>
>> to appear transiently in the logger's name list - and be gc'ed
>> just after...
> Is this test running in othervm mode?  or samevm mode?   I would think
> there is no logger created when checkAttributes is being called.

Hi Mandy,

AFAICT this test is running in samevm mode.

> The checkAttributes method is intended to verify LoggingMXBean and
> PlatformLoggingMXBean are functionally equivalent.  I would suggest to
> just check the two loggers created by this test and simply skip others
> at the beginning of the loop to make the test reliable. What you have is
> okay to print out warning but I think it's not necessary in the fix.  In
> addition, the check on mxbean1.getParentLoggerName !=
> mxbean2.getParentLoggerName may also run into this race when a logger
> being gc'ed.

Right. I have changed the test to temporarily retrieve the named loggers
and keep them in an HashMap - this way they should not be gc'ed.


-- daniel

> Mandy

More information about the core-libs-dev mailing list