RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java
Daniel Jeliński
djelinski at openjdk.org
Fri Sep 5 09:23:11 UTC 2025
On Thu, 4 Sep 2025 12:52:31 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:
> The test javax/net/ssl/DTLS/PacketLossRetransmission takes about 2 minutes to complete. The reason is that the server or client socket times out after 10 seconds while waiting to receive a DatagramPacket that has already been removed (to simulate packet loss). Given that it will time out, it is better to reduce its value.
> After reducing the timeout , the total test execution completes in approximately 20 seconds on average.
> Additionally, unnecessary scenarios are removed; for instance, when acting as a client, there is no "server_hello" message type to remove, and similarly, when acting as a server, there is no "client_hello" message on that side, so there is no corresponding packet loss to simulate.
LGTM.
The removal of useless test cases isn't strictly necessary. The test cases that don't lose any messages usually complete under a second. If you really want to remove all useless cases, add an assertion that needPacketLoss is false at the end of the test.
If you want to improve the run time even further, this test doesn't really need to use a DatagramSocket. With some effort it could be rewritten to exchange ByteBuffers directly between the SSLEngines, similar to what is done in [`test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java`](https://github.com/openjdk/jdk/blob/9c06dcb4396c3307d625663d92c0e11d794a56ea/test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java). Then you wouldn't need to wait for the timeout to expire, and instead you could retransmit the packets immediately after dropping them, or after making sure that the peer doesn't act.
-------------
Marked as reviewed by djelinski (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/27093#pullrequestreview-3188619440
More information about the security-dev
mailing list