目录
1. 概述 3
1.1 概述： 3
1.2 系统信息： 3
2. 连接池问题 5
2. 1 问题描述 5
2.2 错误日志分析 5
2.3连接池问题总结 14
3. 其他问题 14
3. 1 部署 14
3. 1 部署类型 15
 
1. 概述
1.1 概述：
应客户的要求，某局BATCH系统存在的问题进行诊断。经过日志分析及故障现象定位造成问题的原因，形成此份报告。
为了提供系统的稳定和性能，建议针对性的修改一些参数(会在报告中详述)，在下次重启Server时付诸实施。如果需要疑惑的问题，
1.2 系统信息：
1) 版本信息
WebLogic Version：WebLogic Server Temporary Patch for CR370091 Tue Jul 08 17:31:21 EDT 2008 WebLogic Server Temporary Patch for CR370915 Tue Jul 15 14:36:25 IST 2008 WebLogic Server 10.0 MP1 Thu Oct 18 20:17:44 EDT 2007 1005184
Java Version：IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc64-64 j9vmap6423-20071007 (JIT enabled)
2) 架构信息
各节点属于单独被管节点，未在同一集群中
3) 连接池配置
4) 故障连接池SCDS配置
 
 
2. 连接池问题
2. 1 问题描述
 
如上图所示SCDS连接池，在Weblogic服务启动后，BATCH4节点连接池不能按预期配置的初始建立80个连接。服务运行一段时候间后Current Capacity容量保持在40左右，运行一段时间后部分业务不可用，必须重启服务。查看中间件后台日志信息，发现日志中存在大量与连接池错误有关日志。
2.2 错误日志分析
1）网络闪断问题
####<2014-8-23 上午01时41分37秒 GMT+08:00> <Error> <JDBC> <nw_cpees_pichuli_3> <BATCH4> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1408729297399> <BEA-001112> <Test "SELECT 1 FROM DUAL" set up for pool "SCWWDS4" failed with exception: "java.sql.SQLException: Io 异常: Connection reset".> 
####<2014-9-3 上午02时52分43秒 GMT+08:00> <Error> <JDBC> <nw_cpees_pichuli_3> <BATCH4> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1409683963815> <BEA-001112> <Test "SELECT 1 FROM DUAL" set up for pool "SCWWDS4" failed with exception: "java.sql.SQLException: Io 异常: Connection reset".>
####<2014-9-5 上午12时55分00秒 GMT+08:00> <Error> <JDBC> <nw_cpees_pichuli_3> <BATCH4> <Sched_cpees_Worker-32> <<anonymous>> <> <> <1409849700178> <BEA-001112> <Test "SELECT 1 FROM DUAL" set up for pool "SCWWDS4" failed with exception: "java.sql.SQLException: Io 异常: Connection reset".> 
####<2014-9-13 上午01时33分30秒 GMT+08:00> <Error> <JDBC> <nw_cpees_pichuli_3> <BATCH4> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1410543210281> <BEA-001112> <Test "SELECT 1 FROM DUAL" set up for pool "SCWWDS4" failed with exception: "java.sql.SQLException: Io 异常: Connection reset".> 
以上日志说明BATH4节点所使用的SCWWDS4连接池与数据库之间网络物理连接有闪断问题，可能存在网络不稳定状况，建议网络工程师在近期检查网络状况。
2）物理连接关闭
Weblogic Server日志：
####<2014-9-5 上午02时10分12秒 GMT+08:00> <Info> <JDBC> <nw_cpees_pichuli_3> <BATCH4> <Thread-2574368> <<anonymous>> <> <> <1409854212313> <BEA-001128> <Connection for pool "SCDS" closed.> 
在Weblogic Server日志中可以观察到大量的Connection for pool "SCDS" closed信息，表示系统在某一时刻会批量关闭一批连接，一般断掉物理连接会这么做（WebLogic 配置池收缩也会这么做，如果未配置的话默认为900s检查一次，从您的配置文件发现未配置池收缩）。从线程名称看，是应用程序的线程关闭了连接。且在应用日志发现有大量如下日志信息：
972102: 0E9F01ITRG2C594F: 220809998 INFO cn.gwssi.common.dao.ds.source.DBController(close:321) - [gwssi] 线程[972102]关闭数据库连接；连接时间:2014/09/15 08:30:20 143；关闭时间:2014/09/15 08:30:20 147
建议让开发人员检查程序，为什么要关闭物理连接。一般我们不建议应用程序直接管理连接池的连接，这些都是Weblogic自身管理的，不然容易造成混乱。应用程序只在需要时从连接池中获取连接，使用完成后调用connection.close()方法把连接还给池即可。（这里的close不是关闭连接物理连接，而是把连接还给连接池，以便应用程序再使用）
3）连接池参数不合理
Weblogic Server日志：
#####<2014-9-15 上午09时10分58秒 GMT+08:00> <Info> <Common> <nw_cpees_pichuli_3> <BATCH4> <Thread-973306> <<anonymous>> <> <> <1410743458081> <BEA-000628> <Created "1" resources for pool "SCDS", out of which "1" are available and "0" are unavailable.> 
在Weblogic Server日志中可以观察到大量的上述信息，表示系统业务高峰期时大量创建连接，另与现场工程师沟通发现出现过Reached maximum capacity of pool信息。可以看出当前连接池参数设置稍有不合理之处，建议将连接池最大值调整为120，步增长调整为5。
4）连接泄露
Weblogic Server日志：
####<2014-9-12 上午11时39分41秒 GMT+08:00> <Warning> <JDBC> <nw_cpees_pichuli_3> <BATCH4> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-
tuning)'> <<WLS Kernel>> <> <> <1410493181108> <BEA-001153> <Forcibly releasing inactive connection 
"weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@3c296c5" back into the connection pool "SCDS", currently reserved by: java.lang.Exception
at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:291)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:314)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:292)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:425)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:316)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:93)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:106)
at weblogic.jdbc.pool.Driver.connect(Driver.java:149)
at weblogic.jdbc.jts.Driver.getNonTxConnection(Driver.java:642)
at weblogic.jdbc.jts.Driver.connect(Driver.java:124)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:339)
at cn.gwssi.plugin.dao.datasource.db.ConnectSourceImpl.getConnection(ConnectSourceImpl.java:166)
at cn.gwssi.common.dao.ds.UserConnectionPool.getConnection(UserConnectionPool.java:68)
at cn.gwssi.common.dao.ds.ConnectFactory.getConnection(ConnectFactory.java:73)
at cn.gwssi.plugin.dao.datasource.table.TableImpl.getConnection(TableImpl.java:105)
at cn.gwssi.common.dao.func.RegisterSqlRowset.executeSql(RegisterSqlRowset.java:58)
at cn.gwssi.common.dao.iface.DaoFunction.execute(DaoFunction.java:293)
at cn.gwssi.common.dao.BaseTable.invokeRegisterMethod(BaseTable.java:567)
at cn.gwssi.common.dao.BaseTable.executeFunction(BaseTable.java:502)
at cn.gwssi.app.codemap.cache.method.MethodCodeDefine.loadCodeData(MethodCodeDefine.java:234)
at cn.gwssi.app.codemap.cache.method.MethodCodeDefine.getCodeSet(MethodCodeDefine.java:204)
at cn.gwssi.app.codemap.txn.TxnCodeList.txnFFFF02(TxnCodeList.java:58)
at cn.gwssi.common.txn.service.TxnBrokerApp.getValueListFromDao(TxnBrokerApp.java:272)
at cn.gwssi.common.web.proxy.application.PojoClient.getValueListFromDao(PojoClient.java:101)
at cn.gwssi.common.web.proxy.application.ApplicationTransactionClient.getValueListFromDao(ApplicationTransactionClient.java:217)
at cn.gwssi.common.web.proxy.TxnClient.getValueListFromDao(TxnClient.java:455)
at cn.gwssi.common.web.tag.util.ListData.getValueListFromDao(ListData.java:369)
at cn.gwssi.common.web.tag.util.ListData.getParamList(ListData.java:243)
at cn.gwssi.common.web.tag.export.FieldTagDefinition.getValueList(FieldTagDefinition.java:436)
at cn.gwssi.common.web.tag.export.FieldTagDefinition.getValueList(FieldTagDefinition.java:413)
at cn.gwssi.common.web.tag.util.BaseFieldTag.getValueList(BaseFieldTag.java:282)
at cn.gwssi.common.web.tag.select.SelectFieldTag.prepareOptions(SelectFieldTag.java:496)
at cn.gwssi.common.web.tag.select.SelectFieldTag.prepareListData(SelectFieldTag.java:407)
at cn.gwssi.common.web.tag.select.SelectFieldTag.prepareElement_in(SelectFieldTag.java:356)
at cn.gwssi.common.web.tag.util.BaseFieldTag.prepareElement(BaseFieldTag.java:749)
at cn.gwssi.common.web.tag.theme.BlockTheme.prepareField(BlockTheme.java:316)
at cn.gwssi.common.web.tag.frame.GblockTag.prepareField(GblockTag.java:620)
at cn.gwssi.common.web.tag.frame.GblockTag.createField(GblockTag.java:551)
at cn.gwssi.common.web.tag.util.BaseFieldTag.createElement(BaseFieldTag.java:777)
at cn.gwssi.common.web.tag.select.SelectFieldTag.doEndTag(SelectFieldTag.java:375)
at jsp_servlet._app._15_dwfw._rcgz._cepct.__query_45_tzscx._jsp__tag8(__query_45_tzscx.java:538)
at jsp_servlet._app._15_dwfw._rcgz._cepct.__query_45_tzscx._jsp__tag5(__query_45_tzscx.java:412)
at jsp_servlet._app._15_dwfw._rcgz._cepct.__query_45_tzscx._jsp__tag4(__query_45_tzscx.java:346)
at jsp_servlet._app._15_dwfw._rcgz._cepct.__query_45_tzscx._jsp__tag1(__query_45_tzscx.java:241)
at jsp_servlet._app._15_dwfw._rcgz._cepct.__query_45_tzscx._jsp__tag0(__query_45_tzscx.java:192)
at jsp_servlet._app._15_dwfw._rcgz._cepct.__query_45_tzscx._jspService(__query_45_tzscx.java:155)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:34)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:394)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:309)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at cn.gwssi.filter.SecurityFilter.doFilter(SecurityFilter.java:35)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3393)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2140)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2046)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
.>
 
