On Mon, 12 Dec 2022 14:50:21 GMT, Daniel Fuchs <[email protected]> wrote:
> The test has been observed failing once in the CI, on windows, with a
> BindException (address already in use) on the client side. This usually means
> that the system has run out of ephemeral ports or file descriptors. The
> proposed fix will catch the BindException, run the gc, wait a bit, and retry
> once. No guarantee that this will actually work - but maybe worth a try,
> though I worry a bit the authentication count might get wrong if the request
> that gets the BindException is the first one that follows the 401/407
> response - in case the connection was closed after receiving 401/407. Since
> we have no visibility of which call to connect() fails, it is hard to cater
> for this possibility without making the test too permissive.
>
> The alternative would be to throw a SkipException in case BindException is
> received.
>
> While working on the fix I noticed that some parts of the test had been
> commented out waiting for a RFE to be implemented. Since the RFE has been
> implemented since then, I went out and uncommented that part of the test.
>
> Comments welcome.
test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTestClient.java line
53:
> 51: try {
> 52: Thread.sleep(500);
> 53: } catch (InterruptedException iex) {
If it only fails rarely, would it be safer to delay a few seconds to allow more
time for resources to be freed?
-------------
PR: https://git.openjdk.org/jdk/pull/11634
