Here's an updated diff :
   - added current CR# to the @bug tag
   - made logger1 and logger2 instance variables
   - renamed test instance variable lmxbeantest
   - removed excessive diagnostic print outs


--- a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
+++ b/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
@@ -23,7 +23,7 @@

 /*
  * @test
- * @bug 7024172
+ * @bug 7024172 7067691
  * @summary Test if proxy for PlatformLoggingMXBean is equivalent
  *          to proxy for LoggingMXBean
  *
@@ -43,6 +43,13 @@
     static String LOGGER_NAME_2 = "com.sun.management.Logger.Logger2";
     static String UNKNOWN_LOGGER_NAME = "com.sun.management.Unknown";

+    // These instance variables prevent premature logger garbage collection
+    // See getLogger() weak reference warnings.
+    Logger logger1;
+    Logger logger2;
+
+    static LoggingMXBeanTest lmxbeantest;
+
     public static void main(String[] argv) throws Exception {
         MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
         LoggingMXBean proxy =
@@ -51,7 +58,7 @@
                 LoggingMXBean.class);

         // test LoggingMXBean proxy
-        LoggingMXBeanTest p = new LoggingMXBeanTest(proxy);
+        lmxbeantest = new LoggingMXBeanTest(proxy);

         // check if the attributes implemented by PlatformLoggingMXBean
         // and LoggingMXBean return the same value
@@ -59,14 +66,16 @@
             ManagementFactory.getPlatformMXBean(mbs, 
PlatformLoggingMXBean.class);

         checkAttributes(proxy, mxbean);
+
+    lmxbeantest = null;
     }

     // same verification as in java/util/logging/LoggingMXBeanTest2
     public LoggingMXBeanTest(LoggingMXBean mbean) throws Exception {

-        Logger logger1 = Logger.getLogger( LOGGER_NAME_1 );
+        logger1 = Logger.getLogger( LOGGER_NAME_1 );
         logger1.setLevel(Level.FINE);
-        Logger logger2 = Logger.getLogger( LOGGER_NAME_2 );
+        logger2 = Logger.getLogger( LOGGER_NAME_2 );
         logger2.setLevel(null);

         /*
@@ -207,6 +216,7 @@
         // verify logger names
         List<String> loggers1 = mxbean1.getLoggerNames();
         List<String> loggers2 = mxbean2.getLoggerNames();
+
         if (loggers1.size() != loggers2.size())
throw new RuntimeException("LoggerNames: unmatched number of entries");
         List<String> loggers3 = new ArrayList<>(loggers1);
@@ -219,7 +229,10 @@
             if (!mxbean1.getLoggerLevel(logger)
                     .equals(mxbean2.getLoggerLevel(logger)))
                 throw new RuntimeException(
-                    "LoggerLevel: unmatched level for " + logger);
+                    "LoggerLevel: unmatched level for (" + logger
+            + ", " + mxbean1.getLoggerLevel(logger)
+            + ", " + mxbean2.getLoggerLevel(logger) + ")");
+
             if (!mxbean1.getParentLoggerName(logger)
                     .equals(mxbean2.getParentLoggerName(logger)))
                 throw new RuntimeException(


On 11/ 9/11 04:08 AM, Alan Bateman wrote:
On 08/11/2011 15:35, Gary Adams wrote:
 Here's another intermittent bug that is attributed
to the garbage collection of the loggers before the
final static check can be applied in the test.

CR#7067691 : java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently
I agree with Mandy that it would be great to do a quick audit of the other logging (and PlatformLoggingMXBean) tests to see if we have similar issues. I should explain that one reason why these test failures may not have been observed in the past is because most people ran jtreg in its default mode (called othervm mode, where each tests runs in its own VM). Nowadays we run the tests via the make file or use jtreg -agentvm so that tests are running sequentially in an agent VM. Not all areas can run in agent VM mode yet but for the areas that do then we get a good speed up as the startup cost is eliminated and also it's possible to have a pool of agent VMs to make use of all cores when doing test runs (-agentvm -concurrency:auto for example). However agent VM makes things less predictable and for these tests it means that the GC will be unpredictable which is why this test was failing only very intermittently.

Anyway, the changes look fine to me. I agree with Mandy that many logger1 and logger2 could be instance variables. I would suggest "proxy" or something more readable rather than "testp" for the LoggingMXBean proxy. I also agree with Mandy's comment about adding the @bug.

-Alan.

Reply via email to