The short answer is yes it has to do with the threading model.
A jms adapter request / response pattern will cause as other dehydration points do, the original thread to be returned (and subsequently a commit, once it passed through the owner of the transaction) and a second thread [in this case an engine one] to delivery the result and continue the execution of the rest of the process.
So sequence wise - the below happens
Thread (1) -> receive (initial) -> invoke (of jms adapter plnk) -> receive (create the subscription).
Thread (2) [upon result] -> delivery [receive part2] -> throw
In this case the fault is unhandled and the original thread gone, and we don't maintain a conversation id. This is why one gets the ReceiveTimeoutException, because the DeliveryService.getResult (which waits for the result) will timeout w/o getting the fault or a result ever passed back.
In a case like this, one needs to employ the second way of throwing faults - and that's via reply, but this time not just with an output variable but rather with a faultname as well.
With that in place - his process worked.
sca_bpel-106-FaultHandling_rev1.0.jar shows this technique.
After deployment - test the "Test asynccalldurablefaultthrower_client_ep" service, and put "reply" as input. This will trigger a fault to be replied in the detail process. If you go to EM now you will see that the master is in state "recovery needed" because a fault policy kicked in.
If you try again but this time with "fault" as input - and go to EM you will see another exception - that says "Waiting for result - timed out". That originates from the "throw" in the callee process.
If you want to look into the composite yourself - just import the sar in jdeveloper.
0 comments:
Post a Comment