[ https://issues.apache.org/jira/browse/FELIX-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15801235#comment-15801235 ]
Jeroen Daanen commented on FELIX-5471: -------------------------------------- Yes we are stopping components while some other components are starting concurrently. For instance, we use the dependency manager to create services as being configured by an end user. So a configuration change may trigger the removal services, which will be replaced by other or new services. On top of that we have services launching other services, which are being required/used in other services. > Ensure that unbound services are always handled synchronously > ------------------------------------------------------------- > > Key: FELIX-5471 > URL: https://issues.apache.org/jira/browse/FELIX-5471 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Affects Versions: org.apache.felix.dependencymanager-r1 > Reporter: Pierre De Rop > Assignee: Pierre De Rop > Fix For: org.apache.felix.dependencymanager-r9 > > > When a component loses a service dependency, it should handle the lost > service synchronously. For example, if service A loses a dependency on B > (because B is being unregistered), then A.remove(B) should be called > synchronously (when B is being unregistered from the service registry), else > the A.remove(B) callback could possibly be invoked while B is already > unregistered and stopped. > Currently, unbound services may be handled asynchronously if DM is used in a > concurrent mode (using a threadpool). And even if no threadpool is used, the > issue may happen if there is a highly concurrent situation where services are > registered/removed concurrently from multiple threads. > So, a patch should be done in order to ensure that a service dependency > remove event is always handled synchronously (especially if DM is used with a > threadpool). > I will provide a testcase soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)