Tom Watson created FELIX-6327:
---------------------------------

             Summary: NoSuchElementException can occur with 
SingleDynamicCustomizer when services are removed
                 Key: FELIX-6327
                 URL: https://issues.apache.org/jira/browse/FELIX-6327
             Project: Felix
          Issue Type: Bug
          Components: Declarative Services (SCR)
    Affects Versions: scr-2.1.22
            Reporter: Tom Watson


The fix for issue FELIX-6317 introduced this issue.  The following exception 
can occur when the bound reference is removed and an attempt is made to bind to 
the next best reference.  If the reference is bound but then we detect that 
that reference has been removed then we check again for the next best service.  
If there are none then the following exception is thrown:

{quote}
java.util.NoSuchElementException
        at 
java.base/java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1206)
        at java.base/java.util.TreeMap$ValueIterator.next(TreeMap.java:1253)
        at 
org.apache.felix.scr.impl.manager.DependencyManager$SingleDynamicCustomizer.tryinvokeBind(DependencyManager.java:939)
        at 
org.apache.felix.scr.impl.manager.DependencyManager$SingleDynamicCustomizer.removedService(DependencyManager.java:1036)
        at 
org.apache.felix.scr.impl.manager.DependencyManager$SingleDynamicCustomizer.removedService(DependencyManager.java:805)
        at 
org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1226)
        at 
org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1121)
        at 
org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:981)
        at 
org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1160)
        at 
org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:114)
{quote}

There are some other issues with the current code where conditions could leave 
a DependencyManager in a state where it always thinks there is a thead working 
on tryinvokeBind.  Additional safeguards are needed to ensure the state of the 
DependencyManager is restored on exit of tryinvokeBind.

I'm marking as critical because this is a regression and likely worse than the 
original symptom of FELIX-6317 albeit probably much less likely to occur.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to