You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Adrian Sutton <ad...@symphonious.net> on 2005/08/11 00:39:07 UTC
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?
Regards,
Adrian Sutton.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Removing The Need For releaseConnection
Posted by Oleg Kalnichevski <ol...@apache.org>.
Adrian et al,
Here's my take for what it is worth.
One of the greatest problem with HttpClient has always been the fact
that we tried to cover very different use patterns and application types
using the same monolithic API. As a result the 2.0 and 3.0 API was still
too difficult for those "get me that damn file" type of users and at the
same time not flexible enough for developing customized HTTP services.
The releaseConnection method was clearly an attempt to simplify the
connection management for ordinary users at the expense of flexibility
provided for the power users.
The good news is that this is no longer an issue. Since we have split
monolithic HttpClient into a number of abstraction layers one can simply
pick only those bits and pieces that suit their type of application
best. For instance, HttpCommons already provides everything that one may
need to run simple client and server side services without actually
enforcing any design choices for those application aspects that do not
directly relate to the HTTP protocol.
http://svn.apache.org/viewcvs.cgi/jakarta/httpclient/trunk/http-common/src/examples/org/apache/http/examples/ElementalHttpGet.java
http://svn.apache.org/viewcvs.cgi/jakarta/httpclient/trunk/http-common/src/examples/org/apache/http/examples/ElementalHttpEchoServer.java
For instance, HttpCommon do not make any provisions to manage HTTP
connections. The connection management can be introduced at the level
above HttpCommons with very little code. The Coyote HttpConnector I am
currently working on can be used as an example:
http://svn.apache.org/viewcvs.cgi/jakarta/httpclient/trunk/coyote-httpconnector/src/java/org/apache/http/coyote/
So, the evil (TM) plan is to make releaseConnection irrelevant. We still
should seriously consider providing some connection management
capabilities in the HttpClient layer that sits on top of HttpCommons,
where releaseConnection method may exist in some form or shape. For all
those who needs more flexibility that HttpClient is able to provide
there are HttpCommons (basic HTTP components) + HttpAuth (the
authentication framework) + HttpCookie (the HTTP state management
framework) + HttpConn (the connection management framework) to pick
components from and roll out their own HTTP client / proxy / server.
Oleg
On Thu, Aug 11, 2005 at 08:39:07AM +1000, Adrian Sutton wrote:
> 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?
>
> Regards,
>
> Adrian Sutton.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Removing The Need For releaseConnection
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Adrian,
> * IOException or other exception while reading from the stream. Our
> input stream wrapper could catch this and release the connection then
> rethrow the exception.
Aren't there fatal and non-fatal IOExceptions? If there is a
read timeout, how are you going to decide whether the application
is going to try again or not?
> * 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).
Sounds reasonable, though I would add a flag to switch between the
abort() and releaseConnection() semantics when InputStream.close()
is called.
I suspect people tend to be sloppy when it comes to closing streams,
especially when they are considered useless or faulty. But it wouldn't
make that much difference if we told them to close the stream instead
of telling them to release the connection. Especially if the stream
is at hand, while the method is not.
I'm not familiar with the new API yet, but if there still is a
Method.releaseConnection() or HttpResponse.releaseConnection(),
we could rename it to close() and then tell people: you have to close
either the method/response or the stream you got from it. I'd like
that better than explicitly calling a release method for something
that was implicitly allocated.
> Am I crazy? Thoughts?
No, I don't think you're crazy :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org