java.net.http.HttpClient: invalid exception when bad status line is returned

Hello, I am tasting java.net.http.HttpClient with openjdk version "11.0.1" 2018-10-16 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.1+13) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.1+13, mixed mode) on Mac OS X 10.14.2. Consider the case when server responds with bad (invalid

Re: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted

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

Re: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted

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

Re: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted

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

Re: RFR: 8207404: MulticastSocket tests failing on AIX

On 18/01/2019 08:54, Langer, Christoph wrote: Hi, here is the updated webrev with modifications to the problem list and reverting the static imports: _http://cr.openjdk.java.net/~clanger/webrevs/8207404.1/__ I think this is ok. -Chris.

Re: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted

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

Re: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted

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

RE: RFR: 8207404: MulticastSocket tests failing on AIX

Hi Christoph, Had a look at the latest webrev and everything looks OK to me. Have also re-tested on my AIX systems and all tests oass OK. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus

Re: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted

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)

[13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted

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

RE: RFR: 8207404: MulticastSocket tests failing on AIX

Hi, here is the updated webrev with modifications to the problem list and reverting the static imports: http://cr.openjdk.java.net/~clanger/webrevs/8207404.1/ It went fine through our test system so I think it's good now. Please review. Thanks Christoph From: Chris Hegarty Sent: Donnerstag,