Hi,
Attached is a trivial patch which fixes a typo in the javadoc of
java.net.http.HttpClient class.
I've a signed and approved OCA, but will need a sponsor for this patch.
-Jaikiran
# HG changeset patch
# User Jaikiran Pai
# Date 1527920758 -19800
# Sat Jun 02 11:55:58 2018 +0530
# No
Hello,
I've been experimenting with the new HttpClient API that's part of Java
now. I am using the latest EA build 16 of Java 11 from here[1]. I'm
still in the early stages of integrating this into one of the libraries
where we use HTTP clients.
Based on my usage so far, I have some minor
f
> On 1. Jun 2018, at 17:40, Chris Hegarty wrote:
>
> Norman,
>
> On 01/06/18 16:33, Norman Maurer wrote:
>> ...
>> Sure thing (its exactly the same code as in the pr):
>
> Thank you. I just want to run some tests and verify any
> potential changes to satisfy myself, so I will be in a
> bette
Norman,
On 01/06/18 16:33, Norman Maurer wrote:
...
Sure thing (its exactly the same code as in the pr):
Thank you. I just want to run some tests and verify any
potential changes to satisfy myself, so I will be in a
better position to review the code once Alan posts a
review request.
-Chris
Hi Chris,
> On 1. Jun 2018, at 17:28, Chris Hegarty wrote:
>
> Hi Norman,
>
> On 30/05/18 09:16, Norman Maurer wrote:
>> ...
>> I added a reproducer which not uses any netty classes to the PR that for now
>> ignores test-failures caused by this when running on Java11+:
>> https://github.com/
Hi Norman,
On 30/05/18 09:16, Norman Maurer wrote:
...
I added a reproducer which not uses any netty classes to the PR that for
now ignores test-failures caused by this when running on Java11+:
https://github.com/netty/netty/pull/7984#issuecomment-393071386
Would it be possible for you to p
> On 1. Jun 2018, at 14:50, Alan Bateman wrote:
>
>
>
> On 01/06/2018 13:19, Florian Weimer wrote:
>>
>> But there is a race, even on Linux. If the network is fast enough and you
>> get an RST segment from the other end, kernel the receive buffer is
>> discarded.
> Right although it can
On 01/06/2018 13:19, Florian Weimer wrote:
But there is a race, even on Linux. If the network is fast enough and
you get an RST segment from the other end, kernel the receive buffer
is discarded.
Right although it can be a bit more predictable with loopback connections.
So whatever you
> On 1. Jun 2018, at 14:13, Alan Bateman wrote:
>
> On 01/06/2018 10:21, Florian Weimer wrote:
>> On 05/29/2018 04:26 PM, Norman Maurer wrote:
>>> Yes thats what I am saying… I think if a write fails due a connection-reset
>>> a read should still be possible until we are told by the OS that w
On 06/01/2018 02:13 PM, Alan Bateman wrote:
I can't say for sure whether the kernels actually drop the socket buffer
or not. For the scenario, the connection reset is reported when writing
and on both Linux and macOS you can read the previously received bytes
in the socket buffer.
But there i
On 01/06/2018 10:21, Florian Weimer wrote:
On 05/29/2018 04:26 PM, Norman Maurer wrote:
Yes thats what I am saying… I think if a write fails due a
connection-reset a read should still be possible until we are told by
the OS that we also hit an error here.
Are there implementations where the k
On 05/29/2018 04:26 PM, Norman Maurer wrote:
Yes thats what I am saying… I think if a write fails due a connection-reset a
read should still be possible until we are told by the OS that we also hit an
error here.
Are there implementations where the kernel does *not* zap the read
buffer when
12 matches
Mail list logo
