On Thu, 2014-01-09 at 11:07 -0700, Shawn Heisey wrote: > On 1/5/2014 9:03 AM, Oleg Kalnichevski wrote: > > That is intended. HttpClient instances are expected to be immutable > > (not their dependencies though). This helps make them thread safe > > without incurring an overhead of synchronization. One should customize > > individual requests or execution contexts and never meddle with > > HttpClient instances. > > Thank you for your reply. > > This is why I say it will be quite a paradigm shift for Solr. Solr is > *almost* there in that usually those settings are only changed when the > server object is first created, but typically it's done by creating the > HttpClient object and then modifying its defaults. Now the "create the > SolrServer and/or HttpClient with appropriate defaults" paradigm will > need to be 100% explicit.
It does not have to be. There is nothing that should prevent you from using a factory pattern or a builder pattern in order to apply reasonable defaults when creating HttpClient instances while giving the users an option to override those properties they care about. But the main point is that HttpClient instances should rarely need to change, if at all. Most of configuration should take place at the request (HttpRequest) or the session (HttpContext) level. I do not think this is such a major paradigm shift. > How much of a bad idea would it be to create a new HttpClient object > when a default parameter at the SolrServer level needs to change, > turning the old one into collectable garbage? I don't like the idea, > just curious. > HttpClient instances are very expensive to create. One ought to re-use them as much as possible. Would not it be better to change HttpContext instead? Oleg > > There is no migration guide but HttpClient programming principles are > > covered here > > http://hc.apache.org/httpcomponents-client-4.3.x/tutorial/html/index.html > > I think it's going to take me a while before I can fully wrap my head > around what to do here. I look forward to figuring it all out and > learning a lot in the process. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
