[jira] [Commented] (FELIX-5471) Ensure that unbound services are always handled synchronously

["Jeroen Daanen (JIRA)" <ji...@apache.org>]

    [ 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)