Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi Daniel, On Tuesday 20 June 2017 06:39 PM, Daniel Fuchs wrote: On 20/06/2017 12:42, Ujwal Vangapally wrote: Thanks for the Review Daniel, Harsha. Yes with this fix JConsole running on JDK 8 won't be able to connect to a process running on higher version of Java containing this change. I think even Harsha is agreeing this, his point is that the use case where a client running on JDK 8 trying to connect to a process running on latest releases is rare. As mostly for Local Management both client and server will be running on same machine using same JDK for starting both client and server . please correct me if this is not the case. Well - I believe it could be quite common to use VisualVM running on JDK 8 to connect to JDK 9 processes. JMX is all about interoperability so I'd be very reluctant to break this 'by default'. Agreed. can we have this fix with interoperability issue between versions ? Maybe you could make the fix conditional to a system property being defined? Also are you sure what you are proposing is the correct fix for this issue? It's more of a workaround than a fix as we don't see any other way to fix this issue. Note that - if I'm not mistaken - you can work around the original issue by specifying -Djava.rmi.server.hostname= on the command line. http://docs.oracle.com/javase/8/docs/technotes/guides/rmi/javarmiproperties.html This will instruct RMI to put the specified inside its stubs. The inconvenience is that this is global (for all RMI stubs, just not only those used by JMX) - but would that be an issue for the use case mentioned in the bug? We had the same consideration that setting the RMI property will change the Interface address for all the stubs which may not be an acceptable fix in this case. One possible fix (enhancement) would be to define a JMX system property that will control the Interface address that goes into RMI stubs. If that seems like too much work, we can close this issue as 'won't fix' as we don't have any acceptable fix. best regards, -- daniel -Harsha Thanks, Ujwal. On 6/20/2017 2:40 PM, Daniel Fuchs wrote: Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
On 20/06/2017 12:42, Ujwal Vangapally wrote: Thanks for the Review Daniel, Harsha. Yes with this fix JConsole running on JDK 8 won't be able to connect to a process running on higher version of Java containing this change. I think even Harsha is agreeing this, his point is that the use case where a client running on JDK 8 trying to connect to a process running on latest releases is rare. As mostly for Local Management both client and server will be running on same machine using same JDK for starting both client and server . please correct me if this is not the case. Well - I believe it could be quite common to use VisualVM running on JDK 8 to connect to JDK 9 processes. JMX is all about interoperability so I'd be very reluctant to break this 'by default'. can we have this fix with interoperability issue between versions ? Maybe you could make the fix conditional to a system property being defined? Also are you sure what you are proposing is the correct fix for this issue? Note that - if I'm not mistaken - you can work around the original issue by specifying -Djava.rmi.server.hostname= on the command line. http://docs.oracle.com/javase/8/docs/technotes/guides/rmi/javarmiproperties.html This will instruct RMI to put the specified inside its stubs. The inconvenience is that this is global (for all RMI stubs, just not only those used by JMX) - but would that be an issue for the use case mentioned in the bug? best regards, -- daniel Thanks, Ujwal. On 6/20/2017 2:40 PM, Daniel Fuchs wrote: Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi, I would expect to see a mix of versions in many operational cases. For example, in a large deployment there will be a mix of versions active and the folks monitoring it should not have to change their management tools unnecessarily. The usual rule for interoperability between versions is that it should work between the previous and next versions. (+/- 1). If there is any issue with compatibility between versions, you'll need to file a CCC to make sure it gets adequate review. Roger On 6/20/17 7:42 AM, Ujwal Vangapally wrote: Thanks for the Review Daniel, Harsha. Yes with this fix JConsole running on JDK 8 won't be able to connect to a process running on higher version of Java containing this change. I think even Harsha is agreeing this, his point is that the use case where a client running on JDK 8 trying to connect to a process running on latest releases is rare. As mostly for Local Management both client and server will be running on same machine using same JDK for starting both client and server . please correct me if this is not the case. can we have this fix with interoperability issue between versions ? Thanks, Ujwal. On 6/20/2017 2:40 PM, Daniel Fuchs wrote: Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Thanks for the Review Daniel, Harsha. Yes with this fix JConsole running on JDK 8 won't be able to connect to a process running on higher version of Java containing this change. I think even Harsha is agreeing this, his point is that the use case where a client running on JDK 8 trying to connect to a process running on latest releases is rare. As mostly for Local Management both client and server will be running on same machine using same JDK for starting both client and server . please correct me if this is not the case. can we have this fix with interoperability issue between versions ? Thanks, Ujwal. On 6/20/2017 2:40 PM, Daniel Fuchs wrote: Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
