hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject [HttpConn] connection manager
Date Sun, 21 Jan 2007 09:35:47 GMT
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:

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?


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

View raw message