[
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14740999#comment-14740999
]
Carsten Ziegeler commented on FELIX-5028:
-----------------------------------------
Actually the patch does not fix the problem - so far I couldn't come up with a
reproducible test case. As the patch does not fix the problem, I'm wondering if
the problem we're hitting is caused by something else.
Now, what we see is that in some circumstances getService returns null - in our
case the component at hand implements two service hooks (EventListenerHook,
FindHook), has no references, no activator/deactivaor and is not immediate. On
startup of our app we see the NPE; we assume this is because the hooks are
get/unget a lot by the framework causing a high concurrency on
getService/ungetService.
> 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
> Fix For: scr-2.0.2
>
> Attachments: simple_fix.patch
>
>
> 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)
