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/HttpAsyncThreadingDesign The comment on the change is: added API description ------------------------------------------------------------------------------ == API == - ''describe the interfaces defined for the HttpAsync API'' + The application programming interface (API) for HttpAsync in package {{{org.apache.http.async}}} + defines three interfaces. The following figure shows their place with respect to the steps that + have to be executed. attachment:interfaces.png + + Two of the interfaces are application-facing. {{{HttpDispatcher}}} is used to transfer control + over a request to HttpAsync. Since this is done by a call from an application thread, the + implementation can then execute code in that application thread. Eventually, the request has + to be passed to the background threads that handle the asynchronous communication. The application + obtains an instance of the second interface as a result of the call to {{{HttpDispatcher}}}. + [[BR]] + Instances of {{{HttpHandle}}} are specific to a request. When the application tries to access + the response to a specific request, it does so through the {{{HttpHandle}}} for that request. + When the application is done with processing a response to a specific request, it indicates + that to the {{{HttpHandle}}} for that request. If the application has to cancel a specific request, + it does so through the {{{HttpHandle}}} for that request. Again, the implementation has the + opportunity to execute some of the steps in the calling application thread. + Thread synchronization is a particular issue here, since several application threads may be + calling the same instance of {{{HttpHandle}}} concurrently. + [[BR]] + The third interface {{{HttpNotificationHandler}}} is used by background threads + to notify applications of incoming responses, or of problems encountered while executing a + request. It would have been possible to define notifications in terms of specific objects for + thread synchronization. While background threads would not have had to execute application code + for notification in that case, the flexibility for application developers would have been + signifcantly reduced. Instead, a background thread is calling directly into application code, + which can then use suitable means to relay the notification to application threads. The thread + calling into application code is symbolized by the cyan border around the red box for + "handle notification". + Implementing the {{{HttpNotificationHandler}}} interface requires '''special care''' + by application developers, since a misbehaving notification handler can + take down background threads and thereby stall other requests as well. + + The step "chase redirect" is shown in brackets since it is not yet part of the API. + If it becomes part of the API, it will probably not be in the {{{HttpHandle}}} interface, + although it's position in the figure might trick you into expecting that. There are + too many problems to be solved first, so let's not worry about chasing redirects now. == Blocking IO Implementation == @@ -97, +132 @@ ''describe the original design, which maximizes responsibilites for application threads'' + attachment:reddesign.png + === Cyan Design === ''describe an alternative design, which maximizes responsibilities for background threads'' + + attachment:cyandesign.png == Non-blocking IO Implementation == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
