jmx-dev RFR 6425769: jmx remote bind address

[Jaroslav Bachorik]

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
> >
>