jmx-dev RFR 6425769: jmx remote bind address

Daniel Fuchs daniel.fuchs at
Mon Nov 2 15:19:51 UTC 2015

Hi Severin,

Adding serviceability-dev at 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.

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.


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/


Also - I believe the new option should be documented in:

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, and say, it's
> impossible to start two JMX agents binding to fixed ports but to
> different network interfaces,{9111,9112} and
>{9111,9112} say.
> The JDK would bind to all local interfaces by default. In the above
> example to *and* 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:
> webrev:
> 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

More information about the hotspot-dev mailing list