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

[Mandy Chung]

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.

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.

Mandy