RFR [11] 8205671: Remove HTTP Client tests erroneously problem listed by the TLS 1.3 integration

Seems that the integration of TLS 1.3 erroneously added a number of HTTP Client tests to the ProblemList. Previous to the TLS 1.3 push, work was done to ensure that the HTTP Client tests ran successfully with the changes in the TLS 1.3 branch. These tests should not have been problem listed. di

Re: RFR [11] 8205671: Remove HTTP Client tests erroneously problem listed by the TLS 1.3 integration

Looks good to me Chris. best, -- daniel On 26/06/2018 11:45, Chris Hegarty wrote: Seems that the integration of TLS 1.3 erroneously added a number of HTTP Client tests to the ProblemList. Previous to the TLS 1.3 push, work was done to ensure that the HTTP Client tests ran successfully with th

Re: RFR [11] 8205671: Remove HTTP Client tests erroneously problem listed by the TLS 1.3 integration

Looks good Chris. - Michael. On 26/06/2018, 11:45, Chris Hegarty wrote: Seems that the integration of TLS 1.3 erroneously added a number of HTTP Client tests to the ProblemList. Previous to the TLS 1.3 push, work was done to ensure that the HTTP Client tests ran successfully with the changes

New HttpClient PUT request fails oddly - is it size is it number of invocations!

In my random experimentation with the new HttpClient API usage, I have ended up running into an odd and hard to decipher exception when dealing with PUT requests. I am noticing that if I issue multiple PUT requests using the same HttpClient instance, the first 2 invocations succeed while the 3r

Re: New HttpClient PUT request fails oddly - is it size is it number of invocations!

So it looks like there some race condition somewhere in the HttpClient implementation. I just addeda smalldelay between the PUT requests, in the test that I sent in the patch and it's now started passing: diff -r 955a66f0f04a test/jdk/java/net/httpclient/PUTRequestSizeTest.java --- a/test/jdk/j

Re: New HttpClient PUT request fails oddly - is it size is it number of invocations!

Hi Jaikiran, I filed the following JIRA issue to track this: https://bugs.openjdk.java.net/browse/JDK-8205684 Thanks for the test and initial investigation. We’ll look into it. -Chris. > On 26 Jun 2018, at 14:52, Jaikiran Pai wrote: > > So

Re: New HttpClient PUT request fails oddly - is it size is it number of invocations!

Thanks Chris! -Jaikiran On 26/06/18 7:34 PM, Chris Hegarty wrote: Hi Jaikiran, I filed the following JIRA issue to track this: https://bugs.openjdk.java.net/browse/JDK-8205684 Thanks for the test and initial investigation. We’ll look into it. -Chris. On 26 Jun 2018, at 14:52, Jaikiran Pai

Re: New HttpClient PUT request fails oddly - is it size is it number of invocations!

Hi Jaikiran, I believe you need to drain the request body in the server before sending the response. If you pass -ea -esa options to jtreg, you should see the following assertion printed by the server: java.lang.AssertionError: State is not RESPONSE (REQUEST) at jdk.httpserver/sun.net.http

Re: New HttpClient PUT request fails oddly - is it size is it number of invocations!

Hi Daniel, You are right- I just added: diff -r 955a66f0f04a test/jdk/java/net/httpclient/PUTRequestSizeTest.java --- a/test/jdk/java/net/httpclient/PUTRequestSizeTest.java  Tue Jun 26 18:33:18 2018 +0530 +++ b/test/jdk/java/net/httpclient/PUTRequestSizeTest.java  Tue Jun 26 20:05:20 2

Re: New HttpClient PUT request fails oddly - is it size is it number of invocations!

Hi Jaikiran, On 26/06/2018 15:41, Jaikiran Pai wrote: So is this a case of the server implementation misbehaving? I haven't checked what the expectations are from a spec point of view for handling such requests on the server. Or is it a combination of a misbehaving server plus the HttpClient i

Re: New HttpClient PUT request fails oddly - is it size is it number of invocations!

Hi Daniel, On 26/06/18 8:26 PM, Daniel Fuchs wrote: Hi Jaikiran, On 26/06/2018 15:41, Jaikiran Pai wrote: So is this a case of the server implementation misbehaving? I haven't checked what the expectations are from a spec point of view for handling such requests on the server. Or is it a comb