hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-httpclient Wiki] Update of "HttpAsyncThreadingDesign" by RolandWeber
Date Sat, 20 May 2006 18:00:10 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change

The following page has been changed by RolandWeber:

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.''


== Background ==

The purpose of the [http://jakarta.apache.org/httpcomponents/http-async/index.html HttpAsync]
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
Typically, applications also want to be notified when a response becomes available.
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.
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.


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
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
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: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

View raw message