Integrated: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov wrote: > 8258422: Cleanup unnecessary null comparison before instanceof check in > java.base This pull request has now been integrated. Changeset: 022bc9f0 Author:Andrey Turbanov Committer: Aleksei Efimov URL: https://git.openjdk.ja

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

On Mon, 11 Jan 2021 23:29:53 GMT, Aleksei Efimov wrote: >> @AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think >> it's better to not touch it under this PR. > > To double check that docs build will be stable after integration the > following actions have been performed: > -

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

On Mon, 11 Jan 2021 17:12:24 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, >> This PR is ready for integration - `JDK-8258657` has been resolved. >> You can proceed with issuing `integrate` bot command. Then I will `sponsor` >> it. >> But before that, I would like to ask if you would like to ta

Re: How to reuse TCP connection when using a proxy with java.net.http.HttpClient in HTTP/1.1

The client could drain if yo close the stream,but I think it’s more flexible If the Application decides if it want to do that (it could be a config option but I guess it’s uncommon that you stop reading and. It want to discard data. Gruss Bernd -- http://bernd.eckenfels.net ___

Re: How to reuse TCP connection when using a proxy with java.net.http.HttpClient in HTTP/1.1

Hi, On Mon, Jan 11, 2021 at 10:13 PM Nicolas Henneaux wrote: > > Thanks Simone, that makes sense. I haven't thought there is actually no other > way for the server to know the response is fully consumed or not. Just to be clear, it's not a server problem. The server won't read the next request

Re: How to reuse TCP connection when using a proxy with java.net.http.HttpClient in HTTP/1.1

Thanks Simone, that makes sense. I haven't thought there is actually no other way for the server to know the response is fully consumed or not. Thanks all! Nicolas On Mon, 11 Jan 2021 at 22:08, Simone Bordet wrote: > Hi, > > On Mon, Jan 11, 2021 at 9:28 PM Nicolas Henneaux > wrote: > > > > Hi

Re: How to reuse TCP connection when using a proxy with java.net.http.HttpClient in HTTP/1.1

Hi, On Mon, Jan 11, 2021 at 9:28 PM Nicolas Henneaux wrote: > > Hi Daniel, > > Thanks for your quick feedback. > > Indeed if I fetch all the bytes, the connection is kept. What's the reason > behind this behaviour? It's normal behavior. The server may have not finished to send all the bytes in

Re: How to reuse TCP connection when using a proxy with java.net.http.HttpClient in HTTP/1.1

Hi Daniel, Thanks for your quick feedback. Indeed if I fetch all the bytes, the connection is kept. What's the reason behind this behaviour? Best regards, Nicolas On Mon, 11 Jan 2021 at 21:00, Daniel Fuchs wrote: > Hi Nicolas, > > If I understand correctly you are closing the input stream wi

Re: How to reuse TCP connection when using a proxy with java.net.http.HttpClient in HTTP/1.1

Hi Nicolas, If I understand correctly you are closing the input stream without draining the bytes. With HTTP/1.1 this will force the connection to get closed. This is the expected behavior. best regards, -- daniel On 11/01/2021 20:29, Nicolas Henneaux wrote: Hi, I have a problem when using J

How to reuse TCP connection when using a proxy with java.net.http.HttpClient in HTTP/1.1

Hi, I have a problem when using Java HttpClient with a proxy and HTTP/1.1 version. When using a stream body handler, there is no re-use of the TCP connection. When using another body handler (java.net.http.HttpResponse.BodyHandlers#ofString() or java.net.http.HttpResponse.BodyHandlers#discarding)

Withdrawn: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions

On Mon, 11 Jan 2021 17:24:23 GMT, Volker Simonis wrote: > JDK-8237578 exposes some SocketExceptions directly which were previously > wrapped inside an SSLException. The change updated one test to take this new > behaviour into account (i.e. TrustTrustedCert.java) but apparently missed > other

RFR: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions

JDK-8237578 exposes some SocketExceptions directly which were previously wrapped inside an SSLException. The change updated one test to take this new behaviour into account (i.e. TrustTrustedCert.java) but apparently missed other tests. The fix for the other tests is similar like the fix for Tr

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

On Mon, 11 Jan 2021 16:57:00 GMT, Aleksei Efimov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in >> java.base > > Hi @turbanoff, > This PR is ready for integration - `JDK-8258657` has been resolved. > You can proceed with issuing `integrate` bot command. Then I

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov wrote: > 8258422: Cleanup unnecessary null comparison before instanceof check in > java.base Hi @turbanoff, This PR is ready for integration - `JDK-8258657` has been resolved. You can proceed with issuing `integrate` bot command. Then I will `sp

Re: RFR: JDK-8243376: java.net.SocketPermission.implies(Permission p) spec is mismatching with implementation [v2]

On Wed, 6 Jan 2021 04:34:12 GMT, Jayashree S Kumar wrote: >> Issue >> >> https://bugs.openjdk.java.net/browse/JDK-8243376 >> >> Problem >> >> The scenario is: >> - Some specified target hostname resolves to two IP addresses (always the >> same address pair). >> - The DNS resolved order of