Synchronous BPEL process with a wait activity fails with a timeout

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] [] [] [tid: [ACTIVE].ExecuteThread: '19' for
queue: 'weblogic.kernel.Default (self-tuning)'] [userId: ] [ecid: b1ee8223c4e185ca:5044d24d:13b1807f7e8:-8000-
0000000000000672,0:2] [SRC_CLASS: DeliveryHandler] [ BPELProcess1_pt] [APP: soa-infra] [composite_name:
WaitTestProject3] [ fabric] [SRC_METHOD: initialRequestAnyType] [ bpelprocess1_client_ep]
[ soa-infra] [[ Waiting for response has timed out. The conversation id is null. Please
check the process instance for detail.
at com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.request(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(

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:


  • Change bpel.config.transaction to “requiredNew”

6 Replies to “Synchronous BPEL process with a wait activity fails with a timeout”

  1. Thanks!!
    if i keep syncCaller txn property to required and remove the asyncCallee wait activity its still giving the same error.
    Not just the wait – there can be more dehydration point.
    Please confirm.

  2. we are having an issue with bpel 10g. It is taking rows from a table which are ordered in a certain sequence and calling a function to process these rows. sometimes the called function outputs the processed rows out of sequence.
    If you have a solution to this could you mail it to me

    Many Thanks

    • Hi Barry,

      It has been quite a while since I have worked with 10g and this issue doesn’t ring a bell. Hope you can figure it out! I’ll let you know if I perhaps think of something.

      Best regards,

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.