On Tue, 13 Dec 2022 13:50:30 GMT, Michael McMahon <[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? Otherwise, the change looks fine to me.
Good point. What delay would you recommend?
-------------
PR: https://git.openjdk.org/jdk/pull/11634
