hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpConn] connection manager
Date Sun, 21 Jan 2007 12:34:04 GMT
On Sun, 2007-01-21 at 10:35 +0100, Roland Weber wrote:
> Hi all,
> 
> I have reached a first milestone. The MTHCM is copied to
> ThreadSafeClientConnManager and compiles without a reference
> to HttpHostConnection or HttpConnectionManager. Theoretically,
> the API is sufficient to use direct connections or non-secure
> proxy connections without authentication. But writing an
> example that actually does it is another milestone :-)
> 
> There is one gaping hole however:
> SimpleHttpConnectionManager.finishLastResponse(connection)
> 
> This concept does not map to the new API, and I'd like to
> discuss our options before hacking it in. I see the following
> situations in which a connection can be released:
> 
> 1. no attempt has been made to communicate
>    => no response to consume, connection CAN be re-used
> 2. request sent partially, for example only the header
>    => connection MUST NOT be re-used
> 3. request sent completely, response not received
>    => connection COULD be re-used after consuming the entity,
>    but probably shouldn't since we'd have to interpret parts
>    of the response to determine whether there is an entity
> 4. request sent completely, response header received partially
>    => same as 3
> 5. req. s. c., rsp. header received completely, no entity
>    => connection CAN be re-used, nothing needs to be consumed
> 6. req. s. c., rsp. entity received partially or not at all
>    => connection COULD be re-used after consuming the entity
> 7. req. s.c., rsp. received completely
>    => connection CAN be re-used, nothing needs to be consumed
> 
> The code in SimpleHttpConnectionManager deals with situations
> 1, 5, 6, and 7. I'd have to dig into HttpClient 3.x to tell how
> 2-4 are dealt with there.
> I don't like the idea of trying to detect the current situation
> under the cover. I would prefer to add a few methods replacing
> the original setLastResponse() and expect the application or
> HttpClient to call these appropriately.
> Maybe add some flag under the cover to detect read/write on
> the connection, so we can tell if the connection is released
> after a communication attempt without a call to one of the
> indicator methods.
> We might go as far as expecting the application or HttpClient
> to consume the response before the connection is released if
> re-use is desired.
> 
> What do you think?
> 

Seems to make sense. But, again, I feel some questions cannot be
adequately answered until we have HttpClient more or less functional and
are able to test various options in action.

I agree it is reasonable to require consumers of the connection manager
services to release connections only if the response content has been
consumed in its entirety. The connection manager simply has no way of
knowing what state the released connection is in. 

Oleg


> cheers,
>   Roland
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


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


Mime
View raw message