[jira] [Comment Edited] (SLING-5216) Concurrent creation of voting can lead to continuous re-voting

["Stefan Egli (JIRA)" <ji...@apache.org>]

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

Stefan Egli edited comment on SLING-5216 at 11/2/15 2:48 PM:
-------------------------------------------------------------

added another specific test case for concurrent voting in http://svn.apache.org/viewvc?rev=1712016&view=rev


was (Author: egli):
added another specific case for concurrent voting in http://svn.apache.org/viewvc?rev=1712016&view=rev

> 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)