Manual Recovery Process Is Creating Duplicate Messages with JMS Adapter (Doc ID 1187003.1)

Last updated on MARCH 08, 2017

Applies to:

Oracle(R) BPEL Process Manager - Version: 10.1.3.1 and later   [Release: AS10gR3 and later ]
Information in this document applies to any platform.

Symptoms

INFLIGHT INSTANCES CREATED THROUGH JMS ADAPTER SHOWING UP IN RECOVERY CONSOLE

jms aq queue -> jms adapter -> (receive) Bpel process A -> sleep(20seconds) -> asynch invoke -> Bpel process B

and here are the usecase steps:

1. Through the JMS Adapter an instance of Process A dequeues a message from queue and an instance of "A" is created through the "receive" activity.

<receive createInstance="yes" id="BpRcv0" name="Receive_1"
operation="Consume_Message" partnerLink="JMSAdapterToBPELService"
portType="ns1:Consume_Message_ptt"
variable="Receive_1_Consume_Message_InputVariable"/>

At this point the process A will appear in the "Recover(Invokes) Tab" since the state of "A" is

invoke_message.state=0

2. Process "A" then does some work, which in the case of this application in the bug it does some transforms etc... but process "A" stays in the recovery tab until a dehydration point is reached.

*** Note if during this time someone recovers the instance then we will get a new seperate instance of "A->B" that duplicates the orginal instance. This is what the customer wants to avoid

3. Process "A" then does an asynchronous invoke of "B" which is a dehydration point and causes "A" to be removed from "Recover(Invokes) Tab", and so, we are safe since we cannot recover an inflight instance - the state changes at this point to 2.

invoke_message.state=2

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms