Uploaded image for project: 'Aries'
  1. Aries
  2. ARIES-1921

AbstractServiceReferenceRecipe - why is *tracked* attribute closed on stop?



    • Type: Question
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: blueprint-core-1.8.0
    • Fix Version/s: None
    • Component/s: Blueprint
    • Labels:
    • Environment:

      JBoss Fuse 630396 (blueprint.core-1.8.0), camel 2.17.0, windows


      I'm experiencing difficulties with osgi service references - I'm unsure if this is the right way of asking about it - but I'll give it a try.

      I've got 2 bundles - lets call them Producer and Consumer. Producer produces an OSGI service, and Consumer uses it, via blueprint reference:

      <reference id="myTestService" interface="com.foo.TestService" timeout="30000"/>

      When the producer is restarted, Consumer's reference starts pointing to the old version of the service, instead of the new one, and stays in that state until I manually restart the consumer. This only happens under the condition that I use Camel and it's @BeanInject annotation to inject the service into a bean.
      I've debugged this quite a lot, but I'm not very familiar with the codebase. I've managed to track the problem down to AbstractServiceReferenceRecipe#tracked attribute, which ends up with closed = true, and keeps that way forever. This happens when BlueprintContainerImpl#processProcessors calls untrackServiceReferences. I can provide a test project, with 3 bundles - Producer, Consumer (in which the problem occurrs) and ConsumerWithoutCamel (which works fine), if necessary.

      I tried to fix this by commenting out tracked.close() in AbstractServiceReferenceRecipe#stop, but I fear that this will have other side effects, which I can't forsee with my level of familiarity with this framework
      Maybe the author of Tracked class - [~gnt] - could help?

      Thank you very much,

      Rastislav Papp




            • Assignee:
              rastislav.papp Rastislav Papp
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: