felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Agemo Cui (JIRA)" <j...@apache.org>
Subject [jira] Updated: (FELIX-1185) If a static/mandatory reference to a service is unregistered, the component should be deactivated synchronously instead of asynchronously
Date Sat, 30 May 2009 15:44:08 GMT

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


Mime
View raw message