Oracle® Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite 11g Release 1 (11.1.1.7) Part Number E10226-17 |
|
|
PDF · Mobi · ePub |
This chapter describes how to diagnose Oracle SOA Suite problems early and take the proper corrective actions with the assistance of the WebLogic Diagnostic Framework (WLDF) for monitoring diagnostic scenarios using watches and notifications and the Oracle Fusion Middleware Diagnostic Framework for gathering SOA-specific diagnostic scenarios into data dumps that are formatted for viewing and analyzing.
This chapter includes the following sections:
For information about troubleshooting, see Appendix B, "Troubleshooting Oracle SOA Suite and Oracle BPM Suite."
Note:
The information in this chapter applies only to Oracle databases. Your experience may differ if using a non-Oracle database.
When you monitor and diagnose problems in Oracle SOA Suite, you face the following challenges:
Capturing diagnostic data at the moment of occurrence (also known as just-in-time diagnostics), especially for intermittent issues such as obtaining multiple thread dumps when the system hangs or obtaining heap dumps before a system runs out of memory.
Obtaining advanced information such as data shape (counts by state and growth patterns for the SOA schema and MDS schema).
Communicating back and forth with Oracle Support Services to provide basic information such as versions, logs, configuration files, patches applied, and so on.
Detecting problems and taking corrective actions early before they escalate.
To address these challenges, Oracle SOA Suite is integrated with the following diagnostic frameworks that assist you in identifying problems early and taking the proper corrective actions:
WLDF: For monitoring diagnostic scenarios using watches and notifications.
Diagnostic Framework: For gathering SOA-specific diagnostic scenarios into data dumps that are formatted for viewing and analyzing. These data dumps can be made accessible through the Support Work Bench and uploadable as part of a service request (SR).
WLDF is a monitoring and diagnostics framework included with Oracle WebLogic Server that defines and implements a set of services that run within server processes and participate in the standard server life cycle.
Using WLDF, you can capture diagnostic data from Oracle SOA Suite. You configure WLDF watches and notifications from Oracle WebLogic Server Administration Console to collect diagnostic data to identify problems. This data enables you to isolate and diagnose faults when they occur.
For more information about WLDF, see Oracle Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server.
Watches monitor server and application states and send notifications based on criteria that you set. Watches and notifications are configured as part of a diagnostic module targeted to one or more server instances in a domain. When you create a watch, you build rule expressions for monitoring using the attributes of Oracle SOA Suite and Oracle WebLogic Server MBeans in Oracle WebLogic Server Administration Console.
For example, assume you want to be notified when the percentage of free heap memory falls below 100%. You create a watch that uses the Oracle WebLogic Server MBean weblogic.management.runtime.JRockitRuntimeMBean
and its attribute HeapFreePercent
. You then define logic indicating that when HeapFreePercent
is less than 100%, you want to receive a notification. You can also use the MBean JVMRuntimeMBean
when running with a non-JRockit virtual machine (VM).
For information about creating watches and notifications in Oracle WebLogic Server Administration Console, see Section 12.5, "Creating Watches and Notifications" and Section "Configuring the Diagnostic Framework" of Oracle Fusion Middleware Administrator's Guide.
The watch rule expressions that you create use the attributes of Oracle SOA Suite and Oracle WebLogic Server MBeans to collect data and perform monitoring. You diagnose scenarios with available MBeans to provide statistics about that scenario or to log messages. Managed beans (MBeans) are Java objects that represent JMX manageable resources in a distributed environment. The attributes of the following MBeans are available for defining in watches to monitor scenarios:
Oracle WebLogic Server MBeans
Diagnostic Oracle SOA Suite MBeans
Dynamic Monitoring Service (DMS) metrics exposed as MBeans
Oracle SOA Suite provides several diagnostic scenarios that you can monitor with watches and notifications. Table 12-1 provides details about the supported diagnostic scenarios and the MBeans to use for monitoring.
Table 12-1 Supported Diagnostic Scenarios and MBeans
Scenario | Description | Diagnostic Data Source |
---|---|---|
Memory issues (startup, deployment, and runtime) |
Monitor the free heap available. If the free heap percentage is below a threshold, a notification is triggered to generate a thread stack dump and heap dump. |
Oracle WebLogic Server MBean |
Deployment hanging |
Monitor the elapsed time of a deployment. If it exceeds a threshold, a notification is triggered. |
Oracle SOA Suite deployment MBean |
Data source issues |
Monitor the suspension and connection pool/transaction timeouts |
JDBC MBeans |
Server overload |
Monitor the server's self-health. |
Oracle WebLogic Server MBean |
Stuck threads |
Monitor stuck threads. If any are found, a notification is triggered. |
A stuck thread watch/Diagnostic Framework notification is automatically included. Diagnostic Framework incident packages can be created with a tool such as the ADR Command Interpreter (ADRCI). Incidents are created automatically. |
Table 12-2 lists some of the available MBeans and DMS Metrics to select when creating watches for monitoring and collecting diagnostic data.
Table 12-2 MBeans and DMS Metrics
Diagnostic Data Source (MBean) and Usage | Description | Oracle WebLogic Server MBean | SOA MBean or DMS Metric |
---|---|---|---|
|
For memory statistics |
Yes |
- - |
|
For deployment elapsed time |
- - |
SOA MBean |
|
For health state information |
Yes |
- - |
|
For JDBC data sources and for accessing transaction runtime characteristics |
Yes |
- - |
For more information about Oracle WebLogic Server MBeans, see Oracle Fusion Middleware Oracle WebLogic Server MBean Reference.
The Diagnostic Framework is an Oracle Fusion Middleware feature that aids in detecting, diagnosing, and resolving problems. The problems that are targeted are critical errors such as those caused by code bugs, metadata corruption, customer data corruption, deadlocked threads, and inconsistent state. The Diagnostic Framework detects critical failures and captures dumps of relevant diagnostics information (logs, metrics, server images, and so on). WLDF watches and notifications trigger events for which the Diagnostic Framework listens and generates appropriate data dumps. The dumps are formatted into incident packages for viewing and analysis.
The problems captured as incidents include critical errors such as those described in Table 12-1. Each incident package is identified by a unique ID. When a critical error occurs, it is assigned this unique ID known as an incident number. Diagnostic data for the error (such as log files) is immediately captured and tagged with this number.
The data is then stored in the Automatic Diagnostic Repository (ADR). ADR is a file-system repository for cataloging occurrences of failures and storage of associated diagnostic data. The data is retrieved by incident package number, formatted, viewed with Oracle database tools such as ADRCI, and analyzed.
ADRCI enables you to view the names of the dump files and the alert log with XML tags stripped. This viewing enables you to investigate problems, and package and upload first-failure diagnostic data to Oracle Support Services.
You can also use the Diagnostic Framework WLST commands to perform the following tasks:
Query problems
View incident dump files
Create manual incidents
Manually execute dumps
The Diagnostic Framework is supported on all JRF-supported platforms.
The Diagnostic Framework automatically includes several dumps. For information about these dumps, see Section "Investigating, Reporting, and Solving a Problem" of Oracle Fusion Middleware Administrator's Guide.
In addition to these dumps, several Oracle SOA Suite dumps are also supported. For information about Oracle SOA Suite dumps, see Section 12.2, "Executing Oracle SOA Suite Diagnostic Dumps."
For more information about solving problems, incidents, and WLDF and Diagnostic Framework integration, see Chapter "Diagnosing Problems" of Oracle Fusion Middleware Administrator's Guide.
For more information about ADR, see Section 12.7, "Viewing Incident Packages with ADR Tools."
If you have a recurring problem in Oracle SOA Suite, this can cause for the creation of multiple incident packages. To prevent the server from being overloaded when many failures are occurring, the Diagnostic Framework automatically flood controls some incidents. To avoid this problem, you can configure the Diagnostic Framework to control the number of incident packages. For more information, see Section "Configuring the Diagnostic Framework" of Oracle Fusion Middleware Administrator's Guide.
When you create a watch in the Oracle WebLogic Server Administrator's Console, you also define a notification. A notification named FMWDFW notification is automatically available for selection. While you can create your own notifications, Oracle recommends that you select FMWDFW notification because it creates the Oracle SOA Suite dumps described in Section 12.2, "Executing Oracle SOA Suite Diagnostic Dumps."
When an error is detected, the FMWDFW notification handler creates an incident and the Diagnostic Framework takes over incident processing semantics. These semantics are controlled by incident processing rules. The incident processing rules are defined in an XML file and loaded and registered with the Diagnostic Framework during SOA Infrastructure startup.
If you encounter scenarios different from those listed in Table 12-1, you must work with Oracle Support Services to obtain a copy of the customized incident processing rules file.
You can configure a customized incident processing rules file through the Diagnostic Framework. Place the customized rules file in either of the following locations.
Server level configuration: FMW_HOME
/user_projects/
domains/
domain_name
/config/fmwconfig/servers/
server_name
/dfw
Domain level configuration: FMW_HOME
/user_projects/
domains/
domain_name
/config/fmwconfig
/dfw
The Diagnostic Framework automatically loads the file on server start up. All dumps are registered as system scoped unless an application name is prefixed to the file name:
myrules.xml
: System scoped. This means the rules file applies to all applications deployed on Oracle WebLogic Server.
application_name
#
name
.xml
: Application scoped. This means the rules file applies only to a specific SOA composite application. Everything before the #
is treated as the application name deployed in Oracle WebLogic Server (for example, loanApplication#custom-rules.xml
). If soa-infra#custom-rules.xml
is specified, it applies to all SOA composite applications deployed in the SOA Infrastructure.
For more information, see section "Configuring Custom Diagnostic Rules" of the Oracle Fusion Middleware Administrator's Guide.
Note:
While configuration in the SOA server home directory is supported for 11g Release 1 (11.1.1.7.0), Oracle Corporation recommends that you configure incident processing rules files through the Diagnostic Framework, as described in Section 12.1.3.1, "Configuring Incident Processing Rules Files Through the Diagnostic Framework."
Oracle Support Services can place a customized rules file (named custom-rules.xml
) under the SOA server instance home directory (for example, FMW_HOME
/user_projects/domains/
domain_name
/servers/
server_name
).
Example 12-1 shows a sample custom rules file. When an ERROR
level message is detected in the *-diagnostic.log
from the oracle.soa.bpel.engine.ws
module, the soa.composite.trail
dump is executed. A restart of the system to load the rules actually disturbs the accuracy of diagnostic data collected.
Example 12-1 Sample Custom Rules File
<?xml version="1.0" encoding="UTF-8"?>
<diagnosticRules xmlns="http://www.oracle.com/DFW/DiagnosticsFrameworkRules"
xmlns:xs="http://www.w3.org/2001/XMLSchema-instance">
<logDetectionConditions>
<condition module="oracle.soa.bpel.engine.ws"/>
</logDetectionConditions>
<defaultActions>
<dumpAction name="soa.composite.trail">
<argument name="ecid" value="ECID" valueType="Fact" mandatory="true"/>
</dumpAction>
</defaultActions>
</diagnosticRules>
In addition, you can dynamically load the rules file into the SOA Infrastructure without restarting the server. A dynamic reload is important because a server restart can disturb the accuracy of the diagnostic data collected.
To dynamically reload the file without restarting the server, enter the following WLST command:
wls:/soainfra/serverConfig> reloadCustomRules(name='rule_file')
For more information about reloadCustomRules
, see Chapter "Diagnostic Framework Custom WLST Commands" of Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
In addition to the diagnostic dumps available with Oracle WebLogic Server, Oracle SOA Suite supports the creation of the diagnostic dumps shown in Table 12-3.
Table 12-3 Oracle SOA Suite Diagnostic Dumps
Dump | Description |
---|---|
|
Runtime environment dumps. |
|
Runtime platform configuration dumps. |
|
Database dumps. |
|
Deployed composite metadata dumps. |
|
Instance audit trail dumps. |
|
Event dumps. |
|
Deployed composite WSDL/schema cache dumps. |
|
Static dumps (system, invoke, engine, and audit thread counts) and runtime scheduled and working message count dumps. |
|
Average instance processing time dumps. |
|
Average instance processing delay dumps (for asynchronous processes). |
|
Synchronous business processes dump statistics such as minimum, maximum, and average processing time (in milliseconds) and count of instances processed. |
|
Asynchronous BPEL process dump statistics such as minimum, maximum, and average processing time (in milliseconds) and count of instances processed. |
|
Request level dump statistics such as minimum, maximum, and average processing time (in milliseconds) and count of requests processed as the request flows though various layers of the BPEL process service engine. |
|
Resequencer group processing delay dumps. |
|
Adapter connection factory configurations. Use to identify if the same Java Naming and Directory Interface (JNDI) is being used by multiple composites. |
|
JCA adapter connection pool statistics and connection pool leaks. The current open connection statistics are displayed, enabling tuning of the connection pool. |
|
Adapter DMS statistics such as message size and fault count. |
The Diagnostic Framework outputs and records the diagnostic dumps. You can list details about all the diagnostic dumps with the WLST listDumps
and describeDump
commands.
Note:
You must start WLST
from MW_HOME
/oracle_common/common/bin
. Otherwise, the ODF functions are missing.
./wlst.sh
To list the dumps:
Connect to the server on which the SOA Infrastructure is installed.
wls:/offline> connect('user_name', 'password', 't3://myhost:8001') Connecting to t3://myhost:8001 with userid user_name ... Successfully connected to managed Server 'soa_server1' that belongs to domain 'soainfra'.
List the Diagnostic Framework dumps.
wls:/soainfra/serverConfig> listDumps() odl.activeLogConfig jvm.classhistogram dms.ecidctx jvm.flightRecording wls.image odl.logs dms.metrics odl.quicktrace http.requests jvm.threads Use the command describeDump(name=<dumpName>) for help on a specific dump.
List the Oracle SOA Suite dumps.
wls:/soainfra/serverConfig> listDumps(appName='soa-infra') adf.ADFConfigDiagnosticDump soa.composite soa.composite.trail soa.config soa.db soa.edn soa.env soa.wsdl bpel.dispatcher bpel.apt bpel.apd bpel.sps bpel.aps bpel.rs mediator.resequencer soa.adapter.ra soa.adapter.connpool soa.adapter.stats Use the command describeDump(name=<dumpName>) for help on a specific dump.
The Oracle SOA Suite dumps are described in the following subsections.
For more information about listDumps
and describeDump
, see Chapter "Diagnostic Framework Custom WLST Commands" of Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
For more information about Diagnostic Framework dumps, see Chapter "Diagnosing Problems" of Oracle Fusion Middleware Administrator's Guide.
Table 12-4 provides details about runtime environment diagnostic dumps.
Table 12-4 Runtime Environment Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
|
Enter the following WLST command line syntax to display a dump description and execute a dump of soa.env
.
wls:/soainfra/serverConfig> describeDump(name='soa.env', appName='soa-infra') Name: soa.env Description: SOA diagnostic dump that captures SOA runtime environment info: version, label, topology. ... Mandatory Arguments: Optional Arguments: wls:/soainfra/serverConfig> executeDump(name='soa.env', appName='soa-infra') Begin dumping EMInstanceProperties key=soaClusterName value=NULL key=label value=PCBPEL_11.1.1.6.0_GENERIC_111018.1315.1477 key=CompositeLabel value=NULL key=version value=11.1.1.6.0 key-HttpUrl value=http://myhost.us.example.com:8001 End dumping EMInstanceProperties Cluster Info: ----------------------------------------------- cluster name:null cluster is leader:true cluster is standalone:true
Table 12-5 provides details about runtime platform configuration diagnostic dumps.
Table 12-5 Runtime Platform Configuration Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
Service engine configurations: The following configurations are persisted in MDS (
|
Enter the following WLST command line syntax to display a dump description and execute a dump of soa.config
:
wls:/soainfra/serverConfig> describeDump(name='soa.config', appName='soa-infra') Name: soa.config Description: SOA diagnostic dump that captures SOA runtime configuration info, such as deployed-composites.xml, service engine configurations, etc. Mandatory Arguments: Optional Arguments: Name Type Description zip BOOLEAN Boolean flag (default to 'true') indicating if the dump files need to be compressed into one single zip file, true - compress dump result into a single zip, false, otherwise, default: true output STRING Path to Output destination, a directory where the dump content will be written to, default to DFW dump path if not specified ... wls:/soainfra/serverConfig> executeDump(name='soa.config', appName='soa-infra') . . . . . . Start dumping artifacts from MDS URI:deployed-composites/deployed-composites.xml to /tmp/soa_ dumps139780820495.tmp/soa_config734535543.d Finished dumping specified MDS metadata to /tmp/soa_dumps139780820495.tmp/soa_ config734535543.d Start dumping artifacts from MDS URI:soa/configuration/default/ to /tmp/soa_ dumps139780820495.tmp/soa_config734535543.d/se-configurations Finished dumping specified MDS metadata to: /tmp/soa_dumps139780820495.tmp/soa_ config734535543.d/se-configurations MDS artifacts dumped, next, compressing all dump files into: /tmp/oracle-dfw--1770056289547048694.tmp/soa_config364634563344231671.zip
The executeDump
command dumps deployed-composites.xml
from the MDS repository and service engine configurations for all installed service engines into a single, compressed ZIP file (soa_config364634563344231671.zip
).
Enter the following WLST command line syntax to execute a dump of soa.config
with the zip
parameter set to false
. This setting writes the dump text file and artifacts to the dump path location without compressing them into one ZIP file.
. . . . . . wls:/soainfra/serverConfig> executeDump(name='soa.config', appName='soa-infra', args={'zip':'false'})Start dumping artifacts from MDS URI:deployed-composites/deployed-composites.xml to: /tmp/oracle-dfw-7178460573556479044.tmp/soa_config199325881615155981.d Finished dumping specified MDS metadata to: /tmp/oracle-dfw-7178460573556479044.tmp/soa_config199325881615155981.d Start dumping artifacts from MDS URI:soa/configuration/default/ to: /tmp/oracle-dfw-7178460573556479044.tmp/soa_ config199325881615155981.d/se-configurations Finished dumping specified MDS metadata to: /tmp/oracle-dfw-7178460573556479044.tmp/soa_ config199325881615155981.d/se-configurations
Examine the contents under the default dump path:
[jdoe@myhost /tmp]$ ls -alR oracle-dfw-7178460573556479044.tmp oracle-dfw-7178460573556479044.tmp: total 52 drwxr----- 3 jdoe dba 4096 Oct 24 15:43 . drwxrwxrwt 104 root root 36864 Oct 24 15:37 .. drwxr----- 4 jdoe dba 4096 Oct 24 15:43 soa_config199325881615155981.d -rw-r----- 1 jdoe dba 561 Oct 24 15:43 soa_config199325881615155981.txt oracle-dfw-7178460573556479044.tmp/soa_config199325881615155981.d: total 16 drwxr----- 4 jdoe dba 4096 Oct 24 15:43 . drwxr----- 3 jdoe dba 4096 Oct 24 15:43 .. drwxr----- 2 jdoe dba 4096 Oct 24 15:43 deployed-composites drwxr----- 2 jdoe dba 4096 Oct 24 15:43 se-configurations oracle-dfw-7178460573556479044.tmp/soa_ config199325881615155981.d/deployed-composites: total 12 drwxr----- 2 jdoe dba 4096 Oct 24 15:43 . drwxr----- 4 jdoe dba 4096 Oct 24 15:43 .. -rw-r----- 1 jdoe dba 1437 Oct 24 15:43 deployed-composites.xml oracle-dfw-7178460573556479044.tmp/soa_ config199325881615155981.d/se-configurations: total 56 drwxr----- 2 jdoe dba 4096 Oct 24 15:43 . drwxr----- 4 jdoe dba 4096 Oct 24 15:43 .. -rw-r----- 1 jdoe dba 267 Oct 24 15:43 adapter-config.xml -rw-r----- 1 jdoe dba 425 Oct 24 15:43 b2b-config.xml -rw-r----- 1 jdoe dba 2040 Oct 24 15:43 bpel-config.xml -rw-r----- 1 jdoe dba 1525 Oct 24 15:43 bpmn-config.xml -rw-r----- 1 jdoe dba 895 Oct 24 15:43 businessrules-config.xml -rw-r----- 1 jdoe dba 119 Oct 24 15:43 cep-config.xml -rw-r----- 1 jdoe dba 215 Oct 24 15:43 edn-config.xml -rw-r----- 1 jdoe dba 836 Oct 24 15:43 mediator-config.xml -rw-r----- 1 jdoe dba 1148 Oct 24 15:43 soa-infra-config.xml -rw-r----- 1 jdoe dba 2693 Oct 24 15:43 workflow-config.xml -rw-r----- 1 jdoe dba 2146 Oct 24 15:43 workflow-identity-config.xml -rw-r----- 1 jdoe dba 605 Oct 24 15:43 workflow-notification
Enter the following WLST command line syntax to execute a dump of soa.config
that compresses all dump into a ZIP file in the specified output directory.
wls:/soainfra/serverConfig> executeDump(name='soa.config', appName='soa-infra'
,args={'output':'/home/myhome/CFG_DUMP_DIR_APP_ZIP'})
Table 12-6 provides details about database diagnostic dumps. The types of database information captured include data shape information such as counts by state and growth patterns for Oracle SOA Suite schemas and the MDS schema.
Table 12-6 Database Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
BPEL database table growth data using JDBC-based access to execute the query and dump the result: SELECT dt.table_name table_name,ds.bytes/1024/1024 segment_size_mb, ds.extents extents_used, dt.num_rows total_rows, to_char(dt.last_analyzed,'YYYY-MM-DD HH24:MI:SS') last_analyzed_date FROM dba_segments ds, dba_tables dt WHERE dt.owner = ds.owner and dt.owner = 'schema_user_name' and dt.tablespace_name = ds.tablespace_name and dt.table_name = ds.SEGMENT_NAME and ds.segment_type = 'TABLE' and dt.table_name in ('CUBE_INSTANCE', 'MEDIATOR_CASE_INSTANCE','COMPOSITE_ INSTANCE', 'AUDIT_TRAIL', 'WORK_ITEM', 'DLV_MESSAGE', 'XML_DOCUMENT','DOCUMENT_CI_REF') |
Enter the following WLST command line syntax to display a dump description and execute a dump of soa.db
:
wls:/soainfra/serverConfig> describeDump(name='soa.db', appName='soa-infra') Name: soa.db Description: SOA diagnostic dump for SOA runtime DB usage info, e.g. bpel growth statistics Mandatory Arguments: Optional Arguments: wls:/soainfra/serverConfig> executeDump(name='soa.db', appName='soa-infra') EXECUTE QUERY SELECT dt.table_name table_name,ds.bytes/1024/1024 segment_size_mb, ds.extents extents_used, dt.num_rows total_rows, to_char(dt.last_analyzed, 'YYYY-MM-DD HH24:MI:SS') last_analyzed_date FROM dba_segments ds, dba_tables dt WHERE dt.owner = ds.owner and dt.owner ='schema_user_name' and dt.tablespace_name = ds.tablespace_name and dt.table_name = ds.SEGMENT_NAME and ds.segment_type = 'TABLE' and dt.table_name in ('CUBE_INSTANCE', 'MEDIATOR_CASE_INSTANCE','COMPOSITE_INSTANCE', 'AUDIT_TRAIL', 'WORK_ITEM', 'DLV_MESSAGE','XML_DOCUMENT','DOCUMENT_CI_REF') COMMENT: BPEL DB GROWTH DATA. TABLE_NAME SEGMENT_SIZE_MB EXTENTS_USED TOTAL_ROWS LAST_ANALYZED_DATE ------------------------------------------------------------------------- ResultSet Metadata:weblogic.jdbc.wrapper.ResultSetMetadata_oracle_jdbc_driver_ OracleResultSetMetadata@76a4b0 RECORD #1: TABLE_NAME: COMPOSITE_INSTANCE SEGMENT_SIZE_MB:0 EXTENTS_USED:1 TOTAL_ROWS:9 LAST_ANALYZED_DATE:2011-09-30 22:02:25 RECORD #2: TABLE_NAME:DOCUMENT_CI_REF SEGMENT_SIZE_MB:0 EXTENTS_USED:1 TOTAL_ROWS:0 LAST_ANALYZED_DATE:2011-09-30 22:02:34 RECORD #3: TABLE_NAME:WORK_ITEM SEGMENT_SIZE_MB:0 EXTENTS_USED:1 TOTAL_ROWS:0 LAST_ANALYZED_DATE:2011-09-30 22:02:36 RECORD #4: TABLE_NAME:AUDIT_TRAIL SEGMENT_SIZE_MB:0 EXTENTS_USED:1 TOTAL_ROWS:8 LAST_ANALYZED_DATE:2011-09-30 22:02:39
This dump shows the query string and records from the result set.
Table 12-7 provides details about deployed composite metadata diagnostic dumps. The types of information captured include the current composite processed when an incident occurs, MDS artifact references (for example, namespace exports), and abnormal transactions.
Table 12-7 Deployed Composite Metadata Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
Per composite metadata from MDS:
|
Enter the following WLST command line syntax to display a dump description and execute a dump of soa.composite
:
wls:/soainfra/serverConfig> describeDump(name='soa.composite' , appName='soa-infra') Name: soa.composite Description: SOA diagnostic dump that captures composite MDS artifacts, and scratch area entries listing for composite's scratch area, dump MDS artifacts for composites that either match specified parameters: composite name/partition/revision, or associated with an ECID (Execution Context ID identifying a message flow across multiple composite instance(s), support wild card '*' as composite name/partition/revision, meaning matching composites with any composite name/any partition/any revision. Rules for actual parameter evaluation: if ecid is specified, use it to match composites associated with the ECID, composite name/partition/revision not used. ; if ecid is not specified, then use composite name/partition/revision to match composites; if composite name/partition/revision are not specified (all missing), try to get ECID from dump context; if ECID is obtained from dump context, use it to match composites associated with it, if no ECID from dump context, try to obtain composite name from dump context, if composite name obtained from dump context, then apply dump to all deployed composites. Mandatory Arguments: Optional Arguments: Name Type Description ecid STRING ECID (Execution Context ID - for tracking message flow across multiple composite instances), when present, will be used to locate composites associated with it, and other composite matching parameters ignored; it can be obtained from dump context if not specified as dump parameter, see rules for actual parameter evaluation for details. zip BOOLEAN Boolean flag (default to 'true') indicating if the dump files need to be compressed into one single zip file, true - dump into a single zip file, false, otherwise, default: true. revision STRING Revision of composite , e.g. '1.0', '2.0', can be wild card meaning matching any revision, when missing, assume default composite's revision in the composite series. partition STRING Partition of composite, default to partition(s) associated with resolved revision(s) can be wild card '*', meaning matching any partition. compositeName STRING Composite name, e.g., 'OrderProcessing', can be wild card '*', meaning matching any composite. output STRING Output destination directory where dump contents are written to, default to DFW dump path. wls:/soainfra/serverConfig> executeDump(name='soa.composite', appName='soa-infra',args=('compositeName':'WSInMedPubBpelSubFileOut', 'revision':'1.0','partition':'default','output':'/home/myhome/COMPOSITE_DUMP_ MDS_ZIP'}) . . . . . . Start dumping composite [name=WSInMedPubBpelSubFileOut, partition=partition_1, revision= 1.0 ] MDS metadata to :/tmp/soa_dumps1019331262763443905.tmp/ soa_composite4533356433976235311.d/partition_1/WSInMedPubBpelSubFileOut_ rev1.0 Finished dumping composite MDS metadata to :/tmp/soa_dumps 1019331262763443905.tmp/soa_composite4533356433976235311.d/default /WSInMedPubBpelSubFileOut_rev1.0
A dump output file is created at the specified dump location of /home/myhome/COMPOSITE_DUMP_MDS_ZIP
.
The Location field shows the dump results compressed at the specified location. In the navigator on the left are the MDS artifacts of the ZIP file (for example, the .edl
file, .bpel
file, and so on). The .txt
file at the bottom is the main dump file in the ZIP file.
Enter the following WLST command line syntax to execute a dump of soa.composite
that includes all SOA composite applications, revisions, and partitions.
wls:/soainfra/serverConfig> executeDump(name='soa.composite',
appName='soa-infra',args=('compositeName':'*',
'revision':'*','partition':'*','output':'/home/myhome//COMPOSITE_DUMP_
DIR_ALLCOMP_ALL_REV_ALL_PART'})
The Location field shows the dump result compressed at the specified location.
All SOA composite applications from all partitions with all revisions are dumped.
Table 12-8 provides details about instance audit trail diagnostic dumps. The type of information captured includes the SOA composite application instance audit trail, individual service component audit trails, faults, sensors, and event delivery network (EDN) information associated with the message flow identified by the ECID.
Table 12-8 Instance Audit Trail Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
|
Enter the following WLST command line syntax to display a dump description and execute a dump of soa.composite.trail
:
wls:/soainfra/serverConfig> describeDump(name='soa.composite.trail' , appName='soa-infra') Name: soa.composite.trail Description: SOA diagnostic dump for a given ECID (Execution Context ID identifying a message flow across multiple composite instances), captures composite application instances audit trail, components audit trail, faults, sensors, etc. associated with the message flow identified by the ECID; Rules for actual parameter evaluation: if ecid is specified, use it to match composites associated with the ECID, if ecid is not specified, try to get ECID from dump context, if ECID is obtained from dump context, use it to match composites associated with it, if no ECID from dump context, throw exception. Mandatory Arguments: Optional Arguments: Name Type Description ecid STRING ECID (Execution Context ID- for tracking message flow across multiple composite instances). zip BOOLEAN Boolean flag (default to 'true') indicating if the dump files need to be compressed into one single zip file, true - compress dump result into a single zip, false, otherwise, default: true wls:/soainfra/serverConfig> executeDump(name='soa.composite.trail', appName='soa-infra',args={'ecid':'cf1cec292805f383:-598c1140:1388238a4ce:-8000- 00000000000028c1'}) Executing SOA Diagnostic Dump: soa.composite.trail Description: SOA diagnostic dump that, for a given ECID (Execution Context ID identifying a message flow across multiple composite instances), captures composite application instances audit trail, components audit trail, faults, sensors, etc. associated with the message flow indentified by the ECID; Rules for actual parameter evaluation: if ecid is specified, use it to match composites associated with the ECID, if ecid is not specified, try to get ECID from dump context, if ECID is obtained from dump context, use it to match composites associated with it,if no ECID from dump context, throw exception. Parameters: Optional::ecid::STRING::ECID(Execution Context ID - for tracking message flow across multiple composite instances), Optional::zip::BOOLEAN::Boolean flag (default to 'true') indicating if the dump files need to be compressed into one single zip file, true - compress dump result into a single zip, false, otherwise, default: true. Parameter Values: parameter::ecid=cf1cec292805f383:-598c1140:1388238a4ce:-8000-00000000000028c1 parameter::zip=NULL Normalized dump parameters: ecid=cf1cec292805f383:-598c1140:1388238a4ce:-8000-00000000000028c1 zip=true Start dumping audit trails for ECID = [cf1cec292805f383:-598c1140:1388238a4ce:-8000-00000000000028c1], to destination : /tmp/oracle-dfw-3352979816637176191.tmp FAULTS= Trail data =>/tmp/oracle-dfw-3352979816637176191.tmp/soa_ dumps2431385805259626695.tmp/soa_composite_trail4522512822868494030.d/audit_ trail.xml EDN.INFO = /tmp/oracle-dfw-3352979816637176191.tmp/soa_ dumps2431385805259626695.tmp/soa_composite_trail4522512822868494030.d/edn_ info.txt composite.1.DN=default/CompositeWithEDN_11G!1.0 composite.1.ID=3 composite.1.TenantID=-1 composite.1.Created=Fri Jul 13 15:32:03 PDT 2012 composite.1.State=-1 composite.1.StateAsString=STATE_UNKNOWN composite.1.Status=null No trail found... composite.1.component.1.Name=BpelSub composite.1.component.1.Type=bpel composite.1.component.1.ID=bpel:1 composite.1.component.1.State=5 composite.1.component.1.StateAsString=STATE_SUSPENDED composite.1.component.1.Status=completed Trail data =>/tmp/oracle-dfw-3352979816637176191.tmp/soa_ dumps2431385805259626695.tmp/soa_composite_ trail4522512822868494030.d/default/CompositeWithEDN_11G_1.0_3/BpelSub_bpel_1_ component.xml SENSOR.INFO = /tmp/oracle-dfw-3352979816637176191.tmp/soa_ dumps2431385805259626695.tmp/soa_composite_ trail4522512822868494030.d/default/CompositeWithEDN_11G_1.0_3_sensor.txt composite.2.DN=partition_1/CompositeWithEDN_11G!1.0 composite.2.ID=2 composite.2.TenantID=-1 composite.2.Created=Fri Jul 13 15:31:58 PDT 2012 composite.2.State=-1 composite.2.StateAsString=STATE_UNKNOWN composite.2.Status=null No trail found... composite.2.component.1.Name=BpelSub composite.2.component.1.Type=bpel composite.2.component.1.ID=bpel:2 composite.2.component.1.State=5 composite.2.component.1.StateAsString=STATE_SUSPENDED composite.2.component.1.Status=completed Trail data =>/tmp/oracle-dfw-3352979816637176191.tmp/soa_ dumps2431385805259626695.tmp/soa_composite_ trail4522512822868494030.d/partition_1/CompositeWithEDN_11G_1.0_2/BpelSub_bpel_ 2_component.xml SENSOR.INFO = /tmp/oracle-dfw-3352979816637176191.tmp/soa_ dumps2431385805259626695.tmp/soa_composite_ trail4522512822868494030.d/partition_1/CompositeWithEDN_11G_1.0_2_sensor.txt composite.3.DN=partition_1/CompositeWithEDN_11G!1.0 composite.3.ID=1 composite.3.TenantID=-1 composite.3.Created=Fri Jul 13 15:31:24 PDT 2012 composite.3.State=-1 composite.3.StateAsString=STATE_UNKNOWN composite.3.Status=null No trail found... composite.3.component.1.Name=MediatorPub composite.3.component.1.Type=mediator composite.3.component.1.ID=mediator:7CC2E450CD3A11E1BF3F897791557FF9 composite.3.component.1.State=2 composite.3.component.1.StateAsString=STATE_COMPLETED_SUCCESSFULLY composite.3.component.1.Status=null Trail data =>/tmp/oracle-dfw-3352979816637176191.tmp/soa_ dumps2431385805259626695.tmp/soa_composite_ trail4522512822868494030.d/partition_1/CompositeWithEDN_11G_1.0_1/MediatorPub_ mediator_7CC2E450CD3A11E1BF3F897791557FF9_component.xml SENSOR.INFO = /tmp/oracle-dfw-3352979816637176191.tmp/soa_ dumps2431385805259626695.tmp/soa_composite_ trail4522512822868494030.d/partition_1/CompositeWithEDN_11G_1.0_1_sensor.txt Number of composite instance associated with the ECID [cf1cec292805f383:-598c1140:1388238a4ce:-8000-00000000000028c1]: 3 Audit trails dumped for ECID = [cf1cec292805f383:-598c1140:1388238a4ce:-8000-00000000000028c1], at the location :/tmp/oracle-dfw-3352979816637176191.tmp Compressing dump files from directory: [/tmp/oracle-dfw-3352979816637176191.tmp/soa_dumps2431385805259626695.tmp/soa_ composite_trail4522512822868494030.d] to [/tmp/oracle-dfw-3352979816637176191.tmp/soa_composite_ trail4522512822868494030.zip].
For information about obtaining the ECID, see Section 14.1, "Monitoring the Audit Trail and Process Flow of a BPEL Process Service Component."
Table 12-9 provides details about event diagnostic dumps. The types of information captured include EDN business event bus status information and EDN database log records.
Table 12-9 Event Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
All information is written to the dump text file. |
Enter the following WLST command line syntax to display a dump description and execute a dump of soa.edn
:
wls:/soainfra/serverConfig> describeDump(name='soa.edn', appName='soa-infra') Name: soa.edn Description: SOA diagnostic dump that captures EDN BusinessEventBus status info, and optionally, EDN DB Log records. Mandatory Arguments: Optional Arguments: Name Type Description dumpEDNDBLOG BOOLEAN Flag indicating whether EDN DB logs included; false: EDN DB log not included. default: false. wls:/soainfra/serverConfig> executeDump(name='soa.edn', appName='soa-infra') Executing SOA Diagnostic Dump: soa.edn Description: SOA diagnostic dump that captures EDN BusinessEventBus status info, and optionally, EDN DB Log records. Parameters: Optional::dumpEDNDBLOG::BOOLEAN::Flag indicating whether EDN DB log included or not, true: EDN DB log included, false: EDN DB log not included, default: false. Parameter Values: parameter::dumpEDNDBLOG=NULL Type:oracle.integration.platform.blocks.event.saq.SAQBusinessEventBus Configuration:null Status: running=true started=true ThreadCount:3 RetryCount:3 In Global: Tx:false Cluster Info:oracle.integration.platform.blocks.cluster.CoherenceCluster Interface1mpt@163bd717 SharedEDN:false OOAO Queue Name:edn_ooao_queue Java Subscriber Name:edn java subscriber Subscription Info: No namespace subscription... QName subscriptions: ============================================================= qname={http://schemas.oracle.com/events/edl/ActionOccur}ADEvent subscriptions= id=default/WSInMedPubBpelSubFileOut!1.0*soa_7a055d6a-8402-49c2-ac56-5f85cbf3d7f/ BpelSub, consistencyLevel=ONE_AND_ONLY_ONE, filter=XPath Filter: starts-with(/ be:business-event/be:content/ns0:ActionOccurrence/ns0:ParentEntityType/@value, 'A'), runAsRoles=[$publisher] id=partition_1/WSInMedPubBpelSubFileOut!1.0*soa_80a169ab1-395a-4b87-9986-9fa2742a8bd3/ BpelSub, consistencyLevel=ONE_AND_ONLY_ONE, filter=XPath Filter: starts-with(/ be:business-event/be:content/ns0:ActionOccurrence/ns0:ParentEntityType/@value, 'A'), runAsRoles=[$publisher] EventThreadContextInfo: EventTargets: Event:partition_1/WSInMedPubBpelSubFileOut!1.0*soa0a169ab1-395a-4b87-9986-9fa2742a9bd3/ BpelSub:::oracle.fabric.BPELServiceEngine@163bd6b5 Event:default/WSInMedPubBpelSubFileOut!1.0*soa7a055d6a-8402-49c2-ac56-5f85cbf3 d7f/BpelSub:::oracle.fabric.BPELServiceEngine@163bd6b5 EDN DB Log enabled:false
The executeDump
command dumps the event bus status variables (1mpt@163bd717
) and event publish and subscription information. No log messaging information is dumped because the edn-db-log
is set to false
. You can enable the edn-db-log
at the following URL:
http://host_name:port/soa-infra/events/edn-db-log
Notes:
You must have the administrator privilege to enable/disable the edn-db-log
.
Always disable the edn-db-log
after a debugging session to disable logging. This prevents excessive database growth in the EDN database log table. If the edn-db-log
remains enabled, then debugging messages related to events that are published/enqueued into the database and subscribed to/dequeued from the database continue to be persisted into certain EDN database log tables. This causes the table to grow indefinitely.
Table 12-10 provides details about service definition information cached for composites that match the specified parameters: composite name, partition, and revision.
Table 12-10 Deployed Composite WSDL/Schema Cache Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
|
Enter the following WLST command line syntax to display a dump description and execute a dump of soa.wsdl
:
wls:/soainfra/serverConfig> describeDump(name='soa.wsdl', appName='soa-infra') Name: soa.wsdl Description: SOA diagnostic dump that captures services definition info cached for composite(s) that match specified parameters: composite namne partition/revision, support wild card '*' as composite name/ partition/revision, meaning matching composites with any composite name/any partition/any revision. Rules for actual parameter evaluation: if ecid is specified, use it to match composites associated with the ECID, composite name/partition/revision not used. ; if ecid is not specified, then use composite name/partition/revision to match composites; if composite name/partition/revision are not specified (all missing), try to get ECID from dump context; if ECID is obtained from dump context, use it to match composites associated with it, if no ECID from dump context, try to obtain composite name from dump context, if composite name obtained from dump context, then apply dump to all deployed composites. Mandatory Arguments: Optional Arguments: Name Type Description ecid STRING ECID (Execution Context ID - for tracking message flow across multiple composite instances), when present, will be used to locate coposites associated with it and other composite matching parameters are ignored; it can be obtained from dump context if not specified as dump parameter; see rules for actual parameter evaluation for details. revision STRING Revision of composite , e.g. '1.0', '2.0', can be wild card meaning matching any revision, when missing, assume default composite's revision in the composite series. partition STRING Partition of composite, default to partition(s) associated with resolved revision(s) can be wild card '*', meaning matching any partition. compositeName STRING Composite name, e.g., 'OrderProcessing', can be wild card '*', meaning matching any composite. wls:/soainfra/serverConfig> executeDump(name='soa.wsdl', appName='soa-infra' ,arg=('compositeName':'WSInMedPubBpelSubFileOut', 'revision':'1.0','partition':'partition_1'})compositeDN:partition_ 1/WSInMedPubBpelSubFileOut!1.0*soa_8a169ab1-2060-4b87-9986-9fa2742a8bd3 . . . . . . ---------------------------------------------------------------------- is default in series:true composite application name:partition_1 composite name:WSInMedPubBpelSubFileOut composite state:on composite mode:active WSDLManager Instance:oracle.fabric.common.wsdl.WSDLManager@164ec201 Cached wsdl Definitions for the specified composite: including any shared wsdls if there are any: key=http://xmlns.oracle.com/bpel/workflow/taskService value=QName:{http://xmlns.oracle.com/bpel/workflow/taskService} TaskServicetarget name space:http://xmlns.oracle.com/bpel/workflow/taskService key=urn:MyTestWsdl value=QName:{urn:MyTestWsdl}target name space:urn:MyTestwsdl key=http://xmlns.oracle.com/adapter/file/LixinSandboxes/WSInMedPubBpelSubFile Out/FileWrite value=QName:{http://xmlns.oracle.com/pcbpel/adapter/file/LixinSandboxes/ WSInMedPubBpelSubFileOut/FileWrite}FileWritetarget name space:http: //xmlns.oracle.com/pcbpel/adapter/file/LixinSandboxes/ WSInMedPubBpelSubFileOut/FileWrite count of all cached entries:3 SchemaManager instance:oracle.fabric.common.wsdl.SchemaManager@164ec1f8 SchemaManager.isPostDeploy():true SchemaManager.isShared():false SchemaManager.schemaAddressSinceLastBuild():false Cached schema count:0 WSDLManager instance:oracle.fabric.common.wsdl.WSDLManager@14b5b8b0 cached wsdl definitions for the specified composite: including shared wsdls if there is any: --------------------------------------------------------------------------- key=http://xmlns.oracle.com/bpel/workflow/taskService value=QName:{http://xmlns.oracle.com/bpel/workflow/taskService} TaskServicetarget name space:http://xmlns.oracle.com/bpel/workflow/taskService count of all cached entries:1 SchemaManager instance:oracle.fabric.common.wsdl.SchemaManager@145b8cc SchemaManager.isPostDeploy():false SchemaManager.isShared():true SchemaManager.schemaAddressSinceLastBuild():true Cached schema count:0 WSDLManager instance:oracle.fabric.common.wsdl.WSDLManager@14b58b0 WSDLManager instance:oracle.fabric.common.wsdl.WSDLManager@14b58b0 cached wsdl definitions for the specified composite: including shared wsdls if there is any: ------------------------------------------------- key=http://xmlns.oracle.com/bpel/workflow/taskService value=QName:{http://xmlns.oracle.com/bpel/workflow/taskService} TaskServicetarget name space:http://xmlns.oracle.com/bpel/workflow/taskService count of all cached entries:1 SchemaManager instance:oracle.fabric.common.wsdl.SchemaManager@145b8cc SchemaManager.isPostDeploy():false SchemaManager.isShared():true SchemaManager.schemaAddressSinceLastBuild():true Cached schema count:0
Table 12-11 provides details about dispatcher static configuration diagnostic dumps.
Table 12-11 Dispatcher Static Configuration Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
Static pool configurations (dispatcher configurations)
Runtime message queue sizes:
Runtime message queue breakdown sizes (total processed and erred messages, and average message pending and execution time):
|
In addition to the WLST command described in this section, you can also obtain dispatcher static configuration diagnostic information through the System MBean Browser. This option enables you to obtain more specific details about invoke queue, delivery queue, and instance queue scheduled and working messages. For more information, see Section 12.2.8.2, "Obtaining Dispatcher Static Configuration Diagnostic Dumps with the System MBean Browser."
Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.dispatcher
:
wls:/soainfra/serverConfig> describeDump(name='bpel.dispatcher', appName='soa-infra') Name: bpel.dispatcher Description: BPEL dispatcher config info. This dumps the information about the static (System, Invoke, Engine and Audit thread counts) and runtime Scheduled and Working Message Counts Mandatory Arguments: Optional Arguments: Name Type Description format STRING passing value of 'xml' will produce the output in xml format - args={'format':'xml'} wls:/soainfra/serverConfig> executeDump(name='bpel.dispatcher', appName='soa-infra') BPEL Service Engine Dispatcher Info: Static Pool Configurations Audit Thread Count: 3 Engine Threads: 30 Invoke Thread Count: 20 Non-Blocking Invoke Thread Count: 2 System Threads: 2 Runtime Message Queue Sizes Total Scheduled Message Count: 352 Total Working Message Count: 50 Runtime Message Queue Breakdown Sizes Audit Queue : Total Processed Messages :0 Total Errored Messages :0 Average Message Pending Time :n/a Average Message Execution Time :n/a | Scheduled | Working ---------------- | ---------- | ------- audit | 0 | 0 Engine Queue : Total Processed Messages :879 Total Errored Messages :0 Average Message Pending Time :2304.08 Average Message Execution Time :905.56 | Scheduled | Working ---------------- | ---------- | ------- domain | 0 | 0 process | 0 | 0 delivery | 253 | 19 instance | 56 | 11 Invoke Queue : Total Processed Messages :714 Total Errored Messages :0 Average Message Pending Time :1385.2 Average Message Execution Time :954.33 | Scheduled | Working ---------------- | ---------- | ------- invoke | 0 | 0 Non-Blocking Invoke Queue : Total Processed Messages :0 Total Errored Messages :0 Average Message Pending Time :n/a Average Message Execution Time :n/a | Scheduled | Working ---------------- | ---------- | ------- non-block-invoke | 0 | 0 System Queue : Total Processed Messages :1 Total Errored Messages :1 Average Message Pending Time :272 Average Message Execution Time :11014 | Scheduled | Working ---------------- | ---------- | ------- system | 0 | 0 maintenance | 0 | 0
Enter the following WLST command line syntax to execute a dump of bpel.dispatcher
in XML format:
executeDump(name='bpel.dispatcher', appName='soa-infra', args={'format':'xml'})
<dispatcher-trace invokeThreadCount="20" systemThreadCount="2"
nonBlockInvokeThreadCount="2" auditThreadCount="5" engineThreadCount="30">
<systemSet totalErroredMsgs="1" avgMsgPendingTime="277"
avgMsgExecTime="11014" totalProcessedMsgs="1">
<systemQueue>
<scheduled count="0"/>
<working count="0"/>
</systemQueue>
<maintenanceQueue>
<scheduled count="0"/>
<working count="0"/>
</maintenanceQueue>
</systemSet>
<invokeSet totalErroredMsgs="0" avgMsgPendingTime="803.82"
avgMsgExecTime="987.51" totalProcessedMsgs="385">
<invokeQueue>
<scheduled count="43"/>
<working count="20"/>
</invokeQueue>
</invokeSet>
<engineSet totalErroredMsgs="0" avgMsgPendingTime="2391.25"
avgMsgExecTime="1127.45" totalProcessedMsgs="343">
<domainQueue>
<scheduled count="0"/>
<working count="0"/>
</domainQueue>
<processQueue>
<scheduled count="43"/>
<working count="20"/>
</processQueue>
<deliveryQueue>
<scheduled count=147"/>
<working count="14"/>
</deliveryQueue>
<instanceQueue>
<scheduled count="75"/>
<working count="16"/>
</instanceQueue>
</engineSet>
<auditSet totalErroredMsgs="0" avgMsgPendingTime="n/a"
avgMsgExecTime="n/a" totalProcessedMsgs="0">
<auditQueue>
<scheduled count="0"/>
<working count="0"/>
</auditQueue>
</auditSet>
<non-block-invokeSet totalErroredMsgs="0" avgMsgPendingTime="n/a"
avgMsgExecTime="n/a" totalProcessedMsgs="0">
<non-block-invokeQueue>
<scheduled count="0"/>
<working count="20"/>
</non-block-invokeQueue>
</non-block-invokeSet>
</dispatcher-trace>
You can also display dispatcher static configuration diagnostic dumps in the System MBean Browser by invoking the readXMLDispatcherTrace property. This option enables you to obtain more specific details about invoke queue, delivery queue, and instance queue messages currently being processed or scheduled to be processed than you receive with the WLST executeDump
command described in Section 12.2.8.1, "WLST Command Dump Description and Execution."
In the navigation tree, expand the SOA folder.
Right-click soa-infra, and select Administration > System MBean Browser.
Select Application Defined MBeans > oracle.as.soainfra.bpm > Server: server_name > bpel > CubeDispatcher.
Click readXMLDispatcherTrace.
Click Invoke.
Results are displayed in the property window.
Table 12-12 provides details about average instance processing time diagnostic dumps. This information is obtained from the creation and last modified timestamp for the instance persisted in the BPEL process service engine.
Table 12-12 Average Instance Processing Time Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
The average time that instances for various processes take during execution. This information is obtained from the persistence store and includes the time taken by any partners invoked by the process. The average time is in seconds. |
Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.apt
:
wls:/soainfra/serverConfig> describeDump(name='bpel.apt', appName='soa-infra') Name: bpel.apt Description: BPEL Instance Average Procesing Time information. This information is obtained from the creation and last modify timestamp for the instance in the BPEL Engine persistence repository Mandatory Arguments: Optional Arguments: Name Type Description format STRING passing value of 'xml' will produce the output in xml format - args={'format':'xml'} wls:/soainfra/serverConfig> executeDump(name='bpel.apt', appName='soa-infra') BPEL Service Engine Instance Average Processing Time Info: Composite | Component | Instances | Average Processing Time (secs) -------------| -------------- |-------------|-------------------------------- forEach | DummyService | 2| 0.01 | Test | 3| 0.09 -------------| -------------- |-------------|-------------------------------- LinkInvoke | AsynchBPEL | 1| 0.01 | LinkInvoke | 2| 0.11 | SyncBPEL | 2| 0.01 -------------| -------------- |-------------|-------------------------------- RelaxSyntax | SyncBPELService| 2| 0.02 -----------------------------------------------------------------------------
Enter the following WLST command line syntax to execute a dump of bpel.apt
in XML format:
executeDump(name='bpel.apt', appName='soa-infra', args={'format':'xml'})
<AvgInstanceProcessingTime timestamp="2012-03-15 13:11:40.442">
<Composite name="forEach">
<Component name="DummyService" instances="2" Avg="0.01"/>
<Component name="Test" instances="3" Avg="9.09"/>
</Composite>
<Composite name="LinkInvoke">
<Component name="AsynchBPEL" instances="1" Avg="0.01"/>
<Component name="LinkInvoke" instances="2" Avg="0.11"/>
<Component name="SyncBPEL" instances="2" Avg="0.01"/>
</Composite>
<Composite name="RelaxSyntax">
<Component name="SyncBPELService" instances="2" Avg="0.02"/>
</Composite>
</AvgInstanceProcessingTime>
Table 12-13 provides details about average instance processing delay diagnostic dumps for asynchronous processes. This dump provides the average time taken by the BPEL process service engine to retrieve the persisted message from the database and start processing that message. The statistics are generated from the database and not from in-memory.
Table 12-13 Average Instance Processing Delay Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
Average invoke processing delay between the receipt of the incoming message that triggers the process instance and the time at which the BPEL service engine actually started processing the message. Note: The dump described in Section 12.2.9, "Average Instance Processing Time Diagnostic Dumps (bpel.apt)" provides the total execution time for a process instance, which is a function of the time for processing of activities, and also includes the time that the partner takes (if it involves calling one or more). However, because the incoming message is first stored in the database for asynchronous communications before being processed, more specific details are sometimes required to diagnose system bottlenecks. Therefore, details about the delay in the BPEL process service engine selecting the message from the database is also provided with the This dump information is generated from the database and not from in-memory. For further details and better analysis about delays at various layers of the BPEL process service engine, see Section 14.6.1, "Viewing Low Level Request Breakdown Table Details." |
Notes:
Because this dump is executed against the database, the query may run slow if you have very large records.
There are no filters for limiting the data to query.
The dump runs queries provided as database views external to the normal BPEL process service engine persistence schema. You can tune the view directly and receive better results.
Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.apd
:
wls:/soainfra/serverConfig> describeDump(name='bpel.apd', appName='soa-infra') Name: bpel.apd Description: BPEL Instance Average Processing Delay information (for Asynchronous Processes). This provides dump for information regarding the following: Average Invoke Processing Delay: Time delay between receipt of incoming message that triggers the process instance and the time engine actually start processing the message. Mandatory Arguments: Optional Arguments: Name Type Description format STRING passing value of 'xml' will produce the output in xml format - args={'format':'xml'} wls:/soainfra/serverConfig> executeDump(name='bpel.apd', appName='soa-infra') ********Average Invoke Processing Delay******** Composite| Component| Partner Link| Operation| Avg Invoke Processing Delay (secs) -------- | -------- | ---------------|----------------------------------------- Call | AsynchBP | asynchBP_client| process| 0.05 -------- | -------- | -------------- |-----------|----------------------------- Test | Caller2 | caller2_client| process| 0.04 -------- | -------- | -------------- |-----------|----------------------------- EvnTest | EDNProc | null| null| 0.03 -------- | -------- | -------------- |-----------|----------------------------- forEach | Echo | client| initiate| 0.07 -------- | -------- | -------------- |-----------|-----------------------------
Enter the following WLST command line syntax to execute a dump of bpel.apd
in XML format:
executeDump(name='bpel.apd', appName='soa-infra', args={'format':'xml'})
<AvgInstanceProcessingDelays timestamp="2012-03-15 13:11:40.442">
<AvgInvokeProcessingDelays>
<Composite name="Call">
<Component name="AsynchBP">
<Partner Link name="asynchBP_client">
<Operation name="process" Avg="0.05"/>
</Partner Link>
</Component>
</Composite>
<Composite name="Test">
<Component name="Caller2">
<Partner Link name="Caller2_client">
<Operation name="process" Avg="0.04"/>
</Partner Link>
</Component>
</Composite>
<Composite name="EvnTest">
<Component name="EDNProc">
<Partner Link name="null">
<Operation name="null" Avg="0.03"/>
</Partner Link>
</Component>
</Composite>
<Composite name="forEach">
<Component name="Echo">
<Partner Link name="client">
<Operation name="initiate" Avg="0.07"/>
</Partner Link>
</Component>
</Composite>
</AvgInvokeProcessingDelays>
</AvgInstanceProcessingDelays
Table 12-14 provides details about synchronous process statistics diagnostic dumps. This dump provides the minimum, maximum, and average processing time (in milliseconds) and the count of instances processed. You must configure the StatsLastN System MBean Browser property described in Section 14.6.1, "Viewing Low Level Request Breakdown Table Details" to obtain this diagnostic dump. However, if the optional dump parameters duration
and buffer
are specified and StatsLastN is not configured, this dump command provides statistics for throughput (transactions per second) information.
Table 12-14 Synchronous Process Statistics Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
The minimum, maximum, and average processing time (in milliseconds) and the count of instances processed for synchronous processes. |
Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.sps
:
wls:/soainfra/serverConfig> describeDump(name='bpel.sps', appName='soa-infra')
Description: Statistics for Synchronous Business Processes
This dump provides process level (Synchronous BPEL Processes only) statistics
such as min, max and average processing time (in milli-secs) and count of
instances processed. Note that statsLastN must be configured to obtain this
output. However, if optional parameters duration and buffer are specified and
statsLastN is not configured, this dump command would enable the stats for the
throughput (transaction per sec) information
Run Mode: asynchronous
Mandatory Arguments:
Optional Arguments:
Name Type Description
buffer STRING Range for buffer: 100-100000. Example: args={'buffer':'100'}
duration STRING Range for duration: 1-10000. Example: args={'duration':'1'}
format STRING Passing value of 'xml' will produce the output in xml format.
Example: args={'format':'xml'}
Enter the following WLST command line syntax to execute a dump of bpel.sps
with StatsLastN configured.
wls:/soainfra/serverConfig> executeDump(name='bpel.sps',
appName='soa-infra')
Synchronous Process Stats
Process Id: |
------------------------------------------------------------------------------|
default/Synchronous!1.0*soa_13036d87-f3ec-4954-9777-e93248c43086/BPELProcess1 |
|Minimum(m-sec) |Maximum(m-sec) |Average(m-sec) |Count
------------------------------------------------|-----
| 3 | 3 | 3.0 | 1
Enter the following WLST command line syntax to execute a dump of bpel.sps
in XML format with StatsLastN configured.
wls:/soainfra/serverConfig> executeDump(name='bpel.sps', appName='soa-infra',
args={'format':'xml'})
<statistics>
<stats key="default/Synchronous!1.0*soa_13036d87-f3ec-4954-9777-
e93248c43086/BPELProcess1" min="3" max="3" average="3.0" count="1">
</stats>
</statistics>
Enter the following WLST command line syntax to execute a dump of bpel.sps
with throughput values for the duration
and buffer
parameters.
wls:/soainfra/serverConfig> executeDump(name='bpel.sps', appName='soa-infra',
args={'duration':'10', 'buffer':'1000'})
Synchronous Process Stats (with Throughput)
Timestamp Start: 2012-07-25 10:41:16.457
Timestamp End: 2012-07-25 10:42:16.462
Sampling Window (seconds): 60
Buffer Size: 1000
Process Id:
-------------------------------------------------------------------
default/MsgProps20!1.0*soa_fe114dd1-fcfa-494a-920d-6ebd9b670/SyncM |
default/MsgProps!1.0*soa_78ab10-e820-4aa-86e3-87b8c88a1/SyncMsg |
|Minimum(m-sec) |Maximum(m-sec) |Average(m-sec) |Count |Throughput (tps)
------------------------------------------------------------------------
125 | 125 | 125.0 | 1 | 0.01
15 | 15 | 15.0 | 1 | 0.01
Enter the following WLST command line syntax to execute a dump of bpel.sps
in XML format with throughput values for the duration
and buffer
parameters and StatsLastN not configured.
wls:/soainfra/serverConfig> executeDump(name='bpel.sps', appName='soa-infra',
args={'format':'xml', 'duration':'10', 'buffer':'1000'})
<statistics timestamp-start ='2012-07-25 10:10:09.128' timestamp-end
='2012-07-25 10:10:19.13'>
<stats key="default/MtomTestClient!1.0*soa_65dc8543-3e2949e1-a07a-637c25c722
a1/BPELProcess1" min="1292" max="1292" average="1292.0" count="1" throughput=
"0.1">
</stats>
<stats key="default/WSBPELFAProj!1.0*soa_352731eb-44c5-4db6-aff1-e6a440f3a343/WSBPELFAProcess" min="287" max="287"
average="287.0" count="1" throughput="0.1">
</stats>
</statistics>
Table 12-15 provides details about asynchronous process statistics diagnostic dumps. This dump provides process level (asynchronous BPEL processes only) statistics such as minimum, maximum, and average processing time (in milliseconds) and count of instances processed. You must configure the StatsLastN System MBean Browser property described in Section 14.6.1, "Viewing Low Level Request Breakdown Table Details" to obtain this output. However, if the optional parameters duration
and buffer
are specified and StatsLastN is not configured, this dump command provides statistics for throughput (transactions per second) information.
Table 12-15 Asynchronous Process Statistics Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
The minimum, maximum, and average processing time (in milliseconds) and count of instances processed for asynchronous processes. |
Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.aps
:
wls:/soainfra/serverConfig> describeDump(name='bpel.aps', appName='soa-infra')
Name: bpel.aps
Description: Statistics for Asynchronous Business Processes
This dump provides process level (Asynchronous BPEL Processes only) statistics
such as min, max and average processing time (in milli-secs) and count of
instances processed. Note that statsLastN must be configured to obtain this
output. However, if optional parameters duration and buffer are specified and
statsLastN is not configured, this dump command would enable the stats for the
throughput (transaction per sec) information
Run Mode: asynchronous
Mandatory Arguments:
Optional Arguments:
Name Type Description
buffer STRING Range for buffer: 100-100000 .Example: args={'buffer':'100'}
duration STRING Range for duration: 1-10000 .Example: args={'duration':'1'}
format STRING Passing value of 'xml' will produce the output in xml
format. Example: args={'format':'xml'}
Enter the following WLST command line syntax to execute a dump of bpel.aps
with StatsLastN configured.
wls:/soainfra/serverConfig> executeDump(name='bpel.aps',
appName='soa-infra')
Asynchronous Process Stats
Process Id: |
------------------------------------------------------------------------------|
default/Asynchronous!1.0*soa_5c3b99b2-e1ad-4a24-9d13-f02dd8a268e/BPELProcess1 |
default/Asynchronous!1.0*soa_5c3b99b2-e1ad-4a24-9d13-f02dd8a268e/BPELProcessC |
|Minimum(m-sec) |Maximum(m-sec) |Average(m-sec) |Count
------------------------------------------------|-----
| 4 | 4 | 4.0 | 0
| 70 | 70 | 70.0 | 1
Enter the following WLST command line syntax to execute a dump of bpel.aps
in XML format with StatsLastN configured:
executeDump(name='bpel.aps', appName='soa-infra', args={'format':'xml'})
<statistics>
<stats key="default/Asynchronous!1.0*soa_5c3b99b2-e1ad-4a24-9d13-f02dd8a268e/
BPELProcess1 min="4" max="4" average="4.0" count="0">
</stats>
<stats key="default/Asynchronous!1.0*soa_5c3b99b2-e1ad-4a24-9d13-f02dd8a268e/
BPELProcess1Client min="70" max="70" average="70.0" count="1">
</stats>
</statistics>
Enter the following WLST command line syntax to execute a dump of bpel.aps
with throughput values for the duration
and buffer
parameters.
wls:/soainfra/serverConfig> executeDump(name='bpel.aps', appName='soa-infra',
args={'duration':'60', 'buffer':'1000'})
Asynchronous Process Stats (with Throughput)
Timestamp Start: 2012-07-25 10:15:31.207
Timestamp End: 2012-07-25 10:16:31.232
Sampling Window (seconds): 60
Buffer Size: 1000
Process Id: |Minimum(m-sec)
------------------------------------------------------------------------------
default/ch10.4fromParts2!1.0*soa_86cfa7a5-76f3-49fa-908a-1f9b8c | 3111
|Maximum(m-sec) |Average(m-sec) |Count |Throughput (tps)
------------------------------------------------------------------------------
| 3111 | 3111.0 | 1 | 0.01
Enter the following WLST command line syntax to execute a dump of bpel.aps
with throughput values for the duration
and buffer
parameters in XML format and StatsLastN not configured.
wls:/soainfra/serverConfig> executeDump(name='bpel.aps', appName='soa-infra',
args={'format':'xml', 'duration':'60', 'buffer':'1000'})
<statistics timestamp-start ="2012-07-25 10:19:10.937' timestamp-end
='2012-07-25 10:21:10.946">
<stats key="/default/ch11.6flow!1.0*soa_bb2b4125-068b-40d8-9eed-28b71fef6c36f/Test"
min="322" max="322" average="322.0" count="1" throughput="0.01">
</stats>
<stats key="default/ch11.7forEachSeq!1.0*soa_c7bb5f85-dcbc-4c96-a3aa-977fe5ef17cd/Test"
min="356" max="356" average="356.0" count="1" throughput="0.01">
</stats>
<stats key="default/ch11.7forEachPar!1.0*soa_8271932d-5af1-4ebe-b8ed-e1d8b3302b75/Test"
min="2492" max="2492" average="2492.0" count="1" throughput="0.01">
</stats>
</statistics>
Table 12-16 provides details about request diagnostic dumps. This dump provides the minimum, maximum, and average processing time (in milliseconds) and count of requests processed as the request flows though various layers of the BPEL process service engine. You must configure the StatsLastN System MBean Browser property described in Section 14.6.1, "Viewing Low Level Request Breakdown Table Details" to obtain this diagnostic dump. However, if the optional dump parameters duration
and buffer
are specified and StatsLastN is not configured, this dump command provides statistics for throughput (transactions per second) information.
Table 12-16 Request Statistics Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
The minimum, maximum, and average processing time (in milliseconds) and count of requests processed as the request flows though various layers of the BPEL process service engine. |
Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.rs
:
wls:/soainfra/serverConfig> describeDump(name='bpel.rs', appName='soa-infra')
Name: bpel.rs
Description: Statistics for Requests processing by Engine.
This dump provides request level statistics such as min, max and average
processing time (in milli-secs) and count of requests processed as the request
flows though various layers of engine. Note that statsLastN must be configured
to obtain this output. However, if optional parameters duration and buffer are
specified and statsLastN is not configured, this dump command would enable the
stats for the defined interval duration and return statistics which will also
include the throughput (transaction per sec) information
Run Mode: asynchronous
Mandatory Arguments:
Optional Arguments:
Name Type Description
buffer STRING Range for buffer: 100-100000. Example: args={'buffer':'100'}
duration STRING Range for duration: 1-10000 .Example: args={'duration':'1'}
format STRING Passing value of 'xml' will produce the output in xml
format. Example: args={'format':'xml'}
Enter the following WLST command line syntax to execute a dump of bpel.rs
with StatsLastN configured.
wls:/soainfra/serverConfig> executeDump(name='bpel.rs', appName='soa-infra')
or
wls:/soainfra/serverConfig> executeDump(name='bpel.rs', appName='soa-infra',
args={'format':'xml'})
<stats key="eng-composite-request" min="0" max="0" average="0.0" count="0">
<stats key="eng-single-request" min="2" max="3059" average="62.58" count="51">
<stats key="create-and-invoke" min="2" max="3059" average="62.54" count="51">
<stats key="glue-requests-store" min="0" max="1016" average="20.84" count="51">
<stats key="storeBatchEvent" min="0" max="42" average="1.31" count="51">
</stats>
<stats key="scope-serialize" min="0" max="857" average="16.92" count="51">
</stats>
</stats>
<stats key="create-instance" min="0" max="117" average="2.47" count="51">
<stats key="get-process-descriptor" min="0" max="0" average="0.0" count="51">
</stats>
<stats key="factory-create" min="0" max="86" average="1.72" count="51">
</stats>
<stats key="init-root-scope" min="0" max="22" average="0.52" count="51">
</stats>
<stats key="declare-wi-lookup-table" min="0" max="1" average="0.01" count="51">
</stats>
<stats key="init-request-context" min="0" max="0" average="0.0" count="51">
</stats>
</stats>
<stats key="log-sync-stats" min="0" max="3" average="0.05" count="51">
</stats>
<stats key="lookup-process" min="0" max="0" average="0.0" count="51">
</stats>
<stats key="log-requests-stats" min="0" max="1" average="0.01" count="51">
</stats>
<stats key="recycle-objects" min="0" max="0" average="0.0" count="153">
</stats>
<stats key="invoke-method" min="0" max="1445" average="28.58" count="51">
<stats key="audit-counter-create" min="0" max="1430" average="28.23"
count="51">
<stats key="eng-manage" min="0" max="499" average="9.9" count="51">
<stats key="sensor-send-activity-data" min="0" max="0" average="0.0"
count="102">
</stats>
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0"
count="102">
</stats>
</stats>
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0" count="51">
</stats>
<stats key="sensor-send-activity-data" min="0" max="1" average="0.01" count="51">
</stats>
</stats>
***
<stats key="check-access-control" min="0" max="15" average="0.1" count="153">
</stats>
<stats key="check-block-conditions" min="0" max="42" average="0.59" count="153">
<stats key="eng-finalize" min="0" max="42" average="0.55" count="153">
<stats key="eng-manage" min="0" max="9" average="0.13" count="102">
</stats>
<stats key="eng-until" min="0" max="41" average="0.35" count="153">
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0"
count="153">
</stats>
<stats key="sensor-send-activity-data" min="0" max="0" average="0.0" count="153">
</stats>
</stats>
</stats>
<stats key="check-expirable" min="0" max="1" average="0.0" count="153">
</stats>
<stats key="get-node" min="0" max="1" average="0.0" count="153">
</stats>
</stats>
<stats key="get-workitem" min="0" max="35" average="0.24" count="153">
<stats key="load-workitem" min="0" max="5" average="0.03" count="153">
</stats>
<stats key="load-instance-for-workitem" min="0" max="30" average="0.2"
count="153">
<stats key="load-instance" min="0" max="25" average="0.16" count="153">
<stats key="actual-instance-load" min="0" max="25" average="0.16" count="153">
<stats key="cube-instance-load-context" min="0" max="0" average="0.0"
count="153">
</stats>
</stats>
</stats>
<stats key="check-bpel-process-state" min="0" max="1" average="0.0"
count="153">
</stats>
<stats key="populate-context" min="0" max="25" average="0.0" count="153">
</stats>
</stats>
</stats>
</stats>
</stats>
</stats>
<stats key="recycle-objects" min="0" max="1" average="0.01" count="51">
</stats>
</stats>
</stats>
</statistics>
Enter the following WLST command line syntax to execute a dump of bpel.rs
with throughput values for the duration
and buffer
parameters and StatsLastN not configured.
wls:/soainfra/serverConfig> executeDump(name='bpel.rs', appName='soa-infra',
args={'duration':'10', 'buffer':'1000'})
or
wls:/soainfra/serverConfig> executeDump(name='bpel.rs', appName='soa-infra',
args={'format':'xml','duration':'10', 'buffer':'1000'})
<statistics timestamp-start ='2012-07-25 10:12:27.536' timestamp-end
='2012-07-25 10:12:27.546'>
<stats key="eng-composite-request" min="0" max="0" average="0.0" count="0">
<stats key="eng-single-request" min="19" max="55" average="31.75" count="4">
<stats key="create-and-invoke" min="19" max="55" average="31.75" count="4">
<stats key="glue-requests-store" min="2" max="14" average="5.75" count="4">
<stats key="storeBatchEvent" min="1" max="2" average="1.75" count="4">
</stats>
<stats key="scope-serialize" min="8" max="18" average="2.5" count="4">
</stats>
</stats>
<stats key="create-instance" min="0" max="9" average="2.5" count="4">
<stats key="get-process-descriptor" min="0" max="0" average="0.0" count="4">
</stats>
<stats key="factory-create" min="0" max="0" average="0.0" count="4">
</stats>
<stats key="init-root-scope" min="0" max="9" average="2.5" count="4">
</stats>
<stats key="declare-wi-lookup-table" min="0" max="0" average="0.0" count="4">
</stats>
<stats key="init-request-context" min="0" max="0" average="0.0" count="4">
</stats>
</stats>
<stats key="log-sync-stats" min="0" max="0" average="0.0" count="4">
</stats>
<stats key="lookup-process" min="0" max="0" average="0.0" count="4">
</stats>
<stats key="log-requests-stats" min="0" max="0" average="0.0" count="4">
</stats>
<stats key="recycle-objects" min="0" max="0" average="0.0" count="23">
</stats>
<stats key="invoke-method" min="1" max="9" average="3.0" count="4">
<stats key="audit-counter-create" min="1" max="1" average="1.0" count="4">
<stats key="eng-manage" min="0" max="1" average="0.5" count="4">
<stats key="sensor-send-activity-data" min="0" max="0" average="0.0" count="8">
</stats>
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0" count="8">
</stats>
</stats>
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0" count="4">
</stats>
<stats key="sensor-send-activity-data" min="0" max="0" average="0.0" count="4">
</stats>
Table 12-17 provides details about resequencer group processing delay diagnostic dumps.
Table 12-17 Resequencer Group Processing Delay Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
Group information:
Container information:
|
Enter the following WLST command line syntax to display a dump description of mediator.resequencer
:
wls:/soainfra/serverConfig> describeDump(name='mediator.resequencer',
appName='soa-infra')
The following information appears:
Name: mediator.resequencer Description: diagnostic information about the groups, which have not been processed beyond user specified maximum unprocess time Run Mode: asynchronous Mandatory Arguments: Name Type Description resequencerMaxUnprocessTime INTEGER maximum duration for which the group has not been processed, duration should be specified in minutes Optional Arguments:
Enter the following WLST command line syntax to execute a dump of mediator.resequencer
:
wls:/soainfra/serverConfig> executeDump(name='mediator.resequencer', appName='soa-infra', args={'resequencerMaxUnprocessTime':'minutes'}
For minutes, substitute the number of minutes a resequencer group can be pending before it appears in the dump. Information similar to the following appears:
Database Timestamp in UTC :2012-03-29 06:29:31.0 Max unprocess time condition:1 Mediator Resquencer pending group data COMPONENT_DN,OPERATION,GROUP_ID,STATUS,COMPONENT_STATUS,LAST_RECEIVED_TIME, CONTAINER_ID, PENDING MESSAGE COUNT default/Standard!2.0/Mediator1,execute,1001,0,0,2012-03-29 06:24:22.509394,EC09D271796511E18F5CBD26553417B4,1 ------------------------------------------------------------------------------ Containerid Data containerId,renewalTime EC09D271796511E18F5CBD26553417B4,java.util.GregorianCalendar[time=1333002526625 ,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.Zon eInfo[id="GMT-07:00",offset=-25200000,dstSavings=0,useDaylight=false,transition s=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2012,MO NTH=2,WEEK_OF_YEAR=13,WEEK_OF_MONTH=5,DAY_OF_MONTH=28,DAY_OF_YEAR=88,DAY_OF_ WEEK=4,DAY_OF_WEEK_IN_MONTH=4,AM_PM=1,HOUR=11,HOUR_OF_ DAY=23,MINUTE=28,SECOND=46,MILLISECOND=625,ZONE_OFFSET=-25200000,DST_OFFSET=0]
Table 12-18 provides details about connection factory configuration dumps.
Table 12-18 Adapter Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
Dumps the connection factory information:
Indicates if the same JNDI is being used by multiple composites. |
Enter the following WLST command line syntax to display a dump description of soa.adapter.ra
:
wls:/soainfra/serverConfig> describeDump(name='soa.adapter.ra',
appName='soa-infra')
The following information appears:
Name: soa.adapter.ra Description: SOA adapter diagnostic dump that captures connection factory configurations. Rules for actual parameter evaluation: if ecid is specified, use it to match composites associated with the ECID, composite name/partition/revision not used; if ecid is not specified, then use jndiName & adapterType to retrieve the connection factory attributes; if jndiName and adapterType are not specified, then use composite name/partition/revision to match composites; if no composite name/partition/revision are specified, then all the composites with jca binding are dumped. Mandatory Arguments: Optional Arguments: Name Type Description ecid STRING ECID(Execution Context ID - for tracking message flow across multiple composite instances), when presents, will be used to locate composites associated with it, and other composite matching parameters ignored; it can be obtained from dump context if not specified as dump parameter, see rules for actual parameter evaluation for details. revision STRING Revision of composite, e.g. '1.0', '2.0', can be wild card '*', meaning matching any revision, when missing, assume default composite's revision in the composite series. adapterType STRING Resource Adapter type partition STRING Partition of composite, default to partition(s) associated with resolved revision(s), can be wild card '*', meaning matching any partition. compositeName STRING Composite name, e.g., 'OrderProcessing', can be wild card '*',meaning matching any composite. jndiName STRING Adapter Connection Pool JNDI
Enter the following WLST command line syntax to execute a dump of soa.adapter.ra
:
wls:/soainfra/serverConfig> executeDump(name='soa.adapter.ra',
appName='soa-infra', args={'compositeName':'fa', 'partition':'default',
'revision':'1.0'})
The following information appears:
CompositeDN = default/fa!1.0*soa_7ce2ebd9-ce17-4b5a-b436-2567eab33af2 Endpoint Name = service Endpoint type = Service JNDI Name = eis/FileAdapter Adapter Type = FileAdapter Pool Parameters - ================== initial-capacity = 10 test-connections-on-create = false test-connections-on-reserve = false connection-creation-retry-frequency-seconds = 2 shrinking-enabled = true ignore-in-use-connections-enabled = true highest-num-waiters = 0 shrink-frequency-seconds = 60 connection-reserve-timeout-seconds = 5 highest-num-unavailable = 0 max-capacity = 2147483647 profile-harvest-frequency-seconds = 300 capacity-increment = 100 test-connections-on-release = false match-connections-supported = false test-frequency-seconds = 0 Transaction Support = NoTransaction Connection Factory Properties - =============================== outboundDataSource = none outboundDataSourceLocal = none outboundLockTypeForWrite = none controlDir = ${user.dir} inboundDataSource = none workingDirectory = default ================================================================ CompositeDN = default/fa!1.0*soa_7ce2ebd9-ce17-4b5a-b436-2567eab33af2 Endpoint Name = reference Endpoint type = Reference JNDI Name = eis/FileAdapter Adapter Type = FileAdapter Pool Parameters - ================== initial-capacity = 10 test-connections-on-create = false test-connections-on-reserve = false connection-creation-retry-frequency-seconds = 2 shrinking-enabled = true ignore-in-use-connections-enabled = true highest-num-waiters = 0 shrink-frequency-seconds = 60 connection-reserve-timeout-seconds = 5 highest-num-unavailable = 0 max-capacity = 2147483647 profile-harvest-frequency-seconds = 300 capacity-increment = 100 test-connections-on-release = false match-connections-supported = false test-frequency-seconds = 0 Transaction Support = NoTransaction Connection Factory Properties - =============================== outboundDataSource = none outboundDataSourceLocal = none outboundLockTypeForWrite = none controlDir = ${user.dir}inboundDataSource = noneworkingDirectory = default
Table 12-19 identifies the adapter connection pool dump.
Table 12-19 Adapter Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
Dumps the connection pool statistics for the configured connection factory JNDI. |
Enter the following WLST command line syntax to display a dump description of soa.adapter.connpool
:
wls:/soainfra/serverConfig> describeDump(name='soa.adapter.connpool',
appName='soa-infra')
The following information appears
Name: soa.adapter.connpool Description: SOA adapter diagnostic dump that captures the Connection pool stats for configured adapters JNDI. Rules for actual parameter evaluation: if ecid is specified, use it to match composites associated with the ECID, composite name/partition/revision not used; if ecid is not specified, then use jndiName & adapterType to retrieve the connection pool attributes; if jndiName and adapterType are not specified, then use composite name/partition/revision to match composites; if no composite name/partition/revision are specified, then all the composites with jca binding are dumped. Mandatory Arguments: Optional Arguments: Name Type Description ecid STRING ECID(Execution Context ID - for tracking message flow across multiple composite instances), when presents, will be used to locate composites associated with it, and other composite matching parameters ignored; it can be obtained from dump context if not specified as dump parameter, see rules for actual parameter evaluation for details. revision STRING Revision of composite, e.g. '1.0', '2.0', can be wild card '*', meaning matching any revision, when missing, assume default composite's revision in the composite series. adapterType STRING Resource Adapter type partition STRING Partition of composite, default to partition(s) associated with resolved revision(s), can be wild card '*', meaning matching any partition. compositeName STRING Composite name, e.g., 'OrderProcessing', can be wild card '*',meaning matching any composite. jndiName STRING Adapter Connection Pool JNDI
Enter the following WLST command line syntax to execute a dump of soa.adapter.connpool
:
wls:/soainfra/serverConfig> executeDump(name='soa.adapter.connpool',
appName='soa-infra', args={'compositeName':'fa', 'partition':'default',
'revision':'1.0'})
The following information appears:
CompositeDN=default/fa!1.0*soa_7ce2ebd9-ce17-4b5a-b436-2567eab33af2 Endpoint Name = service Endpoint type = Service JNDI Name =eis/FileAdapter Adapter Type =FileAdapter ConnectionPool Attributes: ========================== Important ConnectionPool Attributes: ==================================== InitialCapacity = 10 MaxCapacity = 2147483647 CurrentCapacity = 10 State = Running FreeConnectionsCurrentCount = 10 NumUnavailableCurrentCount = 0 NumberDetectedLeaks = 0 ConnectionsDestroyedByErrorTotalCount = 0 ConnectionsRejectedTotalCount = 0 Other ConnectionPool Attributes: ================================ ActiveConnectionsCurrentCount = 0 FreePoolSizeHighWaterMark = 0 PoolSizeLowWaterMark = 0 ConnectionsMatchedTotalCount = 0 LastShrinkTime = 0 FreeConnectionsHighCount = 10 ConnectionsDestroyedTotalCount = 0 ConnectionsDestroyedByShrinkingTotalCount = 0 ShrinkingEnabled = true ConnectionsCreatedTotalCount = 10 NumUnavailableHighCount = 0 MaxIdleTime = 0 LoggingEnabled = true ConnectionIdleProfileCount = 0 ConnectionProfilingEnabled = false ShrinkCountDownTime = -10565 FreePoolSizeLowWaterMark = 0 ActiveConnectionsHighCount = 0 ProxyOn = false NumWaitersCurrentCount = 0 NumWaiters = 0 CloseCount = 0 PoolSizeHighWaterMark = 0 AverageActiveUsage = 0 RecycledTotal = 0 ConnectionLeakProfileCount = 0 HighestNumWaiters = 0 ShrinkPeriodMinutes = 1 NumberDetectedIdle = 0 CapacityIncrement = 1 ================================================================ CompositeDN=default/fa!1.0*soa_7ce2ebd9-ce17-4b5a-b436-2567eab33af2 Endpoint Name = reference Endpoint type = Reference JNDI Name =eis/FileAdapter Adapter Type =FileAdapter ConnectionPool Attributes: ========================== Important ConnectionPool Attributes: ==================================== InitialCapacity = 10 MaxCapacity = 2147483647 CurrentCapacity = 10 State = Running FreeConnectionsCurrentCount = 10 NumUnavailableCurrentCount = 0 NumberDetectedLeaks = 0 ConnectionsDestroyedByErrorTotalCount = 0 ConnectionsRejectedTotalCount = 0 Other ConnectionPool Attributes: ================================ ActiveConnectionsCurrentCount = 0 FreePoolSizeHighWaterMark = 0 PoolSizeLowWaterMark = 0 ConnectionsMatchedTotalCount = 0 LastShrinkTime = 0 FreeConnectionsHighCount = 10 ConnectionsDestroyedTotalCount = 0 ConnectionsDestroyedByShrinkingTotalCount = 0 ShrinkingEnabled = true ConnectionsCreatedTotalCount = 10 NumUnavailableHighCount = 0 MaxIdleTime = 0 LoggingEnabled = true ConnectionIdleProfileCount = 0 ConnectionProfilingEnabled = false ShrinkCountDownTime = -10565 FreePoolSizeLowWaterMark = 0 ActiveConnectionsHighCount = 0 ProxyOn = false NumWaitersCurrentCount = 0 NumWaiters = 0 CloseCount = 0 PoolSizeHighWaterMark = 0 AverageActiveUsage = 0 RecycledTotal = 0 ConnectionLeakProfileCount = 0 HighestNumWaiters = 0 ShrinkPeriodMinutes = 1 NumberDetectedIdle = 0 CapacityIncrement = 1
Table 12-20 identifies the adapter diagnostic dump.
Table 12-20 Adapter Diagnostic Dumps
Dump Name | Dump Parameters/Dump Mode | Information Captured |
---|---|---|
|
|
Based on the |
Enter the following WLST command line syntax to display a dump description of soa.adapter.stats
:
wls:/soainfra/serverConfig> describeDump(name='soa.adapter.stats', appName='soa-infra')
The following information appears:
Name: soa.adapter.stats Description: SOA adapter diagnostic dump that captures DMS adapter statistics.Rules for actual parameter evaluation: if composite name/partition/revision are specified, dumps the DMS stats for that composite; if no composite name/partition/revision are specified, then all the composites with jca binding are dumped. Mandatory Arguments: Optional Arguments: Name Type Description revision STRING Revision of composite, e.g. '1.0', '2.0', can be wild card '*', meaning matching any revision, when missing, assume default composite's revision in the composite series. partition STRING Partition of composite, default to partition(s) associated with resolved revision(s), can be wild card '*', meaning matching any partition. compositeName STRING Composite name, e.g., 'OrderProcessing', can be wild card '*',meaning matching any composite.
Enter the following WLST command line syntax to execute a dump of soa.adapter.stats
:
wls:/soainfra/serverConfig> wls:/soainfra/serverConfig>
executeDump(name='soa.adapter.stats', appName='soa-infra',
args={'compositeName':'fa',
'partition':'default', 'revision':'1.0'})
The following information appears:
CompositeDN -default/fa!1.0 Service Name -service Process Incoming Message Metrics - ================================ processIncomingMessages.time (Elapsed time in milliseconds ) - 4787 msecs processIncomingMessages.completed (Elapsed time in milliseconds ) - 2 ops processIncomingMessages.minTime (Elapsed time in milliseconds ) - 32 msecs processIncomingMessages.maxTime (Elapsed time in milliseconds ) - 4755 msecs processIncomingMessages.avg (Elapsed time in milliseconds ) - 2393.5 msecs processIncomingMessages.active (Elapsed time in milliseconds ) - 0 threads processIncomingMessages.maxActive (Elapsed time in milliseconds ) - 1 threads Error Metrics - ============= Errors.count (Number of events errored during binding processing ) - 0 ops Process Incoming Message Events - =============================== processIncomingMessagesEvents.count ( Number of processed events ) - 2 ops
When diagnosing a problem that requires a thread dump, it is useful to have sufficient context around the thread activity. The Diagnostic Framework dump jvm.threads
provides DMS execution context (EC) thread stack data for SOA composite applications. The following properties are inserted when the SOA composite application instance starts executing and reset when the HTTP request completes.
composite_name
component_name
composite_instance_id
activity_name
(Lists the activities executed in the BPEL process. Activities that do not have names, such as scope activities, are not captured.)
This information is output in tabular form when the jvm.threads
dump is executed. This dump identifies where each thread is during execution of the jvm.threads
dump.
This is useful for diagnosing which SOA composite applications are processing slowly.
Enter the following WLST command line syntax to execute a dump of jvm.threads
:
executeDump(name='jvm.threads')
===== THREAD CONTEXT INFORMATION ===== id ECID RID Context Values ------- ------------------------------------------------------------- ----- --------------- id=23 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001d3f 0:1 WEBSERVICE_ PORT.name=CatchException_pt composite_name=ExceptionHandler!1.0 J2EE_MODULE.name=fabric component_name=CommsUtilityWS WEBSERVICE_NAMESPACE.name=http://xmlns. oracle.com/ExceptionHandler/CatchException J2EE_APP.name=soa-infraWEBSERVICE.name= catchexception_client_ep composite_instance_id=1 id=61 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-000000000000003c 0 id=70 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001e84 0 id=2170 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001d3f 0 DSID=0000J^2fPtuDSc Y5Hro2yf1G8M9Z000002 id=1616 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000000004 0 id=2179 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-000000000000002b 0 dbRID=0:10 id=2195 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001e7e 0 dbRID=0:2 id=2196 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001e82 0 dbRID=0:2 id=2197 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001e80 0 dbRID=0:5 ===== END OF THREAD CONTEXT INFORMATION =====
This information is also available in the AdminServer-diagnostic.log
file log.
For more information about the jvm.threads
dump, see Chapter "Diagnosing Problems" of Oracle Fusion Middleware Administrator's Guide.
DMS metrics with noun types are exposed as Oracle SOA Suite MBeans to use for diagnosing problems. This section describes the supported DMS metrics. DMS nouns can be used to create watches in Oracle WebLogic Server Administration Console.
The DMS metrics provide graphical details that appear on the Statistics page of the BPEL process service engine. For more information, see Section 14.6, "Monitoring BPEL Process Service Engine Request and Thread Performance Statistics" and Section 14.9, "Viewing Statistics About the Time a Request Spends in the BPEL Process Service Engine."
Table 12-21 shows the supported service engine sensors.
Table 12-21 Service Engine Sensors
Noun Path | Noun Type and Description | Sensor | Type |
---|---|---|---|
The various request types are audit, delivery, domain, instance, invoke, maintenance, non-block-invoke, process, and system. |
|
|
|
|
|
|
Phase Event Phase Event Phase Event Phase Event State |
The request types are audit, engine, invoke, non-block-invoke, and system. |
|
|
State State |
|
|
|
Phase Event |
|
|
Phase Event |
|
|
|
Phase Event |
|
|
|
Phase Event |
|
|
|
Phase Event |
|
|
|
Phase Event |
|
|
|
Phase Event |
|
|
|
|
State State State |
Table 12-22 shows the supported binding sensors.
Table 12-22 Binding Sensors
Noun Path | Noun Type | Sensor | Type |
---|---|---|---|
|
|
|
Phase Phase Phase |
Table 12-23 shows the supported composite sensors.
Table 12-23 Composite Sensors
Noun Path | Noun Type | Sensor | Type |
---|---|---|---|
|
|
|
State Event Phase Phase |
|
|
|
Event Phase |
|
|
Standard deviation (the user interface calculates this as it comes through) |
Event Phase Phase |
|
|
|
Event |
|
|
|
Event |
|
|
|
Phase |
Table 12-24 shows the supported reference and service sensors.
Table 12-24 Reference and Service Sensors
Noun Path | Noun Type | Sensor | Type |
---|---|---|---|
|
|
|
Event Event Phase |
|
|
|
Event Event Event |
Table 12-25 shows the supported Oracle B2B binding sensors.
Table 12-25 Oracle B2B Binding Sensors
Noun Path | Noun Type | Sensor | Type |
---|---|---|---|
|
|
|
Event Event Phase Event State |
|
|
|
Event Event Phase Event State |
|
|
|
State State Event |
|
|
|
Event |
|
|
|
State State State |
|
|
|
Event Event Phase Event State |
|
|
|
Event Event Phase Event State |
Table 12-26 shows the supported Oracle User Messaging Service sensors.
Table 12-26 Oracle User Messaging Service Event Bridge Metrics
Noun Path | Noun Type | Sensor | Type |
---|---|---|---|
|
|
|
Event Event Phase Event Event |
|
|
|
Event Event Phase Event State |
|
|
|
State |
You can create watches and send notifications around diagnosable conditions based on metrics collected from Oracle SOA Suite MBeans. When a watch expression evaluates to true (for example, heap space exceeds a specified amount), a notification is sent.
There are several options for creating watches:
Enable preconfigured rules and watches for deployment, memory, and elapsed time of web service calls with the sca_createWatches
WLST command
Manually create Oracle SOA Suite watches in Oracle WebLogic Server Administration Console
The message IDs shown in Table 12-27 have been assigned for diagnostic purposes.
When you manually create a watch in Oracle WebLogic Server Administrator's Console, you must follow the naming conventions in Table 12-27. The prefix for Oracle SOA Suite-related watches is SOA
-
message_ID
.
When you enable the preconfigured watches, the names are automatically created for you.
Table 12-27 Message Prefixes
Scenario | Message-ID | Dumps Executed | Watch Preconfigured? |
---|---|---|---|
Memory |
|
|
Yes, see Section 12.5.1, "Enabling Preconfigured Rules and Watches." |
Deployment hang |
|
|
Yes, see Section 12.5.1, "Enabling Preconfigured Rules and Watches." |
Data source |
|
|
No, see Section 12.5.2, "Manually Creating Oracle SOA Suite Watches and Notifications" for creation instructions. |
Elapsed time of web service calls |
|
|
Yes, see Section 12.5.1, "Enabling Preconfigured Rules and Watches." |
Resequencer groups pending |
|
|
No, see Section 12.5.2, "Manually Creating Oracle SOA Suite Watches and Notifications" for creation instructions. |
You can also link a WLDF notification to the watch. If you link the out-of-the-box Oracle Fusion Middleware Diagnostic Framework notification (named FMWDFW notification), then a set of SOA-specific dumps are executed. These dumps provide runtime information about the situation and environment. The list of dumps to execute is determined by predefined XML incident rules files.
Other notifications (like email) can also be linked to the watch.
The following preconfigured Diagnostic Framework rules are automatically installed with Oracle SOA Suite:
Log detection condition rule for creating an incident when an OWS-04086
error is encountered.
Condition rule that checks for the presence of the SOA composite application name in the DMS execution context (EC) and adds the soa.wsdl
and soa.composite.trail
diagnostic dumps to the list of dumps executed.
To enable these rules for use and generate the following watches, you must run the sca_createWatches
WLST command after domain creation.
Deployment watch (with a threshold of 5 minutes)
Memory watch (heap free percent with a threshold of 25 percent)
Elapsed time of web service calls watch (with a threshold of 5 minutes)
To enable the preconfigured watches:
Connect using WLST to the Oracle WebLogic Server instance and start an editing session. For information about connecting and starting an editing session, see Chapter "WLST Command and Variable Reference" of Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Execute the following WLST command to enable the preconfigured watches.
wls:/soainfra/serverConfig> sca_createWatches()
The watches are enabled and displayed along with any watches you manually create at the bottom of the Settings for Module_Name page in Oracle WebLogic Server Administration Console.
For information about executing WLST commands in Oracle SOA Suite, see Chapter "Oracle SOA Suite Custom WLST Commands" of Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
To manually create Oracle SOA Suite watches and notifications:
Log in to Oracle WebLogic Server Administration Console.
http://host:port/console
In the Domain Structure, expand Diagnostics, and select Diagnostic Modules.
The Summary of Diagnostic Modules page appears.
You configure a diagnostic system module to monitor an aspect of a server or server resource. You can configure multiple system modules to monitor different aspects of a server, but only one such module can be active on a server.
In the Diagnostic System Modules section, click Module-[Module_Name] (for example, Module-FMWDFW).
On the Settings for Module_Name page, select Watches and Notifications > Watches.
In the Watches section, click New.
The Create a Diagnostic Watch page is displayed.
Enter the following details to create a watch, and click Next.
Field | Description |
---|---|
Watch Name |
Enter a name for the watch (for this example, The name of the watch must conform to the following pattern: message-id#soa-infra#some_other_text For example, This is necessary because the watch name coordinates the Diagnostic Framework incident processing actions when watch conditions evaluate to true. Not following this pattern results in Oracle SOA Suite dumps not getting triggered when Oracle SOA Suite incidents are created. For additional information, see Table 12-27. If the watch is set up with the FMWDFW notification, the notification handler creates an incident that corresponds to the |
Watch Type |
Select an option:
|
Enable Watch |
Select to enable a watch. |
The Configure Watch Rule Expressions page for adding an expression to the watch is displayed.
Click Add Expressions.
The Add Expression wizard is displayed.
In the MBean Server location list, select the Oracle WebLogic Server MBean server for the expression you want to configure (for example, ServerRuntime).
Click Next.
Click the Select an MBean Type from the following list button.
In the MBean Type list, select the MBean to use for collecting diagnostic information (for this example, Oracle WebLogic Server MBean weblogic.management.runtime.JRockitRuntimeMBean is selected).
Click Next.
The Select Instances page is displayed.
From the Instance list, select the instance name or specify an instance name pattern to use to identify the metric for the expression.
Click Next.
Enter the following details to create a watch rule expression, and click Finish.
Field | Description |
---|---|
Message Attribute |
Select a message attribute (for this example, HeapFreePercent is selected). The attributes that are displayed for selection are part of the MBean that you selected in Step 11. For example, if you selected: oracle.dms.name=/soainfra/engines/bpel/request/system.type=soa_infra_bpel_requests
You see assigned attributes such as active_count, active_maxValue, active_minValue, scheduled_count, and others. |
Operator |
Select an operator (for this example, < is selected). |
Value |
Enter a value (for this example, 100 is specified). |
The Configure Watch Rule Expressions page is displayed with the watch rule expression you created.
Click Next.
The Config Watch Alarm page is displayed.
Optionally specify an alarm and the alarm's reset value for the watch.
Click Next.
The Configure Watch Notifications page is displayed.
In the Available table, select a notification to assign to the watch and click >.
When a watch rule expression evaluates to true, a notification is triggered. This notification is handled by the Diagnostic Framework if the FMWDFW notification is selected, which links it to the watch. The FMWDFW notification is automatically shipped with Oracle SOA Suite. Oracle recommends that you select this notification because it creates the Oracle SOA Suite dumps described in Section 12.2, "Executing Oracle SOA Suite Diagnostic Dumps."
The notification handler creates a problem incident package that contains appropriate Oracle SOA Suite dumps in the ADR. The incident package name corresponds to the message ID specified in the watch name. The incident package dumps can be viewed later using standard ADR tools. This feature enables you to take corrective actions for the problem scenario.
Click Finish.
The watch you created is displayed at the bottom of the Settings for Module_Name page. In addition, three WLDF watches that are automatically shipped with Oracle WebLogic Server (Deadlock, StuckThread, and UncheckedException) are also displayed.
In the Name column, click the specific watch name to display configuration details about the watch.
You can create a watch that keeps track of the time it takes for web service binding calls from a composite to an external references to complete. When the specified time threshold is exceeded, an incident can be created or an alert can be triggered. This watch is useful for the following scenarios:
Identify scenarios in which an invoked external reference is operating too slowly, which causes messages to collect while waiting for processing by this reference
Have high service level agreements (SLAs) and want to be notified if the SLAs are being violated from the invoked services
To create a watch to identify the elapsed time of web service binding calls:
Follow the steps described in Section 12.5.2, "Manually Creating Oracle SOA Suite Watches and Notifications" and use these guidelines to create a watch:
Set the CreateWSCallTrackingMBean property to true
under the More SOA Infra Advanced Configuration Properties section of the SOA Infrastructure Common Properties page. This property controls the creation of MBeans for tracking the elapsed time of web service binding calls, and applies globally to all SOA composite applications in the SOA Infrastructure. For each web service binding call to an external reference, a new MBean is registered to keep track of the time, and then unregistered. This property is set to false
by default. Do not set this property to true
until you see problems in your system.
For more information about accessing the SOA Infrastructure Common Properties page, see Section 3.1, "Configuring SOA Infrastructure Properties."
Specify SOA-900005#soa-infra#WSExtElapsedTimeWatch
as the watch name.
Select Collected Metrics from the Watch Type list.
Specify CreateWSCallTrackingMBean
in the Custom MBean Types field. This MBean is not available for selection from the MBean Type field.
Specify an expression rule for tracking the elapsed time it takes in milliseconds for web service binding calls from a SOA composite application to an external references to complete (in minutes). For example, this expression creates an incident when the watch is triggered.
(${ServerRuntime//[oracle.fabric.management.wldf.mbean.WSExternalBindingWatchMXBeanImpl]//ElapsedTime} > 2
An incident is created in the Oracle SOA Suite ADR directory when the watch is triggered. A readme
file in the directory displays information about the incident. For this example, BPEL service component instance 20004
was calling the WSDL-defined port CommsUtilityPort
. The elapsed time was 244013
(2.44013
minutes, which was above the elapsed time of 2
minutes set in the rule expression of the watch). Example 12-2 provides details.
Example 12-2 Incident Details
WatchDomainName: soainfra Watch Data: ServerRuntime//[oracle.fabric.management.wldf.mbean.WSExternalBindingWatch MXBeanImpl]//ElapsedTime : oracle.soa.config:Application=soa-infra.j2eeType= CompositeReferenceWatch.name=bpel#20004/soainfra/AdminServer/soainfra/default/ ExceptionHandler/1.0/soa.2075e8a1-5c69-4e5o-a679-c0ba2f6ae6/REFERENCEs/ CommsUtilityS/PORTs/CommsUtilityPort//ElapsedTime:244013
You can also create this watch automatically with the sca_createWatches
WLST command. For information, see Section 12.5.1, "Enabling Preconfigured Rules and Watches."
You can create a watch that alerts you if the counts of message wait times or processing delays exceed a certain limit.
This watch is controlled by the DispatcherStatsMap attribute of the CubeDispatcher System MBean Browser property. You can access this setting as follows:
Right-click soa-infra, and select Administration > System MBean Browser.
Expand Application Defined MBeans > oracle.as.soainfra.bpm > Server : server_name > bpel > CubeDispatcher.
Click CubeDispatcher.
Follow the steps described in Section 12.5.2, "Manually Creating Oracle SOA Suite Watches and Notifications" and use these guidelines to create a watch in the Add Expressions section of the Create Watch wizard:
Select ServerRuntime, and click Next.
Specify com.collaxa.cube.engine.dispatch.DispatcherMXBeanAdapter
in the Custom MBean Types field, and click Next. This MBean is not available for selection from the MBean Type field.
Specify oracle.as.soainfra.bpm:Application=soa-infra,name=CubeDispatcher,type=bpel
in the Custom Instance field, and click Next.
Specify DispatcherStatsMap(invokeSet)(invoke)(scheduled)
in the Attribute Expression field.
Complete the remaining fields on this page, and click Next.
You can create a watch that tracks how long it takes for resequencer groups to process messages. When the time threshold you specify is exceeded, a notification can be generated.
To create resequencer watches and notifications:
Follow the steps described in Section 12.5.2, "Manually Creating Oracle SOA Suite Watches and Notifications" using the following guidelines:
Create the watch and notification in the Module-FMWDFW module.
On the Create a Diagnostic Watch page, the name of the watch must conform to the following pattern:
MED-900000#soa-infra#some_other_text
For example, MED-900000#soa-infra#PendingGroups
.
When you create the expression, select the following MBean type:
oracle.tip.mediator.dfw.MediatorDiagnostic
There is only once choice for the instance in the expression:
oracle.mediator:name=MediatorDiagnostic,type=MediatorDiagnostic
For the Message Attribute field, select ResequencerMaxUnprocessTime
. For the value, enter the number of minutes a group can be pending before triggering a notification.
For the operator, select the greater than symbol (>).
The completed expression should look similar to the following:
(${ServerRuntime//[oracle.tip.mediator.dwf.MediatorDiagnostic]oracle.mediator:name =MediatorDiagnostic,type=MediatorDiagnostic//resequencerMaxUnprocessTime} > '15')
To create a sample custom rules file:
The watch rules expression is not provided in the dump context, so the criteria specified when generating a dump are not available. You can use a custom file named soa-infra#custom-rules.xml
to register the dump generation rules. For more information, see Section 12.1.3, "Predefined Incident Processing Rules."
Create a watch, as described above.
Create a file named soa-infra#custom-rules.xml
in one of the following locations:
Server level configuration: FMW_HOME
/user_projects/
domains/
domain_name
/config/fmwconfig/servers/
server_name
/dfw
Domain level configuration: FMW_HOME
/user_projects/
domains/
domain_name
/config/fmwconfig
/dfw
Define the rules in the new file. Example 12-3 provides a resequencer sample file.
Restart the domain or load the file dynamically. For information about dynamic loading, see Section 12.1.3, "Predefined Incident Processing Rules."
The WLDF generates the dump.
Example 12-3 shows a sample custom rules file that generates a diagnostic dump when the length of time a group stops processing messages reaches 10 minutes.
Example 12-3 Sample Custom Rules File for Resequencer Dumps
<?xml version="1.0" encoding="UTF-8"?> <diagnosticRules xmlns="http://www.oracle.com/DFW/DiagnosticsFrameworkRules" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"> <processingRules> <rule name="memory diagnosis rule"> <ruleCondition> <condition name="MESSAGE_ID" value="MED-900000" operator="EQ"/> </ruleCondition> <ruleActions> <dumpAction name="mediator.resequencer"> <argument name="resequencerMaxUnprocessTime" value="10" valueType="literal"/> </dumpAction> </ruleActions> </rule> </processingRules> </diagnosticRules>
You can manually execute existing dumps with the WLST command executeDump
and create incidents when one has not been automatically created.
To manually trigger and execute dumps:
Specify the executeDump
command to place dump contents in a file (for this example, soa.config
is the dump executed). This creates the following output:
wls:/soainfra/serverConfig> executeDump(name='soa.config', appName='soa-infra') Start Dumping deployedCompositesCatalog from MDS URI:deployed-composites/deployed-composites.xml to: /myhome/fmwhome/user_ projects/domains/mydomain/servers/myserver/adr/diag/ofm/mydomain/ myserver/incident/incdir_9/deployedCompositesCatalog Finished dumping specified MDS metadata to : /myhome/fmwhome/user_ projects/domains/mydomain/servers/myserver/adr/diag/ofm/mydomain/myserver/incid ent/incdir_9/deployedCompositesCatalog Start Dumping soaServiceEnginesConfigurations from MDS URI:soa/configuration/default to: /myhome/fmwhome/user_projects/ domains/mydomain/servers/myserver/AdminServer/adr/diag/ofm/mydomain/ myserver/incident/incdir_9/soaServiceEnginesConfigurations Finished dumping specified MDS metadata to : /myhome/fmwhome/user_projects/ domains/mydomain/servers/myserver/AdminServer/adr/diag/ofm/mydomain/ myserver/incident/incdir_9/soaServiceEnginesConfigurations
Specify the executeDump
command to display dump contents to the screen.
executeDump(name='soa.edn') Type:oracle.integration.platform.blocks.event.saq.SAQBusinessEventBus Configuration:null Status: running=true started=true ThreadCount:3 RetryCount:3 In Global: Tx:false Cluster Info:oracle.integration.platform.blocks.cluster.CoherenceCluster Interface1mpt@163bd717 SharedEDN:false OOAO Queue Name:edn_ooao_queue Java Subscriber Name:edn java subscriber Subscription Info: No namespace subscription... QName subscriptions: ============================================================= qname={http://schemas.oracle.com/events/edl/ActionOccur}ADEvent subscriptions= id=default/WSInMedPubBpelSubFileOut!1.0*soa_7a055d6a-8402-49c2-ac56-5f85cbf3d7f/ BpelSub, consistencyLevel=ONE_AND_ONLY_ONE, filter=XPath Filter: starts-with(/ be:business-event/be:content/ns0:ActionOccurrence/ns0:ParentEntityType/@value, 'A'), runAsRoles=[$publisher] id=partition_1/WSInMedPubBpelSubFileOut!1.0*soa_80a169ab1-395a-4b87-9986-9fa2742a8bd3/ BpelSub, consistencyLevel=ONE_AND_ONLY_ONE, filter=XPath Filter: starts-with(/ be:business-event/be:content/ns0:ActionOccurrence/ns0:ParentEntityType/@value, 'A'), runAsRoles=[$publisher] EventThreadContextInfo: EventTargets: Event:partition_1/WSInMedPubBpelSubFileOut!1.0*soa0a169ab1-395a-4b87-9986-9fa2742a9bd3/ BpelSub:::oracle.fabric.BPELServiceEngine@163bd6b5 Event:default/WSInMedPubBpelSubFileOut!1.0*soa7a055d6a-8402-49c2-ac56-5f85cbf3 d7f/BpelSub:::oracle.fabric.BPELServiceEngine@163bd6b5 EDN DB Log enabled:false
You can also manually create incidents when one has not been automatically created. For example, this is useful when you notice performance issues and want to create an incident to send to Oracle Support Services. The incident can include SOA dumps, according to the SOA message ID mapping.
This can be performed with the following WLST command:
createIncident(messageId="SOA-90000", appName="soa-infra")
This has the same effect as WLDF watch notification execution, in which the watch has the message ID of SOA-90000
and application name of soa-infra
.
For more information about executeDump
, see Chapter "Diagnostic Framework Custom WLST Commands" of Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
ADRCI is a command-line utility that enables you to investigate problems and package and upload first-failure diagnostic data to Oracle Support Services. ADRCI also enables you to view the names of dump files in the ADR, and to view the alert log with XML tags stripped, with and without content filtering.
ADRCI is installed in the following directory:
MW_HOME/wlserver_10.3/server/adr
For more information about ADRCI, see Chapter "ADRCI: ADR Command Interpreter" of Oracle Database Utilities.
For information about other tools, see Chapter "Managing Diagnostic Data" of Oracle Database Administrator's Guide
The Diagnostic Framework provides WLST commands that you can use to view information about problems and incidents, including the following:
Querying problems across Oracle WebLogic Servers
Querying incidents across Oracle WebLogic Servers
Viewing dump files associated with an incident on an Oracle WebLogic Server
For more information about these WLST commands, see Section "Understanding the Diagnostic Framework" of Oracle Fusion Middleware Administrator's Guide and Chapter "Diagnostic Framework Custom WLST Commands" of Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.