Recently we had a timing issue in our project. We were processing certain events and one event got processed before another one which caused a problem. A quick fix seemed possible by adding a Wait activity in our BPEL process which got processed too quickly. We added the Wait and set it to 2 seconds. We deployed it, ran our unit test again but it seemed to ignore the 2 seconds wait activity even though it showed up in the Enterprise Managers trace. We then had a better look at the Oracle documentation and the Wait activity seemed to have some special rules to it.
When specifying a time period for waiting, note the following:
- Wait times cannot be guaranteed if they are scheduled with other events that require processing. Due to this additional processing, the actual wait time can be greater than the wait time specified in the BPEL process.
- Wait times of less than two seconds are ignored by the server. Wait times above two seconds, but less than one minute, may not get executed in the exact, specified time. However, wait times in minutes do execute in the specified time.
- The default value of 2 seconds for wait times is specified with the MinBPELWait property in the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control Console. You can set this property to any value and the wait delay is bypassed for any waits less than MinBPELWait.
So the 2 seconds didn’t work as the documentation pointed out. Next we tried setting it to 3 seconds. After deploying the composite again and running the unit tests, we ran into a timeout error.
[2012-11-20T02:12:38.781-04:30] [soa_server1] [TRACE]  [oracle.soa.bpel.engine.delivery] [tid: [ACTIVE].ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: b1ee8223c4e185ca:5044d24d:13b1807f7e8:-8000- 0000000000000672,0:2] [SRC_CLASS: DeliveryHandler] [WEBSERVICE_PORT.name: BPELProcess1_pt] [APP: soa-infra] [composite_name: WaitTestProject3] [J2EE_MODULE.name: fabric] [SRC_METHOD: initialRequestAnyType] [WEBSERVICE.name: bpelprocess1_client_ep] [J2EE_APP.name: soa-infra] [[ com.oracle.bpel.client.delivery.ReceiveTimeOutException: Waiting for response has timed out. The conversation id is null. Please check the process instance for detail. at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequestAnyType(DeliveryHandler.java:656) at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequest(DeliveryHandler.java:562) at com.collaxa.cube.engine.delivery.DeliveryHandler.request(DeliveryHandler.java:235) at com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.request(CubeDeliveryBean.java:494) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
After some looking around, a colleague of mine came up with a reference to an Oracle support document 1507094.1. This document states that the Wait activity works well with an asynchronous BPEL process but not with a synchronous BPEL process where a transaction is required. The Wait activity involves a dehydration. Dehydration will persist the process and continue the process in a new thread. When the BPEL process is transaction required, the persist will not be complete until the BPEL process completes and transaction commits.
One of the solutions is possible:
- Remove the following line from the synchronous BPEL process component:
<property name="bpel.config.transaction" type="xs:string" many="false">required</property>
- Change bpel.config.transaction to “requiredNew”
<property name="bpel.config.transaction" type="xs:string" many="false">requiredNew</property>