示例 2：使用 wsadmin 脚本诊断常见连接管理器使用问题此示例说明如何使用 connection manager 诊断提供程序的状态转储功能。
为了方便地进行与诊断提供程序的可重复交互，可以采用 wsadmin 脚本。在此示例中，将使用 wsadmin 脚本访问 Connection Manager 诊断提供程序，以了解与连接使用相关的问题。第一步是使用 wsadmin 查找相应的诊断提供程序 MBean。为了方便起见，所有诊断提供程序 MBean 都在其 JMX 对象名称中包含 diagnosticProvider=true，以便以下脚本片段列出所有可用诊断提供程序：
清单 1. Jython 脚本 listObjectNames.py，用于输出名称中包含 diagnosticProvider=true 的 MBean1
2
3
| dpObjectNames = AdminControl.queryNames('diagnosticProvider=true,*')
print dpObjectNames
|
清单 1 中的脚本可以使用以下命令通过 wsadmin 执行：
wsadmin -lang jython -f listObjectNames.py
所得到的结果与以下所示类似：
清单 2. 在非联合服务器上运行 DiagnosticProvider=true 脚本的输出1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| WASX7209I: Connected to process "server1" on node don7Node03 using SOAP connector;
The type of process is: UnManagedProcess
WebSphere:name=Default Datasource,process=server1,platform=dynamicproxy,node=don7Node03,
JDBCProvider=Derby JDBC Provider,diagnosticProvider=true,j2eeType=JDBCDataSource,
J2EEServer=server1,Server=server1,version=6.1.0.0,type=DataSource,mbeanIdentifier=cells
/don7Node03Cell/nodes/don7Node03/servers/server1/resources.xml#DataSource_1156718666915,
JDBCResource=Derby JDBC Provider,cell=don7Node03Cell,spec=1.0
WebSphere:name=DefaultEJBTimerDataSource,process=server1,platform=dynamicproxy,node=
don7Node03,JDBCProvider=Derby JDBC Provider (XA),diagnosticProvider=true,j2eeType=
JDBCDataSource,J2EEServer=server1,Server=server1,version=6.1.0.0,type=DataSource,
mbeanIdentifier=cells/don7Node03Cell/nodes/don7Node03/servers/server1/resources.xml
#DataSource_1000001,JDBCResource=Derby JDBC Provider (XA),cell=don7Node03Cell,spec=1.0
WebSphere:name=PLANTSDB,process=server1,platform=dynamicproxy,node=don7Node03,JDBCProvider
=Samples Derby JDBC Provider (XA),diagnosticProvider=true,j2eeType=JDBCDataSource,
J2EEServer=server1,Server=server1,version=6.1.0.0,type=DataSource,mbeanIdentifier=cells
/don7Node03Cell/nodes/don7Node03/servers/server1/resources.xml#DataSource_1156718677751,
JDBCResource=Samples Derby JDBC Provider (XA),cell=don7Node03Cell,spec=1.0
WebSphere:name=Runtime Advisor,process=server1,platform=dynamicproxy,node=don7Node03,
diagnosticProvider=true,reInit="Des:reinitialize the Runtime Performance Advisor.
#DesLookup:perfTuningAdmin.operation.reInit.des",version=6.1.0.0,type=ServerRule
DriverMBean,mbeanIdentifier=ServerRuleDriverMBean2,cell=don7Node03Cell,spec=1.0,
perfTuningAdmin.operation.takeHeapDump="Des:Triggers IBM JDK to take a multiple heap
dumps based upon downward trends in memory#DesLookup:perfTuningAdmin.operation.
takeHeapDump.des"
WebSphere:name=WebcontainerDiagnosticProvider,process=server1,platform=dynamicproxy,node=
don7Node03,diagnosticProvider=true,version=6.1.0.0,type=WebcontainerDiagnosticProvider,
mbeanIdentifier=null,cell=don7Node03Cell,spec=1.0
|
在清单 2 中，可以看到给出了多个包含 j2eeType=JDBCDataSource 的对象名称这些对象名称与连接管理器数据源 MBean 的名称对应。清单 3 显示了用于对 PLANTSDB 数据源诊断提供程序执行格式化状态转储的 Jython 代码。
清单 3. 用于从 PLANTSDB 数据源诊断提供程序生成格式化状态转储的 Jython 脚本1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| import javax.management.ObjectName
import java.util.Locale
# find JMX object name for DiagnosticService MBean -- provides formatting helper methods
dsObjectName = AdminControl.queryNames('type=DiagnosticService,*')
# find JMX object name for specific diagnosticProvider MBean we're interested in
dpObjectName = AdminControl.queryNames('name=PLANTSDB,*')
# turn on all state collection for connection manager diagnostic providers
result = AdminControl.invoke_jmx(javax.management.ObjectName(dsObjectName),
'setStateCollectionSpec', ['ConnMgrDP.*:.*=1'],['java.lang.String'])
# invoke the stateDump on the diagnostic provider
result = AdminControl.invoke_jmx(javax.management.ObjectName(dsObjectName),
'stateDumpFormattedById', [dpObjectName, '.*', java.lang.Boolean(0),
java.util.Locale('en_US')], ['java.lang.String', 'java.lang.String',
'boolean', 'java.util.Locale'])
print result[0]
|
其输出可能与以下所示类似：
清单 4. PLANTSDB 数据源诊断提供程序的格式化状态转储输出1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| WASX7209I: Connected to process "server1" on node don7Node03 using SOAP connector;
The type of process is: UnManagedProcess
DiagnosticProviderId: ConnMgrDP_jdbc/PlantsByWebSphereDataSource
EventType: stateDump MessageKey: null
ResourceBundleName: null
Source Class: ConnectionFactoryMbeanImpl Source Method: stateDump ContentType: 1
Cell: don7Node03Cell Node: don7Node03 Server: server1 SrvDetail:
Item Concatenated Name Value
approximateNumberFreeConnections = 1
approximateNumberSharedConnections = 0
approximateNumberUnSharedConnections = 0
approximateNumberWaitingConnections = 0
connections-7e3a7e3a-destroyState = false
connections-7e3a7e3a-handleCount = 0
connections-7e3a7e3a-isParkedWrapper = false
connections-7e3a7e3a-isStale = false
connections-7e3a7e3a-managedConnection = WSRdbManagedConnectionImpl@6c3a6c3a
connections-7e3a7e3a-mcWrapperState = STATE_ACTIVE_FREE
connections-7e3a7e3a-poolState = STATE_ACTIVE_FREE
connections-7e3a7e3a-tranWrapperInUse = NONE
connections-7e3a7e3a-transactionId = null
inStuckConnectionMode = false
poolManagerObject = 526655332
quiesced = false
|
清单 4 中的输出列出了数据源的一些全局数据，然后给出了一些与数据源中当前处于活动状态的特定连接 (connections-7e3a7e3a) 关联的属性。
DiagnosticService MBean在清单 4 中，您会注意到我们没有直接访问连接管理器的诊断提供程序 stateDump 方法，而是调用了 DiagnosticService MBean 的 stateDumpFormattedById 方法。DiagnosticService 提供了一系列方法来帮助对从诊断提供程序返回的结果进行格式化。DiagnosticService MBean 的主要作用是格式化诊断提供程序输出和充当注册中心（以便查找在其上运行 DiagnosticService 的 JVM 中的任意诊断提供程序）。
您可能会发现以下 DiagnosticService 方法对于从诊断提供程序获取格式化的结果非常有用。其中的每个方法都接受诊断提供程序的 JMX 对象名称、属性列表（一个正则表达式，指示所感兴趣的属性，例如 connections-.*-transactionId）以及区域设置（用于选择用于进行格式化的恰当区域设置）作为参数：
- configDumpFormattedById(java.lang.String, java.lang.String, boolean, java.util.Locale)
- stateDumpFormattedById(java.lang.String, java.lang.String, boolean, java.util.Locale)
- selfDiagnosticFormattedById(java.lang.String, java.lang.String, boolean, java.util.Locale)
使用此信息诊断提供程序所生成的所有信息看起来似乎有些让人生畏。应该如何对其进行处理呢？以下是能够从此信息确定的两个典型情况：
- 单个事务使用了很多连接
应用程序中经常会报告连接池耗尽的问题。每个数据源和连接工厂都维护着自己的指向基础资源的连接池。当连接池中的所有资源都分配给了线程时，下一个从连接池请求连接的线程将必须等待。如果连接配置为共享且应用程序经过了恰当的编码能够进行共享，则数据源或连接工厂可以向多个调用方提供相同的托管连接。反过来，编码不合理的应用程序可能会使用相同资源的同一个连接池中的很多物理托管连接。在有些情况下，在从连接池请求连接时被阻塞的线程可能实际上就是持有相同资源的其他连接的线程，从而导致死锁的情况发生。通过分析 Connection Manager 诊断提供程序的状态输出，可以诊断一些常见的应用程序问题。
- 首先，您可能希望检查在特定数据源或 J2C 连接工厂的连接池中是否存在连接争用。为每个数据源或 J2C 连接工厂创建了不同的 Connection Manager 诊断提供程序，因此可以通过选择恰当的诊断提供程序来方便地重点处理所涉及的数据源或连接工厂。从数据源或连接工厂的诊断提供程序返回的侦听信息将通过 approximateNumberWaitingConnections 数据指示等待获得连接的线程数量。如果多个示例上等待连接的数量大于 0，则该资源可能存在争用。
- 下一步是检查相同的事务是否使用了多个托管连接。使用多个托管连接的事务之所以这样，可能是由于疏忽所致。connections-(connection-reference)-transactionId 值指示与特定托管连接关联的 transactionId。如果多个托管连接与同一个 transactionId 关联，则需要进行进一步分析。
当应用程序导致每个事务持有对相同资源的多个托管连接的引用时，该资源的可用连接池会在加载此应用程序时很快耗尽。可以采用很多方法来对此进行补救，通过重新配置或重新设计应用程序，但这些方法不在本文的讨论范畴之内（请参见）。
- 大量连接句柄
当不再需要连接而未将其关闭并返回到池中时，连接池也会很快耗尽。如果应用程序代码使用 UserTransaction 类显式地区分事务，然后却未能始终在完成后提交或回滚，则可能会出现这样的情况。
在这种情况下，由于事务未能恰当关闭，因此会找到一系列具有非空 connections-(connection-reference)-transactionId 值的连接。还会看到这些连接的 connections-(connection-reference)-handleCount 值大于 0。
|
