hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: Keeping Connections Alive
Date Tue, 18 Nov 2003 05:19:56 GMT
Hi Sam,

My thought, probably not well articulated, was to add the ability to 
observe and interact with the status of HttpConnections.  This would 
allow for classes other that the connection managers to play a hand in 
the connection management.  Another possibility would be to have a 
HttpConnectionFactory that is responsible for creating connections and 
is also notified by the connection manager of connection state changes. 
  In general I would like to add plugin support to the connection 
management process.  I think composition of functionality using the 
connection managers and various plugins will allow for greater 
flexibility.

Mike


On Nov 17, 2003, at 1:26 PM, Sam Berlin wrote:

> Hi Mike,
>
> Using a listener seems like an interesting idea, although I don't 
> quite see the rationale behind it.  MTCM (well, CM's in general 
> really) seem to be designed specifiically for this purpose: to manage 
> http connections.  Having an observable interface to HttpConnection 
> would require adding new methods that notify HttpConnection when it is 
> assigned/active, as currently the 'releaseConnection' method basically 
> delegates the call to the HttpConnectionManager that is managing it, 
> leaving HttpConnection as stateless as possible.  Perhaps the 
> HttpConnectionManager can actually have the task of informing the 
> observers of the HttpConnection about its status -- that would remove 
> any need to add extraneous methods and state to HttpConnection (other 
> than a way of setting/getting listeners).  Of course, it might 
> actually be a good idea to add this state information to 
> HttpConnection for other reasons (that I can't think of at the 
> moment).
>
> Thanks,
> Sam
>
> Michael Becke wrote:
>
>> Hi Sam,
>>
>> I think this is definitely something that could be a useful addition 
>> to HttpClient.  Though it would be possible to add this functionality 
>> to the MultiThreadedHttpConnectionManager (MTCM) I think I would like 
>> to keep it separate.  Partially because I think MTCM is getting a 
>> little to complicated, but also because I think it could be used 
>> outside of the MTCM.  In general I think we want a pluggable method 
>> for tracking the lifecycle of a connection.  Something like a 
>> HttpConnection listener that is informed when a connection is 
>> created, assigned, released, etc.  This listener could then handle 
>> closing the connections after some period of idleness.  Any 
>> suggestions or contributions that you may have will be appreciated.
>>
>> Thanks,
>>
>> Mike
>>
>> On Nov 14, 2003, at 12:58 PM, Sam Berlin wrote:
>>
>>> Thanks for the reply, Mike.  Is there any interest in a feature that 
>>> would close connections that have been unused for a certain amount 
>>> of time?  I imagine the easiest way to implement this would be to 
>>> just add some settable parameters (set/getCloseConnectionTime) to 
>>> MultiThreadedHttpConnectionManager along with another Thread that 
>>> will occasionally iterate through the list of 'freeConnections' in 
>>> the 'connectionPool', checking an amount of time has lapsed since 
>>> the connection was last marked as free.  HttpConnection (or 
>>> HttpConnectionAdapater, since this feature would only be in 
>>> MultiThreadedHttpConnectionManager) could have a new value added to 
>>> it that stores the most recent time it was released.  Note that this 
>>> would all rely on the user correctly calling 'releaseConnection', 
>>> but that's essentially a requirement already anyway.  If people are 
>>> interested in such a feature, I would be more than willing to write 
>>> up such a patch (as I will probably be doing it for the version 
>>> LimeWire uses anyway).
>>>
>>> Thanks,
>>> Sam
>>>
>>> Michael Becke wrote:
>>>
>>>> Hi Sam,
>>>>
>>>> HttpClient does not do any active connection reclaiming, except 
>>>> when the resources are reused.  In the case of the 
>>>> SimpleHttpConnectionManager the connection is never closed/reopened 
>>>> unless it is required for a new method execution.  The case for 
>>>> MultiThreadedHttpConnectionManager is similar though a little more 
>>>> complicated.  It keeps a pool of connections with a per-host and 
>>>> total connection limit.  Again these connections are never closed 
>>>> until a request for a new connection warrants it.
>>>>
>>>> Mike
>>>>
>>>> On Nov 13, 2003, at 4:10 PM, Sam Berlin wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I'd like to clarify a point about HttpClient that I do not fully 
>>>>> understand.  How/when does the actual connection to a server 
>>>>> close?  I understand that MultiThreadedHttpConnectionManager (and 
>>>>> possibly SimpleConnectionManager as well) will keep the connection 
>>>>> alive and reuse it for subsequent HTTP requests.  Is there a way 
>>>>> to set a limit on how long the connection should be kept alive 
>>>>> before waiting for a subsequent request to reuse that connection?
>>>>>
>>>>> Thanks,
>>>>> Sam
>>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>


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


Mime
View raw message