[
https://issues.apache.org/jira/browse/FELIX-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799473#comment-15799473
]
Pierre De Rop commented on FELIX-5471:
--------------------------------------
Hi Jeroen,
I have committed a patch in rv 1777378 in ComponentImpl class in order to
clarify the javadoc for the schedule method, and I renamed the "trySynchronous"
argument of the schedule method to "bypassThreadPoolIfPossible" in order to
make the method less confusing. So if there is no threadpool, the flag is
ignored and then the default serial queue executor is used (the task is
scheduled synchronously if the queue is not currently being run by another
master thread). If now a threadpool is used and if bypassThreadPoolIfPossible
is true, then the task is also run synchronously if the queue is not currently
being run from the threadpool.
So, whether or not a ComponentExecutorFactory is used, we always try to handle
removed service events synchronously if the component is not currently handling
a service dependency (if its queue is idle, not busy).
Now let's try to clarify so you can estimate if you may or may not have the
issue (whether or not you use a ComponentExecutorFactory):
* First let's recap the issue: sometimes, when a service X is being
unregistered, then the other services (M for example) depending on X may not be
called in M.unbind(X) synchronously while X is being unregistered. So X may
then be stopped at a point where M.unbind(X) is not yet called (but will be
called eventually, soon).
* When the issue does not happen ? you won't have the ordering issue if you
stop your components synchronously from a single thread and after all
components have been started (like it is the case for example when the
framework is shutting down or when you manually stop a bundle from the gogo
shell).
* When the issue may happen ? you may have the issue if you concurrently add
*and* remove some components at the same time. For example you may have the
issue in the following use case (whether or not you use concurrent DM):
** X, and Y are available, and M optionally depends on X, Y.
** you add M from thread T1
** then concurrently, you remove X from thread T2
So, using the scenario above, it may happen that M.unbind(X) is called after
X.stop().
This is because we have implemented the thread model in a non blocking way,
using queues.
So to summarize: if you manage to stop components from a single thread and at
a point where components are all fully started, then there is no issue.
Now, I also added two concurrent test cases:
- ServiceRaceWithOrderedUnbindTest.java: this junit test does not use DM in
concurrent mode (no ComponentExecutorFactory is used, as it is the case in
default DM). So, the test uses manually created threads in order to perform
concurrent component creations. Then, the components are unregistered from a
single thread. And the test verifies if the unbound methods are called
synchronously while the lost service dependencies are being unregistered.
- ServiceRaceParallelWithOrderedUnbindTest.java: same test as above, but this
time we are using a ComponentExecutorFactory (concurrent DM is used).
So, are stopping components while some other components are starting ?
thank you.
> 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)
