You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Michel Onoff <mi...@web.de> on 2010/09/02 09:42:30 UTC
Re: HttpConnection thread-safety
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HttpConnection thread-safety
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2010-09-02 at 09:42 +0200, Michel Onoff wrote:
> 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
> >>
> >
...
> 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.
>
There are two possibilities, if you feel very strongly about it.
(1) feel free to contribute patches for javadocs and the tutorial. A new
section for the 'Advanced topics' chapter about thread-safe connections
would probably make most sense.
(2) consider contributing your custom implementations of Http(Server|
Client)Connection interfaces to HttpCore
> Thanks
> MO
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org