Process Instances Do Not Appear In The BPEL Console - Timeout Errors
Oracle(R) BPEL Process Manager - Version: 10.1.2 to 10.1.3
This problem can occur on any platform.
Symptoms
New BPEL process instances are not visible in the BPELConsole.
However, Instance activity can be seen in the domain.log.
Additionally you may see transaction timeout errors in the Domain.log
Cause
At the application server J2EE layer, the JTA transaction timeout is less than the time it takes to perform an activity.
The recommended JTA transaction timeout value should be increased to the total time of the sync activity or exec activity, then add 2-3 minutes.
Solution
To implement the solution, please execute the following steps:
1. Within the J2EE application container level, increase the JTA transaction timeout value to the
expected total time of a sync activity or exec activity, then add 2-3 minutes.
2. Restart the container and retest.
If using OAS, this is configured via the iasconsole > midtier:instance > OC4J:instance > config > server.xml > transaction-config timeout parameter that by default is set to 30000.
Info on this parameter:
Oracle® Application Server Containers for J2EE, User’s Guide, 10g Release 2 (10.1.2)
Part No. B14011-01
Page 116/144
http://download-west.oracle.com/docs/cd/B14099_09/web.1012/b14011.pdf
<transaction-config>
Transaction configuration for the server.
Attribute:
¦ timeout="30000" — Specifies the maximum amount of time (in milliseconds) that a transaction can take to finish before it is rolled back due to a timeout. The default value is 30000. This timeout will be a default timeout for all transactions
that are started in OC4J. You can change it by using the dynamic API—UserTransaction.setTransactionTimeout(milliseconds).
In OAS / OC4J / SOA Suite 10.1.3 this parameter is no longer supported. Instead this is defined through the Application Server Control url, and then: oc4j_soa instance > administration > under SERVICES / Transaction Manager (JTA) > administration > under GENERAL, modify 'Transaction Timeout'. Apply and restart the container. For more details see: Oracle® Containers for J2EE Services Guide, 10g (10.1.3.1.0), Part Number B28958-01 - http://download-west.oracle.com/docs/cd/B31017_01/web.1013/b28958/jta.htm
Additionally, Appendix A1.1 of the BPEL Developer Guide goes into detail for each of the timeout settings, at http://download-west.oracle.com/docs/cd/B31017_01/integrate.1013/b28981/app_trblshoot.htm#sthref3957
NOTES: The 'syncMaxWaitTime' parameter in the Manage / BPEL Domain link of the BPELConsole can also be modified to alter the maximum time the process result receiver will wait for a result before returning. Results from asynchronous BPEL processes are retrieved synchronously via a receiver that will wait for a result from the container. This can useful when debugging transaction timeout errors that can sometimes accompany the main subject of this Note.
Additionallty: The level of logging can be modified to improve performance of a system via the 'Manage BPEL Domain' link within the BPEL console. From there you can alter the audit level based on your desired preferences;
auditLevel: Audit trail logging level Controls the amount of audit events logged by a process; currently supported logging levels are:
* off - absolutely no logging performed whatsoever; may result in a slight performance boost for processing instances.
* minimal - all events are logged; however, no audit details are logged.
* production - all events are logged. The audit details for assign activities are not logged; the details for all other nodes are logged.
* development - all events are logged; all audit details for all activities are logged.
The default value is "development".
This problem can occur on any platform.
Symptoms
New BPEL process instances are not visible in the BPELConsole.
However, Instance activity can be seen in the domain.log.
Additionally you may see transaction timeout errors in the Domain.log
Cause
At the application server J2EE layer, the JTA transaction timeout is less than the time it takes to perform an activity.
The recommended JTA transaction timeout value should be increased to the total time of the sync activity or exec activity, then add 2-3 minutes.
Solution
To implement the solution, please execute the following steps:
1. Within the J2EE application container level, increase the JTA transaction timeout value to the
expected total time of a sync activity or exec activity, then add 2-3 minutes.
2. Restart the container and retest.
If using OAS, this is configured via the iasconsole > midtier:instance > OC4J:instance > config > server.xml > transaction-config timeout parameter that by default is set to 30000.
Info on this parameter:
Oracle® Application Server Containers for J2EE, User’s Guide, 10g Release 2 (10.1.2)
Part No. B14011-01
Page 116/144
http://download-west.oracle.com/docs/cd/B14099_09/web.1012/b14011.pdf
<transaction-config>
Transaction configuration for the server.
Attribute:
¦ timeout="30000" — Specifies the maximum amount of time (in milliseconds) that a transaction can take to finish before it is rolled back due to a timeout. The default value is 30000. This timeout will be a default timeout for all transactions
that are started in OC4J. You can change it by using the dynamic API—UserTransaction.setTransactionTimeout(milliseconds).
In OAS / OC4J / SOA Suite 10.1.3 this parameter is no longer supported. Instead this is defined through the Application Server Control url, and then: oc4j_soa instance > administration > under SERVICES / Transaction Manager (JTA) > administration > under GENERAL, modify 'Transaction Timeout'. Apply and restart the container. For more details see: Oracle® Containers for J2EE Services Guide, 10g (10.1.3.1.0), Part Number B28958-01 - http://download-west.oracle.com/docs/cd/B31017_01/web.1013/b28958/jta.htm
Additionally, Appendix A1.1 of the BPEL Developer Guide goes into detail for each of the timeout settings, at http://download-west.oracle.com/docs/cd/B31017_01/integrate.1013/b28981/app_trblshoot.htm#sthref3957
NOTES: The 'syncMaxWaitTime' parameter in the Manage / BPEL Domain link of the BPELConsole can also be modified to alter the maximum time the process result receiver will wait for a result before returning. Results from asynchronous BPEL processes are retrieved synchronously via a receiver that will wait for a result from the container. This can useful when debugging transaction timeout errors that can sometimes accompany the main subject of this Note.
Additionallty: The level of logging can be modified to improve performance of a system via the 'Manage BPEL Domain' link within the BPEL console. From there you can alter the audit level based on your desired preferences;
auditLevel: Audit trail logging level Controls the amount of audit events logged by a process; currently supported logging levels are:
* off - absolutely no logging performed whatsoever; may result in a slight performance boost for processing instances.
* minimal - all events are logged; however, no audit details are logged.
* production - all events are logged. The audit details for assign activities are not logged; the details for all other nodes are logged.
* development - all events are logged; all audit details for all activities are logged.
The default value is "development".
Comments