Hi Daniel,
> Right - here is a better implementation anyway:
> http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.02/
>
Looks much better. Thanks a lot!
Best regards,
Andrej Golovnin
On 18/01/2019 14:24, Daniel Fuchs wrote:
Hi Andrej,
On 18/01/2019 14:03, Andrej Golovnin wrote:
Is creating new Optionals a real problem? And before you answer please
remember what Donald Knuth said: The real problem is that programmers
have spent far too much time worrying about efficiency in
Hi Andrej,
On 18/01/2019 14:03, Andrej Golovnin wrote:
Is creating new Optionals a real problem? And before you answer please
remember what Donald Knuth said: The real problem is that programmers
have spent far too much time worrying about efficiency in the wrong
places and at the wrong times;
Hi Daniel,
Yes that looks like my first implementation. But then
> I reflected that avoiding to map Optional to Duration
> and then back to a new Optional containing the same
> duration could be avoided by simply storing the original
> optional obtained from the HttpClient.
>
> The current code on
Hi Andrej,
Yes that looks like my first implementation. But then
I reflected that avoiding to map Optional to Duration
and then back to a new Optional containing the same
duration could be avoided by simply storing the original
optional obtained from the HttpClient.
The current code only creates
Hi Daniel,
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.01/
>
>
>
126 private static class ConnectTimeoutTracker {
127 final Optional max;
128 final AtomicLong startTime = new AtomicLong();
129 ConnectTimeoutTracker(Optional connectTimeout) {
Hi,
Please find below a small fix for:
8216561: HttpClient: The logic of retry on connect exception is inverted
https://bugs.openjdk.java.net/browse/JDK-8216561
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.01/
The patch now allows retry on connect exception, ensuring
that t
