RFR: JDK-8160240 - javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java failed with error "Address already in use: bind"
Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8160240/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8160240 it has been observed that, during continuous integration regression tests on some platforms, there is an intermittent bind failure, when starting the orbd for the test. Thus, as the test is composed of two run commands, one without security manager and one with security manager, it is assumed that, the second run starts before the sockets in use in the first run have been fully released. Therefore, to overcome the bind already in use port conflict, the test's second run with security manager has been modified to use different ports, for cos nameservice and activator, to those of the first run. regards Mark
Mark, fixed port numbers are always going to be problematic in tests. Is there any way the port numbers can be assigned after the test starts up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be modified/accessed via reflection so that the initUsingIiopUrl can be re-called once you're sure of a free port on test client. That failing, maybe you can use a try/finally block in main method to ensure that stopTestComponents() is always called. Looks like there's potential for the test to exit early without cleaning up if startRmiIiopServer() runs into an exception. Regards, Sean. On 01/07/16 00:38, Mark Sheppard wrote:
Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8160240/webrev/
to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8160240
it has been observed that, during continuous integration regression tests on some platforms, there is an intermittent bind failure, when starting the orbd for the test. Thus, as the test is composed of two run commands, one without security manager and one with security manager, it is assumed that, the second run starts before the sockets in use in the first run have been fully released. Therefore, to overcome the bind already in use port conflict, the test's second run with security manager has been modified to use different ports, for cos nameservice and activator, to those of the first run.
regards Mark
Hi Mark, Instead of spreading around the condition and the port numbers, can you pass the pair of port numbers (as int's) to startOrbD and startRmiIiopServer? That would allow the logic for changing the port numbers to be put into startTestComponents. And you could take advantage of the TestLibrary.Utils.freeport() to pick a free port. Roger On 7/1/2016 11:45 AM, Seán Coffey wrote:
Mark,
fixed port numbers are always going to be problematic in tests. Is there any way the port numbers can be assigned after the test starts up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be modified/accessed via reflection so that the initUsingIiopUrl can be re-called once you're sure of a free port on test client.
That failing, maybe you can use a try/finally block in main method to ensure that stopTestComponents() is always called. Looks like there's potential for the test to exit early without cleaning up if startRmiIiopServer() runs into an exception.
Regards, Sean.
On 01/07/16 00:38, Mark Sheppard wrote:
Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8160240/webrev/
to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8160240
it has been observed that, during continuous integration regression tests on some platforms, there is an intermittent bind failure, when starting the orbd for the test. Thus, as the test is composed of two run commands, one without security manager and one with security manager, it is assumed that, the second run starts before the sockets in use in the first run have been fully released. Therefore, to overcome the bind already in use port conflict, the test's second run with security manager has been modified to use different ports, for cos nameservice and activator, to those of the first run.
regards Mark
Hi Roger, thanks for the feedback and suggestion. so is the suggestion one of parsing the command line of the test to extract the -port argument and then fabricate the NS port with an increment, and then pass this into the startComponents method and thus, eliminate the security manager check? I'm not too keen on using ephemeral ports for the tests. the port # chosen are not in the ephemeral range on any test platform (or at least shouldn't be, afaik) they are a variation on the default ports of 1050 1049 .... 4050 4049, 5050 5049. The issue stems from the tests executing faster than the kernel releases TCP resources when terminating connections have closed and it is intermittent as I understand it, TestLibrary.Utils.freeport() may have some issues also, in that it grabs a port by creating a Socket and then releases, and then indicates it is available for use, as a free port, based on the assumption that this port wont be a candidate for immediate selection in the ephemeral range ... this may not always be the case. regards Mark On 01/07/2016 17:01, Roger Riggs wrote:
Hi Mark,
Instead of spreading around the condition and the port numbers, can you pass the pair of port numbers (as int's) to startOrbD and startRmiIiopServer? That would allow the logic for changing the port numbers to be put into startTestComponents.
And you could take advantage of the TestLibrary.Utils.freeport() to pick a free port.
Roger
On 7/1/2016 11:45 AM, Seán Coffey wrote:
Mark,
fixed port numbers are always going to be problematic in tests. Is there any way the port numbers can be assigned after the test starts up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be modified/accessed via reflection so that the initUsingIiopUrl can be re-called once you're sure of a free port on test client.
That failing, maybe you can use a try/finally block in main method to ensure that stopTestComponents() is always called. Looks like there's potential for the test to exit early without cleaning up if startRmiIiopServer() runs into an exception.
Regards, Sean.
On 01/07/16 00:38, Mark Sheppard wrote:
Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8160240/webrev/
to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8160240
it has been observed that, during continuous integration regression tests on some platforms, there is an intermittent bind failure, when starting the orbd for the test. Thus, as the test is composed of two run commands, one without security manager and one with security manager, it is assumed that, the second run starts before the sockets in use in the first run have been fully released. Therefore, to overcome the bind already in use port conflict, the test's second run with security manager has been modified to use different ports, for cos nameservice and activator, to those of the first run.
regards Mark
Hi Mark, On 7/1/2016 2:25 PM, Mark Sheppard wrote:
Hi Roger, thanks for the feedback and suggestion.
so is the suggestion one of parsing the command line of the test to extract the -port argument and then fabricate the NS port with an increment, and then pass this into the startComponents method and thus, eliminate the security manager check? That would be equivalent; factoring out the ports all the way to the command line. Still it would be using fixed ports, as per Sean's comments.
I'm not too keen on using ephemeral ports for the tests. the port # chosen are not in the ephemeral range on any test platform (or at least shouldn't be, afaik) they are a variation on the default ports of 1050 1049 .... 4050 4049, 5050 5049. The issue stems from the tests executing faster than the kernel releases TCP resources when terminating connections have closed and it is intermittent
ok , but the port number values should not be important; only that they are unique. It would be much more work to have the orb and server open their own ephemeral port and then be able to configure the client to use it. But that would have the fewest problems with port usage. Still, it is probably not practical.
as I understand it, TestLibrary.Utils.freeport() may have some issues also, in that it grabs a port by creating a Socket and then releases, and then indicates it is available for use, as a free port, based on the assumption that this port wont be a candidate for immediate selection in the ephemeral range ... this may not always be the case.
I'm not sure if this is better or worse than fixed ports; it was proposed as an improvement over fixed ports but not without timing problems. Passing the ports from the command line is likely to be good enough unless multiple test runs are done concurrently on the same system. It would also be possible for startTestComponents to be able to detect that startOrbd failed to start on a particular port and try again with a different one; ditto startRmiIiopServer(). But that's also probably not worth applying for a single test, but more for an enhancement to the suite of tests. Roger
regards Mark
On 01/07/2016 17:01, Roger Riggs wrote:
Hi Mark,
Instead of spreading around the condition and the port numbers, can you pass the pair of port numbers (as int's) to startOrbD and startRmiIiopServer? That would allow the logic for changing the port numbers to be put into startTestComponents.
And you could take advantage of the TestLibrary.Utils.freeport() to pick a free port.
Roger
On 7/1/2016 11:45 AM, Seán Coffey wrote:
Mark,
fixed port numbers are always going to be problematic in tests. Is there any way the port numbers can be assigned after the test starts up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be modified/accessed via reflection so that the initUsingIiopUrl can be re-called once you're sure of a free port on test client.
That failing, maybe you can use a try/finally block in main method to ensure that stopTestComponents() is always called. Looks like there's potential for the test to exit early without cleaning up if startRmiIiopServer() runs into an exception.
Regards, Sean.
On 01/07/16 00:38, Mark Sheppard wrote:
Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8160240/webrev/
to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8160240
it has been observed that, during continuous integration regression tests on some platforms, there is an intermittent bind failure, when starting the orbd for the test. Thus, as the test is composed of two run commands, one without security manager and one with security manager, it is assumed that, the second run starts before the sockets in use in the first run have been fully released. Therefore, to overcome the bind already in use port conflict, the test's second run with security manager has been modified to use different ports, for cos nameservice and activator, to those of the first run.
regards Mark
Hi Sean, thanks for the feedback ... we should be ok with fixed ports. The orbd by default uses the fixed ports of 1050 and 1049. The selected ports are not in the ephemeral range on any platform. solaris /usr/sbin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port 32768 65535 linux cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 windows netsh int ipv4 show dynamicport tcp netsh int ipv6 show dynamicport tcp https://www.cymru.com/jtk/misc/ephemeralports.html As such the name service and the activator are expected to start on well known service ports: so the ports chosen are variants of 1050 1049 ... 5050 5049 etc. should be ok. The clash happens when the orbd's TCP resources of the first run are not released immediately by the windows/solaris kernel - as the TCP connections go through their various state changes. It is an intermittent failure. I'll have a look at the exception cases to ensure that all services are terminated in such instances ... I had thought that I did this originally, but will double check various scenarios regards Mark On 01/07/2016 16:45, Seán Coffey wrote:
Mark,
fixed port numbers are always going to be problematic in tests. Is there any way the port numbers can be assigned after the test starts up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be modified/accessed via reflection so that the initUsingIiopUrl can be re-called once you're sure of a free port on test client.
That failing, maybe you can use a try/finally block in main method to ensure that stopTestComponents() is always called. Looks like there's potential for the test to exit early without cleaning up if startRmiIiopServer() runs into an exception. Regards, Sean. On 01/07/16 00:38, Mark Sheppard wrote:
Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8160240/webrev/
to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8160240
it has been observed that, during continuous integration regression tests on some platforms, there is an intermittent bind failure, when starting the orbd for the test. Thus, as the test is composed of two run commands, one without security manager and one with security manager, it is assumed that, the second run starts before the sockets in use in the first run have been fully released. Therefore, to overcome the bind already in use port conflict, the test's second run with security manager has been modified to use different ports, for cos nameservice and activator, to those of the first run.
regards Mark
participants (3)
-
Mark Sheppard
-
Roger Riggs
-
Seán Coffey