Question

这是环境：

Java 5
在Windows上运行Tomcat 6.0.18的Web应用程序（不确定版本）
数据库：SQL Server 2008 R2
JDBC驱动程序：jTDS 1.2.5
连接池提供商：C3P0 0.9.1.2

我正在尝试调试客户端所遇到的问题。基本上每隔几周，我们的Web应用程序就锁定在他们的服务器上，他们无法访问它。重启可以解决问题。进一步调查显示，所有内容都被锁定的原因是一切都在等待数据库连接返回。我认为问题可能出在SQL Server上，而不是C3P0。

我认为正在发生的是C3P0的“空闲检查查询”正在悬挂。查询是这样的：

select * from c3p0_connection_test_table

看起来这个查询运行了，结果永远不会返回。这是我在线程转储中看到的内容。请注意DefaultConnectionTester.activeCheckConnection()，这是空闲检查：

"com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2" daemon prio=6 tid=0x0000000007c32000 nid=0x1250 runnable [0x000000001072f000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at java.io.DataInputStream.readFully(DataInputStream.java:178)
    at java.io.DataInputStream.readFully(DataInputStream.java:152)
    at net.sourceforge.jtds.jdbc.SharedSocket.readPacket(SharedSocket.java:841)
    at net.sourceforge.jtds.jdbc.SharedSocket.getNetPacket(SharedSocket.java:722)
    - locked <0x000000016ac03f48> (a java.util.ArrayList)
    at net.sourceforge.jtds.jdbc.ResponseStream.getPacket(ResponseStream.java:466)
    at net.sourceforge.jtds.jdbc.ResponseStream.read(ResponseStream.java:103)
    at net.sourceforge.jtds.jdbc.ResponseStream.peek(ResponseStream.java:88)
    at net.sourceforge.jtds.jdbc.TdsCore.wait(TdsCore.java:3928)
    at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCore.java:1045)
    - locked <0x000000016d965268> (a net.sourceforge.jtds.jdbc.TdsCore)
    at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQLQuery(JtdsStatement.java:465)
    at net.sourceforge.jtds.jdbc.JtdsStatement.executeQuery(JtdsStatement.java:1301)
    at com.mchange.v2.c3p0.impl.DefaultConnectionTester.activeCheckConnection(DefaultConnectionTester.java:73)
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.testPooledConnection(C3P0PooledConnectionPool.java:374)
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.refurbishIdleResource(C3P0PooledConnectionPool.java:310)
    at com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask.run(BasicResourcePool.java:1999)
    at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)

但是什么可能导致这样一个简单的查询挂起来从套接字读取？我不相信这个表上会有任何数据库锁定，因为它完全由C3P0管理，从不插入/更新。此外，任何失败的尝试从池中获取连接（如果这是挂起的原因），我会期望在某处的堆栈跟踪。相反，我看到的是应用程序只是锁定，因为所有未来的连接请求都在等待这个“空闲检查”完成。

以下是等待“空闲检查”完成的其中一个线程：

    "http-80-3" daemon prio=6 tid=0x0000000007c33800 nid=0x122c in Object.wait() [0x000000001082d000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:579)
    - locked <0x0000000167a88a60> (a com.mchange.v2.resourcepool.BasicResourcePool)
    at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:477)
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525)
    at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128)
    at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:81)
    at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
    at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167)
    at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:142)
    at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:85)
    at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1354)
    at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:555)
    at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:371)
    at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
    at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
    at $Proxy15.getTransaction(Unknown Source)
    at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:317)
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:105)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
    at $Proxy79.getCrowdProperties(Unknown Source)
    at com.jamasoftware.contour.gateway.crowd.CrowdSsoServices.autoLogin(Unknown Source)
    at com.jamasoftware.contour.security.AutoLoginServicesManager.autoLogin(Unknown Source)
    at org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:74)
    at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
    at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
    at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:277)
    at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
    at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
    at com.jamasoftware.contour.view.filter.CheckSetupFilter.doFilter(Unknown Source)
    at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
    at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
    at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
    at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
    at org.springframework.security.concurrent.ConcurrentSessionFilter.doFilterHttp(ConcurrentSessionFilter.java:99)
    at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
    at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
    at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
    at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
    at com.jamasoftware.contour.view.filter.ExpirationFilter.doFilter(Unknown Source)
    at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
    at com.jamasoftware.contour.view.filter.GzipFilter.doFilter(Unknown Source)
    at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
    at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:175)
    at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
    at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
    at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:864)
    at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
    at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1665)
    at java.lang.Thread.run(Thread.java:619)

