RE: [HttpClient] Regarding retrieving an unbuffered stream.

[Jeff Dever <jd...@nortelnetworks.com>]

Hey Martin,

Those are great comments, and the unbuffered stream use for HttpMultiClient
is an issue that had not come up before.  HttpMultiClient and related
classes is currently under review and is expected to change (dIon Gillard is
fronting this effort).  For this reason little effort was put into
HttpMultiClient at this time until the interface has been finalized.

The concept of buffering the stream unconditionally in HttpClient predates
the HttpMultiClient interface.  The concept of the execute() method and the
Command Pattern that it has its roots in makes sense when the execution can
be completed as an autonomous operation, but is somewhat different when the
operation is just initiated by this call.

On an unrelated note, I addressed the enhancement you requested in the bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=11904
Thanks for the patch, and the discussion!  Please don't hesitate to offer
your insight.


-----Original Message-----
From: Elwin, Martin [mailto:melwin@rsasecurity.com]
Sent: Monday, September 09, 2002 10:21 AM
To: Jakarta Commons Developers List
Subject: [HttpClient] Regarding retriving an unbuffered stream.


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>