Re: Migrating to HttpClient 4.3.1 from 4.2.6 - Solr

2014-01-09 Thread Shawn Heisey

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.


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.


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



Re: Migrating to HttpClient 4.3.1 from 4.2.6 - Solr

2014-01-09 Thread Oleg Kalnichevski
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