From sgehwolf at redhat.com Mon Nov 2 10:38:02 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Nov 2015 11:38:02 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address Message-ID: <1446460682.10865.20.camel@redhat.com> Hi, Here is a patch addressing JDK-6425769. The issue is that the JMX agent binds to the wildcard address by default, preventing users to use system properties for JMX agents on multi-homed hosts. Given a host with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's impossible to start two JMX agents binding to fixed ports but to different network interfaces, 192.168.0.1:{9111,9112} and 192.168.0.2:{9111,9112} say. The JDK would bind to all local interfaces by default. In the above example to 192.168.0.1 *and* 192.168.0.2. The effect is that the second Java process would get a "Connection refused" error because another process has already been bound to the specified JMX/RMI port pairs. Bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/00/ Testing done: jdk_jmx and jdk_management tests all pass after this change (no regressions). There is also a new JTREG test which fails prior this change and passes after. Updates to the diagnostic command have been tested manually. I understand that, if approved, the JDK and hotspot changes should get pushed together? Hotspot changes are fairly trivial since it's only a doc-update for the new JDK property in the relevant diagnostic command. Could someone please review and sponsor this change? Please let me know if there are questions. Thanks, Severin From daniel.fuchs at oracle.com Mon Nov 2 15:19:51 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 2 Nov 2015 16:19:51 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <1446460682.10865.20.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> Message-ID: <56377F17.4050006@oracle.com> Hi Severin, Adding serviceability-dev at openjdk.java.net into the loop - that's a better alias than hotspot-dev for this kind of changes - maybe someone from serviceability-dev will offer to sponsor :-) I will let serviceability team members comment on the hotspot changes. ConnectorBootstrap.java I have one suggestion and one concern: Suggestion: I would suggest to reuse 'csf' (Client Socket Factory) and ssf (Server Socket Factory) variables rather than introduce the two new variables rmiServerSocketFactory and rmiClientSocketFactory. You might want to create a new boolean 'useSocketFactory' variable, if that makes the code more readable. Concern: If I understand correctly how RMI socket factories work, the client socket factory will be serialized and sent to the client side. This is problematic for interoperability, as the class may not present in the remote client - if the remote client is e.g. jdk 8. As far as I can see, your new DefaultClientSocketFactory doesn't do anything useful - so I would suggest to simply get rid of it, and only set the Server Socket Factory when SSL is not involved. Tests: Concerning the tests - we're trying to get rid of shell scripts rather than introducing new ones :-) Could the test be rewritten in pure java using the Process API? I believe there's even a test library that will let you do that easily jdk/test/lib/testlibrary/jdk/testlibrary/ (see ProcessTools.java) Other: Also - I believe the new option should be documented in: src/java.management/share/conf/management.properties best regards, -- daniel On 02/11/15 11:38, Severin Gehwolf wrote: > Hi, > > Here is a patch addressing JDK-6425769. The issue is that the JMX agent > binds to the wildcard address by default, preventing users to use > system properties for JMX agents on multi-homed hosts. Given a host > with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's > impossible to start two JMX agents binding to fixed ports but to > different network interfaces, 192.168.0.1:{9111,9112} and > 192.168.0.2:{9111,9112} say. > > The JDK would bind to all local interfaces by default. In the above > example to 192.168.0.1 *and* 192.168.0.2. The effect is that the second > Java process would get a "Connection refused" error because another > process has already been bound to the specified JMX/RMI port pairs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/00/ > > Testing done: > jdk_jmx and jdk_management tests all pass after this change (no > regressions). There is also a new JTREG test which fails prior this > change and passes after. Updates to the diagnostic command have been > tested manually. > > I understand that, if approved, the JDK and hotspot changes should get > pushed together? Hotspot changes are fairly trivial since it's only a > doc-update for the new JDK property in the relevant diagnostic command. > > Could someone please review and sponsor this change? Please let me know > if there are questions. > > Thanks, > Severin > From jaroslav.bachorik at oracle.com Mon Nov 2 15:54:03 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 2 Nov 2015 16:54:03 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <56377F17.4050006@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> Message-ID: <5637871B.30705@oracle.com> Hi, On 2.11.2015 16:19, Daniel Fuchs wrote: > Hi Severin, > > Adding serviceability-dev at openjdk.java.net into the loop - that's > a better alias than hotspot-dev for this kind of changes - maybe > someone from serviceability-dev will offer to sponsor :-) > > I will let serviceability team members comment on the hotspot changes. > > ConnectorBootstrap.java > > I have one suggestion and one concern: > > Suggestion: I would suggest to reuse 'csf' (Client Socket Factory) and > ssf (Server Socket Factory) variables rather than introduce the two > new variables rmiServerSocketFactory and rmiClientSocketFactory. > You might want to create a new boolean 'useSocketFactory' variable, > if that makes the code more readable. > > Concern: If I understand correctly how RMI socket factories work, > the client socket factory will be serialized and sent to the client > side. This is problematic for interoperability, as the class may not > present in the remote client - if the remote client is e.g. jdk 8. > > As far as I can see, your new DefaultClientSocketFactory doesn't do > anything useful - so I would suggest to simply get rid of it, and only > set the Server Socket Factory when SSL is not involved. > > Tests: > > Concerning the tests - we're trying to get rid of shell scripts > rather than introducing new ones :-) > Could the test be rewritten in pure java using the Process API? > > I believe there's even a test library that will let you do that > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > (see ProcessTools.java) > > Other: > > Also - I believe the new option should be documented in: > src/java.management/share/conf/management.properties I share Daniel's concerns. Also, the part of the changeset is related to javax.rmi.ssl - someone maintaining this library should also comment here. Also, the change is introducing new API (system property) and changing the existing one (adding SslRmiServerSocketFactory public constructors) so compatibility review process will have to be involved. -JB- > > best regards, > > -- daniel > > On 02/11/15 11:38, Severin Gehwolf wrote: > > Hi, > > > > Here is a patch addressing JDK-6425769. The issue is that the JMX agent > > binds to the wildcard address by default, preventing users to use > > system properties for JMX agents on multi-homed hosts. Given a host > > with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's > > impossible to start two JMX agents binding to fixed ports but to > > different network interfaces, 192.168.0.1:{9111,9112} and > > 192.168.0.2:{9111,9112} say. > > > > The JDK would bind to all local interfaces by default. In the above > > example to 192.168.0.1 *and* 192.168.0.2. The effect is that the second > > Java process would get a "Connection refused" error because another > > process has already been bound to the specified JMX/RMI port pairs. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/00/ > > > > Testing done: > > jdk_jmx and jdk_management tests all pass after this change (no > > regressions). There is also a new JTREG test which fails prior this > > change and passes after. Updates to the diagnostic command have been > > tested manually. > > > > I understand that, if approved, the JDK and hotspot changes should get > > pushed together? Hotspot changes are fairly trivial since it's only a > > doc-update for the new JDK property in the relevant diagnostic command. > > > > Could someone please review and sponsor this change? Please let me know > > if there are questions. > > > > Thanks, > > Severin > > > From sgehwolf at redhat.com Mon Nov 2 18:06:55 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Nov 2015 19:06:55 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <5637871B.30705@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> Message-ID: <1446487615.10865.57.camel@redhat.com> Hi, Thanks Jaroslav and Daniel for the reviews! Comments inline. On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > Hi, > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > Hi Severin, > > > > Adding serviceability-dev at openjdk.java.net into the loop - that's > > a better alias than hotspot-dev for this kind of changes - maybe > > someone from serviceability-dev will offer to sponsor :-) > > > > I will let serviceability team members comment on the hotspot > > changes. > > > > ConnectorBootstrap.java > > > > I have one suggestion and one concern: > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket Factory) > > and > > ssf??(Server Socket Factory) variables rather than introduce the > > two > > new variables rmiServerSocketFactory and rmiClientSocketFactory. > > You might want to create a new boolean 'useSocketFactory' variable, > > if that makes the code more readable. > > > > Concern: If I understand correctly how RMI socket factories work, > > the client socket factory will be serialized and sent to the client > > side. This is problematic for interoperability, as the class may > > not > > present in the remote client - if the remote client is e.g. jdk 8. > > > > As far as I can see, your new DefaultClientSocketFactory doesn't do > > anything useful - so I would suggest to simply get rid of it, and > > only > > set the Server Socket Factory when SSL is not involved. Thanks. Fixed in updated webrev. > > Tests: > > > > Concerning the tests - we're trying to get rid of shell scripts > > rather than introducing new ones :-) > > Could the test be rewritten in pure java using the Process API? > > > > I believe there's even a test library that will let you do that > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > (see ProcessTools.java) It'll take me a bit to rewrite the test in pure Java, but should be fine. This is not yet fixed in the updated webrev. > > Other: > > > > Also - I believe the new option should be documented in: > > src/java.management/share/conf/management.properties Docs have been updated in?src/java.management/share/conf/management.properties. > I share Daniel's concerns. Also, the part of the changeset is related > to javax.rmi.ssl - someone maintaining this library should also > comment here. > > Also, the change is introducing new API (system property) and > changing the existing one (adding SslRmiServerSocketFactory public > constructors) so compatibility review process will have to be > involved. OK. What exactly is there for me to do? I'm not familiar with this process. Note that the intent would be to get this backported to JDK 8. New webrev at: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ Thanks, Severin > -JB- > > > > best regards, > > > > -- daniel > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > Hi, > > > > > > Here is a patch addressing JDK-6425769. The issue is that the JMX > > > agent > > > binds to the wildcard address by default, preventing users to use > > > system properties for JMX agents on multi-homed hosts. Given a > > > host > > > with local network interfaces, 192.168.0.1 and 192.168.0.2 say, > > > it's > > > impossible to start two JMX agents binding to fixed ports but to > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > 192.168.0.2:{9111,9112} say. > > > > > > The JDK would bind to all local interfaces by default. In the > > > above > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is that the > > > second > > > Java process would get a "Connection refused" error because > > > another > > > process has already been bound to the specified JMX/RMI port > > > pairs. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/ > > > 00/ > > > > > > Testing done: > > > jdk_jmx and jdk_management tests all pass after this change (no > > > regressions). There is also a new JTREG test which fails prior > > > this > > > change and passes after. Updates to the diagnostic command have > > > been > > > tested manually. > > > > > > I understand that, if approved, the JDK and hotspot changes > > > should get > > > pushed together? Hotspot changes are fairly trivial since it's > > > only a > > > doc-update for the new JDK property in the relevant diagnostic > > > command. > > > > > > Could someone please review and sponsor this change? Please let > > > me know > > > if there are questions. > > > > > > Thanks, > > > Severin > > > > > > From jaroslav.bachorik at oracle.com Tue Nov 3 14:45:51 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 3 Nov 2015 15:45:51 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <1446487615.10865.57.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> Message-ID: <5638C89F.2090406@oracle.com> On 2.11.2015 19:06, Severin Gehwolf wrote: > Hi, > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > Hi, > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > >> Hi Severin, > >> > >> Adding serviceability-dev at openjdk.java.net into the loop - that's > >> a better alias than hotspot-dev for this kind of changes - maybe > >> someone from serviceability-dev will offer to sponsor :-) > >> > >> I will let serviceability team members comment on the hotspot > >> changes. > >> > >> ConnectorBootstrap.java > >> > >> I have one suggestion and one concern: > >> > >> Suggestion: I would suggest to reuse 'csf' (Client Socket Factory) > >> and > >> ssf (Server Socket Factory) variables rather than introduce the > >> two > >> new variables rmiServerSocketFactory and rmiClientSocketFactory. > >> You might want to create a new boolean 'useSocketFactory' variable, > >> if that makes the code more readable. > >> > >> Concern: If I understand correctly how RMI socket factories work, > >> the client socket factory will be serialized and sent to the client > >> side. This is problematic for interoperability, as the class may > >> not > >> present in the remote client - if the remote client is e.g. jdk 8. > >> > >> As far as I can see, your new DefaultClientSocketFactory doesn't do > >> anything useful - so I would suggest to simply get rid of it, and > >> only > >> set the Server Socket Factory when SSL is not involved. > > Thanks. Fixed in updated webrev. > > >> Tests: > >> > >> Concerning the tests - we're trying to get rid of shell scripts > >> rather than introducing new ones :-) > >> Could the test be rewritten in pure java using the Process API? > >> > >> I believe there's even a test library that will let you do that > >> easily jdk/test/lib/testlibrary/jdk/testlibrary/ > >> (see ProcessTools.java) > > It'll take me a bit to rewrite the test in pure Java, but should be > fine. This is not yet fixed in the updated webrev. > > >> Other: > >> > >> Also - I believe the new option should be documented in: > >> src/java.management/share/conf/management.properties > > Docs have been updated > in src/java.management/share/conf/management.properties. > > > I share Daniel's concerns. Also, the part of the changeset is related > > to javax.rmi.ssl - someone maintaining this library should also > > comment here. > > > > Also, the change is introducing new API (system property) and > > changing the existing one (adding SslRmiServerSocketFactory public > > constructors) so compatibility review process will have to be > > involved. > > OK. What exactly is there for me to do? I'm not familiar with this > process. Note that the intent would be to get this backported to JDK 8. Not much for you. But for the potential Oracle sponsor this means she will have to remember to go through some extra hoops before integrating your patch. -JB- > > New webrev at: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > Thanks, > Severin > > > -JB- > >> > >> best regards, > >> > >> -- daniel > >> > >> On 02/11/15 11:38, Severin Gehwolf wrote: > >>> Hi, > >>> > >>> Here is a patch addressing JDK-6425769. The issue is that the JMX > >>> agent > >>> binds to the wildcard address by default, preventing users to use > >>> system properties for JMX agents on multi-homed hosts. Given a > >>> host > >>> with local network interfaces, 192.168.0.1 and 192.168.0.2 say, > >>> it's > >>> impossible to start two JMX agents binding to fixed ports but to > >>> different network interfaces, 192.168.0.1:{9111,9112} and > >>> 192.168.0.2:{9111,9112} say. > >>> > >>> The JDK would bind to all local interfaces by default. In the > >>> above > >>> example to 192.168.0.1 *and* 192.168.0.2. The effect is that the > >>> second > >>> Java process would get a "Connection refused" error because > >>> another > >>> process has already been bound to the specified JMX/RMI port > >>> pairs. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/ > >>> 00/ > >>> > >>> Testing done: > >>> jdk_jmx and jdk_management tests all pass after this change (no > >>> regressions). There is also a new JTREG test which fails prior > >>> this > >>> change and passes after. Updates to the diagnostic command have > >>> been > >>> tested manually. > >>> > >>> I understand that, if approved, the JDK and hotspot changes > >>> should get > >>> pushed together? Hotspot changes are fairly trivial since it's > >>> only a > >>> doc-update for the new JDK property in the relevant diagnostic > >>> command. > >>> > >>> Could someone please review and sponsor this change? Please let > >>> me know > >>> if there are questions. > >>> > >>> Thanks, > >>> Severin > >>> > >> > > > From sgehwolf at redhat.com Wed Nov 4 10:54:36 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 04 Nov 2015 11:54:36 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <5638C89F.2090406@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> Message-ID: <1446634476.3554.8.camel@redhat.com> Hi, Updated webrev with jtreg test in Java: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 I believe this updated webrev addresses all concerns and incorporates suggestions brought up by Jaroslav and Daniel. I'm still looking for a sponsor and a hotspot/servicability-dev reviewer. Could somebody maintaining javax.rmi.ssl have a look at this as well? Thank you! Cheers, Severin On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: > On 2.11.2015 19:06, Severin Gehwolf wrote: > > Hi, > > > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > > Hi, > > > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > > > Hi Severin, > > > > > > > > Adding serviceability-dev at openjdk.java.net into the loop - > > > > that's > > > > a better alias than hotspot-dev for this kind of changes - > > > > maybe > > > > someone from serviceability-dev will offer to sponsor :-) > > > > > > > > I will let serviceability team members comment on the hotspot > > > > changes. > > > > > > > > ConnectorBootstrap.java > > > > > > > > I have one suggestion and one concern: > > > > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket > > > > Factory) > > > > and > > > > ssf??(Server Socket Factory) variables rather than introduce > > > > the > > > > two > > > > new variables rmiServerSocketFactory and > > > > rmiClientSocketFactory. > > > > You might want to create a new boolean 'useSocketFactory' > > > > variable, > > > > if that makes the code more readable. > > > > > > > > Concern: If I understand correctly how RMI socket factories > > > > work, > > > > the client socket factory will be serialized and sent to the > > > > client > > > > side. This is problematic for interoperability, as the class > > > > may > > > > not > > > > present in the remote client - if the remote client is e.g. jdk > > > > 8. > > > > > > > > As far as I can see, your new DefaultClientSocketFactory > > > > doesn't do > > > > anything useful - so I would suggest to simply get rid of it, > > > > and > > > > only > > > > set the Server Socket Factory when SSL is not involved. > > > > Thanks. Fixed in updated webrev. > > > > > > Tests: > > > > > > > > Concerning the tests - we're trying to get rid of shell scripts > > > > rather than introducing new ones :-) > > > > Could the test be rewritten in pure java using the Process API? > > > > > > > > I believe there's even a test library that will let you do that > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > > > (see ProcessTools.java) > > > > It'll take me a bit to rewrite the test in pure Java, but should be > > fine. This is not yet fixed in the updated webrev. > > > > > > Other: > > > > > > > > Also - I believe the new option should be documented in: > > > > src/java.management/share/conf/management.properties > > > > Docs have been updated > > in src/java.management/share/conf/management.properties. > > > > > I share Daniel's concerns. Also, the part of the changeset is > > > related > > > to javax.rmi.ssl - someone maintaining this library should also > > > comment here. > > > > > > Also, the change is introducing new API (system property) and > > > changing the existing one (adding SslRmiServerSocketFactory > > > public > > > constructors) so compatibility review process will have to be > > > involved. > > > > OK. What exactly is there for me to do? I'm not familiar with this > > process. Note that the intent would be to get this backported to > > JDK 8. > Not much for you. But for the potential Oracle sponsor this means she > will have to remember to go through some extra hoops before > integrating your patch. I see. Thanks for clarifying it. > -JB- > > > > > New webrev at: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > > > Thanks, > > Severin > > > > > -JB- > > > > > > > > best regards, > > > > > > > > -- daniel > > > > > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Here is a patch addressing JDK-6425769. The issue is that the > > > > > JMX > > > > > agent > > > > > binds to the wildcard address by default, preventing users to > > > > > use > > > > > system properties for JMX agents on multi-homed hosts. Given > > > > > a > > > > > host > > > > > with local network interfaces, 192.168.0.1 and 192.168.0.2 > > > > > say, > > > > > it's > > > > > impossible to start two JMX agents binding to fixed ports but > > > > > to > > > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > > > 192.168.0.2:{9111,9112} say. > > > > > > > > > > The JDK would bind to all local interfaces by default. In the > > > > > above > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is that > > > > > the > > > > > second > > > > > Java process would get a "Connection refused" error because > > > > > another > > > > > process has already been bound to the specified JMX/RMI port > > > > > pairs. > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425 > > > > > 769/ > > > > > 00/ > > > > > > > > > > Testing done: > > > > > jdk_jmx and jdk_management tests all pass after this change > > > > > (no > > > > > regressions). There is also a new JTREG test which fails > > > > > prior > > > > > this > > > > > change and passes after. Updates to the diagnostic command > > > > > have > > > > > been > > > > > tested manually. > > > > > > > > > > I understand that, if approved, the JDK and hotspot changes > > > > > should get > > > > > pushed together? Hotspot changes are fairly trivial since > > > > > it's > > > > > only a > > > > > doc-update for the new JDK property in the relevant > > > > > diagnostic > > > > > command. > > > > > > > > > > Could someone please review and sponsor this change? Please > > > > > let > > > > > me know > > > > > if there are questions. > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > > > From sgehwolf at redhat.com Mon Nov 9 09:32:05 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 09 Nov 2015 10:32:05 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <1446634476.3554.8.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> Message-ID: <1447061525.3551.3.camel@redhat.com> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > Hi, > > Updated webrev with jtreg test in Java: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 > > I believe this updated webrev addresses all concerns and incorporates > suggestions brought up by Jaroslav and Daniel. > > I'm still looking for a sponsor and a hotspot/servicability-dev > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > this > as well? Thank you! Ping? Friendly reminder that I still need reviewers and a sponsor for this. Thanks, Severin > Cheers, > Severin > > On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: > > On 2.11.2015 19:06, Severin Gehwolf wrote: > > > Hi, > > > > > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > > > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > > > Hi, > > > > > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > > > > Hi Severin, > > > > > > > > > > Adding serviceability-dev at openjdk.java.net into the loop - > > > > > that's > > > > > a better alias than hotspot-dev for this kind of changes - > > > > > maybe > > > > > someone from serviceability-dev will offer to sponsor :-) > > > > > > > > > > I will let serviceability team members comment on the hotspot > > > > > changes. > > > > > > > > > > ConnectorBootstrap.java > > > > > > > > > > I have one suggestion and one concern: > > > > > > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket > > > > > Factory) > > > > > and > > > > > ssf??(Server Socket Factory) variables rather than introduce > > > > > the > > > > > two > > > > > new variables rmiServerSocketFactory and > > > > > rmiClientSocketFactory. > > > > > You might want to create a new boolean 'useSocketFactory' > > > > > variable, > > > > > if that makes the code more readable. > > > > > > > > > > Concern: If I understand correctly how RMI socket factories > > > > > work, > > > > > the client socket factory will be serialized and sent to the > > > > > client > > > > > side. This is problematic for interoperability, as the class > > > > > may > > > > > not > > > > > present in the remote client - if the remote client is e.g. > > > > > jdk > > > > > 8. > > > > > > > > > > As far as I can see, your new DefaultClientSocketFactory > > > > > doesn't do > > > > > anything useful - so I would suggest to simply get rid of it, > > > > > and > > > > > only > > > > > set the Server Socket Factory when SSL is not involved. > > > > > > Thanks. Fixed in updated webrev. > > > > > > > > Tests: > > > > > > > > > > Concerning the tests - we're trying to get rid of shell > > > > > scripts > > > > > rather than introducing new ones :-) > > > > > Could the test be rewritten in pure java using the Process > > > > > API? > > > > > > > > > > I believe there's even a test library that will let you do > > > > > that > > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > > > > (see ProcessTools.java) > > > > > > It'll take me a bit to rewrite the test in pure Java, but should > > > be > > > fine. This is not yet fixed in the updated webrev. > > > > > > > > Other: > > > > > > > > > > Also - I believe the new option should be documented in: > > > > > src/java.management/share/conf/management.properties > > > > > > Docs have been updated > > > in src/java.management/share/conf/management.properties. > > > > > > > I share Daniel's concerns. Also, the part of the changeset is > > > > related > > > > to javax.rmi.ssl - someone maintaining this library should also > > > > comment here. > > > > > > > > Also, the change is introducing new API (system property) and > > > > changing the existing one (adding SslRmiServerSocketFactory > > > > public > > > > constructors) so compatibility review process will have to be > > > > involved. > > > > > > OK. What exactly is there for me to do? I'm not familiar with > > > this > > > process. Note that the intent would be to get this backported to > > > JDK 8. > > Not much for you. But for the potential Oracle sponsor this means > > she > > will have to remember to go through some extra hoops before > > integrating your patch. > > I see. Thanks for clarifying it. > > > -JB- > > > > > > > > New webrev at: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > > > > > Thanks, > > > Severin > > > > > > > -JB- > > > > > > > > > > best regards, > > > > > > > > > > -- daniel > > > > > > > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > Here is a patch addressing JDK-6425769. The issue is that > > > > > > the > > > > > > JMX > > > > > > agent > > > > > > binds to the wildcard address by default, preventing users > > > > > > to > > > > > > use > > > > > > system properties for JMX agents on multi-homed hosts. > > > > > > Given > > > > > > a > > > > > > host > > > > > > with local network interfaces, 192.168.0.1 and 192.168.0.2 > > > > > > say, > > > > > > it's > > > > > > impossible to start two JMX agents binding to fixed ports > > > > > > but > > > > > > to > > > > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > > > > 192.168.0.2:{9111,9112} say. > > > > > > > > > > > > The JDK would bind to all local interfaces by default. In > > > > > > the > > > > > > above > > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is > > > > > > that > > > > > > the > > > > > > second > > > > > > Java process would get a "Connection refused" error because > > > > > > another > > > > > > process has already been bound to the specified JMX/RMI > > > > > > port > > > > > > pairs. > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-64 > > > > > > 25 > > > > > > 769/ > > > > > > 00/ > > > > > > > > > > > > Testing done: > > > > > > jdk_jmx and jdk_management tests all pass after this change > > > > > > (no > > > > > > regressions). There is also a new JTREG test which fails > > > > > > prior > > > > > > this > > > > > > change and passes after. Updates to the diagnostic command > > > > > > have > > > > > > been > > > > > > tested manually. > > > > > > > > > > > > I understand that, if approved, the JDK and hotspot changes > > > > > > should get > > > > > > pushed together? Hotspot changes are fairly trivial since > > > > > > it's > > > > > > only a > > > > > > doc-update for the new JDK property in the relevant > > > > > > diagnostic > > > > > > command. > > > > > > > > > > > > Could someone please review and sponsor this change? Please > > > > > > let > > > > > > me know > > > > > > if there are questions. > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > From jaroslav.bachorik at oracle.com Wed Nov 11 15:52:43 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Nov 2015 16:52:43 +0100 Subject: jmx-dev RFR 8142398: ManagementAgent.status diagnostic command only outputs the specifically set properties Message-ID: <5643644B.2080102@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8142398 Webrev: http://cr.openjdk.java.net/~jbachorik/8142398/webrev.00 This patch adds the list of the default agent properties with the info whether the default value has been overridden to the ManagementAgent.status DCMD output. Thanks, -JB- From jaroslav.bachorik at oracle.com Thu Nov 12 12:13:07 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 12 Nov 2015 13:13:07 +0100 Subject: jmx-dev RFR 8141591: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently Message-ID: <56448253.9020503@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8141591 Webrev: http://cr.openjdk.java.net/~jbachorik/8141591/webrev.00 In rare circumstances, when an external executor is provided, the ClientNotifForwarder$NotifFetcher.doRun() method might fail because of RejectedExecutionException caused by the executor being externally shut down. The patch adds a guard against this possibility. If the executor has been shut down the fetcher will also properly stop. Thanks, -JB- From shanliang.jiang at oracle.com Fri Nov 13 07:05:48 2015 From: shanliang.jiang at oracle.com (Shanliang JIANG) Date: Fri, 13 Nov 2015 08:05:48 +0100 Subject: jmx-dev RFR 8141591: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: <56448253.9020503@oracle.com> References: <56448253.9020503@oracle.com> Message-ID: Hi Jaroslav, The issue is that after a JMX client is terminated, its ClientNotifForwarder continues deliver a job to a user specific Executor, I think a better fix to not allow this happen. I am not sure that it is a good solution to check RejectedExecutionException, here is the Java doc: "Exception thrown by an Executor when a task cannot be accepted for execution." it means that the exception is possibly thrown in other cases too, like too many tasks if it is shared. So ignore simply this exception in case of not ?shouldStop()? seems incorrect. And Executor is an interface and a user could provide any implementation class, so possible a user would throw any another RuntimeException or even an Error in this case. Shanliang > On 12 Nov 2015, at 13:13, Jaroslav Bachorik wrote: > > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8141591 > Webrev: http://cr.openjdk.java.net/~jbachorik/8141591/webrev.00 > > In rare circumstances, when an external executor is provided, the ClientNotifForwarder$NotifFetcher.doRun() method might fail because of RejectedExecutionException caused by the executor being externally shut down. > > The patch adds a guard against this possibility. If the executor has been shut down the fetcher will also properly stop. > > Thanks, > > -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Fri Nov 13 08:04:54 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 13 Nov 2015 09:04:54 +0100 Subject: jmx-dev RFR 8141591: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: References: <56448253.9020503@oracle.com> Message-ID: <564599A6.1030802@oracle.com> On 13.11.2015 08:05, Shanliang JIANG wrote: > Hi Jaroslav, > > The issue is that after a JMX client is terminated, its > ClientNotifForwarder continues deliver a job to a user specific > Executor, I think a better fix to not allow this happen. > > I am not sure that it is a good solution to check > RejectedExecutionException, here is the Java doc: > "Exception thrown by an |Executor| > when > a task cannot be accepted for execution." > > it means that the exception is possibly thrown in other cases too, like > too many tasks if it is shared. So ignore simply this exception in case > of not ?shouldStop()? seems incorrect. > > And Executor is an interface and a user could provide any implementation > class, so possible a user would throw any another RuntimeException or > even an Error in this case. Well, the main problem is the self-rescheduling part. Normally, a scheduled executor would be used to perform periodic tasks and it would know how to handle its own shutdown. But, unfortunately, the more generic Executor is required. If only it were at least ExecutorService where you can use 'isShutdown()' method ... The fact that the user provided executor can throw RejectedExecutionException at its discretion opens whole another can of worms. The code as it is now will simply bail out of the notification fetching loop with the thrown exception. Sadly, there is no cleanup performed so the ClientNotifForwarder will stay in inconsistent state (marked as STARTED when it is, in fact, TERMINATED, notification listeners not de-registered, etc.). To make things worse there seem to be no official documentation as what is the expected behaviour of the externally provided executor. The only documentation to the env property "jmx.remote.x.fetch.notifications.executor" is in ClientNotifForwarder.java (L125-128) and it is not exactly exhaustive. -JB- > > Shanliang > > On 12 Nov 2015, at 13:13, Jaroslav Bachorik > > > > > wrote: > > > > Please, review the following test change > > > > Issue : https://bugs.openjdk.java.net/browse/JDK-8141591 > > Webrev: http://cr.openjdk.java.net/~jbachorik/8141591/webrev.00 > > > > In rare circumstances, when an external executor is provided, the > > ClientNotifForwarder$NotifFetcher.doRun() method might fail because of > > RejectedExecutionException caused by the executor being externally > > shut down. > > > > The patch adds a guard against this possibility. If the executor has > > been shut down the fetcher will also properly stop. > > > > Thanks, > > > > -JB- > From shanliang.jiang at oracle.com Fri Nov 13 17:07:42 2015 From: shanliang.jiang at oracle.com (Shanliang JIANG) Date: Fri, 13 Nov 2015 18:07:42 +0100 Subject: jmx-dev RFR 8141591: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: <564599A6.1030802@oracle.com> References: <56448253.9020503@oracle.com> <564599A6.1030802@oracle.com> Message-ID: <0838E637-4F57-4BED-B973-3AAACABC719C@oracle.com> > On 13 Nov 2015, at 09:04, Jaroslav Bachorik wrote: > > On 13.11.2015 08:05, Shanliang JIANG wrote: >> Hi Jaroslav, >> >> The issue is that after a JMX client is terminated, its >> ClientNotifForwarder continues deliver a job to a user specific >> Executor, I think a better fix to not allow this happen. >> >> I am not sure that it is a good solution to check >> RejectedExecutionException, here is the Java doc: >> "Exception thrown by an |Executor| >> when >> a task cannot be accepted for execution." >> >> it means that the exception is possibly thrown in other cases too, like >> too many tasks if it is shared. So ignore simply this exception in case >> of not ?shouldStop()? seems incorrect. >> >> And Executor is an interface and a user could provide any implementation >> class, so possible a user would throw any another RuntimeException or >> even an Error in this case. > Well, the main problem is the self-rescheduling part. Normally, a scheduled executor would be used to perform periodic tasks and it would know how to handle its own shutdown. But, unfortunately, the more generic Executor is required. If only it were at least ExecutorService where you can use 'isShutdown()' method ... > > The fact that the user provided executor can throw RejectedExecutionException at its discretion opens whole another can of worms. The code as it is now will simply bail out of the notification fetching loop with the thrown exception. Sadly, there is no cleanup performed so the ClientNotifForwarder will stay in inconsistent state (marked as STARTED when it is, in fact, TERMINATED, notification listeners not de-registered, etc.). To make things worse there seem to be no official documentation as what is the expected behaviour of the externally provided executor. The only documentation to the env property "jmx.remote.x.fetch.notifications.executor" is in ClientNotifForwarder.java (L125-128) and it is not exactly exhaustive. Here is my suggestion (I create a webrev because it is easier to look at): http://cr.openjdk.java.net/~sjiang/JDK-8141591/00/ It does rescheduling within the synchronisation, which makes sure to not deliver a new task after a JMX client is terminated. This class is complicated because the fetching should be stopped if no more listener or during re-connection, but then could be re-started at anytime. Shanliang > > -JB- > > >> >> Shanliang >> > On 12 Nov 2015, at 13:13, Jaroslav Bachorik >> > > >> > wrote: >> > >> > Please, review the following test change >> > >> > Issue : https://bugs.openjdk.java.net/browse/JDK-8141591 >> > Webrev: http://cr.openjdk.java.net/~jbachorik/8141591/webrev.00 >> > >> > In rare circumstances, when an external executor is provided, the >> > ClientNotifForwarder$NotifFetcher.doRun() method might fail because of >> > RejectedExecutionException caused by the executor being externally >> > shut down. >> > >> > The patch adds a guard against this possibility. If the executor has >> > been shut down the fetcher will also properly stop. >> > >> > Thanks, >> > >> > -JB- >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Wed Nov 18 17:06:26 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 18 Nov 2015 18:06:26 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <1447061525.3551.3.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> Message-ID: <1447866386.3660.53.camel@redhat.com> Hi, Re-posting this for review since I've done another version which duplicates some of the code in?SslRMIServerSocketFactory.java but does not change API other than adding the new property. I personally don't like it, but maybe this version is preferred? Bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/ Thanks, Severin On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev with jtreg test in Java: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > I believe this updated webrev addresses all concerns and > > incorporates > > suggestions brought up by Jaroslav and Daniel. > > > > I'm still looking for a sponsor and a hotspot/servicability-dev > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > > this > > as well? Thank you! > > Ping? Friendly reminder that I still need reviewers and a sponsor for > this. > > Thanks, > Severin > > > Cheers, > > Severin > > > > On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: > > > On 2.11.2015 19:06, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > > > > > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > > > > Hi, > > > > > > > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > > > > > Hi Severin, > > > > > > > > > > > > Adding serviceability-dev at openjdk.java.net into the loop - > > > > > > that's > > > > > > a better alias than hotspot-dev for this kind of changes - > > > > > > maybe > > > > > > someone from serviceability-dev will offer to sponsor :-) > > > > > > > > > > > > I will let serviceability team members comment on the > > > > > > hotspot > > > > > > changes. > > > > > > > > > > > > ConnectorBootstrap.java > > > > > > > > > > > > I have one suggestion and one concern: > > > > > > > > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket > > > > > > Factory) > > > > > > and > > > > > > ssf??(Server Socket Factory) variables rather than > > > > > > introduce > > > > > > the > > > > > > two > > > > > > new variables rmiServerSocketFactory and > > > > > > rmiClientSocketFactory. > > > > > > You might want to create a new boolean 'useSocketFactory' > > > > > > variable, > > > > > > if that makes the code more readable. > > > > > > > > > > > > Concern: If I understand correctly how RMI socket factories > > > > > > work, > > > > > > the client socket factory will be serialized and sent to > > > > > > the > > > > > > client > > > > > > side. This is problematic for interoperability, as the > > > > > > class > > > > > > may > > > > > > not > > > > > > present in the remote client - if the remote client is e.g. > > > > > > jdk > > > > > > 8. > > > > > > > > > > > > As far as I can see, your new DefaultClientSocketFactory > > > > > > doesn't do > > > > > > anything useful - so I would suggest to simply get rid of > > > > > > it, > > > > > > and > > > > > > only > > > > > > set the Server Socket Factory when SSL is not involved. > > > > > > > > Thanks. Fixed in updated webrev. > > > > > > > > > > Tests: > > > > > > > > > > > > Concerning the tests - we're trying to get rid of shell > > > > > > scripts > > > > > > rather than introducing new ones :-) > > > > > > Could the test be rewritten in pure java using the Process > > > > > > API? > > > > > > > > > > > > I believe there's even a test library that will let you do > > > > > > that > > > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > > > > > (see ProcessTools.java) > > > > > > > > It'll take me a bit to rewrite the test in pure Java, but > > > > should > > > > be > > > > fine. This is not yet fixed in the updated webrev. > > > > > > > > > > Other: > > > > > > > > > > > > Also - I believe the new option should be documented in: > > > > > > src/java.management/share/conf/management.properties > > > > > > > > Docs have been updated > > > > in src/java.management/share/conf/management.properties. > > > > > > > > > I share Daniel's concerns. Also, the part of the changeset is > > > > > related > > > > > to javax.rmi.ssl - someone maintaining this library should > > > > > also > > > > > comment here. > > > > > > > > > > Also, the change is introducing new API (system property) and > > > > > changing the existing one (adding SslRmiServerSocketFactory > > > > > public > > > > > constructors) so compatibility review process will have to be > > > > > involved. > > > > > > > > OK. What exactly is there for me to do? I'm not familiar with > > > > this > > > > process. Note that the intent would be to get this backported > > > > to > > > > JDK 8. > > > Not much for you. But for the potential Oracle sponsor this means > > > she > > > will have to remember to go through some extra hoops before > > > integrating your patch. > > > > I see. Thanks for clarifying it. > > > > > -JB- > > > > > > > > > > > New webrev at: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > > > > > > > Thanks, > > > > Severin > > > > > > > > > -JB- > > > > > > > > > > > > best regards, > > > > > > > > > > > > -- daniel > > > > > > > > > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Here is a patch addressing JDK-6425769. The issue is that > > > > > > > the > > > > > > > JMX > > > > > > > agent > > > > > > > binds to the wildcard address by default, preventing > > > > > > > users > > > > > > > to > > > > > > > use > > > > > > > system properties for JMX agents on multi-homed hosts. > > > > > > > Given > > > > > > > a > > > > > > > host > > > > > > > with local network interfaces, 192.168.0.1 and > > > > > > > 192.168.0.2 > > > > > > > say, > > > > > > > it's > > > > > > > impossible to start two JMX agents binding to fixed ports > > > > > > > but > > > > > > > to > > > > > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > > > > > 192.168.0.2:{9111,9112} say. > > > > > > > > > > > > > > The JDK would bind to all local interfaces by default. In > > > > > > > the > > > > > > > above > > > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is > > > > > > > that > > > > > > > the > > > > > > > second > > > > > > > Java process would get a "Connection refused" error > > > > > > > because > > > > > > > another > > > > > > > process has already been bound to the specified JMX/RMI > > > > > > > port > > > > > > > pairs. > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > > 64 > > > > > > > 25 > > > > > > > 769/ > > > > > > > 00/ > > > > > > > > > > > > > > Testing done: > > > > > > > jdk_jmx and jdk_management tests all pass after this > > > > > > > change > > > > > > > (no > > > > > > > regressions). There is also a new JTREG test which fails > > > > > > > prior > > > > > > > this > > > > > > > change and passes after. Updates to the diagnostic > > > > > > > command > > > > > > > have > > > > > > > been > > > > > > > tested manually. > > > > > > > > > > > > > > I understand that, if approved, the JDK and hotspot > > > > > > > changes > > > > > > > should get > > > > > > > pushed together? Hotspot changes are fairly trivial since > > > > > > > it's > > > > > > > only a > > > > > > > doc-update for the new JDK property in the relevant > > > > > > > diagnostic > > > > > > > command. > > > > > > > > > > > > > > Could someone please review and sponsor this change? > > > > > > > Please > > > > > > > let > > > > > > > me know > > > > > > > if there are questions. > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > > > > > > > > From jaroslav.bachorik at oracle.com Wed Nov 25 16:40:00 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 25 Nov 2015 17:40:00 +0100 Subject: jmx-dev [ping] Re: RFR 8142398: ManagementAgent.status diagnostic command only outputs the specifically set properties In-Reply-To: <5643644B.2080102@oracle.com> References: <5643644B.2080102@oracle.com> Message-ID: <5655E460.7050400@oracle.com> On 11.11.2015 16:52, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8142398 > Webrev: http://cr.openjdk.java.net/~jbachorik/8142398/webrev.00 > > This patch adds the list of the default agent properties with the info > whether the default value has been overridden to the > ManagementAgent.status DCMD output. > > Thanks, > > -JB-