tree 39f6b6f86fe16b20a18d0be0b2fb756b8e5a7a55
parent 661103595e90529a2a3fc0af3648331f02b1af30
author Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com> 1534846674 +0200
committer Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com> 1534846674 +0200

Add delay in test to avoid race condition

We previously observed random-looking failures from this test. I think they
were caused by a race condition where the client tries to reconnect while the
server is still closing the connection and has not yet returned to an
accepting state. In that case, the server would fail to see and reply to the
ClientHello, and the client would have to resend it.

I believe logs of failing runs are compatible with this interpretation:
- the proxy logs show the new ClientHello and the server's closing Alert are
  sent the same millisecond.
- the client logs show the server's closing Alert is received after the new
  handshake has been started (discarding message from wrong epoch).

The attempted fix is for the client to wait a bit before reconnecting, which
should vastly enhance the probability of the server reaching its accepting
state before the client tries to reconnect. The value of 1 second is arbitrary
but should be more than enough even on loaded machines.

The test was run locally 100 times in a row on a slightly loaded machine (an
instance of all.sh running in parallel) without any failure after this fix.