hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julius Davies" <juliusdav...@gmail.com>
Subject Re: [HttpConn][HttpClient] status update
Date Sat, 10 Feb 2007 14:25:20 GMT
Ditching releaseConnection() in favour of InputStream.close()???

+1 +1 +1 !!!

By "AutoClose", I guess you mean that it will close itself if the EOF
is read?  That makes sense.

On this note (things that annoy end-users)...  I think
MultiThreadedConnectionManager should become the default connection
manager.  If someone really knows what they're doing and doesn't want
MTCM, they will have the ability to turn it off.  But if someone
doesn't know what they're doing, MTCM is much better for them.  My
personal "numbers" would be "max 30 connections", and "max 30
connections per host" (not sure if that's how it still works).



On 2/10/07, Roland Weber <http-async@dubioso.net> wrote:
> Hi folks,
> I've reached a milestone with ClientRequestDirector. The replacement
> for HttpMethodDirector is now able to establish secure connections
> through a proxy. Along with that goes a first draft of HttpClient
> that uses the CRD. If you should look at the API at this stage, please
> remember that I'm _really_ still working on HTTPCLIENT-627 [1] and
> need the CRD as a sanity check of the connection management API.
> The rest of this mail is implementation details and an outlook.
> I did not "port" HttpMethodDirector to the new API, as I found the
> approach much too difficult. HMD is based on the HttpMethod concept
> and full of authentication related code, which is out of scope for
> the current problem. Instead I had HMD open in one editor window
> and implemented the CRD in another one, using a top-down approach
> to provide similar functionality. Wherever I left out functionality
> found in HMD, I put in a comment. Likewise when I felt there is
> an open question. The CRD code now looks as if more questions
> are posed than answered. It's a scrag, but I still feel that it
> is on the right track and that the missing functionality can be
> fitted nicely.
> To implement the route-building logic, I have added new classes that
> match my "HTTP route" idea. HttpRoute is meant as a replacement for
> HostConfiguration, which I would like to keep in a different role
> after HTTPCLIENT-618 [2]. ManagedClientConn and ClientConnManager
> are updated to use HttpRoute rather than HostConfiguration. TSCCM
> still uses HostConfig internally, as I don't want to start cleaning
> it up until there are testcases to ease Oleg's mind.
> There is one tiny little hole in the client API... connections can
> not yet be released. The examples send an OPTIONS request, which
> will generate a response without entity. In that case, the CRD
> releases the connection immediately.
> Connection release will be the next milestone. I'm thinking about
> an approach that relies on closing the input stream or entity rather
> than a releaseConnection method, as suggested in [4]. It will involve
> AutoCloseInputStream and check for connection re-use and some kind
> of extended interface (don't know which one yet) and I don't know
> what else. If possible, I will address HTTPCLIENT-589 [3] along the
> way, plus the questions I raised some weeks ago in [5]. After that,
> it's time for testcases and review.
> cheers,
>   Roland
> [1] https://issues.apache.org/jira/browse/HTTPCLIENT-627
> [2] https://issues.apache.org/jira/browse/HTTPCLIENT-618
> [3] https://issues.apache.org/jira/browse/HTTPCLIENT-589
> [4]
> http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200508.mbox/%3c304447CF-0A71-49C2-871D-5476E9F75226@symphonious.net%3e
> [5]
> http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/%3c45B333F3.3010706@dubioso.net%3e
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Julius Davies

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

View raw message