You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Daniel Mueller <da...@gmail.com> on 2007/07/06 20:57:25 UTC
Threadsafety of the classes in core
Hi all,
Just a quick question. I'm in the process writing a client based on
http-core (alpha5) and just wanted to check back if I've gotten the things
the right way around concerning the threadsafety of the used classes. I've
started from the example 'Basic HTTP GET'. Am I right assuming that the
following classes (and corresponding implementations) are threadsafe and can
be used concurrently from multiple threads as long as you don't modify them
after initialization: HttpParams, HttpProcessor, HttpHost and
ConnectionReuseStrategy. On the other hand the following cannot be used in a
threadsafe manner: HttpContext (unless you want to use the synced variant)
and HttpClientConnection (HttpRequest and HttpResponse are obviously not).
Any kind of pooling of connections has to be implemented atop of this (which
is what httpclient does, last time I checked).
Are these assumptions correct or am I missing something.
Thanks a lot and keep up the great work. It's appreciated.
Cheers,
Daniel
PS: some short javadoc notice as to what the legal uses are in a
multithreaded environment wouldn't hurt. Maybe if somebody stumbles the next
time across one of those particular classes...
[1]
http://jakarta.apache.org/httpcomponents/httpcomponents-core/examples.html
Re: Threadsafety of the classes in core
Posted by Roland Weber <os...@dubioso.net>.
> Concurrent access to all other classes from multiple threads _MUST_ be
>> synchronized.
Modifying access, that is.
> Ok, I thought I might get away with a couple of classes being reused
> between
> threads, but that seems not to be the case.
You can re-use parameters if you don't modify them.
HttpCore won't modify parameters by itself. You can
also re-use unmodifiable classes such as HttpHost.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Threadsafety of the classes in core
Posted by Daniel Mueller <da...@gmail.com>.
Hi Oleg,
Per default one has to assume HttpCore classes are _NOT_ threading-safe.
> There are three exceptions to this rule I can think of on the top of my
> head:
<snip/>
Concurrent access to all other classes from multiple threads _MUST_ be
> synchronized.
Ok, I thought I might get away with a couple of classes being reused between
threads, but that seems not to be the case.
I do not want to over-synchronize HttpCore low level classes mainly for
> performance reasons.
Which is IMO the correct thing to do.
<snip/>
> PS: some short javadoc notice as to what the legal uses are in a
> > multithreaded environment wouldn't hurt. Maybe if somebody stumbles the
> next
> > time across one of those particular classes...
> >
>
> I am aware I have to document all this stuff. It is on my (rather
> lengthy) TODO list.
>
Yeah, I didn't want to nitpick, I'm aware that there's still much to do and
not many to do it. The work is still fantastic.
Cheers,
Daniel
Re: Threadsafety of the classes in core
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-07-06 at 21:11 +0200, Oleg Kalnichevski wrote:
> On Fri, 2007-07-06 at 20:57 +0200, Daniel Mueller wrote:
> > Hi all,
> >
> > Just a quick question. I'm in the process writing a client based on
> > http-core (alpha5) and just wanted to check back if I've gotten the things
> > the right way around concerning the threadsafety of the used classes. I've
> > started from the example 'Basic HTTP GET'. Am I right assuming that the
> > following classes (and corresponding implementations) are threadsafe and can
> > be used concurrently from multiple threads as long as you don't modify them
> > after initialization: HttpParams, HttpProcessor, HttpHost and
> > ConnectionReuseStrategy. On the other hand the following cannot be used in a
> > threadsafe manner: HttpContext (unless you want to use the synced variant)
> > and HttpClientConnection (HttpRequest and HttpResponse are obviously not).
> > Any kind of pooling of connections has to be implemented atop of this (which
> > is what httpclient does, last time I checked).
> >
> > Are these assumptions correct or am I missing something.
> >
>
> Daniel,
>
> Per default one has to assume HttpCore classes are _NOT_ threading-safe.
> There are three exceptions to this rule I can think of on the top of my
> head:
>
Four rather.
I do need holidays.
Oleg
> (1) Shutdown method of the HttpConnection interface
> HttpConnection#shutdown();
> (2) SyncHttpExecutionContext
> (3) IOSession interface implementation(s) in the NIO extensions
> (4) IOControl interface implementation(s) in the NIO extensions
>
> Concurrent access to all other classes from multiple threads _MUST_ be
> synchronized.
>
> I do not want to over-synchronize HttpCore low level classes mainly for
> performance reasons.
>
> Unlike HttpCore, HttpClient will be threading-safe per default (provided
> it is being used with a threading safe connection manager).
>
> > Thanks a lot and keep up the great work. It's appreciated.
> > Cheers,
> > Daniel
> >
> > PS: some short javadoc notice as to what the legal uses are in a
> > multithreaded environment wouldn't hurt. Maybe if somebody stumbles the next
> > time across one of those particular classes...
> >
>
> I am aware I have to document all this stuff. It is on my (rather
> lengthy) TODO list.
>
> Cheers
>
> Oleg
>
>
> > [1]
> > http://jakarta.apache.org/httpcomponents/httpcomponents-core/examples.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Threadsafety of the classes in core
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-07-06 at 21:11 +0200, Oleg Kalnichevski wrote:
> On Fri, 2007-07-06 at 20:57 +0200, Daniel Mueller wrote:
> > Hi all,
> >
> > Just a quick question. I'm in the process writing a client based on
> > http-core (alpha5) and just wanted to check back if I've gotten the things
> > the right way around concerning the threadsafety of the used classes. I've
> > started from the example 'Basic HTTP GET'. Am I right assuming that the
> > following classes (and corresponding implementations) are threadsafe and can
> > be used concurrently from multiple threads as long as you don't modify them
> > after initialization: HttpParams, HttpProcessor, HttpHost and
> > ConnectionReuseStrategy. On the other hand the following cannot be used in a
> > threadsafe manner: HttpContext (unless you want to use the synced variant)
> > and HttpClientConnection (HttpRequest and HttpResponse are obviously not).
> > Any kind of pooling of connections has to be implemented atop of this (which
> > is what httpclient does, last time I checked).
> >
> > Are these assumptions correct or am I missing something.
> >
>
> Daniel,
>
> Per default one has to assume HttpCore classes are _NOT_ threading-safe.
> There are three exceptions to this rule I can think of on the top of my
> head:
>
> (1) Shutdown method of the HttpConnection interface
> HttpConnection#shutdown();
> (2) SyncHttpExecutionContext
> (3) IOSession interface implementation(s) in the NIO extensions
> (4) IOControl interface implementation(s) in the NIO extensions
>
(5) DefaultConnectingIOReactor and DefaultListeningIOReactor, of course
Oleg
> Concurrent access to all other classes from multiple threads _MUST_ be
> synchronized.
>
> I do not want to over-synchronize HttpCore low level classes mainly for
> performance reasons.
>
> Unlike HttpCore, HttpClient will be threading-safe per default (provided
> it is being used with a threading safe connection manager).
>
> > Thanks a lot and keep up the great work. It's appreciated.
> > Cheers,
> > Daniel
> >
> > PS: some short javadoc notice as to what the legal uses are in a
> > multithreaded environment wouldn't hurt. Maybe if somebody stumbles the next
> > time across one of those particular classes...
> >
>
> I am aware I have to document all this stuff. It is on my (rather
> lengthy) TODO list.
>
> Cheers
>
> Oleg
>
>
> > [1]
> > http://jakarta.apache.org/httpcomponents/httpcomponents-core/examples.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Threadsafety of the classes in core
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-07-06 at 20:57 +0200, Daniel Mueller wrote:
> Hi all,
>
> Just a quick question. I'm in the process writing a client based on
> http-core (alpha5) and just wanted to check back if I've gotten the things
> the right way around concerning the threadsafety of the used classes. I've
> started from the example 'Basic HTTP GET'. Am I right assuming that the
> following classes (and corresponding implementations) are threadsafe and can
> be used concurrently from multiple threads as long as you don't modify them
> after initialization: HttpParams, HttpProcessor, HttpHost and
> ConnectionReuseStrategy. On the other hand the following cannot be used in a
> threadsafe manner: HttpContext (unless you want to use the synced variant)
> and HttpClientConnection (HttpRequest and HttpResponse are obviously not).
> Any kind of pooling of connections has to be implemented atop of this (which
> is what httpclient does, last time I checked).
>
> Are these assumptions correct or am I missing something.
>
Daniel,
Per default one has to assume HttpCore classes are _NOT_ threading-safe.
There are three exceptions to this rule I can think of on the top of my
head:
(1) Shutdown method of the HttpConnection interface
HttpConnection#shutdown();
(2) SyncHttpExecutionContext
(3) IOSession interface implementation(s) in the NIO extensions
(4) IOControl interface implementation(s) in the NIO extensions
Concurrent access to all other classes from multiple threads _MUST_ be
synchronized.
I do not want to over-synchronize HttpCore low level classes mainly for
performance reasons.
Unlike HttpCore, HttpClient will be threading-safe per default (provided
it is being used with a threading safe connection manager).
> Thanks a lot and keep up the great work. It's appreciated.
> Cheers,
> Daniel
>
> PS: some short javadoc notice as to what the legal uses are in a
> multithreaded environment wouldn't hurt. Maybe if somebody stumbles the next
> time across one of those particular classes...
>
I am aware I have to document all this stuff. It is on my (rather
lengthy) TODO list.
Cheers
Oleg
> [1]
> http://jakarta.apache.org/httpcomponents/httpcomponents-core/examples.html
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org