Play Framework 2.0.4 и BoneCP — как избежать утечки соединений?

В моем приложении есть только одно место, где используются соединения.
Это выглядит примерно так:

Connection conn = Db.getConnection();
try
{
    // do some job
}
finally
{
    conn.close();
}

Таким образом, соединение всегда закрыто.
Но через некоторое время я всегда получаю гораздо больше соединений, чем определено в конфигурацииbonecp...

Вопрос:
Есть ли четкое решение этой проблемы?
Может, стоит попробовать поиграть в framework 2.1?

Я действительно не могу понять, как некоторые люди без проблем используют этот фреймворк...

Конфигурация:

db.default.autocommit=true
db.default.isolation=READ_COMMITTED

db.default.partitionCount=3
db.default.minConnectionsPerPartition=6
db.default.maxConnectionsPerPartition=12
db.default.acquireIncrement=1

db.default.acquireRetryAttempts=5
db.default.acquireRetryDelay=50 milliseconds

db.default.connectionTimeout=50 milliseconds
db.default.idleMaxAge=3 minutes

db.default.idleConnectionTestPeriod=0
db.default.initSQL="SELECT 1"

db.default.logStatements=true
db.default.maxConnectionAge=10 minutes

db.default.releaseHelperThreads=0

Спасибо!


playframework playframework-2.0 connection-leaks bonecp
person Oleg Golovanov    schedule 08.12.2012    source источник

Ответы (4)


arrow_upward
1
arrow_downward

Также посмотрите на параметр poolThreshold. По умолчанию это установлено на 20% всех подключений (в версиях ‹ 0.8 я установил его по умолчанию на ноль от 0,8 и выше, потому что это многих удивляет).

Уоллес

person wwadge    schedule 10.12.2012
comment
Спасибо за совет, но это не помогает. Я настроил BoneCP на использование максимум 24 соединений, но через 10 часов он использовал все 50 доступных... - person Oleg Golovanov; 13.12.2012
comment
Какую версию BoneCP вы используете? Последняя версия на данный момент: 0.8.0-rc1 - person wwadge; 17.12.2012
comment
Я использую play framework 2.0.4, который поставляется с BoneCP 0.7.1 :) В настоящее время я решил свою проблему, перезапуская сервер каждые несколько часов. В любом случае, спасибо! - person Oleg Golovanov; 18.12.2012

arrow_upward
0
arrow_downward

Насколько я понимаю, conn.close() на самом деле не закрывает соединение. Вместо этого он освобождает соединение обратно в пул соединений. Пул соединений всегда пытается иметь minConnections, в вашем случае 6 на раздел, к базе данных.

Это может быть причиной того, что «всегда получайте гораздо больше подключений», но так оно и должно работать.

person Franz    schedule 10.12.2012
comment
Да, conn.close() не закрывает соединение, а возвращает его в пул. Вы не поняли проблему: я настроил BoneCP для использования максимум N подключений, но он использует больше, чем N. - person Oleg Golovanov; 13.12.2012

arrow_upward
0
arrow_downward

попробуйте с BoneCP 0.8.0-rc1 и используйте эту конфигурацию:

db.default.idleMaxAge=10 minutes
db.default.idleConnectionTestPeriod=35 seconds
db.default.connectionTimeout=20 second
db.default.connectionTestStatement="SELECT 1"
db.default.maxConnectionAge=30 minutes
person Marco    schedule 15.03.2013
comment
Не могли бы вы объяснить, почему это может помочь? - person cdmckay; 09.12.2013

arrow_upward
0
arrow_downward

Я столкнулся с той же проблемой после развертывания моего веб-сайта на Amazon.

Пробное решение 1

использовать

Connection conn = Db.withConnection(); //instead of DB.getConnection()

Если это не сработает, используйте последнюю версию BoneCp и добавьте ее в свой SBT. (Очевидно, были проблемы с тем, как BoneCP обрабатывает Connection.)

val appDependencies = Seq(
"com.jolbox" % "bonecp" % "0.8.0-rc2-SNAPSHOT-20130712-14382677.jar",
....

val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA).settings(
  libraryDependencies += "com.jolbox" % "bonecp" % "0.8.0-rc2-SNAPSHOT-20130712-14382677.jar" from "https://dl.dropboxusercontent.com/u/36714110/libraries/bonecp-patches/bonecp-0.8.0-rc2-SNAPSHOT-20130712-14382677.jar"
,resolvers += ...

Обратитесь к странице boneCP GitHub, где упоминается эта проблема.

И, пожалуйста, дайте мне знать, если это поможет вам.

person Incpetor    schedule 15.08.2014