Tomcat игнорирует removeAbandonedTimeout и закрывает соединения в пуле - PullRequest
0 голосов
/ 24 октября 2018

Я работаю над Tomcat 7.0 с подключением JDBC к DB2 на as400 с использованием dbcp commons.Как только я загружаю сервер, он сразу же открывает и закрывает соединения с базой данных, игнорируя установленный мной 30-минутный параметр removeAbandonedTimeout.Я пробовал несколько настроек безрезультатно.Например, через 15 секунд он откроет 150 соединений и закроет 140 без видимой причины.Это приложение работает на старом сервере WebSphere, и оно не закрывает соединения, если они действительно не работают.

Вот моя конфигурация:

 <Resource name="MYDB"
          auth="Container"
          type="javax.sql.DataSource"
          factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"
          driverClassName="com.ibm.as400.access.AS400JDBCDriver"
          url="jdbc:as400://mydb.na.sysco.net;blockCriteria=2;dateFormat=iso;libraries=*LIBL;naming=system;errors=full"
          username="user"
          password="pass"
          maxActive="350"
          maxWait="180000"
          minIdle="10"
          maxIdle="50"
          testWhileIdle="true"
          validationQuery="select 1 from sysibm.sysdummy1"
          timeBetweenEvictionRunsMillis="34000"
          minEvictableIdleTimeMillis="1800000"
          removeAbandonedTimeout="1800"
          removeAbandoned="true"
          logAbandoned="true"/>

Когда система находится в режиме ожидания или толькоПара тестовых учетных записей ведет себя так, как и ожидалось, но как только я загружаю сервер, массивы открываются и закрываются сразу же.Например, он откроет 150 соединений и закроет 90 соединений за тот же 15-секундный интервал.Я читаю, что сокеты открываются и закрываются, что связано с началом и окончанием заданий QZ на as400 из моего программного обеспечения для мониторинга.Он будет постоянно делать это, пока используются соединения.

Это побеждает назначение пулов соединений.Любые мысли или идеи приветствуются.

Также сбивает с толку, потому что не ясно, с какими параметрами мне следует использовать для начала.Параметры dbcp commons, которые являются уникальными из параметров пула соединений JDBC Tomcat, не принимаются, т. Е. RemoveAbandonedOnMaintenance.Но значение по умолчанию 1800000 для minEvictableIdleTimeMillis выбрано, а не 60000 из параметров пула Tomcat jdbc.

https://commons.apache.org/proper/commons-dbcp/api-1.2.2/index.html

https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

Когда я не явноустановить параметры, это то, что я получаю по умолчанию.Похоже, в нем перечислены все параметры пула tomcat jdbc, а не параметры общего ресурса DBCP.Однако он выбирает значение по умолчанию для minEvictableIdleTimeout из общего ресурса DBCP, а не 60 секунд из параметров пула соединений Tomcat JDBC.Чужая часть - это параметр removeAbandoned, который не указан для dbcp общего ресурса, это - removeAbandonedOnMaintenance и removeAbandonedOnBorrow.Я уже неделю пытаюсь прижать это желе к стене.

Я использую jmxproxy для получения статистики и настроек в реальном времени.

http://myserver:8080/manager/jmxproxy/?qry=Catalina%3Atype%3DDataSource%2C*

Name: Catalina:type=DataSource,class=javax.sql.DataSource,name="EOPDB"
modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
maxIdle: 8
testOnBorrow: false
defaultTransactionIsolation: -1
testOnReturn: false
maxActive: 350
numActive: 104
numTestsPerEvictionRun: 3
minIdle: 0
maxWait: 180000
closed: false
defaultAutoCommit: true
numIdle: 8
validationQueryTimeout: -1    
testWhileIdle: false
driverClassName: com.ibm.as400.access.AS400JDBCDriver
accessToUnderlyingConnectionAllowed: false
url: jdbc:as400://mydb;blockCriteria=2;dateFormat=iso;libraries=*LIBL;naming=system;errors=full
removeAbandonedTimeout: 300
defaultReadOnly: false
logAbandoned: false
poolPreparedStatements: false
maxOpenPreparedStatements: -1
removeAbandoned: false
minEvictableIdleTimeMillis: 1800000
timeBetweenEvictionRunsMillis: -1
initialSize: 0

Ответы [ 2 ]

0 голосов
/ 25 октября 2018

maxIdle - максимальное количество соединений, которые могут оставаться незанятыми в пуле.Как только число незанятых соединений пересекает maxIdle, любое соединение, выпущенное приложением, немедленно закрывается без проверки времени простоя соединения для minEvictableIdleTimeMillis.

0 голосов
/ 25 октября 2018

Есть 2 значения, которые могут быть потенциально проблематичными в вашем сценарии

      timeBetweenEvictionRunsMillis="34000"
      removeAbandoned="true"

timeBetweenEvictionRunsMillis
- это 34 секунды, в вашем сценарии было создано 150 соединений в серединеэтот период и 90 были уничтожены, когда пришло время, оставив в пуле 60 соединений, почти 50 из которых были запрошены maxIdle = 50Выглядит непропорционально по сравнению с minEvictableIdleTimeMillis , поскольку вы ожидаете, что простаивающее соединение будет жить 30 минут (1800000 мс) в пуле, но вы будете проверять каждые 34 секунды, не предпринимая никаких действий, поскольку соединения должны жить намного дольше.

removeAbandonedTimeout Это заставляет ваше приложение выполнять запросы быстрее, чем за 1,8 секунды.

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

Убедитесь, что ваше приложение правильно возвращает соединения в пул, они будут считаться заброшенными и закрытыми.
Надеюсь, это поможет.

Варианты объяснены здесь .

...