felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre De Rop (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5471) Ensure that unbound services are always handled synchronously
Date Wed, 04 Jan 2017 21:57:58 GMT

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

View raw message