####<2014-8-20 下午10时02分55秒 GMT+08:00> <Warning> <JDBC> <nw_cpees_pichuli_3> <BATCH4> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-
tuning)'> <<WLS Kernel>> <> <> <1408543375817> <BEA-001153> <Forcibly releasing inactive connection 
"weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@2f3223b" back into the connection pool "SCDS", currently reserved by: java.lang.Exception
at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:291)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:314)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:292)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:425)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:316)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:93)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:106)
at weblogic.jdbc.pool.Driver.connect(Driver.java:149)
at weblogic.jdbc.jts.Driver.getNonTxConnection(Driver.java:642)
at weblogic.jdbc.jts.Driver.connect(Driver.java:124)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:339)
at cn.gwssi.plugin.dao.datasource.db.ConnectSourceImpl.getConnection(ConnectSourceImpl.java:166)
at cn.gwssi.common.dao.ds.UserConnectionPool.getConnection(UserConnectionPool.java:68)
at cn.gwssi.common.dao.ds.ConnectFactory.getConnection(ConnectFactory.java:73)
at cn.gwssi.common.dao.ds.ConnectFactory.getConnection(ConnectFactory.java:52)
at cn.gwssi.common.ioc.component.DefaultDBConnection.getConnection(DefaultDBConnection.java:74)
at cn.gwssi.common.ioc.component.DefaultDBConnection.getConnection(DefaultDBConnection.java:91)
at cn.gwssi.common.dao.db.DBAccessor.getConnection(DBAccessor.java:64)
at cn.gwssi.common.dao.db.DBWriter.executeUpdate(DBWriter.java:51)
at cn.gwssi.common.dao.impl.BaseDAO.executeUpdate(BaseDAO.java:65)
at cn.gwssi.common.dao.impl.GWDAO.execute(GWDAO.java:42)
at cn.gwssi.common.scheduler.ScheduleLog.startLog(ScheduleLog.java:134)
at cn.gwssi.common.scheduler.AbstractStatefulJob.beginTracer(AbstractStatefulJob.java:72)
at cn.gwssi.common.scheduler.AbstractStatefulJob.execute(AbstractStatefulJob.java:30)
at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
.> 
从上述日志中可以看出，当前应用存在连接泄露。对该问题Oracle官方文档 （ID 1329416.1）对上述问题作出了具体解释，描述如下：
WebLogic Server JDBC Connections Being Forcibly Released with Error BEA-001153: Forcibly releasing inactive connection (文档 ID 1329416.1)
 
