Hi Severin,
Adding [email protected] 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
