I'm not sure its worth the time, but on failure, a combination of
netstat and lsof
could identify the consumers of the sockets.
Roger
On 11/29/19 2:49 AM, Alan Bateman wrote:
On 22/11/2019 16:35, Chris Hegarty wrote:
:
QuickAckTest only creates one DatagramSocket and one MulticastSocket, so
just consumes two UDP socket resources. Prior tests run in the same VM
must be consuming the majority of UDP socket resources ( and not
releasing them), then this test just happens to be the unlucky one that
hits the limit, right? So we may end up playing whack-a-mole on these
tests for a while, as needed. Maybe all tests creating UDP sockets
should be run in othervm? But that might be a bit unnecessary.
From a quick check, there aren't a huge number of tests using these
APIs so it might be possible to identify a few suspects. There are at
least some tests that don't close when they fail so maybe there is a
cascading impact. Another point is that some of the groups for tired
testing may be running the jdk_net and jdk_nio tests in the same run,
we might not see this with jdk_net runs.
-Alan
