[
https://issues.apache.org/jira/browse/SLING-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-4139.
--------------------------------
Resolution: Fixed
fixed : topology announcements that are no longer active (thus no longer in the
AnnouncementRegistryImpl's cache) will be cleaned up from the repository. They
used carry a heartbeat which made them invalid automatically, but SLING-3389
removed writing that heartbeat. Added a number of tests to reproduce what has
been reported in both SLING-4139 and SLING-3726.
> regression: stale topology announcements possible after crash/reconfig
> ----------------------------------------------------------------------
>
> Key: SLING-4139
> URL: https://issues.apache.org/jira/browse/SLING-4139
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Affects Versions: Discovery Impl 1.0.12
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Fix For: Discovery Impl 1.0.14
>
>
> discovery.impl 1.0.4, with SLING-3389, introduced a bug whereas it got
> possible that a stale topology announcement remained in the system (and was
> not cleaned up) when a combination of crash/restart and
> reconfiguration/switch-over of topology connectors occurred.
> SLING-3726 discribes one symptom of this problem, which resulted in a
> duplicate instance in the topology-tree reported by discovery.impl.
> Another case where this can be reproduced is the following scenario:
> * consider 3 instances A, B and C. A and B are in the same cluster. C has a
> topology connector to A.
> * now A crashes - which leaves B and C not seeing each other through the
> topology (which is correct since the connector C-A is not possible)
> * now consider C removing the topology connector (config change) - hence C
> will see itself isolated in a topology (which is correct)
> * now consider A to restart
> ** at this point the announcement from C is still stored under
> /var/discovery/impl/clusterInstance/A/announcements/C
> ** there is a filter which only reports incoming announcements (ie A's
> announcements in this case) if the connector-client (C in this case) is
> really connected. This results in A reporting a topology which consists only
> of 1 cluster containing A and B (which is correct).
> ** above mentioned filter however does not apply to B. SLING-3389 introduced
> removal of announcement-timestamps being written to the repository in order
> to reduce write-activity (which was thought of being unnecessary). Thus after
> SLING-3389 the idea is that it is A's responsibility to make sure all the
> announcements it contains (from C in this case) are current/alive/correct.
> ** now unfortunately (and that's the bug in this case) there is only a
> filter (which applies to A) but not actual removal of outdated announcements.
> Thus B will report a topology consisting of 1 cluster containing A and B -
> plus it reports C in the topology as well (as it 'sees' that through the
> announcement stored at A/announcements/C).
> Hence the filter mechanism which replaced timestamps in SLING-3389 introduced
> a regression and must be replaced with a proper cleanup mechanism of outdated
> announcements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
