[
https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978205#comment-15978205
]
Peter Kriens commented on FELIX-5618:
-------------------------------------
If you checkout the workspace in bndtools then double click the bnd.bnd file in
the osgi.enrout.examples.concurrency.cycle project, select the Run tab, click
on the Run or Debug icon right top of the window.
You can switch the order of the bundles by going to the Source tab and reorder
the -runbundles list.
The problem is both in the field and event strategy. I switch to the even
strategy to show the ordering with sysouts.
If you want it with different versions you can change the -runbundles. Extra
dependencies can be added via
https://github.com/pkriens/felix.scr.cycle/blob/master/cnf/central.xml, which
is a normal POM. In bndtools, you need to trigger the update by modifying
build.bnd to kick it. (Add a space or so)
> 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
(v6.3.15#6346)
