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 <[EMAIL PROTECTED]>
01.06.2004 03:14
Please respond to "Commons HttpClient Project"
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
