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 ------------------------------------------------------------------------------ == 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, + I want to send several independent requests asynchronously with a single thread. + [[BR]] - and process the responses in the order of arrival. + Then, the application should process the responses in the order of arrival. == Variations == @@ -15, +15 @@ == Related / Out Of Scope == * [wiki:Self:UseCases/SingleAsyncRequest single asynchronous request] + * [wiki:Self:UseCases/SingleAsyncRequestNotify single asynchronous request with notification] * sequences of requests, like chasing redirects * fire and forget @@ -22, +23 @@ = 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. Queueing requires a scheduling algorithm for + picking up the queued requests. - 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. + A mechanism is required so that the application + can associate the sent requests with the received responses, as suggested for the + [wiki:Self:UseCases/SingleAsyncRequestNotify single asynchronous request with notification]. 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 @@ -42, +43 @@ 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 focus of this use case is the design of a queueing mechanism for requests. - - 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]] + Interfaces for connection management and request scheduling are desirable. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
