You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Michael Becke <mb...@ppr.info> on 2004/06/01 03:14:07 UTC
Re: Connection Accounting Problem
Hi Satya,
Sorry for the slow response... The number of connections in use does
not get decremented in this case as no connections are actually being
destroyed. The connection manager still holds references to the same
number of connections after closeIdleConnections() is called.
connectionsInUse is meant to detail the number of connections that have
been allocated, not the number that are open. Given these semantics
the behavior is correct I believe.
The next question is if this makes sense. I see two possibilities here:
1) Document getConnectionsInUse() to better describe the current
behavior.
2) Change closeIdleConnections() to delete closed connections. This
will require changes to the IdleConnectionHandler, so that we know
which connections are closed.
Any suggestions or preferences?
Mike
On May 27, 2004, at 5:27 PM, http-client@jrapid.com wrote:
> After Calling
> MultiThreadedHttpConnectionManager.closeIdleConnections(idleTime), the
> timedout connections are closed, however, connectinon count does not
> decrease.
> Therefore, if I call
> MultiThreadedHttpConnectionManager.getConnectionsInUse(), I still get
> the same value as before calling closeIdleConnections(). After a bit
> of code browsing the problem seems to be in the following code:
> public synchronized void closeIdleConnections(long idleTimeout) {
> idleConnectionHandler.closeIdleConnections(idleTimeout);
> }
> Which does not decrease the number of connections after actually
> removing them.
> The code should be:
> public synchronized void closeIdleConnections(long idleTimeout) {
> idleConnectionHandler.closeIdleConnections(idleTimeout);
>
> //Now do the connection accounting (Pseudo code)
> numConnections = idleConnectionHandler.getConnectionsCount();
>
> //Also adjust the hostPool.numConnections
> }
> Any taker?
> --Satya
>
> ---------------------------------------------------------------------
> 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
Re: Connection Accounting Problem
Posted by ht...@jrapid.com.
Hello Mike,
getConnectionsInPool() is certainly a more intutive name.
At the same, as you already mentioned, certainly there need to be a
connection killer method:
MultiThreadedHttpConnectionManager.destroyIdleConnections(long idleTime)
Also, I would recommend one method which could spit out connection
statistics at any time for the given Connection Manager. This will be great
method for testing purpose as well.
MultiThreadedHttpConnectionManager.displayCurrentStatistics();
----------------------------------
Curent Connection Statistics
----------------------------------
Total connectinos in Pool = 10
Open connectinos = 3
Close connections = 5
Stale connections = 2
And, if are even more adventurous we could extend our report to:
Average wait time for connection = 1356 ms
Maximum wait time for connectino = 1892 ms
-Satya
==============
Michael Becke writes:
> Hi Roland,
>
> Sounds like a good plan to me. I will deprecate getConnectionsInUse() and
> replace it with a better name. getConnectionsInPool() is good, perhaps
> also getConnectionsAllocated()?
>
> For deleting connections I think we have two options. One is to kill all
> closed connections. The only problem here is that we will end up calling
> isOpen()->iStale() on all the connections. Another possibility to is kill
> all connections that are currently not being used. This would be all
> connections currently held by the connection manager.
>
> Mike
>
> Roland Weber wrote:
>> Hi Mike,
>>
>> deprecate "getConnectionsInUse()",
>> replace with "getConnectionsInPool()" ?
>>
>> Introduce something like
>> "garbageCollectConnections()" or
>> "deleteIdleConnections()"
>> for people who really want to throw
>> away the closed connections ?
>>
>> I'd stick with your option 1 until there
>> is a case where the other behavior is
>> actually needed.
>>
>> cheers,
>> Roland
>>
>>
>>
>>
>>
>> Michael Becke <mb...@ppr.info>
>> 01.06.2004 03:14
>> Please respond to "Commons HttpClient Project"
>> To: "Commons HttpClient Project"
>> <co...@jakarta.apache.org>
>> cc: Subject: Re: Connection Accounting Problem
>>
>>
>> Hi Satya,
>>
>> Sorry for the slow response... The number of connections in use does not
>> get decremented in this case as no connections are actually being
>> destroyed. The connection manager still holds references to the same
>> number of connections after closeIdleConnections() is called.
>> connectionsInUse is meant to detail the number of connections that have
>> been allocated, not the number that are open. Given these semantics the
>> behavior is correct I believe.
>>
>> The next question is if this makes sense. I see two possibilities here:
>>
>> 1) Document getConnectionsInUse() to better describe the current
>> behavior.
>> 2) Change closeIdleConnections() to delete closed connections. This
>> will require changes to the IdleConnectionHandler, so that we know which
>> connections are closed.
>>
>> Any suggestions or preferences?
>>
>> Mike
>>
>>
>> On May 27, 2004, at 5:27 PM, http-client@jrapid.com wrote:
>>
>>
>>> After Calling
>>> MultiThreadedHttpConnectionManager.closeIdleConnections(idleTime), the
>>> timedout connections are closed, however, connectinon count does not
>>> decrease.
>>> Therefore, if I call
>>> MultiThreadedHttpConnectionManager.getConnectionsInUse(), I still get
>>> the same value as before calling closeIdleConnections(). After a bit of
>>> code browsing the problem seems to be in the following code:
>>> public synchronized void closeIdleConnections(long idleTimeout) {
>>> idleConnectionHandler.closeIdleConnections(idleTimeout);
>>> }
>>> Which does not decrease the number of connections after actually
>>> removing them.
>>> The code should be:
>>> public synchronized void closeIdleConnections(long idleTimeout) {
>>> idleConnectionHandler.closeIdleConnections(idleTimeout);
>>>
>>> //Now do the connection accounting (Pseudo code)
>>> numConnections = idleConnectionHandler.getConnectionsCount();
>>>
>>> //Also adjust the hostPool.numConnections
>>> }
>>> Any taker?
>>> --Satya
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: Connection Accounting Problem
Posted by Michael Becke <be...@u.washington.edu>.
Hi Roland,
Sounds like a good plan to me. I will deprecate getConnectionsInUse()
and replace it with a better name. getConnectionsInPool() is good,
perhaps also getConnectionsAllocated()?
For deleting connections I think we have two options. One is to kill
all closed connections. The only problem here is that we will end up
calling isOpen()->iStale() on all the connections. Another possibility
to is kill all connections that are currently not being used. This
would be all connections currently held by the connection manager.
Mike
Roland Weber wrote:
> Hi Mike,
>
> deprecate "getConnectionsInUse()",
> replace with "getConnectionsInPool()" ?
>
> Introduce something like
> "garbageCollectConnections()" or
> "deleteIdleConnections()"
> for people who really want to throw
> away the closed connections ?
>
> I'd stick with your option 1 until there
> is a case where the other behavior is
> actually needed.
>
> cheers,
> Roland
>
>
>
>
>
> Michael Becke <mb...@ppr.info>
> 01.06.2004 03:14
> Please respond to "Commons HttpClient Project"
>
> To: "Commons HttpClient Project"
> <co...@jakarta.apache.org>
> cc:
> Subject: Re: Connection Accounting Problem
>
>
> Hi Satya,
>
> Sorry for the slow response... The number of connections in use does
> not get decremented in this case as no connections are actually being
> destroyed. The connection manager still holds references to the same
> number of connections after closeIdleConnections() is called.
> connectionsInUse is meant to detail the number of connections that have
> been allocated, not the number that are open. Given these semantics
> the behavior is correct I believe.
>
> The next question is if this makes sense. I see two possibilities here:
>
> 1) Document getConnectionsInUse() to better describe the current
> behavior.
> 2) Change closeIdleConnections() to delete closed connections. This
> will require changes to the IdleConnectionHandler, so that we know
> which connections are closed.
>
> Any suggestions or preferences?
>
> Mike
>
>
> On May 27, 2004, at 5:27 PM, http-client@jrapid.com wrote:
>
>
>>After Calling
>>MultiThreadedHttpConnectionManager.closeIdleConnections(idleTime), the
>>timedout connections are closed, however, connectinon count does not
>>decrease.
>>Therefore, if I call
>>MultiThreadedHttpConnectionManager.getConnectionsInUse(), I still get
>>the same value as before calling closeIdleConnections(). After a bit
>>of code browsing the problem seems to be in the following code:
>>public synchronized void closeIdleConnections(long idleTimeout) {
>> idleConnectionHandler.closeIdleConnections(idleTimeout);
>>}
>>Which does not decrease the number of connections after actually
>>removing them.
>>The code should be:
>>public synchronized void closeIdleConnections(long idleTimeout) {
>> idleConnectionHandler.closeIdleConnections(idleTimeout);
>>
>> //Now do the connection accounting (Pseudo code)
>> numConnections = idleConnectionHandler.getConnectionsCount();
>>
>> //Also adjust the hostPool.numConnections
>>}
>>Any taker?
>>--Satya
>>
>>---------------------------------------------------------------------
>>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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: Connection Accounting Problem
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Mike,
deprecate "getConnectionsInUse()",
replace with "getConnectionsInPool()" ?
Introduce something like
"garbageCollectConnections()" or
"deleteIdleConnections()"
for people who really want to throw
away the closed connections ?
I'd stick with your option 1 until there
is a case where the other behavior is
actually needed.
cheers,
Roland
Michael Becke <mb...@ppr.info>
01.06.2004 03:14
Please respond to "Commons HttpClient Project"
To: "Commons HttpClient Project"
<co...@jakarta.apache.org>
cc:
Subject: Re: Connection Accounting Problem
Hi Satya,
Sorry for the slow response... The number of connections in use does
not get decremented in this case as no connections are actually being
destroyed. The connection manager still holds references to the same
number of connections after closeIdleConnections() is called.
connectionsInUse is meant to detail the number of connections that have
been allocated, not the number that are open. Given these semantics
the behavior is correct I believe.
The next question is if this makes sense. I see two possibilities here:
1) Document getConnectionsInUse() to better describe the current
behavior.
2) Change closeIdleConnections() to delete closed connections. This
will require changes to the IdleConnectionHandler, so that we know
which connections are closed.
Any suggestions or preferences?
Mike
On May 27, 2004, at 5:27 PM, http-client@jrapid.com wrote:
> After Calling
> MultiThreadedHttpConnectionManager.closeIdleConnections(idleTime), the
> timedout connections are closed, however, connectinon count does not
> decrease.
> Therefore, if I call
> MultiThreadedHttpConnectionManager.getConnectionsInUse(), I still get
> the same value as before calling closeIdleConnections(). After a bit
> of code browsing the problem seems to be in the following code:
> public synchronized void closeIdleConnections(long idleTimeout) {
> idleConnectionHandler.closeIdleConnections(idleTimeout);
> }
> Which does not decrease the number of connections after actually
> removing them.
> The code should be:
> public synchronized void closeIdleConnections(long idleTimeout) {
> idleConnectionHandler.closeIdleConnections(idleTimeout);
>
> //Now do the connection accounting (Pseudo code)
> numConnections = idleConnectionHandler.getConnectionsCount();
>
> //Also adjust the hostPool.numConnections
> }
> Any taker?
> --Satya
>
> ---------------------------------------------------------------------
> 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