[jira] Updated: (FELIX-1185) If a static/mandatory reference to a service is unregistered, the component should be deactivated synchronously instead of asynchronously

["Agemo Cui (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Agemo Cui updated FELIX-1185:
-----------------------------

    Attachment: scr-changes on revision 778604.zip

I use State design pattern to have refactoried the class AbstractComponentManager.

There are 8 states in all.
They are: Disabled, Enabled(Unsatisfied), Registered, Factory, Active, Destroyed, Activating and Deactivating.
State Unsatisfied is duplicate to State Enabled so it's removed.
State Registered, Factory and Active are the "Satisfied" state in concept. Only DelayedComponentManager can transit to the State Registered. Only FactoryServiceComponentManager can transit to the State Factory.
State Activating and Deactivating are transient ones. They will be changed to other "stable" state automatically when the corresponding work is done.

The transition cases are listed below.
1. Disabled --(enable)-> Enabled
2. Disabled --(dispose)-> Destoryed
3. Enabled --(activate)-> Satisfied (Registered, Factory or Active, depends on the type of the component)
4. Enabled --(disable)-> Disabled
5. Enabled --(dispose)-> Destroyed
6. Registered --(getService, SUCCESS)-> Active
7. Registered --(getService, FAIL)-> Enabled
8. Factory --(getService)-> Active
9. Satisfied --(deactivate)-> Enabled


Each event specified above is mapped to a method xxxxxInternal in the code. They are all atomic operation that is "synchonized".

If a event is applied to a State, which is not in the above case list, nothing will be done(A debug log will be printed).

So for a enable calling(not the same meaning event in the transition case), it consists of the following primitive operations: enabledInternal and activateInternal.
For a dispose calling(not the same meaning event in the transition case), it consists of the following primitive operations: deactivateInternal and disposeInternal.

With these changes, I have confidence of no deadlock after making the deactivation synchronous which is described in this problem.
Because there's no crossing lock and there's no circular dependency.


All the changed source files are attached.

Please review. If it's OK and you approve, I hope my changes could be committed.

Thanks.


> If a static/mandatory reference to a service is unregistered, the component should be deactivated synchronously instead of asynchronously
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: FELIX-1185
>                 URL: https://issues.apache.org/jira/browse/FELIX-1185
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.0.8
>            Reporter: Agemo Cui
>             Fix For: scr-1.0.10
>
>         Attachments: scr-changes on revision 778604.zip
>
>
> In the specification cmpn 112.3.3 Reference Policy, it says "Component configurations are deactivated before any bound service for a reference having a static policy becomes unavailable."
> My understanding is the deactivate method of the component must be called before any unbind method for a static/mandatory reference is called. And it's reasonable for a static/mandatory reference to be still available in the deactivate method.
> If the component is deactivated asynchronously when a static/mandatory reference to a service is unregistered, then it's possible that the unbind method is called before the deactivate method is called, which makes the service unavailable in the deactivate method.
> This bug may relate to FELIX-1178.
> The fix for this bug should also fix FELIX-1178. No need to add a new flag.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.