[
https://issues.apache.org/jira/browse/SLING-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-5216.
--------------------------------
Resolution: Fixed
considering done as more testing didn't unveil a bug at this stage.
> Concurrent creation of voting can lead to continuous re-voting
> --------------------------------------------------------------
>
> Key: SLING-5216
> URL: https://issues.apache.org/jira/browse/SLING-5216
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Affects Versions: Discovery Impl 1.0.2
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Priority: Blocker
> Fix For: Discovery Impl 1.2.0
>
>
> This is a regression of SLING-3195:
> With SLING-3195 the cluster view id was redefined from being a unique
> per-voting/per view-incarnation id to being a stable, persisted, permanent
> cluster Id (see [in
> View.java|https://github.com/apache/sling/blob/bac2a2bf4c3ccdf6fa13866ffe6930c20b0230d6/bundles/extensions/discovery/impl/src/main/java/org/apache/sling/discovery/impl/common/View.java#L96]).
> This was achieving the goal of exposing a stable view id for users of the
> discovery API.
> However, it introduced a regression in that this same {{getViewId()}} was
> also used during voting when multiple votings happened simultaneously, to
> agree on the lowest such 'view incarnation id'. With the change to making
> this viewId the stable one though, and not adjusting its usage in this
> multiple-votings-sorting, this sorting became broken. Basically now when
> multiple votings happen simultaneously, then it can be that the participating
> instances sort differently and don't agree on one vote. Resulting in the
> {{HeartbeatHandler}} to come to the conclusion that there is no winner (as
> there should only be 1), and start a fresh vote. Resulting in repeated new
> votings being created.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
