hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject [PATCH] handling close properly on response input streams
Date Thu, 05 Dec 2002 21:21:07 GMT
OK, as a hopeful sign, I addressed one more round at some issues pointed 
out by Michael, Ortwin, and Ryan, and my patch shrank a little bit.

Key changes over previous submission:

    * spelling insure --> ensure
    * AutoCloseInputStream is still called that, but now actually calls
      close on the underlying stream (this is essential for correctly
      handling partial reads of previous responses on persistent
      connections).  ContentLengthInputStream and ChunkedInputStream no
      longer take a "watcher" as a parameter, do not close the
      underlying stream (as before), and do not attempt to notify any
      watchers.  Instead _readResponseBody() _always_ wraps a non-null
      response in an AutoCloseInputStream.
    * ResponseConsumedWatcher interface is no longer public, instead it
      is a package interface, as it is now only used by HttpMethodBase
      and AutoCloseInputStream (which is package level access itself).
    * Above changes should accommodate oversight pointed out by Michael
      - the previously unwrapped stream now gets wrapped.  Keep in mind
      that the wrapping has two effects, one of which is to close the
      underlying stream once the data is consumed, and another of which
      is to alert the "watcher" that the response has been consumed.
       The watcher (in this case, the instance of HttpMethodBase)
      figures out whether the connection should be closed, and whether
      it should be released to the connection manager.  All of this
      logic can be found in one place - HttpMethodBase.responseBodyConsumed.
    * I had missed, in my previous submission, the fact that
      ConnectMethod overrides execute().  Unfortunately,
      HttpMethodBase.execute() will now "release" the connection if the
      response has been consumed prior to the function exiting.  In the
      case of ConnectMethod, by virtual of the a null input stream on
      the response, my alterations assumed that this meant the
      connection had been fully consumed.  I made the
      "responseBodyConsumed()" function protected, and now overridden by
      ConnectMethod to do nothing.  I can only guess that my oversight
      would have caused problems with proxied connections, as I am not
      currently able to test them.

As to this last point, I was hoping that there would be some test case 
that I could try, or write, but as near as I can tell, this would be 
very difficult to set up a test case without an actual proxy server, 
which I don't have hanging around.  Thus, I ask the question - could 
someone try this patch using the test cases configured to talk to a 
proxy server?  And then let the group know, so that I can stop worrying 
about getting this patch accepted!

Thanks.

-Eric.


Mime
View raw message