[
https://issues.apache.org/jira/browse/FELIX-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15791022#comment-15791022
]
Jeroen Daanen commented on FELIX-5471:
--------------------------------------
Indeed this solves the problems we talked about in the felix user mailing list.
However, I am wondering wether it is a good decision to introduce the timeout.
If I am correct, the timeout for instance occurs when handling the remove
callback takes a long time e.g. when the component is just processing the
services its requires in a synchronized block, while the remove callback is
synchronized on the same, or the implementation of the remove call back
triggers a lot. This could easily take some time depending on your
implementation, so you could run into this timeout pretty quickly.
My suggestion would be to remove the timeout and the configurable property and
just wait endlessly, because if thats happening I think there is another
programming error (a deadlock or something) which must not be just 'ignored' by
the warning message which is logged now when the timeout occurs.
What do you think Pierre?
> 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)
