8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

[Alan Bateman]

On 02/04/2020 09:48, Daniel Fuchs wrote:
> :
>
>> DefaultInterface might be better in a test infra class (in java/net) 
>> to avoid duplicate it in several tests.
>
> I have considered that. The problem is that it requires the test that
> uses it to add @modules java.base/java.net:+open directive in the test
> itself. At the moment only one test uses it - so there is no
> duplication (yet). Maybe we should wait until we need it elsewhere
> before thinking of ways to move it to the test library?
Okay, I was assuming it would end up being used by several 
MulticastSocket tests.

> :
>
> When I ran this test it was failing in timeout with *no* traces.
> I hate that. I added traces to figure out at which point it was
> failing. There might be a bit of duplication in the information,
> but I'd rather have that than wonder if the test is actually
> doing what I think it does. When unexplainable things happen,
> I start doubting everything ;-)
>
> If you insist I'll reluctantly remove the redundant information,
> but I do think it helps.
All I'm asking is that additional tracing being consistent with the 
existing traces. Stack traces and thread dumps the most useful when 
there is a timeout or test timeout. I wonder if there is an  issue with 
the timeout/failure handler right now so you should have got one here in 
the event that the receive blocks indefinitely.

-Alan