Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-3809

New deployment of another SwitchYard application disables ExchangeInterceptors

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • jboss-fuse-6.2.1
    • jboss-fuse-6.2.1
    • SwitchYard
    • None
    • % %
    • Hide
      1. Deploy switchyard-example2 and {{switchyard-example1 in sequence: 
        $ cd switchyard-example2/
$ mvn jboss-as:deploy
$ cd ../switchyard-example1/
$ mvn jboss-as:deploy

        You'll see the interceptor not working.

      2. Redeploy switchyard-example2 alone. You'll see the interceptor starts working.
      3. Then redeploy switchyard-example1 alone. You'll see the interceptor disabled again.
      4. Redeploy switchyard-example2 and switchyard-example1 in sequence again, but before switchyard-example1 starts to invoke switchyard-example2 run the following command under switchyard-example2: 
        $ cd switchyard-example2/
$ mvn exec:java

        Then you'll see the interceptor remains working.

      Show
      Deploy switchyard-example2 and {{ switchyard-example1 in sequence: $ cd switchyard-example2/ $ mvn jboss-as:deploy $ cd ../switchyard-example1/ $ mvn jboss-as:deploy You'll see the interceptor not working. Redeploy switchyard-example2 alone. You'll see the interceptor starts working. Then redeploy switchyard-example1 alone. You'll see the interceptor disabled again. Redeploy switchyard-example2 and switchyard-example1 in sequence again, but before switchyard-example1 starts to invoke switchyard-example2 run the following command under switchyard-example2 : $ cd switchyard-example2/ $ mvn exec:java Then you'll see the interceptor remains working.

    Description

      Product JIRA for SWITCHYARD-2775

      Suppose we have two SwitchYard applications, switchyard-example1 and switchyard-example2. switchyard-example1 (consumer) invokes switchyard-example2 (provider) via SCA binding. switchyard-example2 has an exchange intercepter SimpleInterceptor.

      When we deploy switchyard-example2 and switchyard-example1 in sequence, SimpleInterceptor doesn't work. The log shows:

      [example1.ConsumerServiceBean] ============================================================
[example2.ProviderServiceBean] Received: ConsumerServiceBean
[example1.ConsumerServiceBean] Hello, ConsumerServiceBean!
[example1.ConsumerServiceBean] ============================================================

      Then redeploying switchyard-example2 alone, we see it starts to work:

      [example1.ConsumerServiceBean] ============================================================
[example2.SimpleInterceptor] ***** Before: ProviderService -> ProviderService
[example2.ProviderServiceBean] Received: ConsumerServiceBean
[example2.SimpleInterceptor] ***** After:  ProviderService <- ProviderService
[example1.ConsumerServiceBean] Hello, ConsumerServiceBean!
[example1.ConsumerServiceBean] ============================================================

      But then redeploying switchyard-example1 alone this time, we now see it disabled again:

      [example1.ConsumerServiceBean] ============================================================
[example2.ProviderServiceBean] Received: ConsumerServiceBean
[example1.ConsumerServiceBean] Hello, ConsumerServiceBean!
[example1.ConsumerServiceBean] ============================================================

      Interestingly, if we redeploy switchyard-example1 but invoke switchyard-example2 in some other way (e.g. remote client invocation using HttpInvoker) before switchyard-example1 starts to invoke switchyard-example2, the interceptor remains working.

      This observation makes me suspect that a local SCA invocation from a newly deployed application somehow overrides the bean registry with its thread local context.

      Attachments

        Issue Links

          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. ENTESB-3811 [FSW 6.0.x] New deployment of another SwitchYard application disables ExchangeInterceptors

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              virchete_jira David virgil naranjo (Inactive)
              rhn-support-tasato Tadayoshi Sato
              Tomas Turek Tomas Turek
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: