felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3456) Component ignores required static service addition when in Activating state
Date Mon, 14 May 2012 17:37:53 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274780#comment-13274780

David Jencks commented on FELIX-3456:

I'm afraid I don't think the approach in FELIX-3456-fmeschbe.patch is workable.   I have 3
main objections:

1. I don't think it is acceptable to return from a event that might have changed the state
without doing the work.  Thus I don't think any asynchronous processing is acceptable unless
specifically mandated by the spec (as for enable/disable).  One of my suggestions had a similar
"queue work we can't do right now" approach and the results were too unpredictable.

2. A hardcoded wait time is a bad solution to the problem.  You can avoid the fixed wait by
using a lock with a timeout.  Also this is a radically out of order proposal.  In the half-second
the state may have gone back and forth between e.g. active and inactive and enabled and disabled
many times.

3. If you replace the delayAndCheck with a lock, or regard it as a new style of lock, the
locks are too small.  The locks should be around the entire event processing.  The only part
of the processing that can take any time is calling out to the framework and config admin,
which has to happen in the locked region anyway.  So locking the entire event processing won't
take any longer and will make the effect of the code more possible to understand.
> Component ignores required static service addition when in Activating state
> ---------------------------------------------------------------------------
>                 Key: FELIX-3456
>                 URL: https://issues.apache.org/jira/browse/FELIX-3456
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions:  scr-1.6.0
>         Environment: Using org.apache.felix.scr svn rev 1298268 on Mac
>            Reporter: Richard Ellis
>            Priority: Critical
>         Attachments: FELIX-3456-1.1.diff, FELIX-3456-1.diff, FELIX-3456-3.diff, FELIX-3456-4.diff,
> I have a component with two required static service references (A and B). In my scenario
A and B are registered nearly simultaneously on different threads and this causes the DependencyManager
to ignore the addition of one of these two services (B). This causes the component to remain
unsatisfied and never activate, since the service that was ignored is not re-registered at
any time and nothing subsequently causes the component to re-activate.
> This happens as follows:
> 12:30:59:317 Thread 1 - Registers Service B/257
> 12:30:59:320 Thread 2 - Registers Service A/258
> 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258
> 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, activate component
> 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating
> 12:30:59:321 Thread 2 - Activating component
> 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257
> 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB
> 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored for static
reference <--- I believe we end up here because Thread 2 has moved the component from Unsatisfied
to Activating and the reference is a static reference
> 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate
> 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied
> Because the addition of Service B has been ignored and serviceB is a required dependency
my component then never activates even though my reqiured service is present.
> There is a comment in DependencyManager#serviceAdded method:
> // FELIX-1413: if the dependency is static and the component is
> // satisfied (active) added services are not considered until
> // the component is reactivated for other reasons.
> This suggests that the static service should only be ignored if the component is satisfied(active),
which would be correct, but in this case the component is only activating (and will fail to
activate because one of the two dependencies is not yet satisfied) and there is no check of
state at this time.
> A simple fix would be to check the state of the component as well as if the service is
static e.g.
> replace if ( m_dependencyMetadata.isStatic() )
> with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() ==
AbstractComponentManager.STATE_ACTIVE )
> This is an easy fix, but I guess may leave a small window where a static reference could
get replaced while a component was still activating if another instance of the same service
was registered on a different thread.
> There are other fixes that could be done by synchronizing more around service additions.
> Is anyone willing to make this fix or does anyone have any thoughts about this issue?
> Thanks

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message