[
https://issues.apache.org/jira/browse/SLING-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-3832:
------------------------------------
Fix Version/s: (was: Discovery Impl 1.0.12)
Discovery Impl 1.0.14
> on 'discovery bindTopologyEventListener' an INIT event can be sent after
> CHANGING/CHANGED
> -----------------------------------------------------------------------------------------
>
> Key: SLING-3832
> URL: https://issues.apache.org/jira/browse/SLING-3832
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Affects Versions: Discovery Impl 1.0.10
> Reporter: Stefan Egli
> Fix For: Discovery Impl 1.0.14
>
>
> [DiscoveryServiceImpl|http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/discovery/impl/src/main/java/org/apache/sling/discovery/impl/DiscoveryServiceImpl.java?view=markup],
> in bindTopologyEventListener, does not correctly synchronize sending the
> INIT event - the INIT event is sent outside of synchronized(lock) - opening
> up the possibility of a race condition where bindTopologyEventListener
> happens while a CHANGING or CHANGED event is just being sent (which would
> hold the lock object), and an INIT could be sent *after* CHANGING and/or
> CHANGED.
> Basically:
> * even though the API guarantees that the order of events is always:
> INIT->CHANGING->CHANGED
> * it can happen, due to this bug, that you can first get CHANGING and/or
> CHANGED and then afterwards an INIT.
> * nevertheless, INIT is never called twice
> To fix this, bindTopologyEventListener needs to send the INIT event in the
> synchronized(lock) block
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)