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: 2016-05-25
  • Resolved: 2016-04-26
Related Reports
Relates :  
Relates :  
Relates :  

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:; 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

RMI Http Proxy support has been removed as well as this test

When Http proxy support is removed, this issue can be closed.

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.

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 or, the test will fail.

Alan wrote the following: ---------- I just checked t4.ie.oracle.com and the hosts file is: ::1 t4 localhost t4 localhost loghost 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.

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.

EVALUATION Speculation: I think the systems that see failures are Ubuntu systems, and localhost is which is different from the more typical The test includes the line System.setProperty("http.proxyHost", ""); That might have something to do with the problem.