Connection is not closed when releasing if connectionHandle is expired
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
BoneCP |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Hello,
Last week, we observed some unexpected behavior using bonecp. Our max connections were set to 10 (5 max per partition, 2 partitions), but over the course of half an hour, the number of connections reached 40.
However, bonecp reported that it only had 10 connections. When garbage collection was performed, the 'extra' connections were cleaned up.
This seemed strange, so we started looking into it. Eventually, we found the culprit. In BoneCP.
{code}
protected void internalRelease
// snip
if (connectionHand
&& !isConnectionHa
ConnectionPa
postDestroyC
maybeSignalF
connectionHa
return; // don't place back in queue - connection is broken or expired.
}
// snip
}
{code}
As you can see, this code does not actually _close_ the connection, it assumes it is already closed and therefore calls the postDestroyConn
However, this code might also be executed if the connection is not closed yet. This can happen if the connectionHandle is expired (i.e., the maxConnectionAge has passed), in which case the connection might still be open and will not be closed by here. Which leads such a connection to be released from the pool (i.e. BoneCP does not see it anymore), but still be open (which explains the increase in connections past the maxConnection level).
If you agree that this is a bug, we can supply a patch for it.
Regards, Geert
P.S. We use bonecp 0.7.1.RELEASE
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in bonecp: | |
status: | New → Fix Committed |
Changed in bonecp: | |
status: | Fix Committed → Fix Released |
I encountered the same problem. Moreover, under certain conditions pool stucks forever in getConnection method because of this error.