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-5028) ServiceFactory for components might return null
Date Tue, 15 Sep 2015 21:15:45 GMT

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

Pierre De Rop commented on FELIX-5028:


I looked at the last commit from rv 1703178 and now it seems that the ungetService() is not
checking anymore bad cases where the framework calls ungetService() more than it calls getServices().
So, don't you think that the following patch would be better:

    public void ungetService( Bundle bundle, ServiceRegistration<S> serviceRegistration,
S o )
        obtainStateLock( );
            // unget the service instance if no bundle is using it
            // any longer unless delayed component instances have to
            // be kept (FELIX-3039).
            // We also check if the useCount does not go below zero (when ungetService is
            // called more times than getService is called).
            if (  m_useCount.get() > 0 && m_useCount.decrementAndGet() == 0 &&
!isImmediate() && !keepInstances() )
                ungetService( );
            releaseStateLock(  );

> ServiceFactory for components might return null
> -----------------------------------------------
>                 Key: FELIX-5028
>                 URL: https://issues.apache.org/jira/browse/FELIX-5028
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-2.0.0
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>             Fix For: scr-2.0.2
> There seems to be an uneven handling of locking/status information in getService/ungetService
of the service factory registered by the SingleComponentManager. (I didn't check the other
> We have a concurrent get/ungetService for the same service. While the unget service uses
a lock around decrementing the counter, incrementing the counter and other actions in getService
are not using the lock. There is a partial lock there. 
> But this can lead to the problem that while the preconditions for getService are still
fine, ungetService cleans up which then makes getService to return null.
> We have a huge app where we can reproduce the problem, I'll try to trim this down to
a simple test case.

This message was sent by Atlassian JIRA

View raw message