dm Server
  1. dm Server
  2. DMS-2261

Service listener does not see published service

    Details

    • Type: Defect Defect
    • Status: Done Done
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 2.0.0.RC1
    • Fix Version/s: 2.0.0.RELEASE
    • Component/s: None
    • Labels:
      None
    • Environment:

      OSX/Windows, Java 6

      Description

      See forum post for detailed information on the use case. Attaching a sample application that tries to recreate the issue.

      Sample application has a 2 slices. Slice 1 publishes a service and Slice 2 publishes the service. Slice 1 has an osgi:list with a listener. Listener will only be triggered if Slice 2 is started prior to slice 1, i.e. Slice 2 service is already published.

      Attachment also includes customized version of Slices to account for kernel refactoring (see DMS-2257).

        Issue Links

          Activity

          Hide
          Andy Wilkinson added a comment -

          Thanks for taking the time to boil this down to a sample application that recreates the issue. Unfortunately, I'm out on my Christmas break at the moment and very few of the team are left in the office so we may not get a chance to look at this until the new year. Apologies for the delay if that turns out to be the case.

          Show
          Andy Wilkinson added a comment - Thanks for taking the time to boil this down to a sample application that recreates the issue. Unfortunately, I'm out on my Christmas break at the moment and very few of the team are left in the office so we may not get a chance to look at this until the new year. Apologies for the delay if that turns out to be the case.
          Hide
          Andy Wilkinson added a comment -

          Thanks again for the sample application.

          I've spent some time playing around with it to try to get a feel from the problem. From this playing around my feeling at the moment is that the problem is in someway related to service scoping as I've been unable to reproduce the problem when I set the plan's scoped attribute to false. Interestingly when the plan is scoped, I have seen the problem occur irrespective of the ordering of the service publisher and the service consumer in the plan. This leads me to suspect that it isn't dependent on this ordering specifically. My gut feel is that there's some sort of race occurring which is causing the problem to be intermittent.

          Show
          Andy Wilkinson added a comment - Thanks again for the sample application. I've spent some time playing around with it to try to get a feel from the problem. From this playing around my feeling at the moment is that the problem is in someway related to service scoping as I've been unable to reproduce the problem when I set the plan's scoped attribute to false. Interestingly when the plan is scoped, I have seen the problem occur irrespective of the ordering of the service publisher and the service consumer in the plan. This leads me to suspect that it isn't dependent on this ordering specifically. My gut feel is that there's some sort of race occurring which is causing the problem to be intermittent.
          Hide
          Andy Wilkinson added a comment -

          I believe that I understand some of the problem, although it doesn't precisely match what I thought I'd observed earlier. That may have been user error on my part, however.

          The root cause of the problem is that service scoping only scopes services that are published by an application context definition that is in the default META-INF/spring location. This means that if the user has specified a custom location, or is using a Web-related bundle where the application context is created via a DispatcherServlet (as is the case in Dmitry's sample application). This means that the services are always published in the global scope.

          When the lookup is performed, the ScopeRegistry is checked for all services that are in the consumer's scope. None is found as the services haven't been scoped due to the problem described above. This means that the logic then looks for a service in the global scope. However, although the service itself isn't scoped, the bundle that published it is and therefore, the service is identified as belonging to an application scope so it's not in the global scope and the hook filters it out.

          Show
          Andy Wilkinson added a comment - I believe that I understand some of the problem, although it doesn't precisely match what I thought I'd observed earlier. That may have been user error on my part, however. The root cause of the problem is that service scoping only scopes services that are published by an application context definition that is in the default META-INF/spring location. This means that if the user has specified a custom location, or is using a Web-related bundle where the application context is created via a DispatcherServlet (as is the case in Dmitry's sample application). This means that the services are always published in the global scope. When the lookup is performed, the ScopeRegistry is checked for all services that are in the consumer's scope. None is found as the services haven't been scoped due to the problem described above. This means that the logic then looks for a service in the global scope. However, although the service itself isn't scoped, the bundle that published it is and therefore, the service is identified as belonging to an application scope so it's not in the global scope and the hook filters it out.
          Hide
          Ben Hale (c) added a comment -

          We believe we can fix this problem by relaxing the logic a little such that when a service is found in the application's scope, we will always use the service regardless of whether we're looking in the application's scope or in the global scope. This works around the problem described above where we believe we should be looking in the global scope, when in fact we should be looking in the application's scope.

          Show
          Ben Hale (c) added a comment - We believe we can fix this problem by relaxing the logic a little such that when a service is found in the application's scope, we will always use the service regardless of whether we're looking in the application's scope or in the global scope. This works around the problem described above where we believe we should be looking in the global scope, when in fact we should be looking in the application's scope.
          Hide
          Glyn Normington (c) added a comment - - edited

          A clarification of the proposed fix. The current code handles a consumer in an application scope when no matching service is found in the scope's service model by looking in the global scope. The logic needs to change in this case so that the application scope is checked before, and preferred to, the global scope.

          Unfortunately, this does not cover the case of a service in the application scope which is yet to be published but which is not included in the scope's service model. In this case, rather than waiting, the consumer could bind to a global service, which is incorrect behaviour when compared to the behaviour where the service model includes the service.

          I have raised DMS-2288 to cover the case when a non-web bundle has its application context files in a non-default location.

          I have raised DMS-2289 to consider unifying the web and non-web behaviour.

          Show
          Glyn Normington (c) added a comment - - edited A clarification of the proposed fix. The current code handles a consumer in an application scope when no matching service is found in the scope's service model by looking in the global scope. The logic needs to change in this case so that the application scope is checked before, and preferred to, the global scope. Unfortunately, this does not cover the case of a service in the application scope which is yet to be published but which is not included in the scope's service model. In this case, rather than waiting, the consumer could bind to a global service, which is incorrect behaviour when compared to the behaviour where the service model includes the service. I have raised DMS-2288 to cover the case when a non-web bundle has its application context files in a non-default location. I have raised DMS-2289 to consider unifying the web and non-web behaviour.
          Hide
          Glyn Normington (c) added a comment -

          Also note that this issue is most likely to occur with slices as web bundles do not normally publish services.

          Show
          Glyn Normington (c) added a comment - Also note that this issue is most likely to occur with slices as web bundles do not normally publish services.
          Hide
          Glyn Normington (c) added a comment -

          Fixed in the 2.0.x branch. Still to migrate the fix to master, but closing this issue now.

          Show
          Glyn Normington (c) added a comment - Fixed in the 2.0.x branch. Still to migrate the fix to master, but closing this issue now.

            People

            • Assignee:
              Glyn Normington (c)
              Reporter:
              Dmitry Sklyut
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                First Response Date:

                Time Tracking

                Estimated:
                Original Estimate - 4h 40m Original Estimate - 4h 40m
                4h 40m
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 12h 4m
                12h 4m