Carsten’s example results in the sequence 1. bind X ranking 1 2. bind X ranking 100 3 unbind X ranking 1
IIRC this is explicitly mandated by the spec. This is a different order than Tom’s example. FWIW I suspect Tom’s situation can arise after component activation if two threads register two more X’s simultaneously at different rankings. > On Jul 11, 2023, at 11:55 PM, Christoph Läubrich (Jira) <j...@apache.org> > wrote: > > > [ > https://issues.apache.org/jira/browse/FELIX-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17742296#comment-17742296 > ] > > Christoph Läubrich commented on FELIX-6616: > ------------------------------------------- > > [~cziegeler] I think what you describes is expected and the usual pattern for > dynamic single reference is using a AtomicReference and use the different > compare and set methods but I'm not sure if it is the same problem and why a > compnent should be "confused" here, maybe [~tjwatson] is referring to a > static (non dynamic) service where it would be indeed be quite unexpected. > >> Dynamic greedy 1..1 references may activate with no reference service bound >> --------------------------------------------------------------------------- >> >> Key: FELIX-6616 >> URL: https://issues.apache.org/jira/browse/FELIX-6616 >> Project: Felix >> Issue Type: Bug >> Components: Declarative Services (SCR) >> Affects Versions: scr-2.2.6 >> Reporter: Tom Watson >> Assignee: Tom Watson >> Priority: Major >> Fix For: scr-2.2.8 >> >> >> If using a 1..1 cardinality for a dynamic greedy reference there is a timing >> issue possible which will cause SCR to unbind all reference when activating >> the component. >> The timing window involves at least two threads. >> 1) thread 1 is in the process of activating the component with a 1..1 >> dynamic greedy reference to service X (ranking=1) >> 2) thread 2 is in the process of registering another service X with a higher >> service ranking=100 >> When this happens thread 1 determines it should bind service X ranking 1. >> Thread 1 creates the service component instance and enables the tracking of >> all the dependencies. It then proceeds to bind all the required services. >> Before binding service X ranking=1 thread 2 registers service X ranking=100. >> Thread 2 then finds the created service component instance that thread 1 >> has created (but is still in the process of binding all the services) and >> then thread 2 binds service X ranking=100. At this point thread 2 thinks >> the component actually got bound to service X ranking=1 so it begins to >> unbind it. Before unbinding, if thread 1 proceeds it will bind service X >> ranking=1. So now the component itself (depending on the implementation) >> will start using X ranking=1. But then thread 2 proceeds and it will unbind >> service X ranking=1. >> So basically we are left with this flow: >> 1) bind X ranking=100 >> 2) bind X ranking=1 >> 3) unbind X ranking =1 >> At this point the component will be confused and think it likely has no >> services to use. > > > > -- > This message was sent by Atlassian Jira > (v8.20.10#820010)
