hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michel Onoff <michel.on...@web.de>
Subject Re: HttpConnection thread-safety
Date Thu, 02 Sep 2010 07:42:30 GMT
On 2010-08-30 15:59, Oleg Kalnichevski wrote:
> On Mon, 2010-08-30 at 15:09 +0200, Michel Onoff wrote:
>>> 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. 
>> Oleg,
>> this assumes that DefaultHttp(Client|Server)Connection (a concrete
>> implementation) maintains no reading state that could interfere with
>> writing operations and no writing state that could influence reading
>> operations.
>> Can you confirm that this is the case, before I start with coding?
>> Thanks
>> MO


I'm happy to confirm that, at least after extensive experimentations on
desktop class hardware, DefaultHttp(Client|Server)Connection seems to be
thread-safe when one thread receives and another sends.

Next week I'll proceed the experiments on a 24 core server.

> I can confirm that. Default HTTP connection implementations are
> full-duplex capable.
> Source code is your best friend, though.

Shouldn't this aspect be documented? I mean, not only in source code but
in the javadoc as well? After all, the tutorial insists that a
connection is not fully thread-safe but being full-duplex capable is
still of big help.

At least, this solves my current concerns.


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message