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

Mon Jun 24 10:31:04 UTC 2019

Hi Mark

On 23/06/2019, 13:53, mark sheppard wrote:
>
> Hi Michael, Chris,
>     a brief note on the possibility of stray packets.
>
> For the test to receive data from external sources it would be 
> necessary that the senders are
> using the same port ( as well as the mcast address) as your test 
> (which is an ephemeral port).
> So the source of such stray data could be concurrently executing 
> instances of the tests
> on other test machines when each test's ephemeral port coincidentally 
> match !!
> 
That's correct. The sender needs to send to the same port, and the port 
is essentially random,
though the range is far from unlimited, and the test has only failed a 
couple of times
in many thousands of runs.

> However, the fact that you are repairing a NumberformatException would 
> indicate that the source
> was not another instance of this test, as the test would receive a 
> string representation of an integer.
> However,  Chris alludes to 
> /test/java/nio/channels/DatagramChannel/Promiscuous, and
> this uses the same mcast address (pre your changes) as this test and 
> its integer data would not be interpretable by this test, afaik.

Right, I did say the cause was not likely the same test, because the 
test is reading 100 zero bytes.
I just added that protection as an additional measure.

> 
> So it is the source of possible conflict and a NumberFormatException. 
> -- depending on the same ephemeral port allocation taking place.
> 
> Should the test check that multicast is enabled on the test host?

Doesn't seem to be necessary as the test is receiving something.
> 
> the sender's address could always be output in the receive method ?
> 
> as a side issue:
> Noting the idioms used in the test binding to wildcard address for the 
> receiving socket
> so the test is open to receiving data on any address associated with 
> the test host, that is 
> destined to the ephemeral port allocated. The ephemeral port limits 
> receipt of stay data but
> doesn't eliminates it. The alternative is to bind to mcast address.
> 
> Sender Datagram socket is unbound, so will send on the default 
> interface (?)
> 
> What's the expectation when the test executes in multihomed environment?
> 
> This has been a problem for tests in the past (in my limited 
> experience), especially the
> sending over the correct interface.
> 
> Is the assumption that if the test host is multihomed, then the 
> appropriate OS
> configuration for sending/receiving on the multicast exists, such that 
> the send will
> go over an interface configured for your chosen mcast address?
> That is to say, the sender will send on the appropriate interface
> for the specified multicast address in a multihomed scenario.
> It's assumed the default interface is multicast enabled
>  and that interface has a route specified.
> 
Since the socket is receiving something unexpected, I think I agree that 
binding
to the multicast address could be worth doing as well. That would filter out
packets that perhaps broadcast or just sent directly to the bound port, 
independent
of the multicast group. I will try out that suggestion and if it works okay,
I'll include it in the change.

Thanks
Michael
> 
> maybe a few things to consider.
> 
> regards
> Mark
>
> ------------------------------------------------------------------------
> *From:* net-dev <net-dev-bounces at openjdk.java.net> on behalf of 
> Michael McMahon <michael.x.mcmahon at oracle.com>
> *Sent:* Friday 21 June 2019 16:27
> *To:* Chris Hegarty
> *Cc:* OpenJDK Network Dev list
> *Subject:* Re: RFR: 8219804 ava/net/MulticastSocket/Promiscuous.java 
> fails intermittently due to NumberFormatException
> 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 
> <http://cr.openjdk.java.net/%7Emichaelm/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/ 
> <http://cr.openjdk.java.net/%7Emichaelm/8219804/webrev.2/>
>
> Thanks,
> Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190624/c6a7fa81/attachment-0001.html>