hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Johnson <sjohn...@mercury.com>
Subject RE: Removing The Need For releaseConnection
Date Wed, 10 Aug 2005 23:12:54 GMT
Hi Adrian,

Are you speaking of HTTPClient 4.0?

We are using HTTPClient 2.0 in production, and have
a requirement to only read x number of bytes of the body.
For a while we were reading the whole body and throwing
away the unwanted bytes, but for 70meg files this proved
problematic for performance reasons, when we only wanted 50K.

So we have overriden HTTPClient to stop reading at some
arbitrary MAX body size, and we release the connection.


Steve Johnson, Software Engineer, sjohnson@mercury.com
direct 720.564.6532 


-----Original Message-----
From: Adrian Sutton [mailto:adrian@symphonious.net] 
Sent: Wednesday, August 10, 2005 4:39 PM
To: HttpClient Project
Subject: Removing The Need For releaseConnection

Hi all,
We've just re-architected our HTTP layer to be able to switch between  
HttpClient and the standard JRE classes as with JRE 1.5 Sun's classes  
now do NTLM authentication without requiring the user to be prompted  
(but in older JRE's it can't do NTLM at all and HttpClient provides a  
bunch of other benefits as well).

The biggest problem we have (and a common cause of problems for  
others on this list) is needing to call releaseConnection all the  
time.  If you are reading the entire response and dealing with it in  
one place this is easy to take care of but if you ever need to open a  
HTTP connection and then pass off the input stream to various other  
parts of the application, this becomes a pain to manage.

With all the redesigning of HttpClient that's going on, what options  
do we have for removing the need for user managed calls to  
releaseConnection?  We already release the connection automatically  
if the entire response stream is read and I think if the input stream  
is closed as well - in what situations is this not enough?

* IOException or other exception while reading from the stream.  Our  
input stream wrapper could catch this and release the connection then  
rethrow the exception.

* Situations where the response from the server is discarded.  This  
is most common with error responses from servers like 404s etc but  
can happen when the start of the response indicates in some software  
specific manner that the rest of the content is irrelevant (eg: an  
XML declaration that indicates that the file's version is 2.0 and not  
supported by the parser).  I'm not sure how to deal with this case  
though requiring the user to close the input stream would match how  
input streams are normally used, avoid having to read the entire  
response and release the connection (the connection of course  
couldn't be reused by that's probably a fair trade off given the  
saving in not having to download the content).

What other situations are there that would need to be handled?  This  
always seemed like a straight out required part of the architecture  
but it is surprisingly annoying when you try to integrate HttpClient  
into an application without having it pervade the entire codebase.

Am I crazy?  Thoughts?


Adrian Sutton.

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message