Bug 974980 - Transaction handling is broken when calling a service from Camel component
Transaction handling is broken when calling a service from Camel component
Status: CLOSED CURRENTRELEASE
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: SwitchYard (Show other bugs)
6.0.0 GA
Unspecified Unspecified
unspecified Severity high
: ER1
: 6.0.0
Assigned To: Keith Babo
Jiri Pechanec
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-17 06:06 EDT by Jiri Pechanec
Modified: 2014-06-16 19:53 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Reproducer (18.39 KB, application/x-compressed-tar)
2013-06-17 23:39 EDT, Jiri Pechanec
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker SWITCHYARD-1550 Blocker Closed SwitchYardProducer does not prune transient context properties in camel routes 2014-06-16 19:53:31 EDT

  None (edit)
Description Jiri Pechanec 2013-06-17 06:06:12 EDT
The issue is present when there is a Camel-implented service C.

Form this service call a service S that has managedTransaction.Global policy set.

The call then fails with Required policies have not been provided: managedTransaction.Global

The problem is that when TransactionHandler is executed for the service S it goes through handleAfter method instead of handleBefore.

It seems that when service C goes through transaction handler handleBefore then it sets org.switchyard.exchange.transaction.beforeInvoked on SY exchange.

When SwitchYardProducer.process prepares to call the service S it creates a new SY exchange. This exchange has context properties that were obtained from CamelExchange (and SY exchange for service C).

So, the property org.switchyard.exchange.transaction.beforeInvoked is set to true on newly create exchange and when the service is invoked then the trascation handler goes through the wrong phase and required policies are thus not provided.
Comment 1 Keith Babo 2013-06-17 07:11:16 EDT
Can you attach an app to reproduce this and also provide the error / stack trace you are seeing for the failure?

Also, which build is this?  Alpha1?
Comment 2 Jiri Pechanec 2013-06-17 23:39:55 EDT
Created attachment 762276 [details]
Reproducer

The issue is present in DR5

Rproducer is based on the QA camel-service. I added one bean service TransactionalServiceBean. The test works if the service is not marked as requires="managedTransaction.Global". When the policy is added (as is now) It throws an exception - about required policy,
Comment 3 Keith Babo 2013-06-20 22:30:32 EDT
Awesome catch on this issue.  Chances are good we would have missed this for 1.0 Final if you didn't find it.

SwitchYardProducer, which is used to handle switchyard:// endpoints in a Camel route, is propagating context properties with a label of TRANSIENT which should not happen.  This is definitely a bug and will be fixed for SY 1.0.0.Final.

IMO, I don't think this is a blocker for Alpha2 as it is confined to cases where multiple services are called from a Camel route with policy configured on the invoked service.  I should mention there is a workaround available which involves adding a bean to your camel route to manually prune the offending context properties:

@Named("PolicyCleanup")
public class CleanContext {

  public void clean(Exchange exchange) {	   
    exchange.removeProperty("org.switchyard.exchange.transaction.initiated");
  }
}

public void configure() {
        from("switchyard://JavaDSL")
            .log("Message received in Java DSL Route")
            .log("${body}")
            .to("switchyard://TransactedService")
            .beanRef("PolicyCleanup")
            .split(body(String.class).tokenize("\n"))
            .to("switchyard://XMLService?operationName=acceptMessage");
    }

This workaround is not ideal, obviously, but I think it's a minor annoyance for Alpha2 users.  The fix for this is reasonably small, so we could consider delivering this as a patch on top of Alpha2 if it causes big trouble.  This will be fixed in SY 1.0.0.Final and available in Beta builds for customers.
Comment 5 JBoss JIRA Server 2013-06-27 15:41:08 EDT
Keith Babo <kbabo@redhat.com> made a comment on jira SWITCHYARD-1550

pushed
Comment 6 Jiri Pechanec 2013-09-18 08:11:22 EDT
Verified in ER2
Comment 10 JBoss JIRA Server 2014-06-16 19:53:32 EDT
Keith Babo <kbabo@redhat.com> updated the status of jira SWITCHYARD-1550 to Closed

Note You need to log in before you can comment on or make changes to this bug.