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. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
