From jaroslav.bachorik at oracle.com Fri Oct 3 15:02:13 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 03 Oct 2014 17:02:13 +0200 Subject: jmx-dev RFR: 8002307 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal representation by storing an externally mutable object Message-ID: <542EBA75.1000401@oracle.com> This is a second take on fixing JDK-8002307. The previous discussions are accessible as * http://mail.openjdk.java.net/pipermail/jmx-dev/2013-May/000225.html * http://mail.openjdk.java.net/pipermail/jmx-dev/2013-July/000280.html * http://mail.openjdk.java.net/pipermail/jmx-dev/2013-September/000346.html The fix assures the immutability by cloning the provided arrays in the constructor and then cloning them again in the getters. The constructors are fixed in the javax/management/MBeanInfo.java and the arrays used in getters are cloned using an already existing functionality in the same class. javax/management/modelmbean/ModelMBeanInfoSupport.java is modified to take advantage of extending javax/management/MBeanInfo.java and not to store duplicate information (attributes/operations/constructors/notifications arrays). The deserialization routine is adjusted to reflect this and also to enforce data consistency and backward compatibility. Regtests and JCK tests were run successfully. http://cr.openjdk.java.net/~jbachorik/8002307/webrev.05 Thanks, -JB- From Alan.Bateman at oracle.com Mon Oct 13 14:19:33 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Oct 2014 15:19:33 +0100 Subject: jmx-dev 8060166: javax/management/MBeanInfo/NotificationInfoTest.java fails with modular image Message-ID: <543BDF75.4020808@oracle.com> This test gets a URL to MBeanServer.class in a way that is dependent on the JDK internal layout (assumes rt.jar). I'd like to change this test to just use ClassLoader.getSystemResource so that it works when we move to a modular image. The proposed attached are below. -Alan --- a/test/javax/management/MBeanInfo/NotificationInfoTest.java Fri Sep 19 12:07:21 2014 +0100 +++ b/test/javax/management/MBeanInfo/NotificationInfoTest.java Fri Sep 19 12:42:36 2014 +0100 @@ -36,7 +36,6 @@ import java.lang.management.*; import java.lang.reflect.*; import java.net.*; -import java.security.CodeSource; import java.util.*; import java.util.jar.*; import javax.management.*; @@ -83,27 +82,10 @@ System.out.println("Checking platform MBeans..."); checkPlatformMBeans(); - CodeSource cs = - javax.management.MBeanServer.class.getProtectionDomain() - .getCodeSource(); - URL codeBase; - if (cs == null) { - String javaHome = System.getProperty("java.home"); - String[] candidates = {"/lib/rt.jar", "/classes/"}; - codeBase = null; - for (String candidate : candidates) { - File file = new File(javaHome + candidate); - if (file.exists()) { - codeBase = file.toURI().toURL(); - break; - } - } - if (codeBase == null) { - throw new Exception( - "Could not determine codeBase for java.home=" + javaHome); - } - } else - codeBase = cs.getLocation(); + URL codeBase = ClassLoader.getSystemResource("javax/management/MBeanServer.class"); + if (codeBase == null) { + throw new Exception("Could not determine codeBase for " + MBeanServer.class); + } System.out.println(); System.out.println("Looking for standard MBeans..."); From daniel.fuchs at oracle.com Mon Oct 13 14:35:40 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Oct 2014 16:35:40 +0200 Subject: jmx-dev 8060166: javax/management/MBeanInfo/NotificationInfoTest.java fails with modular image In-Reply-To: <543BDF75.4020808@oracle.com> References: <543BDF75.4020808@oracle.com> Message-ID: <543BE33C.8090409@oracle.com> On 13/10/14 16:19, Alan Bateman wrote: > URL codeBase = > ClassLoader.getSystemResource("javax/management/MBeanServer.class"); Interesting simplification. This looks good to me :-) I was intrigued by the difference so I tried the following: System.out.println(ClassLoader.getSystemResource( "javax/management/MBeanServer.class")); System.out.println(javax.management.MBeanServer.class .getProtectionDomain().getCodeSource().getLocation()); the second line throws a NPE - which was most probably the reason for trying to locate rt.jar from java.home in the first place... best regards, -- daniel From Alan.Bateman at oracle.com Mon Oct 13 16:52:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Oct 2014 17:52:27 +0100 Subject: jmx-dev 8060166: javax/management/MBeanInfo/NotificationInfoTest.java fails with modular image In-Reply-To: <543BE33C.8090409@oracle.com> References: <543BDF75.4020808@oracle.com> <543BE33C.8090409@oracle.com> Message-ID: <543C034B.5000406@oracle.com> On 13/10/2014 15:35, Daniel Fuchs wrote: > On 13/10/14 16:19, Alan Bateman wrote: >> URL codeBase = >> ClassLoader.getSystemResource("javax/management/MBeanServer.class"); > > Interesting simplification. This looks good to me :-) > > I was intrigued by the difference so I tried the following: > > System.out.println(ClassLoader.getSystemResource( > "javax/management/MBeanServer.class")); > > System.out.println(javax.management.MBeanServer.class > .getProtectionDomain().getCodeSource().getLocation()); > > > the second line throws a NPE - which was most probably > the reason for trying to locate rt.jar from java.home in > the first place... You may be right and the original author didn't think of getSystemResource. Thanks for the review. -Alan From shanliang.jiang at oracle.com Wed Oct 15 13:35:58 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 15 Oct 2014 15:35:58 +0200 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK Message-ID: <543E783E.9060105@oracle.com> Hi, SNMP is not part of OpenJDK and SNMP packages are not compiled in OpenJDK, so the SNMP sources should be deleted from the OpenJDK Bug: https://bugs.openjdk.java.net/browse/JDK-8060692 Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8060692/00/ Thanks, Shanliang From Alan.Bateman at oracle.com Wed Oct 15 13:46:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Oct 2014 14:46:39 +0100 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543E783E.9060105@oracle.com> References: <543E783E.9060105@oracle.com> Message-ID: <543E7ABF.4070605@oracle.com> On 15/10/2014 14:35, shanliang wrote: > Hi, > > SNMP is not part of OpenJDK and SNMP packages are not compiled in > OpenJDK, so the SNMP sources should be deleted from the OpenJDK > > Bug: https://bugs.openjdk.java.net/browse/JDK-8060692 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8060692/00/ The code removal looks good but don't you also need to update make make/CompileJavaModules.gmk in the top-level remove to remove the snmp directories from java.management_EXCLUDES ? -Alan. From erik.joelsson at oracle.com Wed Oct 15 14:16:07 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 15 Oct 2014 16:16:07 +0200 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543E7ABF.4070605@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> Message-ID: <543E81A7.2010105@oracle.com> Hello, Removing the excludes would be appreciated. Here is a patch: diff -r c173ba994245 make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk +++ b/make/CompileJavaModules.gmk @@ -247,14 +247,6 @@ # Exclude building of IIOP transport for RMI Connector java.management_EXCLUDES := com/sun/jmx/remote/protocol/iiop -# Why is this in the open source tree? -ifdef OPENJDK - java.management_EXCLUDES := \ - com/sun/jmx/snmp \ - sun/management/snmp \ - # -endif - ifeq ($(RMICONNECTOR_IIOP), false) java.management_EXCLUDES += com/sun/jmx/remote/protocol/iiop endif /Erik On 2014-10-15 15:46, Alan Bateman wrote: > On 15/10/2014 14:35, shanliang wrote: >> Hi, >> >> SNMP is not part of OpenJDK and SNMP packages are not compiled in >> OpenJDK, so the SNMP sources should be deleted from the OpenJDK >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8060692 >> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8060692/00/ > The code removal looks good but don't you also need to update make > make/CompileJavaModules.gmk in the top-level remove to remove the snmp > directories from java.management_EXCLUDES ? > > -Alan. From shanliang.jiang at oracle.com Wed Oct 15 15:19:46 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 15 Oct 2014 17:19:46 +0200 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543E81A7.2010105@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> <543E81A7.2010105@oracle.com> Message-ID: <543E9092.9070801@oracle.com> Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ I add: ./01/jdk9-make/ for updating ./make/CompileJavaModules.gmk ./01/jdk9-jdk-src/ is same to ./00 Thanks, Shanliang Erik Joelsson wrote: > Hello, > > Removing the excludes would be appreciated. Here is a patch: > > diff -r c173ba994245 make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk > +++ b/make/CompileJavaModules.gmk > @@ -247,14 +247,6 @@ > # Exclude building of IIOP transport for RMI Connector > java.management_EXCLUDES := com/sun/jmx/remote/protocol/iiop > > -# Why is this in the open source tree? > -ifdef OPENJDK > - java.management_EXCLUDES := \ > - com/sun/jmx/snmp \ > - sun/management/snmp \ > - # > -endif > - > ifeq ($(RMICONNECTOR_IIOP), false) > java.management_EXCLUDES += com/sun/jmx/remote/protocol/iiop > endif > > /Erik > > On 2014-10-15 15:46, Alan Bateman wrote: >> On 15/10/2014 14:35, shanliang wrote: >>> Hi, >>> >>> SNMP is not part of OpenJDK and SNMP packages are not compiled in >>> OpenJDK, so the SNMP sources should be deleted from the OpenJDK >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060692 >>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8060692/00/ >> The code removal looks good but don't you also need to update make >> make/CompileJavaModules.gmk in the top-level remove to remove the >> snmp directories from java.management_EXCLUDES ? >> >> -Alan. > From Alan.Bateman at oracle.com Wed Oct 15 15:29:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Oct 2014 16:29:31 +0100 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543E9092.9070801@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> <543E81A7.2010105@oracle.com> <543E9092.9070801@oracle.com> Message-ID: <543E92DB.7000505@oracle.com> On 15/10/2014 16:19, shanliang wrote: > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ > > I add: > ./01/jdk9-make/ > for updating ./make/CompileJavaModules.gmk > > ./01/jdk9-jdk-src/ is same to ./00 > > Thanks, > Shanliang This looks good. -Alan From daniel.fuchs at oracle.com Wed Oct 15 15:31:42 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Oct 2014 17:31:42 +0200 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543E9092.9070801@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> <543E81A7.2010105@oracle.com> <543E9092.9070801@oracle.com> Message-ID: <543E935E.9070301@oracle.com> On 15/10/14 17:19, shanliang wrote: > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ The new version looks fine :-) -- daniel > > I add: > ./01/jdk9-make/ > for updating ./make/CompileJavaModules.gmk > > ./01/jdk9-jdk-src/ is same to ./00 > > Thanks, > Shanliang > > > Erik Joelsson wrote: >> Hello, >> >> Removing the excludes would be appreciated. Here is a patch: >> >> diff -r c173ba994245 make/CompileJavaModules.gmk >> --- a/make/CompileJavaModules.gmk >> +++ b/make/CompileJavaModules.gmk >> @@ -247,14 +247,6 @@ >> # Exclude building of IIOP transport for RMI Connector >> java.management_EXCLUDES := com/sun/jmx/remote/protocol/iiop >> >> -# Why is this in the open source tree? >> -ifdef OPENJDK >> - java.management_EXCLUDES := \ >> - com/sun/jmx/snmp \ >> - sun/management/snmp \ >> - # >> -endif >> - >> ifeq ($(RMICONNECTOR_IIOP), false) >> java.management_EXCLUDES += com/sun/jmx/remote/protocol/iiop >> endif >> >> /Erik >> >> On 2014-10-15 15:46, Alan Bateman wrote: >>> On 15/10/2014 14:35, shanliang wrote: >>>> Hi, >>>> >>>> SNMP is not part of OpenJDK and SNMP packages are not compiled in >>>> OpenJDK, so the SNMP sources should be deleted from the OpenJDK >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060692 >>>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8060692/00/ >>> The code removal looks good but don't you also need to update make >>> make/CompileJavaModules.gmk in the top-level remove to remove the >>> snmp directories from java.management_EXCLUDES ? >>> >>> -Alan. >> > From mandy.chung at oracle.com Wed Oct 15 16:04:37 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Oct 2014 09:04:37 -0700 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543E9092.9070801@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> <543E81A7.2010105@oracle.com> <543E9092.9070801@oracle.com> Message-ID: <543E9B15.1090703@oracle.com> Hi Shanliang, On 10/15/2014 8:19 AM, shanliang wrote: > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ Thanks for taking this on. The fix looks okay. I think you should also take out: make/common/Modules.gmk line 45: JAVA_MODULES_FILTER := jdk.snmp Mandy From mandy.chung at oracle.com Wed Oct 15 16:06:43 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Oct 2014 09:06:43 -0700 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543E9B15.1090703@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> <543E81A7.2010105@oracle.com> <543E9092.9070801@oracle.com> <543E9B15.1090703@oracle.com> Message-ID: <543E9B93.6060403@oracle.com> On 10/15/2014 9:04 AM, Mandy Chung wrote: > Hi Shanliang, > > On 10/15/2014 8:19 AM, shanliang wrote: >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ > > Thanks for taking this on. The fix looks okay. I think you should > also take out: > > make/common/Modules.gmk > line 45: JAVA_MODULES_FILTER := jdk.snmp > Also jdk/test/com/sun/jmx/snmp should be removed too. Mandy From erik.joelsson at oracle.com Wed Oct 15 16:15:37 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 15 Oct 2014 18:15:37 +0200 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543E9B15.1090703@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> <543E81A7.2010105@oracle.com> <543E9092.9070801@oracle.com> <543E9B15.1090703@oracle.com> Message-ID: <543E9DA9.3000808@oracle.com> Nice catch Mandy, I forgot about that one. /Erik On 2014-10-15 18:04, Mandy Chung wrote: > Hi Shanliang, > > On 10/15/2014 8:19 AM, shanliang wrote: >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ > > Thanks for taking this on. The fix looks okay. I think you should > also take out: > > make/common/Modules.gmk > line 45: JAVA_MODULES_FILTER := jdk.snmp > > Mandy From shanliang.jiang at oracle.com Thu Oct 16 10:20:41 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 16 Oct 2014 12:20:41 +0200 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543E9B93.6060403@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> <543E81A7.2010105@oracle.com> <543E9092.9070801@oracle.com> <543E9B15.1090703@oracle.com> <543E9B93.6060403@oracle.com> Message-ID: <543F9BF9.1040309@oracle.com> Hi, Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/ ./02/jdk9-open/ has 2 more deleted files than in ./01/jdk9-jdk-src/ test/com/sun/jmx/snmp/ SnmpOidHashCode.java, TimeTicksWrapping.java ./02/jdk9-make/ has one more modified: make/common/Modules.gmk Thanks, Shanliang Mandy Chung wrote: > > On 10/15/2014 9:04 AM, Mandy Chung wrote: >> Hi Shanliang, >> >> On 10/15/2014 8:19 AM, shanliang wrote: >>> Here is the new version: >>> http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ >> >> Thanks for taking this on. The fix looks okay. I think you should >> also take out: >> >> make/common/Modules.gmk >> line 45: JAVA_MODULES_FILTER := jdk.snmp >> > > Also jdk/test/com/sun/jmx/snmp should be removed too. > > Mandy > From erik.joelsson at oracle.com Thu Oct 16 10:59:59 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 16 Oct 2014 12:59:59 +0200 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543F9BF9.1040309@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> <543E81A7.2010105@oracle.com> <543E9092.9070801@oracle.com> <543E9B15.1090703@oracle.com> <543E9B93.6060403@oracle.com> <543F9BF9.1040309@oracle.com> Message-ID: <543FA52F.4060906@oracle.com> Looks good now. /Erik On 2014-10-16 12:20, shanliang wrote: > Hi, > > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/ > > ./02/jdk9-open/ has 2 more deleted files than in ./01/jdk9-jdk-src/ > test/com/sun/jmx/snmp/ > SnmpOidHashCode.java, TimeTicksWrapping.java > > ./02/jdk9-make/ has one more modified: > make/common/Modules.gmk > > Thanks, > Shanliang > > Mandy Chung wrote: >> >> On 10/15/2014 9:04 AM, Mandy Chung wrote: >>> Hi Shanliang, >>> >>> On 10/15/2014 8:19 AM, shanliang wrote: >>>> Here is the new version: >>>> http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ >>> >>> Thanks for taking this on. The fix looks okay. I think you >>> should also take out: >>> >>> make/common/Modules.gmk >>> line 45: JAVA_MODULES_FILTER := jdk.snmp >>> >> >> Also jdk/test/com/sun/jmx/snmp should be removed too. >> >> Mandy >> > From mandy.chung at oracle.com Thu Oct 16 17:21:56 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Oct 2014 10:21:56 -0700 Subject: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK In-Reply-To: <543F9BF9.1040309@oracle.com> References: <543E783E.9060105@oracle.com> <543E7ABF.4070605@oracle.com> <543E81A7.2010105@oracle.com> <543E9092.9070801@oracle.com> <543E9B15.1090703@oracle.com> <543E9B93.6060403@oracle.com> <543F9BF9.1040309@oracle.com> Message-ID: <543FFEB4.1080100@oracle.com> On 10/16/14 3:20 AM, shanliang wrote: > Hi, > > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/ > Looks fine to me. thanks Mandy From markus.gronlund at oracle.com Wed Oct 22 09:43:49 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 22 Oct 2014 02:43:49 -0700 (PDT) Subject: jmx-dev RFR(L): 8056049: getProcessCpuLoad() stops working in one process when a different process exits Message-ID: Greetings, ? Kindly asking for reviews for the following changeset. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8056049 Webrev: http://cr.openjdk.java.net/~mgronlun/8056049/webrev01/ ? Description: ? The issue is ?Windows specific. And the problem relates to using the Performance Data Helper API (PDH), more specifically how to use the "Process" PDH object in PDH queries: ? // code comment extract ? /* * Working against the Process object and it's related counters is inherently problematic * when using the PDH API: * * For PDH, a process is not primarily identified by it's process id, * but with a sequential number, for example \Process(java#0), \Process(java#1), .... * The really bad part is that this list is reset as soon as one process exits: * If \Process(java#1) exits, \Process(java#3) now becomes \Process(java#2) etc. * * The PDH query api requires a process identifier to be submitted when registering * a query, but as soon as the list resets, the query is invalidated (since the name * changed). * * Solution: * The #number identifier for a Process query can only decrease after process creation. * * Therefore we create an array of counter queries for all process object instances * up to and including ourselves: * * Ex. we come in as third process instance (java#2), we then create and register * queries for the following Process object instances: * java#0, java#1, java#2 * * currentQueryIndexForProcess() keeps track of the current "correct" query * (in order to keep this index valid when the list resets from underneath, * ensure to call getCurrentQueryIndexForProcess() before every query involving * Process object instance data). */ ? I have already fixed this in the VM as of https://bugs.openjdk.java.net/browse/JDK-8019921 ? In the process of fixing this issue now in the JDK, I realized that the previous implementation of using PDH in the JDK was a bit convoluted - especially if you would like to reuse functionality / add new counters. ? Therefore this change also includes an overall rewrite of the how the JDK will interface with the PDH library, a rewrite of which (hopefully) improves both readability and extensibility. ? I can do a code walkthrough live if anyone is interested to know the exact details of this change. ? Testing completed : Testset SVC (includes jdk_instrument, jdk_management, jdk_jmx, jdk_jdi) ? Thanks in advance Markus ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabrice.bacchella at orange.fr Fri Oct 31 11:48:32 2014 From: fabrice.bacchella at orange.fr (Fabrice Bacchella) Date: Fri, 31 Oct 2014 12:48:32 +0100 Subject: jmx-dev Bug with jmxmp Message-ID: <43FCD797-2DEB-4C43-BFE1-4253EDAACB7A@orange.fr> I found a bug with the current implementation of jmxmp. The javax.management.remote.generic.GenericConnectorServer create an anonymous, non-daemon thread. So it can prevent a jvm to stop. I found the code at : http://grepcode.com/file/repo1.maven.org/maven2/org.jvnet.opendmk/jmxremote_optional/1.0_01-ea/javax/management/remote/generic/GenericConnectorServer.java#GenericConnectorServer Look at the private class Receiver, it as no custom constructor, and it usage is : 289 // start to receive clients 290 receiver = new Receiver(); 291 receiver.start(); 292} Is there any bug trafic or official repository for that ? https://opendmk.java.net is almost dead. From shanliang.jiang at oracle.com Fri Oct 31 13:06:01 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 31 Oct 2014 14:06:01 +0100 Subject: jmx-dev Bug with jmxmp In-Reply-To: <43FCD797-2DEB-4C43-BFE1-4253EDAACB7A@orange.fr> References: <43FCD797-2DEB-4C43-BFE1-4253EDAACB7A@orange.fr> Message-ID: <54538939.7070907@oracle.com> Fabrice, I remember that it was intended to create that thread as non-daemon, in order to keep your JVM alive in case that there is no any other thread. So you have to stop your JMXMP server before stopping the JVM Shanliang Fabrice Bacchella wrote: > I found a bug with the current implementation of jmxmp. The javax.management.remote.generic.GenericConnectorServer create an anonymous, non-daemon thread. > > So it can prevent a jvm to stop. > > I found the code at : > http://grepcode.com/file/repo1.maven.org/maven2/org.jvnet.opendmk/jmxremote_optional/1.0_01-ea/javax/management/remote/generic/GenericConnectorServer.java#GenericConnectorServer > > Look at the private class Receiver, it as no custom constructor, and it usage is : > 289 // start to receive clients > 290 receiver = new Receiver(); > 291 receiver.start(); > 292} > > Is there any bug trafic or official repository for that ? > > https://opendmk.java.net is almost dead. From daniel.fuchs at oracle.com Fri Oct 31 13:07:04 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 31 Oct 2014 14:07:04 +0100 Subject: jmx-dev Bug with jmxmp In-Reply-To: <43FCD797-2DEB-4C43-BFE1-4253EDAACB7A@orange.fr> References: <43FCD797-2DEB-4C43-BFE1-4253EDAACB7A@orange.fr> Message-ID: <54538978.2030103@oracle.com> Hi Fabrice, If I remember well this is by design. It the same with all JMX connector servers. If an application starts a connector server then it must close it explicitly before exiting. Sometime this is problematic - especially if you want to start a connector in a java agent (premain). A long time ago I wrote an article on that: https://blogs.oracle.com/jmxetc/entry/more_on_premain_and_jmx best regards, -- daniel On 31/10/14 12:48, Fabrice Bacchella wrote: > I found a bug with the current implementation of jmxmp. The javax.management.remote.generic.GenericConnectorServer create an anonymous, non-daemon thread. > > So it can prevent a jvm to stop. > > I found the code at : > http://grepcode.com/file/repo1.maven.org/maven2/org.jvnet.opendmk/jmxremote_optional/1.0_01-ea/javax/management/remote/generic/GenericConnectorServer.java#GenericConnectorServer > > Look at the private class Receiver, it as no custom constructor, and it usage is : > 289 // start to receive clients > 290 receiver = new Receiver(); > 291 receiver.start(); > 292} > > Is there any bug trafic or official repository for that ? > > https://opendmk.java.net is almost dead. > From fabrice.bacchella at orange.fr Fri Oct 31 13:15:26 2014 From: fabrice.bacchella at orange.fr (Fabrice Bacchella) Date: Fri, 31 Oct 2014 14:15:26 +0100 Subject: jmx-dev Bug with jmxmp In-Reply-To: <54538978.2030103@oracle.com> References: <43FCD797-2DEB-4C43-BFE1-4253EDAACB7A@orange.fr> <54538978.2030103@oracle.com> Message-ID: <886DC22C-580F-4802-9C1C-A8070434B40D@orange.fr> That's what exactly what I want to do, start one with a agent. I will try your solution. But beside being not daemon, it's also anonymous : Thread-n. That's not very helpfull. Le 31 oct. 2014 ? 14:07, Daniel Fuchs a ?crit : > Hi Fabrice, > > If I remember well this is by design. It the same with all > JMX connector servers. If an application starts a connector > server then it must close it explicitly before exiting. > > Sometime this is problematic - especially if you want to > start a connector in a java agent (premain). > A long time ago I wrote an article on that: > https://blogs.oracle.com/jmxetc/entry/more_on_premain_and_jmx > > best regards, > > -- daniel > > > On 31/10/14 12:48, Fabrice Bacchella wrote: >> I found a bug with the current implementation of jmxmp. The javax.management.remote.generic.GenericConnectorServer create an anonymous, non-daemon thread. >> >> So it can prevent a jvm to stop. >> >> I found the code at : >> http://grepcode.com/file/repo1.maven.org/maven2/org.jvnet.opendmk/jmxremote_optional/1.0_01-ea/javax/management/remote/generic/GenericConnectorServer.java#GenericConnectorServer >> >> Look at the private class Receiver, it as no custom constructor, and it usage is : >> 289 // start to receive clients >> 290 receiver = new Receiver(); >> 291 receiver.start(); >> 292} >> >> Is there any bug trafic or official repository for that ? >> >> https://opendmk.java.net is almost dead. >> > From fabrice.bacchella at orange.fr Fri Oct 31 13:40:24 2014 From: fabrice.bacchella at orange.fr (Fabrice Bacchella) Date: Fri, 31 Oct 2014 14:40:24 +0100 Subject: jmx-dev JMXServiceURL and jmxmp Message-ID: <6194A751-93AD-4242-BE31-E353CCE66A31@orange.fr> In the documentation, at http://docs.oracle.com/javase/7/docs/api/javax/management/remote/JMXServiceURL.html#JMXServiceURL(java.lang.String,%20java.lang.String,%20int,%20java.lang.String) I can read : protocol - the protocol part of the URL. If null, defaults to jmxmp. But jmxmp is not distributed with the jdk, so this constructor is bound to failed on stock jvm. From fabrice.bacchella at orange.fr Fri Oct 31 13:46:45 2014 From: fabrice.bacchella at orange.fr (Fabrice Bacchella) Date: Fri, 31 Oct 2014 14:46:45 +0100 Subject: jmx-dev Bug with jmxmp In-Reply-To: <886DC22C-580F-4802-9C1C-A8070434B40D@orange.fr> References: <43FCD797-2DEB-4C43-BFE1-4253EDAACB7A@orange.fr> <54538978.2030103@oracle.com> <886DC22C-580F-4802-9C1C-A8070434B40D@orange.fr> Message-ID: <8A4EBBD7-F74E-4F65-8FD1-56E5031068FC@orange.fr> Yes, it works well, but as the thread is called Thread-1, I needed to add : if (t.getName().startsWith("Thread-")) continue; Hop I will not be bitten by corner case. Le 31 oct. 2014 ? 14:15, Fabrice Bacchella a ?crit : > That's what exactly what I want to do, start one with a agent. I will try your solution. > > But beside being not daemon, it's also anonymous : Thread-n. That's not very helpfull. > > Le 31 oct. 2014 ? 14:07, Daniel Fuchs a ?crit : > >> Hi Fabrice, >> >> If I remember well this is by design. It the same with all >> JMX connector servers. If an application starts a connector >> server then it must close it explicitly before exiting. >> >> Sometime this is problematic - especially if you want to >> start a connector in a java agent (premain). >> A long time ago I wrote an article on that: >> https://blogs.oracle.com/jmxetc/entry/more_on_premain_and_jmx >> >> best regards, >> >> -- daniel >> >> >> On 31/10/14 12:48, Fabrice Bacchella wrote: >>> I found a bug with the current implementation of jmxmp. The javax.management.remote.generic.GenericConnectorServer create an anonymous, non-daemon thread. >>> >>> So it can prevent a jvm to stop. >>> >>> I found the code at : >>> http://grepcode.com/file/repo1.maven.org/maven2/org.jvnet.opendmk/jmxremote_optional/1.0_01-ea/javax/management/remote/generic/GenericConnectorServer.java#GenericConnectorServer >>> >>> Look at the private class Receiver, it as no custom constructor, and it usage is : >>> 289 // start to receive clients >>> 290 receiver = new Receiver(); >>> 291 receiver.start(); >>> 292} >>> >>> Is there any bug trafic or official repository for that ? >>> >>> https://opendmk.java.net is almost dead. >>> >> From jaroslav.bachorik at oracle.com Fri Oct 31 13:51:18 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 31 Oct 2014 14:51:18 +0100 Subject: jmx-dev JMXServiceURL and jmxmp In-Reply-To: <6194A751-93AD-4242-BE31-E353CCE66A31@orange.fr> References: <6194A751-93AD-4242-BE31-E353CCE66A31@orange.fr> Message-ID: <545393D6.8000209@oracle.com> Hi Fabrice, nice catch! This is indeed a bug. We should not default to an external protocol. Do you want me to file an issue for this or do you prefer to take it through the regular web bug? -JB- On 10/31/2014 02:40 PM, Fabrice Bacchella wrote: > In the documentation, at > http://docs.oracle.com/javase/7/docs/api/javax/management/remote/JMXServiceURL.html#JMXServiceURL(java.lang.String,%20java.lang.String,%20int,%20java.lang.String) > > I can read : > > protocol - the protocol part of the URL. If null, defaults to jmxmp. > > But jmxmp is not distributed with the jdk, so this constructor is bound to failed on stock jvm. > From eamonn at mcmanus.net Fri Oct 31 15:12:46 2014 From: eamonn at mcmanus.net (Eamonn McManus) Date: Fri, 31 Oct 2014 08:12:46 -0700 Subject: jmx-dev JMXServiceURL and jmxmp In-Reply-To: <545393D6.8000209@oracle.com> References: <6194A751-93AD-4242-BE31-E353CCE66A31@orange.fr> <545393D6.8000209@oracle.com> Message-ID: I don't see how this could be changed without running the risk of breaking existing code. Not that I think that risk is very great, but the impact of the current behaviour is not very great either. ?amonn On 31 October 2014 06:51, Jaroslav Bachorik wrote: > Hi Fabrice, > > nice catch! > > This is indeed a bug. We should not default to an external protocol. > > Do you want me to file an issue for this or do you prefer to take it through > the regular web bug? > > -JB- > > > On 10/31/2014 02:40 PM, Fabrice Bacchella wrote: >> >> In the documentation, at >> >> http://docs.oracle.com/javase/7/docs/api/javax/management/remote/JMXServiceURL.html#JMXServiceURL(java.lang.String,%20java.lang.String,%20int,%20java.lang.String) >> >> I can read : >> >> protocol - the protocol part of the URL. If null, defaults to jmxmp. >> >> But jmxmp is not distributed with the jdk, so this constructor is bound to >> failed on stock jvm. >> > From daniel.fuchs at oracle.com Fri Oct 31 15:37:26 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 31 Oct 2014 16:37:26 +0100 Subject: jmx-dev Bug with jmxmp In-Reply-To: <8A4EBBD7-F74E-4F65-8FD1-56E5031068FC@orange.fr> References: <43FCD797-2DEB-4C43-BFE1-4253EDAACB7A@orange.fr> <54538978.2030103@oracle.com> <886DC22C-580F-4802-9C1C-A8070434B40D@orange.fr> <8A4EBBD7-F74E-4F65-8FD1-56E5031068FC@orange.fr> Message-ID: <5453ACB6.2080007@oracle.com> On 31/10/14 14:46, Fabrice Bacchella wrote: > Yes, it works well, but as the thread is called Thread-1, I needed to add : > if (t.getName().startsWith("Thread-")) continue; > > Hop I will not be bitten by corner case. Hey Fabrice, I suppose you could do something like: if (t.getClass().getName().equals("javax.management.remote.generic.GenericConnectorServer$Receiver") { continue; } best regards, -- daniel From shanliang.jiang at oracle.com Fri Oct 31 16:44:12 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 31 Oct 2014 17:44:12 +0100 Subject: jmx-dev Code review: 8046192 Eliminate SNMP dependencies to the internal APIs from open jdk modules Message-ID: <5453BC5C.6000804@oracle.com> Hi, The fix is to remove unnecessary exports for jdk.snmp module. bug: https://bugs.openjdk.java.net/browse/JDK-8046192 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8046192/00/ Thanks, Shanliang From fabrice.bacchella at orange.fr Fri Oct 31 17:15:53 2014 From: fabrice.bacchella at orange.fr (Fabrice Bacchella) Date: Fri, 31 Oct 2014 18:15:53 +0100 Subject: jmx-dev JMXServiceURL and jmxmp In-Reply-To: <545393D6.8000209@oracle.com> References: <6194A751-93AD-4242-BE31-E353CCE66A31@orange.fr> <545393D6.8000209@oracle.com> Message-ID: <3829ADB5-E639-4DF0-A8D4-018DACE51334@orange.fr> You can file the bug. Le 31 oct. 2014 ? 14:51, Jaroslav Bachorik a ?crit : > Hi Fabrice, > > nice catch! > > This is indeed a bug. We should not default to an external protocol. > > Do you want me to file an issue for this or do you prefer to take it through the regular web bug? > > -JB- > > On 10/31/2014 02:40 PM, Fabrice Bacchella wrote: >> In the documentation, at >> http://docs.oracle.com/javase/7/docs/api/javax/management/remote/JMXServiceURL.html#JMXServiceURL(java.lang.String,%20java.lang.String,%20int,%20java.lang.String) >> >> I can read : >> >> protocol - the protocol part of the URL. If null, defaults to jmxmp. >> >> But jmxmp is not distributed with the jdk, so this constructor is bound to failed on stock jvm. >> >