问题原因及解决办法:
 
根据Oracle官方解释，造成该类问题主要原因为：业务系统代码程序获取数据库连接，当完成业务处理后，没有使用代码显式地对该连接进行关闭（即还回池中，并非关闭物理连接），从而导致分配出去的连接不能回收到连接池中进行重用，最后引发数据库连接不足，应用出现无法使用或响应缓慢的问题。建议开发人员检查上述红色标注代码的业务主线，将调用连接的代码编写finally语句块进行关闭处理。
5）连接池被Disabled
12493: null: 220830934 ERROR $plugin.dao.datasource.connect.oracle.OracleConnection.getTxnException  445 - gwssi==>Connection has been administratively disabled. Try later.
java.sql.SQLException: Connection has been administratively disabled. Try later.
at cn.gwssi.plugin.dao.datasource.connect.oracle.OracleConnection.getTxnException(OracleConnection.java:471)
at cn.gwssi.common.dao.ds.source.DBController.getStatement(DBController.java:390)
at cn.gwssi.cpees.d_sf.xml.importfeerealtime.DbHelper.executeRowSet(Unknown Source)
at cn.gwssi.cpees.d_sf.xml.importfeerealtime.ValidateForSFRT.getFeiYongZlmcBydm(Unknown Source)
at cn.gwssi.cpees.d_sf.xml.importfeerealtime.ValidateForSFRT.preCheckAndGetPreCondition(Unknown Source)
at cn.gwssi.cpees.d_sf.xml.importfeerealtime.BatchUseFeeForSFRT.useFeeRealTime(BatchUseFeeForSFRT.java:49)
at cn.gwssi.cpees.d_sf.xml.importfeerealtime.ScanFeeRealTime.txnScanFeeRTime(ScanFeeRealTime.java:34)
at cn.gwssi.cpees.d_sf.xml.importfeerealtime.ScanFeeRealTimeService.__callService(Unknown Source)
at cn.gwssi.cpees.d_sf.xml.importfeerealtime.ScanFeeRealTimeService.__doService(Unknown Source)
at cn.gwssi.common.txn.service.Step.process(Step.java:98)
at cn.gwssi.common.txn.service.Action.doService(Action.java:306)
at cn.gwssi.common.txn.service.Action.callService(Action.java:205)
at cn.gwssi.common.txn.iface.ActionUtil.callService(ActionUtil.java:57)
at cn.gwssi.common.scheduler.ControlJob.perform(ControlJob.java:69)
at cn.gwssi.common.scheduler.AbstractJob.execute(AbstractJob.java:30)
at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Caused by: 
java.sql.SQLException: Connection has been administratively disabled. Try later.
at weblogic.jdbc.common.internal.ConnectionEnv.checkIfEnabled(ConnectionEnv.java:770)
at weblogic.jdbc.wrapper.PoolConnection.checkConnection(PoolConnection.java:56)
at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:83)
at weblogic.jdbc.wrapper.Connection.createStatement(Connection.java:453)
at cn.gwssi.plugin.dao.datasource.db.wrap.ConnectionX.createStatement(ConnectionX.java:43)
at cn.gwssi.common.dao.ds.source.DBController.getStatement(DBController.java:384)
... 15 more
上述日志出现不久后，连接池被disabled，导致应用获取不到连接，大量线程等待数据库连接。见如下日志：
weblogic.jdbc.extensions.PoolDisabledSQLException: weblogic.common.resourcepool.ResourceDisabledException: Pool SCDS is disabled, cannot allocate resources to applications..
at cn.gwssi.plugin.dao.datasource.db.ConnectSourceImpl.getConnection(ConnectSourceImpl.java:169)
at cn.gwssi.common.dao.ds.UserConnectionPool.getConnection(UserConnectionPool.java:68)
at cn.gwssi.common.dao.ds.ConnectFactory.getConnection(ConnectFactory.java:73)
at cn.gwssi.plugin.dao.datasource.table.TableImpl.getConnection(TableImpl.java:105)
at cn.gwssi.plugin.dao.datasource.table.function.prepare.PrepareFunction.getSqlClause(PrepareFunction.java:48)
at cn.gwssi.common.dao.iface.SqlMethod.getStatement(SqlMethod.java:55)
at cn.gwssi.common.dao.method.SqlInsert.getSqlStatement(SqlInsert.java:77)
at cn.gwssi.common.dao.method.SqlInsert.doService(SqlInsert.java:104)
at cn.gwssi.common.dao.method.SqlInsert.execute(SqlInsert.java:125)
at cn.gwssi.common.dao.method.SqlInsert.execute(SqlInsert.java:137)
at cn.gwssi.cpees.d_sf.sflog.TxnAsyncLog.txn04scanfeert(Unknown Source)
at cn.gwssi.cpees.d_sf.sflog.TxnAsyncLogService.__callService(Unknown Source)
at cn.gwssi.cpees.d_sf.sflog.TxnAsyncLogService.__doService(Unknown Source)
at cn.gwssi.common.txn.service.Step.process(Step.java:98)
at cn.gwssi.common.txn.service.Action.doService(Action.java:306)
at cn.gwssi.common.txn.service.Action.callService(Action.java:205)
at cn.gwssi.plugin.jms.JmsTransaction.process1(JmsTransaction.java:174)
at cn.gwssi.plugin.jms.JmsTransaction.process(JmsTransaction.java:106)
at cn.gwssi.plugin.jms.AsyncService$Worker.run(AsyncService.java:91)
at java.lang.Thread.run(Thread.java:810)
Caused by: 
weblogic.jdbc.extensions.PoolDisabledSQLException: weblogic.common.resourcepool.ResourceDisabledException: Pool SCDS is disabled, cannot allocate resources to applications..
at weblogic.jdbc.common.internal.JDBCUtil.wrapAndThrowResourceException(JDBCUtil.java:241)
at weblogic.jdbc.pool.Driver.connect(Driver.java:160)
at weblogic.jdbc.jts.Driver.getNonTxConnection(Driver.java:642)
at weblogic.jdbc.jts.Driver.connect(Driver.java:124)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:339)
at cn.gwssi.plugin.dao.datasource.db.ConnectSourceImpl.getConnection(ConnectSourceImpl.java:166)
... 19 more
该问题属于Weblogic 在该版本已知bug，官方文档
java.sql.SQLException: Connection has been administratively disabled. Try later. (文档 ID 1211143.1) 对问题进行了详细的描述
问题版本与症状：
 
