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 New page: #pragma section-numbers 2 = Threads and Synchronization in HttpAsync = == About == The purpose of this document is to provide a design documentation for the use of threads and synchronization in [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! ''This document is work in progress. Please be patient.'' ---- [[TableOfContents]] ---- == Background == The purpose of the [http://jakarta.apache.org/httpcomponents/http-async/index.html HttpAsync] component 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. Typically, applications also want to be notified when a response becomes available. [[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, 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 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 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. The following figure shows the steps required to execute a request. attachment:responsibilities.png Steps that necessarily have to be executed by an application thread are shown to the left. Only the application can decide which request should be executed and what to do with the 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 shown there since it is the purpose of HttpAsync 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 an API would be very inconvenient to use if the status code of a response was not known at the time of notification. The steps in the middle column can reasonably be assigned to either side. ''To be done:'' * application code vs. library code * order of steps == API == ''describe the interfaces defined for the HttpAsync API'' == Initial Design == ''describe the design chosen for the initial implementation'' == Alternative Design == ''describe a design not chosen for the initial implementation'' --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
