[
https://issues.apache.org/jira/browse/HTTPCLIENT-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761622#action_12761622
]
Oleg Kalnichevski commented on HTTPCLIENT-805:
----------------------------------------------
Kenny, Sean
HttpClient 4.1-snapshot now has a much simpler API for creating and configuring
connection managers. HTTP parameters are no longer required when creating
standard connection managers and the whole initialization process has become
simpler:
---
ThreadSafeClientConnManager cm = new
ThreadSafeClientConnManager(schemeRegistry);
// Increase max total connection to 200
cm.setMaxTotalConnections(200);
// Increase default max connection per route to 20
cm.setDefaultMaxPerRoute(20);
// Increase max connections for localhost:80 to 50
HttpHost localhost = new HttpHost("locahost", 80);
cm.setMaxForRoute(new HttpRoute(localhost), 50);
HttpClient httpClient = new DefaultHttpClient(cm);
---
One would still need to create an instance of SchemeRegistry in order to create
a connection manager. Could you leave with the new approach?
I can also provide a constructor that takes ThreadSafeClientConnManagerFactory,
if necessary, but that would lead to a certain ugliness in code mainly because
damn Java insists on super constructor being the first call in an overloaded
constructor.
Please take a look at the new API and let me know if it is okay to close the
issue as FIXED.
Oleg
> Pass ClientConnectionManager to DefaultHttpClient constructor
> -------------------------------------------------------------
>
> Key: HTTPCLIENT-805
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-805
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient, HttpConn
> Affects Versions: 4.0 Beta 1
> Reporter: Kenny MacLeod
> Fix For: 4.1.0
>
>
> Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1
> fix.
> I'm trying to find the least verbose way of configuring a DefaultHttpClient
> with a ThreadSafeClientConnManager.
> The example code given for this goes through a manual process of configuring
> HttpParams and SchemeRegistry objects, which is more or less copied from the
> DefaultHttpClient.createHttpParams() and createClientConnectionManager()
> methods.
> It's a bit of a chicken and egg situation - DefaultHttpClient can create its
> own HttpParams and SchemeRegistry, which are themselves fine, but only once
> its been constructed, and the constructor requires the
> ThreadSafeClientConnManager, but that in turn requires the HttpParams and
> SchemeRegistry objects. The only way out is to manually construct the
> HttpParams and SchemeRegistry, which is a waste.
> It seems to me that DefaultHttpClient's constructor should take a
> ClientConnectionManagerFactory instead of a ClientConnectionManager. That
> way, the createClientConnectionManager() method already has the factory
> reference, and doesn't have to grub around in the HttpParams object to find
> it.
> The code would then become:
> new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);
> where ThreadSafeClientConnManagerFactory.newInstance() just constructs
> ThreadSafeClientConnManager. There's no manual construction of HttpParams
> and SchemeRegistry, you just leave it up to DefaultHttpClient.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