引起的原因：
 
引起该问题有两种原因：
（1）数据库不可用导致
（2）Weblogic bug导致
 
针对cause1，建议数据库工程师检查数据库，是否存在较为严重问题导致数据库中间件连接中断。
针对Cause2、Cause3建议为该版本Weblogic打Patch 8174835、 Patch 8188896补丁。
 2.3连接池问题总结
根据Oracle官方解释及日志表象，建议后续从以下几方面着手（后续操作建议按给出的先后顺序操作）。
（1）建议网络工程师排查网络，在近期是否有网络不稳定现象。
（2）建议让开发人员检查程序，不建议应用程序直接管理连接池的连接。
（3）建议数据库工程师检查数据库，排查数据库是否存在异常，是否存在较为严重问题导致数据库中间件连接中断。
（4）当前应用程序再使用SCDS数据源时存在连接泄露，建议开发商检查代码，编写finnally语句块进行处理。
（5）找到应用泄露点处理以后，根据Oracle官方文档ID 1211143.1建议为当前版本Weblogic打Patch 8174835、 Patch 8188896补丁。
（6）当前步增长值过小，业务高峰期时容易造成大量线程等待数据库连接，建议打补丁后先将步增长值由原来1个调整为5个。后续观察连接池使用情况，通过中间件控制台Service 》Data Source 》SCDS 》Monitor观察Active Connections High Count 属性，是否存在超过最大配置80现象，如若出现，势必会造成连接等待，建议由原来80增长为120.

