hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-httpclient Wiki] Update of "UseCases/MultiAsyncRequests" by RolandWeber
Date Wed, 28 Dec 2005 18:28:30 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change
notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/UseCases/MultiAsyncRequests

New page:
= Use Case: Multiple Asynchronous Requests =

== Description ==

My application has to send several requests, which do not depend on eachother.
I want to send these requests asynchronously with a single thread,
and process the responses in the order of arrival.

== Variations ==

 * all requests are targetting a single server, for example SOAP calls

== Related / Out Of Scope ==

 * [wiki:Self:UseCases/SingleAsyncRequest single asynchronous request]
 * sequences of requests, like chasing redirects
 * fire and forget


= Discussion =

This use case requires queueing of requests, since it cannot be guaranteed and may not be
intended
that there is a connection available for each request. It also requires a notification mechanism
to indicate availability of responses to the application. Finally, a mechanism is required
so that
the application can associate the sent requests with the received responses.
[[BR]]
Queueing of requests requires a scheduling algorithm for picking up the queued requests.
Different algorithms may be appropriate depending on the scenario, for example if the requests
are all
targetted at a single server, as opposed to all or most requests being targetted at different
servers.

The order of arrival of the responses can differ from the order in which the requests are
sent by the application. Reasons for this are different response times of different servers,
different
response times of the same server on multiple connections, or a scheduling mechanism that
sends the
requests in an order different from that in which they were generated by the application.
[[BR]]
Due to connection availability, connection re-use and pipelining, there may be dependencies
between
the responses for independent requests. The application MUST NOT block to wait for availability
of a
particular response, since that response might never become available until other responses
have been
processed and their connections re-used or released.
There is one exception to this rule: if the scheduling algorithm guarantees in-order sending
of requests,
then the application can block on responses in exactly the same order in which the requests
were
generated and sent.
  
The implementation of the scheduling algorithm, asynchronous sending and notification about
responses
requires at least one background thread if using Java NIO, or one per connection if using
traditional IO.
The responsibility for processing of response headers can be assigned to the application thread,
or to
the background threads.
[[BR]]
The application MUST NOT abuse notification calls by background threads to process responses,
since the
background threads are needed to receive other responses, or to send further requests. The
event handler
for the notification has to delegate processing to an application thread.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message