[HttpConn] connection manager

[Roland Weber <ht...@dubioso.net>]

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?

cheers,
  Roland



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

Re: [HttpConn] connection manager

[Roland Weber <ht...@dubioso.net>]

Hi Oleg,

> 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'm currently working my way upward. While I was dealing with the
connection interfaces, I was pondering connection management. Now I'm
dealing with connection management and pondering HttpMethodDirector.

> 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. 

Well, the old connection interface had the setLastResponse() method.
I was thinking about something like:

interface ManagedClientConnection {

  void setReusable(boolen reusable, HttpEntity toBeConsumed);
}

- when handed out, the connection is reusable
- read/write implicitly changes it to non-reusable
- once the response header is received:
  * if reuse strategy denies: conn.setReusable(false, null)
  * if there's an entity:     conn.setReusable(true, entity)
  * if there's no entity:     conn.setReusable(true, null)

Then the connection manager would know at least those states in
which reuse is an option.

cheers,
  Roland

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

Re: [HttpConn] connection manager

[Oleg Kalnichevski <ol...@apache.org>]

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