Hi Alan, Daniel a couple of observations on the assertion for test failure that you may wish to consider. If there is a BindException for the DatagramSocket instantiations then this would suggest that there is an operating system issue. The sockets are being bound to an ephemeral port, allocated by the OS, which would mean that the OS is choosing a port that it has already allocated ! It may be worth checking that the ephemeral port range in the test environments are appropriately configured, as per IANA recommendations. One potential extreme condition is that IFF there are many thousands of concurrent tests executing, there could be ephemeral port exhaustion ? Another observation is that this is a UDP test, as such, it is unreliable in its outcome. That is to say, UDP sends are not guaranteed to be successful. This could be especially true in a very heavily loaded system, which may have some resource contention, such as available UDP buffer space. As such, there is no guarantee that any send will succeed. It may be an extreme exaggeration, but the OS may accept a message to send, copy from user space to kernel space, but because of some extreme exceptional conditions in the kernel, drops the message without notification. Another point to keep in mind is that the test is multi threaded, and again in heavily loaded system the scheduling of a thread may not be as prompt as expected ?
best regards Mark ________________________________ From: net-dev <net-dev-boun...@openjdk.java.net> on behalf of Daniel Fuchs <daniel.fu...@oracle.com> Sent: Friday 23 August 2019 09:42 To: Alan Bateman <alan.bate...@oracle.com>; Patrick Concannon <patrick.concan...@oracle.com>; OpenJDK Network Dev list <net-dev@openjdk.java.net> Subject: Re: RFR [8193596]: java/net/DatagramPacket/ReuseBuf.java failed due to timeout Hi Alan, On 23/08/2019 10:25, Alan Bateman wrote: > On 23/08/2019 10:10, Patrick Concannon wrote: >> Hi, >> >> Would it be possible to have my fix for JDK-8193596 reviewed? >> >> The test fails intermittently due to binding to wildcard addresses -- >> similar to those that have been fixed under the umbrella of >> JDK-8222938 <https://bugs.openjdk.java.net/browse/JDK-8222938>. This >> fix changes the binding from using a wildcard address to localhost. >> > It's hard to see from the bug report if this interference due to binding > to the wildcard address but the change looks okay to me. Yes I agree - but it fails again then at least that's one thing we won't have to put in question :-) best regards, -- daniel
