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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
