hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCore] HTTP parameters was Re: [HttpConn] test coverage
Date Sat, 26 May 2007 11:13:36 GMT
On Fri, 2007-05-25 at 21:54 +0200, Roland Weber wrote:
> Hi Oleg, all,
> 
> I had another disquieting thought about params.setDefaults()
> today. Is it safe for use in a complex, multithreaded setting
> in the first place? Consider the following two scenarios:
> 
> a) An application creates a set of parameters to be used
> for requests in special cases. Several such requests are
> created and initialized with .setParams() and the same
> params object. The framework calls .getParams().setDefaults()
> for each request, at unspecified times.
> 
> b) An application creates one connection manager, to be
> shared by multiple HttpClient instances. Each client
> tries to establish a params hierarchy
>   client -> conn mgr -> connection (or -> request?)
> by calling params.setDefaults() on the same conn mgr params.


Hi Roland,

Using the same HttpParams object for multiple requests executed in
different threads is a bad idea and is likely to result in some
unpleasant side-effects. 

One possibility to solve the problem would be creating a shallow copy of
the HttpParams argument in each and every call to #setParams method

Another one could be to change #setParams to take a Map as an argument
instead of HttpParams.

I also would like to move #getDefaults / #setDefaults methods to an
optional interface LinkedHttpParams that extends HttpParams and declare
it framework internal use.

>
> Actually, I'm wondering how HttpClient 3.x handles the
> second scenario. Is there some synchronization so that
> the params hierarchy remains fixed while it is accessed?
> Or is it documented that "the last client wins"? Or did I
> mix up the class hierarchy with the "defaults" hierarchy?
> http://jakarta.apache.org/commons/httpclient/preference-api.html#HTTP_parameter_hierarchy
> 

I think HttpClient 3.x does not handle this situation well. It is yet
another example of how we kept on piling on features on top of a flaky
architecture without fixing the fundamentals first.

Oleg

> 
> cheers,
>   Roland
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message