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). yours, Julius On 2/10/07, Roland Weber <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] [5] http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- yours, Julius Davies 416-652-0183 http://juliusdavies.ca/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
