(teststabilization) RFR: 8231506: Fix some instabilities in a few networking tests
mark sheppard
macanaoire at hotmail.com
Mon Sep 30 07:58:33 UTC 2019
Hi Daniel,
a couple of observations and few points to consider in the UnreferencedMulticastSockets
test.
similar to the DatagramSocket version but for this one MulticastSocket will automatically set
the so_reuseaddr option. This has implications when the second MulticastSocket is created.
Unlike the DatagramSocket socket version this test will use the same client address for both
MulticastSocket created. Thus there is a stronger dependency between the try with resourses
statement and the code that creates the second MulticastSocket for the send and receive.
So does the second MulticastSocket need to use the same client unicast address ?
There doesn't seem to be any multicast semantics in the test, other than creating a MukticastSocket,
which is_a DatagramSocket.
Can it be assured that there is no asynchrony in the synthesized code for the autoclose in the try with
resources, both at the java level and within the OS kernel executing the close?
Would an explicit close of the first MulticastSocket add better determinacy to the test execution?
It could happen in a heavily loaded system, that if the close is asynchronous (Windows ?) that when the
server has echo back the datagram there are still two extant sockets in the OS kernel and which socket receives
the packet is indeterminate - this is not a multicast send and receive but a unicast send and receive.
This could lead to intermittent client receive requests hanging (?)
Note also that the client socket "connect" to the server address, meaning that it sends and receive
datagrams from that peer address only.
In the DatagramSocket version, a level of synchronization between the server thread and
the main thread was added, would that be appropriate here again?
best regards
Mark
________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Thursday 26 September 2019 14:16
To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: (teststabilization) RFR: 8231506: Fix some instabilities in a few networking tests
Hi,
Please find below a patch for:
https://bugs.openjdk.java.net/browse/JDK-8231506
8231506: Fix some instabilities in a few networking tests
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8231506/webrev.00/
There's one remaining test that still uses the wildcard
(SocketImplCombinations). It has been observed failing in the past,
and hopefully this change will fix it.
The UnreferencedMulticastSockets, which has also been observed
failing is also be updated with some more diagnosis.
Finally, the DigestEchoServer$TunnelingProxy class has also been
observed causing some instabilities in the httpclient tests that use it:
the proxy tunnel doesn't properly propagate errors from downstream to
upstream, and conversely, which sometimes leaves the reader waiting for
data that will never come. This change should fix that.
best regards,
-- daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190930/c05b4518/attachment.html>
More information about the net-dev
mailing list