On Mon, 2010-08-30 at 11:02 +0200, Michel Onoff wrote: > I read that HttpConnection is *not* thread-safe. > > While this may seem a minor detail, it makes programming with the > blocking model enormously more complex. > > For example, I'm trying to write a simple http load balancer which > forwards client requests to the next available server from a pool in one > direction, and forwards replies from servers to the originating clients > in the opposite direction. > > The idea is to have a task from java.util.concurrent assigned to each > client-side connection and a task for each server-side connection. > > The client-side task blocks on HttpConnection waiting for the next > request, forwards the request to a server-side HttpConnection and > repeats the iteration by blocking for the next request. > > The server-side task blocks waiting for the next response, forwards the > response to the appropriate originating client-side connection and > starts over again waiting for the next response. > > However, since HttpConnection is not thread-safe and since tasks are > executed in independent threads, the above schema does not work safely. > If only one thread is allowed per HttpConnection, the client-side one > that blocks for reading a request cannot forward any response on behalf > of the server-side task. Similarly the server-side thread cannot forward > a request on behalf of the client-side when it blocks reading the next > response. >
One needs to differentiate concepts of thread safety and thread synchronization. It is ultra-trivial to make HttpConnection thread-safe. It will not, however, relieve you from having to synchronize access to connection instances if used by multiple collaborating threads to execute logically separate units of work (transactions). This kind of synchronization logic should not be built into the HttpConnection implementation classes, as it would violate the concept of separation of concerns. In most cases one should be using a specifically designed mechanism to manage connections tailored for a particular problem domain. For example, HttpClient provides a connection management API that can be used to ensure that only one execution thread can have access to a connection instance at a time. This makes vulgar synchronization on class methods unnecessary, as it basically does not solve any real problem. Generally the recommended strategy is to ensure that HttpConnection instance can be used by one thread a at time. One can employ different strategies based on the particular problem domain. > I don't know of a simple workaround. > There are no simple work-arounds to complex problems. Hope this helps. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
