[
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14739355#comment-14739355
]
Carsten Ziegeler commented on FELIX-5028:
-----------------------------------------
I'm not sure, but I think if in SingleComponentManager#getService( Bundle
bundle, ServiceRegistration<S> serviceRegistration )
the useCount would be increased as a first statement, it would be avoided
that the instance and/or the component context are cleaned up through a
concurrent ungetService.
If something fails in getService, we can decrement the counter, and if it gets
to zero, clean up.
> 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
>
>
> 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)
