Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Clarification on synchronous and asynchronous request model for Jetty

Hi,

On Thu, May 11, 2017 at 10:41 PM, Neha Munjal <neha.munjal3@xxxxxxxxx> wrote:
> Hi,
>
> We are using Jetty client jars (v 9.3.7.v20160115) to make both synchronous
> and asynchronous HTTP/2 requests.

Please upgrade, we are now at 9.3.19 and 9.4.5.

> 1. It seems that the synchronous request model internally makes use of
> asynchronous model i.e requests are queued and processed. Every request can
> be provided or configured with a timeout, that would indicate the timeout
> for request/response conversation to complete.
> I would like to clarify that in case we need to retry synchronous requests
> depending upon the response received from the end point, the new request to
> be retried once invoked, would again be placed in the queue and processed. I
> guess that would create ordering problems as there can be many other
> requests that could have come in between the original request and its retry
> request, which will be given preference.

There is no automatic retry. If your application retries a request,
then it will be no different than any other request.

> 2. For asynchronous requests, is there a way to detect connection failures
> early or in a synchronous fashion? Say we have 100 requests sent at the same
> time, but all pointing to a bad host name or to a host that is temporarily
> down and not responding, is there a way to detect these connection failures
> in a synchronous fashion?

Connects can be made blocking by configuring:

HttpClient.setSocketAddressResolver(new SocketAddressResolver.Sync());

and

HttpClient.setConnectBlocking(true);

Note that this is not fool proof though.
You can have 10 request be able to connection, and the 11th cannot.

I don't think it's a good idea to rely on detection of synchronous connects.
Your application should be prepared to handle failures anyway, and
connect failures are just one among many and as such should not be
treated specially.

A more reliable way would be to send a first request, wait for it to
come back, and then send the other 99.
These can still fail, but at least you have not configured the client
with configuration that gives you false confidence.

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


Back to the top