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: HttpAsync => HttpDispatch, thoughts about NIO, status: suspended ------------------------------------------------------------------------------ #pragma section-numbers 2 - = Threads and Synchronization in HttpAsync = + = Threads and Synchronization in HttpDispatch = == About == The purpose of this document is to provide a design documentation for the use of - threads and synchronization in + threads and synchronization in !HttpDispatch - [http://jakarta.apache.org/httpcomponents/http-async/index.html HttpComponents HttpAsync] that is separate from the source code. Unlike the source code, this design document will not only reflect the current implementation, but also lists design alternatives - and gives a rationale for design decisions. And there'll be pictures here! + and gives a rationale for design decisions. And there are pictures here! + [[BR]] + Note that !HttpDispatch is the working title for what was formerly referred to as + [http://jakarta.apache.org/httpcomponents/http-async/index.html HttpAsync]. + There are some leftover references to the old name on this page, in particular the page name and labels in the pictures. - ''This document is work in progress. Please be patient.'' + ''Work on !HttpDispatch is currently suspended.'' + The code mentioned below is archived + [http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpasync/branches/suspended-at-HttpCoreAlpha4/ here]. + It compiles against !HttpCore alpha 4. + A lot of progress has been made in !HttpCore and !HttpConn since it was originally developed. + The code is therefore outdated, but can still serve as a starting point to pick up development. + If you feel like spending time on !HttpDispatch, just send a mail to the developer list. ---- [[TableOfContents]] @@ -22, +31 @@ == Background == - The purpose of the [http://jakarta.apache.org/httpcomponents/http-async/index.html HttpAsync] component + The purpose of the !HttpDispatch component or module is to provide an API that allows applications to execute HTTP requests asynchronously. That means the - application creates a request, hands the request over to HttpAsync, and later picks up the response. + application creates a request, hands the request over to !HttpDispatch, and later picks up the response. Typically, applications also want to be notified when a response becomes available. There is a selection of UseCases that address asynchronous communication. [[BR]] There will always be at least two threads required, one on the application side - and one background thread on the HttpAsync side. On this high level of abstraction, + and one background thread on the !HttpDispatch side. On this high level of abstraction, it doesn't matter whether there are one or many threads on either side. There may - also be several applications using HttpAsync at the same time, or several components + also be several applications using !HttpDispatch at the same time, or several components of one large application. [[BR]] Executing a request involves several steps. Each step needs to be executed by either an - application thread or a background thread (from HttpAsync). As part of the design, it is + application thread or a background thread (from !HttpDispatch). As part of the design, it is necessary to define which step should be executed by which kind of thread. Although it is possible to defer such decision to runtime, threading issues will be easier to handle if the assignment is static. @@ -49, +58 @@ response. To the right are steps that have to be executed by a background thread. Sending of the request and waiting for the response is there since it is the purpose - of HttpAsync to offload such tasks from applications. Notification for incoming responses + of !HttpDispatch to offload such tasks from applications. Notification for incoming responses has to be triggered by the thread that was waiting for the response. Receiving the response header is assigned to the background thread too, because it is a precondition for notification, as explained below. @@ -87, +96 @@ == API == - The application programming interface (API) for HttpAsync in package {{{org.apache.http.async}}} + The application programming interface (API) for HttpDispatch 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 + over a request to HttpDispatch. 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}}}. @@ -196, +205 @@ === Application Considerations === - Applications using HttpAsync have one very important responsibility which was + Applications using !HttpDispatch have one very important responsibility which was not been mentioned so far. It may sound trivial, but really it isn't: Applications '''must''' process responses as they arrive. - Due to the asynchronous nature of HttpAsync, an application can generate several + Due to the asynchronous nature of !HttpDispatch, an application can generate several - requests and pass them to a dispatcher. HttpAsync does ''not'' guarantee that these + requests and pass them to a dispatcher. !HttpDispatch does ''not'' guarantee that these requests will be sent in order. Responses may arrive in any order (even different from the order in which requests are sent), and each response with an entity locks up one connection until it is processed. @@ -222, +231 @@ == Blocking IO Implementation == - This section presents design alternatives for implementing the HttpAsync interfaces. + This section presents design alternatives for implementing the !HttpDispatch interfaces. An implementation is also referred to as a ''dispatcher'', since each implementation of {{{HttpDispatcher}}} requires a matching implementation of {{{HttpHandler}}} and will make use of {{{HttpNotificationHandler}}}, which is implemented by applications. @@ -298, +307 @@ 1. Postprocessing can be switched between application thread and background thread through a parameter.[[BR]] The default is to postprocess in the background thread, since it is unpredictable which of several application threads would be the one that does the postprocessing. 1. Consuming of the remaining response body is done in the background thread, since that step is logically tied to connection management.[[BR]] Applications that don't want the background thread to consume the response body can consume it explicitly before closing the handle. + + + == Non-blocking IO Implementation == + The blocking IO implementation promises maximum performance. It's major drawback is that it requires at least as many background threads as there are connections, since a dedicated thread needs to wait for incoming responses on each connection. + That may be acceptable in client applications, for example a web spider. For server side applications like proxies, this resource inefficiency is typically not acceptable. + [[BR]] + Non-blocking IO allows a single thread to wait for an incoming message on ''any'' connection. Although it is possible to switch sockets between blocking and non-blocking modes, this can not be used to mix non-blocking IO for waiting with blocking IO for receiving. The socket behavior can only be specified for both directions, sending and receiving. + When pipelining, the socket can be used for sending requests at any time, the operation mode must therefore not be changed. + An extra mixed-mode dispatcher that excludes pipelining hardly seems worth the effort. + + ''This is the place for discussing {{{java.nio}}} based dispatchers.'' + The foundation for implementing HTTP communication with NIO is already available in + [http://jakarta.apache.org/httpcomponents/httpcore/jakarta-httpcore-nio/index.html HttpCore-NIO]. + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
