RFR: 8219804 ava/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException

[Michael McMahon]

Hi Chris,

On 21/06/2019, 12:32, Chris Hegarty wrote:
> Michael,
>
> On 21/06/2019 11:53, Michael McMahon wrote:
>> Small test case update. The test has failed a couple of times where 
>> it appears
>> to be receiving input on a multicast socket which could not be 
>> generated by the test case itself.
>> The test happens to use multicast groups that are assigned by IANA, 
>> and globally routable.
>> So, it is conceivable that other entities are sending packets picked 
>> up by the test.
>> The test also does not protect against other instances of itself 
>> running on different hosts
>> at the same time, though that doesn't seem to be the cause of this 
>> failure.
>> The change is to use non-routable multicast groups and to add some 
>> hopefully unique data
>> to the test in case the test might be running on multiple hosts on 
>> the same subnet simultaneously.
>>
>> http://cr.openjdk.java.net/~michaelm/8219804/webrev.1/index.html
>
> I think this is ok.
>
> With this change, the negative scenarios ( that are expected to
> timeout ), are susceptible to retrying when/if rogue packets are
> received ( I guess this is less likely now, since the groups are
> non-routable ). Would it be helpful to just print out the ignored
> packet / data ( in case of future reliability issues )?
>
Yeah, I'll add some logging for that eventuality.

> There is a nio test, java/nio/channels/DatagramChannel/Promiscuous.java
> that follows a similar pattern. Should it be updated in a similar way?
>
I notice that test uses a "reserved" multicast address, which applications
are not supposed to use. Maybe, routers won't forward those packets either.
I think I'd prefer to leave that test as it is, for now, especially 
seeing as it
hasn't failed.

Updated at:
http://cr.openjdk.java.net/~michaelm/8219804/webrev.2/

Thanks,
Michael.