[
https://issues.apache.org/jira/browse/FELIX-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15792649#comment-15792649
]
Jeroen Daanen commented on FELIX-5471:
--------------------------------------
I am glad you could remove the timeout. The new implementation looks good to
me, only the comments on line 1695-1697 of ComponentImpl are a bit confusing
(how would it be possible to don't have the SerialExecutor at that point when
trySynchronous is true (except when someone overrides getExecutor)).
In order to create stable and reliable software, I do have to be sure that the
order is guaranteed. Also I think the usage of the dependency manager is pretty
concurrent in our software (when setting it to parallel), but I cannot estimate
what the actual chance is of the order not being guaranteed? Can it be
reproduced in a unit test?
Anyway, I would really appreciate if this can be fixed and the order is always
guaranteed.
> 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)
