Grails 2.3.4池空。无法在30秒内获取连接

时间:2014-01-28 08:42:15

标签: tomcat grails gorm

我们在tomcat 7.0.30中有grails应用程序破坏。 Grails版本为2.2.4,去年运行非常稳定。 我试图将grails版本切换到2.3.4,在测试环境中它表现正常(没有任何问题)。 但是当我在20分钟后投入生产时,我开始得到以下例外

[ajp-bio-9009-exec-430] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:100; busy:100; idle:0; lastwait:30000].. Stacktrace follows:
org.apache.tomcat.jdbc.pool.PoolExhaustedException: [ajp-bio-9009-exec-430] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:100; busy:100; idle:0; lastwait:30000].
        at grails.gorm.DetachedCriteria$_count_closure4.doCall(DetachedCriteria.groovy:686)
        at grails.gorm.DetachedCriteria$_withPopulatedQuery_closure10.doCall(DetachedCriteria.groovy:931)
        at org.grails.datastore.gorm.GormStaticApi$_withDatastoreSession_closure20.doCall(GormStaticApi.groovy:680)
        at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:302)
        at org.grails.datastore.gorm.AbstractDatastoreApi.execute(AbstractDatastoreApi.groovy:37)
        at org.grails.datastore.gorm.GormStaticApi.withDatastoreSession(GormStaticApi.groovy:679)
        at grails.gorm.DetachedCriteria.withPopulatedQuery(DetachedCriteria.groovy:913)
        at grails.gorm.DetachedCriteria.count(DetachedCriteria.groovy:684)
        at grails.gorm.DetachedCriteria.count(DetachedCriteria.groovy:683)
        at com.webbfontaine.wftaglib.BeanDataLoadController.doLoadData(BeanDataLoadController.groovy:30)
        at com.webbfontaine.wftaglib.BeanDataLoadController$_closure1.doCall(BeanDataLoadController.groovy:14)
        at grails.plugin.cache.web.filter.PageFragmentCachingFilter.doFilter(PageFragmentCachingFilter.java:195)
        at grails.plugin.cache.web.filter.AbstractFilter.doFilter(AbstractFilter.java:63)
        at org.josso.tc70.agent.SSOAgentValve.invoke(SSOAgentValve.java:684)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)

在我们的应用程序中,所有对DB的查询都是通过Grails GORM完成的,我们不使用任何SQL或HQL查询。

我的猜测是grails 2.3.4本身出了问题(某些连接未正确关闭/返回池中)。

我错过了什么或它的grails问题? 有什么想法吗?

3 个答案:

答案 0 :(得分:5)

Grails 2.3.x replaced Commons DBCP with Tomcat JDBC,这可能是您的申请有所不同的原因。您可以检查池配置的差异。

答案 1 :(得分:5)

a few bugs in Grails in dataSource default settings。这些问题将在Grails 2.3.6中修复。

以下是MySQL

的优化数据源设置示例
dataSource {
    pooled = true
    dbCreate = "update"
    url = "jdbc:mysql://localhost:3306/my_database"
    driverClassName = "com.mysql.jdbc.Driver"
    dialect = org.hibernate.dialect.MySQL5InnoDBDialect
    username = "username"
    password = "password"
    properties {
       // Documentation for Tomcat JDBC Pool
       // http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Common_Attributes
       // https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html
       jmxEnabled = true
       initialSize = 5
       maxActive = 50
       minIdle = 5
       maxIdle = 25
       maxWait = 10000
       maxAge = 10 * 60000
       timeBetweenEvictionRunsMillis = 5000
       minEvictableIdleTimeMillis = 60000
       validationQuery = "SELECT 1"
       validationQueryTimeout = 3
       validationInterval = 15000
       testOnBorrow = true
       testWhileIdle = true
       testOnReturn = false
       ignoreExceptionOnPreLoad = true
       // http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#JDBC_interceptors
       jdbcInterceptors = "ConnectionState;StatementCache(max=200)"
       defaultTransactionIsolation = java.sql.Connection.TRANSACTION_READ_COMMITTED // safe default
       // controls for leaked connections 
       abandonWhenPercentageFull = 100 // settings are active only when pool is full
       removeAbandonedTimeout = 120
       removeAbandoned = true
       // use JMX console to change this setting at runtime
       logAbandoned = false // causes stacktrace recording overhead, use only for debugging
       // JDBC driver properties
       // Mysql as example
       dbProperties {
           // Mysql specific driver properties
           // http://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html
           // let Tomcat JDBC Pool handle reconnecting
           autoReconnect=false
           // truncation behaviour 
           jdbcCompliantTruncation=false
           // mysql 0-date conversion
           zeroDateTimeBehavior='convertToNull'
           // Tomcat JDBC Pool's StatementCache is used instead, so disable mysql driver's cache
           cachePrepStmts=false
           cacheCallableStmts=false
           // Tomcat JDBC Pool's StatementFinalizer keeps track
           dontTrackOpenResources=true
           // performance optimization: reduce number of SQLExceptions thrown in mysql driver code
           holdResultsOpenOverStatementClose=true
           // enable MySQL query cache - using server prep stmts will disable query caching
           useServerPrepStmts=false
           // metadata caching
           cacheServerConfiguration=true
           cacheResultSetMetadata=true
           metadataCacheSize=100
           // timeouts for TCP/IP
           connectTimeout=15000
           socketTimeout=120000
           // timer tuning (disable)
           maintainTimeStats=false
           enableQueryTimeouts=false
           // misc tuning
           noDatetimeStringSync=true
       }
    }
}

答案 2 :(得分:2)

我首先检查是否存在“卡住”的线程并保持数据库连接。您可以从JVM threaddump中看到这一点。

您可以通过向Java进程PID发送SIGQUIT(3)信号在unix中执行线程转储。 您可以使用“kill -3 PID”命令执行此操作。 threaddump转到stdout(默认情况下会转到tomcat上的catalina.out)。它不会终止Java进程,因此您通常可以在生产环境中使用此方法。

获取threaddump的另一种方法是使用“jstack PID”命令。

通常值得做一些后续转储几秒钟的一部分。通过这种方式,您可以对转储进行区分,以查看哪些更改以及哪些更改保持不变。您通常必须手动进行差异化。