通过监控发现是weblogic的连接池用完了，报Reached maximum capacity of pool错误开始怀疑是数据库中存在性能差的SQL。但经过两天监控，没有发现数据库有什么异常；调整连接池的回收机制，没有发现未关闭的连接。

目前情况并没有得到改善，用户量大的情况下3~4小时会有一个节点连接池用完。下午下班的时候重启所有的节点，也撑不过一个晚上，第二天早上所有的节点的连接池都会用完。

通过监控发现连接池的一个连接对应着该节点上的一个线程阻塞。结合以往发现阻塞时的表现情况，我高度怀疑是网闸的问题。

我怀疑情况是这样的：用户的一个请求发给应用，转发到某个节点，节点向数据库提出请求，申请到连接，但没有将请求传给数据库，中途被网闸拦截了。

网上绝大部分针对线程阻塞的分析，都认为是数据库的性能问题，而目前数据库性能没有问题。而且以前我们数据库有性能问题时，不仅仅时连接池用完，节点的线程也会用光，整个应用连登录页都无法打开。

   结合到近期应用没有做什么大的升级，只是修改了两个前端页面，而大的升级正是升级了网闸。另外用户数量压力过大的说法也是不成立的，晚上和周未的用户量比不上平时的高峰时段。
   跟客户的网管把情况一分析，网管把网闸重启了一次，问题没有解决。后来他突然明白，新上的防火墙有限制长连接的功能，原来的防火墙没有这个功能。他把防火墙的长连接放开，问题就解决了。

