RFR: JDK-8014045 - test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently (original) (raw)

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(); if (log.isLoggable()) {...} without keeping a strong reference to the logger in the class. In that case I guess it would be possible for that 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.

<http://cr.openjdk.java.net/~dfuchs/JDK-8014045/webrev.01/>

-- daniel

Mandy

More information about the core-libs-dev mailing list