Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
scr-2.1.22
-
None
Description
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:
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)
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.
Attachments
Issue Links
- links to