JDK-7195095 : TEST_BUG: sun/rmi/transport/proxy/EagerHttpFallback.java fails
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 7,8,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2012-08-30
  • Updated: 2023-10-09
  • Resolved: 2016-04-26
Related Reports
Relates :  
JDK-8066750 - Remove HTTP proxy implementation and tests from RMI
Relates :  
JDK-8157813 - Remove sun/rmi/transport/proxy/EagerHttpFallback.java from ProblemList.txt
Relates :  
JDK-8155978 - Remove HTTP proxy implementation and tests from RMI (again)
Description
TESTFAIL:sun/rmi/transport/proxy/EagerHttpFallback.java

The test sun/rmi/transport/proxy/EagerHttpFallback.java fails consistently for some developers on their desktop systems. Oddly, it doesn't seem to fail on JPRT or on our nightly builds.

Test log is as follows:


call on registry stub with port 35557did not successfully perform HTTP fallback to 52732
java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is: 
	java.net.ConnectException: Connection refused
	at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
	at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
	at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
	at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
	at sun.rmi.registry.RegistryImpl_Stub.list(Unknown Source)
	at EagerHttpFallback.main(EagerHttpFallback.java:59)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:474)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.net.ConnectException: Connection refused
	at sun.rmi.transport.proxy.RMIMasterSocketFactory.checkConnector(RMIMasterSocketFactory.java:320)
	at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:266)
	at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
	... 11 more
Comments
RMI Http Proxy support has been removed as well as this test
26-04-2016
When Http proxy support is removed, this issue can be closed.
26-04-2016
This test is on the problem list for jdk8 and jdk7u-dev (open) and so should not be run. The CPU repos have an out-of-date jdk/test/ProblemList.txt file.
22-02-2013
Turns out there's not much OS-specific about this; it's more about how the hostname resolves. This can easily be demonstrated by modifying the /etc/hosts file. If the hostname (uname -n?) resolves to a non-loopback address, the test passes. If it resolves to a loopback address, either 127.0.1.1 or 127.0.0.1, the test will fail.
29-11-2012
Alan wrote the following: ---------- I just checked t4.ie.oracle.com and the hosts file is: ::1 t4 localhost 127.0.0.1 t4 localhost loghost 10.169.104.113 hs-dublin-1 hs-dublin-1.ireland I suspect if I change this so that the hostname maps to its real address rather than the loopback will fix this. ---------- I believe that t4.ie.oracle.com is a Solaris machine. This kind of "misconfiguration" has occurred on other machines as well, such as those in Aurora (which is used for the nightlies). It would probably be better to make this test robust against this kind of configuration instead of having it fail every time it encounters a machine that's configured this way.
29-11-2012
This has occurred a couple times in the TL nightly job, and alanb has run across it. These failures are all on Solaris. (It's been excluded from Linux for some time.) This is an intermittent failure. It's not clear whether the problem on Solaris is the same as on Linux or whether there are two separate problems. The error message and stack trace are the same though. Perhaps this should be excluded from all platforms, not just Linux.
27-11-2012
EVALUATION Speculation: I think the systems that see failures are Ubuntu systems, and localhost is 127.0.1.1 which is different from the more typical 127.0.0.1. The test includes the line System.setProperty("http.proxyHost", "127.0.0.1"); That might have something to do with the problem.
30-08-2012