[
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14746245#comment-14746245
]
Carsten Ziegeler edited comment on FELIX-5028 at 9/15/15 9:32 PM:
------------------------------------------------------------------
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
Forgot to mention that the previous code did check the count and then
decremented it outside of the state lock, so while the count would have been
higher than zero, it might have got to zero by the time decrement is called,
getting it to -1
was (Author: cziegeler):
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
Forgot to mention that the previous code did check the count and then
decremented it outside of the release lock, so while the count would have been
higher than zero, it might have got to zero by the time decrement is called,
getting it to -1
> 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)
