[
https://issues.apache.org/jira/browse/SLING-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16583848#comment-16583848
]
Carsten Ziegeler commented on SLING-7830:
-----------------------------------------
Are those changes to the leaderElectionIds in the repository picked up by all
instances?
Not sure if this is a great idea, but what about making this prefix
configurable in some way and maybe change the way the comparison is done? From
the part before the underscore the highest value is picked (new), while from
the part after the underscore the lowest is picked (old).
This way, the prefix could start with 1, the next installation uses 2 etc.
Maybe we need to spend a little bit logic here as string comparison for numbers
does not always result in the wanted result (like comparing 1 with 101).
We could control from the outside whether a leader change is wanted and
wouldn't need to change anything in the repository, just improve the current
implementation a little bit.
> Defined leader switch
> ---------------------
>
> Key: SLING-7830
> URL: https://issues.apache.org/jira/browse/SLING-7830
> Project: Sling
> Issue Type: Improvement
> Components: Discovery
> Reporter: Carsten Ziegeler
> Priority: Major
>
> The current leader selection is based on startup time and sling id (mainly)
> and is stable across changed in the topology for as long as the leader is up
> and running.
> However there are use cases like blue green deployment where new instances
> with a new version are started and taking over the functionality. However
> with the current discovery setup, the leader would still be one of the
> instances with the old version.
> With a new deployed version, tasks currently bound to the leader should run
> on the new version.
> Therefore the leader needs to switch and stay the leader (until it dies).
> We probably need an additional criteria for the leader selection
> /cc [~egli]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
