Re: [jetty-dev] Clarification on synchronous and asynchronous request mo

[Simone Bordet <sbordet@xxxxxxxxxxx>]

Hi,

On Fri, May 12, 2017 at 12:32 AM, Neha Munjal <neha.munjal3@xxxxxxxxx> wrote:
> Hi Simone,
>
> Thanks for the clarifications.
>
> Regarding retries, that was the point I was making as well. If our
> application retries, it will be treated no different than other request and
> will be queued and processed as other requests.
>
> Thanks for clarifying the blocking connect. I have a further clarification
> in this regard for synchronous requests. Here, for every request, we can
> provide a timeout that governs the time for request/response conversation to
> complete.
> Now, the request/response processing involves making a connection with the
> target end point,

That is not always true.
HttpClient pools connections, so you only need to establish a
connection is there is not one already available.

> sending the request and receiving the response from the
> target end point. While working with other libraries eg. Apache, we make use
> of 2 properties: connectionTimeout (timeout for establishing connections)
> and socketTimeout (timeout to read the response). Using the same
> terminology, how should the request timeout value be configured for
> synchronous Jetty requests.
> Should it be connectionTimeout + socketTimeout or atleast a value that is
> greater that connectionTimeout so that we sufficienty allocate time for
> connection creation and reading the response.

HttpClient defines 4 timeouts:

* addressResolutionTimeout - to resolve the target host via DNS
* connectTimeout - to establish TCP connections
* idleTimeout - the time a connection can stay idle before being closed
* timeout - the time within a request+response cycle must complete

The last one is set on the Request object.

I guess Jetty's idleTimeout corresponds to Apache's socketTimeout.

Request.timeout is there to cap the amount of time a request+response takes.
On a very slow client or server with a very large upload or download,
you may never hit the idleTimeout (even if you do pause due to network
congestion), but you still want to cap the total time the
request+response cycle takes.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.