Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Subject: Re: Threadsafety of the classes in core
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <httpcomponents-dev@jakarta.apache.org>
In-Reply-To: <1183749062.5591.12.camel@okhost>
References: <3fb8d2f00707061157t32bd0269q81826bb08f08f14@mail.gmail.com>
	 <1183749062.5591.12.camel@okhost>
Content-Type: text/plain
Date: Fri, 06 Jul 2007 21:13:50 +0200
Message-Id: <1183749230.5591.15.camel@okhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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