[HttpClient] Regarding retriving an unbuffered stream.

["Elwin, Martin" <me...@rsasecurity.com>]

Hi all,

Having followed the discussions here for a while with great interest I
finally have decided to dare post a comment. You decide if my attempt is
foolish or not... :]

Here goes:

Although I like the work initiated by Odi in this area a lot (refactoring
the HttpMethod(+Base) to provide a user of the library with an unbuffered
stream presents) there are if I'm not mistaken some issues when using the
HttpConnectionManager, for instance in the HttpMultiClient.

Please correct me if I'm wrong here, but as I understand it: When not
reading the response into a buffer directly the HttpConnection used when
executing the method is needed until the response has been completely read
from the socket InputStream. However, as the code snippet from the latest
HttpMultiClient below shows the connection is released directly after
executing the method, returning it to the pool for use by, possibly, other
threads doing HttpMethod.execute(..) calls before the response body has been
read.

------
        try {
            status = method.execute(getState(), connection);
        } catch (IOException ex) {
            throw ex;
        } catch (HttpException ex) {
            throw ex;
        } finally {
            mgr.releaseConnection(connection);
        }
------

I don't currently use the HttpClient or HttpMultiClient but I had to change
my application to handle this, postponing the release of the connection
until the response had been read.

In my application changing this was not a problem, but it's a bit trickier
doing it automagically in the HttpMultiClient. Forcing the user to make a
call when done with the Method (or at least reading the response) is
possible, but perhaps not always an appreciated solution. One could also
consider a strategy where the HttpMethod according to contract needs to call
a methodDone() (or other, more cleverly named method) on the HttpConnection
when done with the connection (maybe by doing something similar to what the
AutoCloseInputStream does) so that one can override that method in a class
PooledHttpConnection, created by the HttpConnectionManager, which takes care
of releasing the connection from the pool. Uhhh...

I wouldn't be surprised if this was one of the reasons the HttpClient was
made buffered from the beginning.

What are your thoughts on this?

Humbly yours,

/M

------------
Martin Elwin
@N59.29606 E18.08052 (WGS-84)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>