[
https://issues.apache.org/jira/browse/FELIX-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559728#comment-16559728
]
Marko Herchet edited comment on FELIX-5887 at 7/27/18 1:56 PM:
---------------------------------------------------------------
I attached a simple sample (two eclipse-projects, target and launch-config)
that produces the "Circular reference detected trying to get service" error.
When changing the launch-config to use felix.scr 2.0.10 instead of 2.0.14, no
error occurs.
Until now this is the only one of my three "Circular Reference" scenarios which
I get in production environment, that I was able to reproduce with a simple
application. And the one that seems to cause the least trouble because the
services will be created and activated anyway.
was (Author: mherchet):
I attached a simple sample (two eclipse-projects, target and launch-config)
that produces the "Circular reference detected trying to get service" error.
When changing the launch-config to use felix.scr 2.0.10 instead of 2.0.14, no
error occurs.
Until now this is the only one of my three "Circular Reference" scenarios I get
in production environment, that I was able to reproduce with a simple
application and the one that seems to do the least troube cause the services
will be created and activated despite of it.
> Cycles in DS depending on bundle order
> --------------------------------------
>
> Key: FELIX-5887
> URL: https://issues.apache.org/jira/browse/FELIX-5887
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-2.0.14, scr-2.1.0
> Environment: MacOS + Windows + Linux
> Reporter: Marko Herchet
> Priority: Critical
> Attachments: TestProjects.7z
>
>
> 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
(v7.6.3#76005)
