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 >> >
Oleg, 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. Thanks MO --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
