[jira] [Comment Edited] (SLING-6852) A question about reliability of keeping non DS tracked references

["Dominik Smogór (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007966#comment-16007966 ] 

Dominik Smogór edited comment on SLING-6852 at 5/12/17 11:17 AM:
-----------------------------------------------------------------

Hello, thank you for a quick response. 
I'm sticking on this list because the example is in sling. 
The doubt I have is precisely related to the level of control  on the created objects that the factory can exert and whether just controlling their lifecycle is enough.
Imagine the following scenario:
1. ModelAdapterFactory creates bundle listeners which in turn are registered within core osgi 
2. The [addingBundle|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.sling/org.apache.sling.models.impl/1.0.0/org/apache/sling/models/impl/ModelPackageBundleListener.java#59]   method gets called, 
3. At the very same moment ModelAdapterFactory gets deactivated, it unregisteres the listeners in it's deactivate method but the listener execution is already in progress.
4. the listener model can potentially utilize object which state is no longer valid (have been crippled as en effect of calling deactivate).


was (Author: dominik.smogor@richemont.com):
Hello, thank you for a quick response. 
I'm sticking on this list because the example is in sling. 
The doubt I have is precisely related to the level of control of the on created objects that the factory can exert and whether just controlling their lifecycle is enough.
Imagine the following scenario:
1. ModelAdapterFactory creates bundle listeners which in turn are registered within core osgi 
2. The [addingBundle|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.sling/org.apache.sling.models.impl/1.0.0/org/apache/sling/models/impl/ModelPackageBundleListener.java#59]   method gets called, 
3. At the very same moment ModelAdapterFactory gets deactivated, it unregisteres the listeners in it's deactivate method but the listener execution is already in progress.
4. the listener model can potentially utilize object which state is no longer valid (have been crippled as en effect of calling deactivate).

> A question about reliability of keeping non DS tracked references
> -----------------------------------------------------------------
>
>                 Key: SLING-6852
>                 URL: https://issues.apache.org/jira/browse/SLING-6852
>             Project: Sling
>          Issue Type: Task
>          Components: Best practices
>    Affects Versions: Sling Models Impl 1.2.0
>            Reporter: Dominik Smogór
>            Priority: Minor
>
> It's a generic best practice question but illustrated on an example within sling models.
> We have 2 kind osgi services being in parent - child 
> 1. a factory service that programmatically registers number listener services 
> 2. the listener services.
> The listener services are called asynchronously (usually in a white board manner) by some 3rd party components. 
> Now, the listener services implementations are keeping a simple object references to the parent service. Osgi is not aware of this link and is not tracking it in any way.
> An example of such a relation is here http://grepcode.com/file/repo1.maven.org/maven2/org.apache.sling/org.apache.sling.models.impl/1.2.0/org/apache/sling/models/impl/ModelAdapterFactory.java#900:
> with the ModelAdapterFactory creating instances of  ModelPackageBundleListener which self register themselves with BundleTracker.
> No the question is: what guarantee do we have that the child services will never use defunct instances of parent objects after they have been deactivated by OSGI (for whatever reason)?
> Isn't it a potential for race conditions (that partner is used frequently throughout sling code base) during after related to bundle / component restarts?
> (disclaimer: I've used the highest sling models version that's there on grepcode)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)