从C3P0的源代码看，顶部有两行：

at java.lang.Object.wait(Native Method)
at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:579)

...仅在连接等待“空闲检查”时才会发生。

不幸的是，这是一个客户端，我无法在此报告环境的具体细节。但是我可以在下次电话会议上向他们提出任何建议。

更新：

他们的申请今天再次被锁定。以下是我们迄今为止尝试过的事情：

他们已更新至最新的jTDS驱动程序（1.2.5）
我已将连接字符串上的socketTimeout属性设置为300但是5分钟后驱动程序仍然卡在socketRead0（）上
我们将有效检查查询从“select * from c3p0_connection_test_table”更改为“select 1”
我们已将unreturnedConnectionTimeout和debugUnreturnedConnectionStackTraces属性添加到C3P0（但这些属性并未捕获断开的连接）

以下是我们设置的所有C3P0连接属性：

    <property name="minPoolSize" value="1"/>
    <property name="maxPoolSize" value="30"/>
    <property name="acquireIncrement" value="3"/>
    <property name="automaticTestTable" value="c3p0_connection_test_table"/>
    <property name="idleConnectionTestPeriod" value="30"/>
    <property name="testConnectionOnCheckin" value="true"/>
    <property name="testConnectionOnCheckout" value="true"/>

发生了一件奇怪的事情，当应用程序被锁定时，我们尝试使用应用程序用户登录SQL Server Management Studio，它不会让我们进入（我认为这只是一个正常的超时错误）。数据库已启动并正在侦听端口1433（使用telnet验证），因此我认为这意味着已达到数据库的最大连接数。不过，我不确定这是否有助于确定此问题的原因。

潜在客户未成功：

This person操作系统存在问题，可能是服务器上的NIC卡数量
下面的回答者向我指出旧版jTDS中的错误here

有用的答案可以要求我检查客户机器上的某些内容，或者指出可能的根本原因。无论什么答案有助于我追踪这一点，我们将获得赏金。

Answer 1

第一个想法：检查他们是否使用最新的jTDS版本，SQL Server已修补并更新到最新的SP！

有一些关于jTDS错误跟踪中此类行为的报告，最值得注意的是this one。显然，SQL Server正在关闭连接，但jTDS没有注意到。

在较新版本的jTDS中，有一个socketTimeout property（默认= 0），这可能会有所帮助。

您还可以测试不同的JDBC驱动程序。

Answer 2

在sql server中检查 - 属性 - 连接 - “使用查询调控器来阻止长时间运行的查询”被禁用

Answer 3

当使用jtds连接到sql server时，我遇到了类似的问题，c3p0（0.9.1）挂起。

我通过不使用c3p0来解决它，只要我需要使用DriverManager打开一个连接。我确信它不是那么高效，但它确实有效。

Answer 4

在测试连接时是否还有另一个线程关闭连接？看起来像C3P0在c3p0-0.9.2-pre3中修复了这个：

- PooledConnections的必需测试，以拥有相关的锁和那些 PooledConnections以防止PooledConnection.close（）偶尔出现死锁与Connection测试一致。非常感谢匿名的SourceForge用户提请注意这个问题。

来自：https://github.com/swaldman/c3p0/blob/master/src/dist-static/CHANGELOG

带有C3P0连接检查的jTDS套接字（SQL Server 2008 R2）

4 个答案: