jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java

[Dmitry Samersoff]

Jaroslav,

Behevior of mulitple loopback is not specified clearly[1] and is up to
OS developers or more precise - kernel setup.

Common practice is to assign 127.*.*.* to interfaces like tun, to be
able to use some socket-related calls ever if it is not connected to peer.

Other common situation - multiple loopback interfaces on host computer
to support virtual instances.

So on my opinion, it's better to be pessimistic and don't assume that
different loopback addresses are able to talk with each other.


[1]
http://tools.ietf.org/html/rfc3330


127.0.0.0/8 - This block is assigned for use as the Internet host
   loopback address.  A datagram sent by a higher level protocol to an
   address anywhere within this block should loop back inside the host.
   This is ordinarily implemented using only 127.0.0.1/32 for loopback,
   but no addresses within this block should ever appear on any network
   anywhere.

-Dmitry


On 2013-10-03 19:02, Jaroslav Bachorik wrote:
> On 2.10.2013 16:11, Dmitry Samersoff wrote:
>> Jaroslav,
>>
>> As a far as loopback address could be resolved to any of 127.0.0.0/8
>> client and server have to use the same loopback address.
> 
> AFAIK, all the IPs 127.*.*.* equally designate the loopback interface.
> This might start breaking when you have more than one loopback interface
> in the system.
> But all of this might be irrelevant here - the IPs are retrieved *after*
> the JMX connection has been established making it clear that they are
> reachable.
> 
>>
>> Generally speaking it's not required for 127.0.1.1 to be able to talk to
>> 127.0.0.1 and we are in risk to get a weird fail instead of clear error
>> message.
> 
> As I said before as long as there is only one loopback interface it is
> safe to assume that all the loopback IPs are virtually identical. When
> we start considering multiple loopback interfaces we would need to take
> into account the also the assigned network interfaces.
> 
> But it might hardly matter - it seems that the main culprit for this
> test to fail on this particular configuration was the fact that
> 127.0.0.1 was *NOT* detected as a loopback IP. This is pretty weird and
> makes one question the sanity of the test setup...
> 
> -JB-
> 
>>
>> -Dmitry
>>
>>
>> On 2013-09-11 18:51, Jaroslav Bachorik wrote:
>>> Please, review this simple patch for an intermittently failing test.
>>>
>>> The test fails in cases when the connection loopback is resolved to be
>>> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The
>>> test does not anticipate this possibility and requires the loopback
>>> address to be exactly 127.0.0.1
>>>
>>> The test will end comparing 127.0.0.1 against 127.0.1.1 and will
>>> consider them non equal even though they are both the same loopback. The
>>> patch adds a bit of flexibility to the test allowing for any two valid
>>> loopback addresses (127.0.0.0/8) to be equal.
>>>
>>> Issue  : JDK-8022220
>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00
>>>
>>> Thanks,
>>>
>>> -JB-
>>>
>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.