On 2010-08-30 13:32, Oleg Kalnichevski wrote: > On Mon, 2010-08-30 at 12:20 +0200, Michel Onoff wrote: >> On 2010-08-30 12:10, Oleg Kalnichevski wrote: >>> 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. >>> >> >> One ultra-simple solution would be to permit two thread to >> simultaneously access the HttpConnection, one for reading, the other for >> writing. (Just to make an analogy, SocketChannel allows such behavior). >> Of course, I don't know how simply this would be to implement on the >> current HttpCore. >> > > If that makes sense in the context of your application, go for it. > ReadWriteLock is available in the j.u.concurrent package. All you have > to do is to extend the default HttpConnection implementations, override > public methods and make them acquire either read or write lock prior to > calling the super method. > > HttpCore (and HttpClient) are toolkits, not applications. One must be > prepared to do certain customizations in order to optimize them for a > particular use scenario. >
OK, I'll take a look on how to make extensions. Thanks --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
