[
https://issues.apache.org/jira/browse/FELIX-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15787762#comment-15787762
]
Pierre De Rop commented on FELIX-5471:
--------------------------------------
Committed patch in 1776574.
A new schedule(boolean synchronous, Runnable task) has been added in
ComponentImpl.java, allowing to possibly schedule a task synchronously through
the internal component executor queue. The method uses a timeout of 30 seconds
to protect against infinite wait, and the timeout can be configured using the
DependencyManager.SCHEDULE_TIMEOUT constant, which is a bundle context
property. it may take a value in millis. (30000 by default).
So, ComponentImpl class is now using the new schedule method in order to handle
removed dependency events synchronously. The ComponentImpl.stop() method is now
also using the same schedule method, and the InvokcationUtil.invokeUpdated
callback is also reusing the DependencyManager.SCHEDULE_TIMEOUT constant, when
handling CM configuration update events.
> 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)
