felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
Date Thu, 20 Apr 2017 23:13:04 GMT

    [ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15977762#comment-15977762

David Jencks commented on FELIX-5618:

I'd forgotten a bit about how the circular refs test was set up, but on the other hand your
description of your code is quite misleading or what's in the git repo isn't what you are
talking about.  The code in your linked git repo uses the event strategy, is that what you
are actually testing or are your earlier hints that you are using the field strategy more

I locally modified one of the existing circular tests (1-1 static, 0-n dynamic) to start the
two components in both orders, and they both appear to work when the components are in the
same bundle.

I don't see how one is supposed to run a test using the code in your git repo, could you explain
what you did to demonstrate the problem?

> Cycles in DS depending on bundle order
> --------------------------------------
>                 Key: FELIX-5618
>                 URL: https://issues.apache.org/jira/browse/FELIX-5618
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>         Environment: MacOS + Windows + Linux
>            Reporter: Peter Kriens
>            Priority: Blocker
>         Attachments: scr-cycle-2.0.2-bottom-top.txt, scr-cycle-2.0.2-top-bottom.txt,
scr-cycle-2.0.6-bottom-top.txt, scr-cycle-2.0.6-top-bottom.txt
> Following test case:
>        top.jar: Top @Reference volatile List<Bottom>
>        bottom.jar: Bottom @Reference Top
> In SCR 2.0.2:
>       top.jar, bottom.jar -> OK, see trace
>            new Top()
>            Top.activate()
>            new Bottom()
>            Bottom.top=<top>
>            Bottom.activate()
>           Top.bottom +=<bottom>
>       bottom.jar, top.jar -> FAILS but recovers
>           [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] 
>           Circular reference detected, getService returning null
>           new Top()
>           Top.activate()
>           new Bottom()
>           Bottom.top=<top>
>           Bottom.activate()
>           Top.bottom +=<bottom>
> In SCR 2.0.4 and later
>      top.jar,bottom.jar -> OK
>            new Top()
>            Top.activate()
>            new Bottom()
>            Bottom.top=<top>
>            Bottom.activate()
>            Top.bottom +=<bottom>
>       bottom.jar, top.jar -> FAILS and DOES NOT RECOVER!
>            new Bottom()
>            new Top()
>            Top.activate()
>            new Bottom()
> The Bottom component never gets added to Top. This is a very serious problem for reliable
systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8
> ----------
> I've traced the cycle problem in 2.0.2. What happens is:
> 1) The Bottom configuration is started. There is no Top, so it is not satisfied
> 2) The Top configuration is started. It is satisfied since it can live with 0 Bottoms.

> 3) The top configuration registers Top
> 4) The bottom configuration sees a Top and initiates Bottom
> 5) The bottom configuration gets Top (which is under construction)
> 6) The top configuration looks at its dependencies
> 7) The top configuration sees there is a Bottom now and tries to get it
> 8) The bottom factory is called again on the same thread and blows up
> I am not sure what happens in 2.0.4 and later but it does look scary that Bottom is now
never added to the Top.
> ---- Fix
> I tried to do the activation in a background thread that but that failed. I think the
cycle should be detected and and de Top should not get its dynamic dependencies after the
activate method returned. But, just a guess, this is complicated stuff.
> ---- Workaround
> The workaround is to not let Top register as a service but manually register it at the
end of the activate method. Since the service is then already initialized and registered,
the Bottom will not get activated until the Top is done.
> There is a bnd workspace that consistently shows this output.
> https://github.com/pkriens/felix.scr.cycle
> I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar

This message was sent by Atlassian JIRA

View raw message