WebLogic Server中数据库连接池是一个经常出问题的地方，总结一下出问题的原因和解决办法。

一、数据库连接泄漏
此类问题一般都是由于开发人员没有正确关闭数据库连接造成的。比如使用完Connection后，没有调用Connection.close()方法。

1、诊断方法
在Console中，找到Connection Pools Tab 和Diagnostics，设置以下属性（不同版本可能略有区别）
Enable Connection Leak Profiling 启用连接池泄漏的监控。
Enable Connection Profiling 启用连接池监控。
Inactive Connection Timeout 100 表示100秒后强制回收无效连接。默认0，表示使用完才释放回连接池。
无需重启，查看server的log，查找“A JDBC pool connection leak was detected”，如果有，看看是哪个类引起的。下面是一个数据库连接泄漏的例子：
A JDBC pool connection leak was detected.
A connection leak occurs when a connection obtained from the pool was not closed explicitly by 
calling close() and then was disposed by the garbage collector and returned to the connection pool.
The following stack trace at create shows where the leaked connection was created.
Stack trace at connection create:
at weblogic.jdbc.wrapper.JTAConnection.init(JTAConnection.java:90)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:468)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:410)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:344)
at troubleshooting.servlets.JdbcConnections.service(JdbcConnections.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1077)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:7047)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3902)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2773)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
问题解决后，把三个属性设置回先前的值。
2、解决方法
正确的关闭数据库连接。具体代码如下：
Connection conn = null;
ResultSet rs = null;
preparedStatement pss = null;
try {
conn = dataSource.getConnection(USERID,pASSWORD);
pss = conn.prepareStatement("SELECT SAVESERIALZEDDATA FROM SESSION.pINGSESSION3DATA WHERE 
SESSIONKEY = ?");
pss.setString(1,sessionKey);
rs = pss.executeQuery();
pss.close();
}
catch (Throwable t) {} 
finally {
try 
{
if (conn != null) conn.close();
} 
catch (Exception e){}
}


二、数据库连接不够用

导致数据库连接不够用的原因主要有：
①某些程序占用connection时间过长，如果多个用户同时使用这些程序，则会导致连接不够用。
②线程死锁，无法释放connection。
1、诊断方法
①监控参数：Waiting For Connection High Count
[domain_name]-> Enviroment -> Servers -> [Server] -> Monitoring -> JDBC查看参数：Waiting For Connection High Count
如果没有此参数，手工添加进来，该参数表示在没有可用连接的情况下，应用程序等待连接的最大个数。调整后的连接池最大值 = 调整前的连接池最大值 + Waiting For Connection High Count。一般来说，数据库连接池的大小与最佳并发用户数相当。

②在Server Log中，明确抛出下列异常：
java.sql.SQLException: Internal error: Cannot obtain XAConnection 
weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool 
BankConnectionPool to allocate to applications, please increase the size of the pool and retry..
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1493)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:455)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:410)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:344)
at troubleshooting.servlets.JdbcConnections.service(JdbcConnections.java:80)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1077)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:7047)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3902)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2773)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
如果此时观察connection的监控，会发现所有connection 都是Active，而且还有大量请求等待connection。
2、解决方法
①提高Maximum Capacity数量，该值一般略大于峰值情况下的数据库连接数。Services > JDBC > Connection Pools > BankConnectionPool > Configuration > Connections
②重点检查synchronize代码段和涉及数据库锁的代码。如果有必要，可以查看thread dump，看看线程在忙什么和等什么。

