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/SingleAsyncRequestNotify New page: = Use Case: Single Asynchronous Request With Response Notification = == Description == I want to send a request over a connection without blocking the application. [[BR]] I want to get a notification when the response is available, so the application does not need to block. == Related / Out of Scope == * [wiki:Self:UseCases/SingleAsyncRequest single asynchronous request] * [wiki:Self:UseCases/MultiAsyncRequests multiple asynchronous requests] * sequences of requests, like chasing redirects * fire and forget = Discussion = This use case requires a notification mechanism to indicate availability of a response to the application. Although not strictly required by the description, there should be a way to associate a request with the response for that request. An application could use several connections simultaneously to send a single request on each. The notification mechanism should also provide access to application specific per-request data, to facilitate re-use of a single notification handler for multiple connections and requests. [[BR]] The requirement for parameters to the notification rules out the use of the generic wait/notify mechanism in {{{java.lang.Object}}} and suggests a callback interface with a method to which parameters can be passed. Error handling can be provided by the same interface, for example as an additional method. The implementation requires at least one background thread for sending the request and detecting the availability of the response. One thread may be shared for multiple connections if Java NIO is used, a separate thread for each connections is needed with 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, interact with the user, or otherwise lock up the thread. Background threads may be needed for other purposes than the notification, even if they are not shared across connections. The callback handler for the notification therefore has to delegate processing to an application thread. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
