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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
