[
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14746245#comment-14746245
]
Carsten Ziegeler commented on FELIX-5028:
-----------------------------------------
I don't think this is needed, because this extra check assumes that the
framework is wrong
We could change m_useCount.decrementAndGet() == 0 to
m_useCount.decrementAndGet() <= 0 as in this processing of ungetService the
count is reset to zero.
A simple check of m_useCount.get() > 0 && m_useCount.decrementAndGet() == 0
would catch the situation where the framework calls ungetService more often,
but it doesn't reset the counter to 0, so e.g. if it's -1 , the next call to
getService gets it to 0 - which would be wrong
> 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 factories)
> 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
(v6.3.4#6332)
