| 2012-05-14 12:53:17 |
Geert Gerritsen |
bug |
|
|
added bug |
| 2012-05-14 12:54:30 |
Geert Gerritsen |
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.internalReleaseConnection(), the following happens:
protected void internalReleaseConnection(ConnectionHandle connectionHandle) throws SQLException {
// snip
if (connectionHandle.isExpired() || (!this.poolShuttingDown && connectionHandle.isPossiblyBroken()
&& !isConnectionHandleAlive(connectionHandle))){
ConnectionPartition connectionPartition = connectionHandle.getOriginatingPartition();
postDestroyConnection(connectionHandle);
maybeSignalForMoreConnections(connectionPartition);
connectionHandle.clearStatementCaches(true);
return; // don't place back in queue - connection is broken or expired.
}
// snip
}
As you can see, this code does not actually close the connection, it assumes it is already closed and therefore calls the postDestroyConnection() method.
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 |
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.internalReleaseConnection(), the following happens:
protected void internalReleaseConnection(ConnectionHandle connectionHandle) throws SQLException {
// snip
if (connectionHandle.isExpired() || (!this.poolShuttingDown && connectionHandle.isPossiblyBroken()
&& !isConnectionHandleAlive(connectionHandle))){
ConnectionPartition connectionPartition = connectionHandle.getOriginatingPartition();
postDestroyConnection(connectionHandle);
maybeSignalForMoreConnections(connectionPartition);
connectionHandle.clearStatementCaches(true);
return; // don't place back in queue - connection is broken or expired.
}
// snip
}
As you can see, this code does not actually close the connection, it assumes it is already closed and therefore calls the postDestroyConnection() method.
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 |
|
| 2012-05-14 12:54:51 |
Geert Gerritsen |
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.internalReleaseConnection(), the following happens:
protected void internalReleaseConnection(ConnectionHandle connectionHandle) throws SQLException {
// snip
if (connectionHandle.isExpired() || (!this.poolShuttingDown && connectionHandle.isPossiblyBroken()
&& !isConnectionHandleAlive(connectionHandle))){
ConnectionPartition connectionPartition = connectionHandle.getOriginatingPartition();
postDestroyConnection(connectionHandle);
maybeSignalForMoreConnections(connectionPartition);
connectionHandle.clearStatementCaches(true);
return; // don't place back in queue - connection is broken or expired.
}
// snip
}
As you can see, this code does not actually close the connection, it assumes it is already closed and therefore calls the postDestroyConnection() method.
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 |
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.internalReleaseConnection(), the following happens:
{code}
protected void internalReleaseConnection(ConnectionHandle connectionHandle) throws SQLException {
// snip
if (connectionHandle.isExpired() || (!this.poolShuttingDown && connectionHandle.isPossiblyBroken()
&& !isConnectionHandleAlive(connectionHandle))){
ConnectionPartition connectionPartition = connectionHandle.getOriginatingPartition();
postDestroyConnection(connectionHandle);
maybeSignalForMoreConnections(connectionPartition);
connectionHandle.clearStatementCaches(true);
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 postDestroyConnection() method.
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 |
|
| 2012-05-14 12:55:06 |
Geert Gerritsen |
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.internalReleaseConnection(), the following happens:
{code}
protected void internalReleaseConnection(ConnectionHandle connectionHandle) throws SQLException {
// snip
if (connectionHandle.isExpired() || (!this.poolShuttingDown && connectionHandle.isPossiblyBroken()
&& !isConnectionHandleAlive(connectionHandle))){
ConnectionPartition connectionPartition = connectionHandle.getOriginatingPartition();
postDestroyConnection(connectionHandle);
maybeSignalForMoreConnections(connectionPartition);
connectionHandle.clearStatementCaches(true);
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 postDestroyConnection() method.
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 |
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.internalReleaseConnection(), the following happens:
[code]
protected void internalReleaseConnection(ConnectionHandle connectionHandle) throws SQLException {
// snip
if (connectionHandle.isExpired() || (!this.poolShuttingDown && connectionHandle.isPossiblyBroken()
&& !isConnectionHandleAlive(connectionHandle))){
ConnectionPartition connectionPartition = connectionHandle.getOriginatingPartition();
postDestroyConnection(connectionHandle);
maybeSignalForMoreConnections(connectionPartition);
connectionHandle.clearStatementCaches(true);
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 postDestroyConnection() method.
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 |
|
| 2012-05-14 12:55:29 |
Geert Gerritsen |
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.internalReleaseConnection(), the following happens:
[code]
protected void internalReleaseConnection(ConnectionHandle connectionHandle) throws SQLException {
// snip
if (connectionHandle.isExpired() || (!this.poolShuttingDown && connectionHandle.isPossiblyBroken()
&& !isConnectionHandleAlive(connectionHandle))){
ConnectionPartition connectionPartition = connectionHandle.getOriginatingPartition();
postDestroyConnection(connectionHandle);
maybeSignalForMoreConnections(connectionPartition);
connectionHandle.clearStatementCaches(true);
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 postDestroyConnection() method.
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 |
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.internalReleaseConnection(), the following happens:
{code}
protected void internalReleaseConnection(ConnectionHandle connectionHandle) throws SQLException {
// snip
if (connectionHandle.isExpired() || (!this.poolShuttingDown && connectionHandle.isPossiblyBroken()
&& !isConnectionHandleAlive(connectionHandle))){
ConnectionPartition connectionPartition = connectionHandle.getOriginatingPartition();
postDestroyConnection(connectionHandle);
maybeSignalForMoreConnections(connectionPartition);
connectionHandle.clearStatementCaches(true);
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 postDestroyConnection() method.
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 |
|
| 2012-08-06 09:07:59 |
Geert Gerritsen |
attachment added |
|
To be applied to the 0.7.1.RELEASE branch https://bugs.launchpad.net/bonecp/+bug/999114/+attachment/3249837/+files/Fix-for-bug-999114.patch |
|
| 2012-08-06 20:02:27 |
Wallace Wadge |
bonecp: status |
New |
Fix Committed |
|
| 2014-08-12 12:46:10 |
Irioth |
bonecp: status |
Fix Committed |
Fix Released |
|