三、数据库连接使用超时
此类问题一般是由于某些数据库操作时间比较长，超过了Inactive connection timeout的设置。
1、诊断方法
在Server Log中，明确有下列提示，并且在提示后抛出应用异常：
Forcibly releasing inactive resource "weblogic.jdbc.common.internal.ConnectionEnv@132967d" back into the pool BankConnectionPool".这里无法列出应用异常，因为每个应用都不一样，不过很有可能会抛出空指针异常，因为Connection被强制放回池中了，继续使用一个空对象会抛出该异常。
2、解决方法
在高级参数中，提高Inactive connection timeout数量。
Services > JDBC > Connection Pools > BankConnectionPool > Configuration > Connections

四、事务超时
此类问题一般是由于某些数据库操作时间比较长，超过了JTA Timeout Seconds的设置。
1、诊断方法
在Server Log中，明确抛出异常：
weblogic.transaction.internal.TimedOutException: Transaction timed out after 300 seconds
2、解决方法
提高Services > JTA Configuration > Timeout Seconds数量。
注意这个参数应该小于Inactive connection timeout的值，因为事务必须在连接超时前完成。如果想分析究竟是哪些SQL语句导致事务超时，可以打开日志AdminServer > Logging > JDBC，选中Enable JDBC Logging，并设置JDBC Log File Name。