We’ve almost come to agreement on this ( at least as much as is possible
without further prototyping ). The point where we reached, which I think is
a good solution, leaves connect timeout and response timeout as
orthogonal mechanisms. I would like to separate the issues.
1) 8208391 [1] will be
Hi,
On Thu, Aug 2, 2018 at 10:44 AM Michael McMahon
wrote:
> On 31/07/2018, 22:07, Simone Bordet wrote:
> ..
> > Finally, I would consider TLS handshake time as part of the request
> > data: the cost will be paid by the first request and capped by "total"
> > timeout (not connectTimeout). With
On 31/07/2018, 22:07, Simone Bordet wrote:
..
Finally, I would consider TLS handshake time as part of the request
data: the cost will be paid by the first request and capped by "total"
timeout (not connectTimeout). With TLS 1.3 optimizations, it may be
just few TLS bytes before the
Simone,
> On 1 Aug 2018, at 20:20, Simone Bordet wrote:
>
> Hi,
>
> On Wed, Aug 1, 2018 at 5:10 PM Chris Hegarty wrote:
>> Before trying to draft the javadoc, the semantic we want for this
>> overall timeout is that it should approximately related to the observed
>> time spent in send[Async].
Hi,
On Wed, Aug 1, 2018 at 5:10 PM Chris Hegarty wrote:
> Before trying to draft the javadoc, the semantic we want for this
> overall timeout is that it should approximately related to the observed
> time spent in send[Async].
I'm not sure I agree, especially for sendAsync(), which should setup
Hi,
On Wed, Aug 1, 2018 at 5:01 PM Michael McMahon
wrote:
> I can understand that a server might respond early with an error code
> like 500 before the client has finished sending a very large request body,
> but I don't see how a server would likely respond early with 200.
> Surely, the server
Simone,
Thanks for you prompt and detailed reply. Comments inline.
> On 31 Jul 2018, at 22:07, Simone Bordet wrote:
>
> ...
> I would argue that you would put this method in HttpClient and so it
> is HttpClient that needs to be configured with the connectTimeout.
Good suggestion. I agree, and
Simone,
Just to clarify a couple of points below:
On 31/07/2018, 22:07, Simone Bordet wrote:
Hi,
On Tue, Jul 31, 2018 at 9:58 PM Chris Hegarty wrote:
It is unfortunate that this has come up so late the JDK 11 lifecycle,
but since this has API impact, and is the right thing to do, it is
Hi,
On Tue, Jul 31, 2018 at 9:58 PM Chris Hegarty wrote:
>
> It is unfortunate that this has come up so late the JDK 11 lifecycle,
> but since this has API impact, and is the right thing to do, it is
> certainly worth addressing now ( rather than waiting to do something in
> a future release).
>
It is unfortunate that this has come up so late the JDK 11 lifecycle,
but since this has API impact, and is the right thing to do, it is
certainly worth addressing now ( rather than waiting to do something in
a future release).
TL;DR provide API support for setting connection and response
I’m giving this serious consideration, and will reply more comprehensively
within the next couple of days.
-Chris
> On 26 Jul 2018, at 19:20, David Lloyd wrote:
>
>> On Wed, Jul 25, 2018 at 9:43 AM Chris Hegarty
>> wrote:
>>
>> Clearly the request builder `timeout` method can be used to
On Wed, Jul 25, 2018 at 9:43 AM Chris Hegarty wrote:
>
> Clearly the request builder `timeout` method can be used to avoid
> extremely long connection timeouts ( as demonstrated below ), but I see
> Bernd's call for more fine grained control over various aspects of the
> request.
>
> I'm not
It's unfortunate that the user sees this when a connection wasn't even
established:
java.net.http.HttpTimeoutException: request timed out
Could it use Channel::isOpen to return a more specific exception?
HttpConnectionException? Or at least a more specific message.
> How important is this
Clearly the request builder `timeout` method can be used to avoid
extremely long connection timeouts ( as demonstrated below ), but I see
Bernd's call for more fine grained control over various aspects of the
request.
I'm not opposed to an "HttpRequest.Builder.connectTimeout` method, but
this is
@openjdk.java.net
Betreff: Re: Connection timeouts in JEP 321 (HTTP Client)
Hi Markus,
The API and implementation supports an overall response timeout through the
method:
HttpRequest.Builder timeout(Duration duration)
So, I don't think any application should be required to wait for 130 seconds
Hi Markus,
The API and implementation supports an overall response timeout through
the method:
HttpRequest.Builder timeout(Duration duration)
So, I don't think any application should be required to wait for 130
seconds.
It does not currently have a timeout setting specific for connection
Somebody pointed me at the upcoming HTTP client implementation, and I'm sad
to see that connection timeouts are missing from the implementation (the
old HTTP API). Is the absence of connection timeouts intended or an
oversight? I'd like to see it added, and it looks like a simple change to
me.
17 matches
Mail list logo
