You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by "Niclas Hedhman (JIRA)" <ji...@apache.org> on 2018/04/28 06:42:00 UTC

[jira] [Resolved] (POLYGENE-305) Library for leader election

     [ https://issues.apache.org/jira/browse/POLYGENE-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Niclas Hedhman resolved POLYGENE-305.
-------------------------------------
    Resolution: Won't Fix
      Assignee: Niclas Hedhman

Having looked at this for a couple of hours, I have realized that this is not going to work.
 # There are variants of this usecase, either "job" or "server" style, where the former probably wants to yield after the job is done, and the server won't need to do that.
 # The mechanisms for a clean shutdown across multiple nodes can be arbitrarily complex depending on the application usecase, and not clear if the generic solution is to handle it or not.
 # Perhaps there is even a case for having "one-shot" jobs to be executed in one JVM only, and whoever is "first" gets to do it, and the others simply wait until leader has completed the job at which point the others drop the job to the wayside.

I am pretty sure there are additional issues, which can eventually create immense problems.

Additionally, Polygene's concerns could be leveraged to put this functionality into application code in relatively simple manners and with much better control of what is going to happen, how and when.

> Library for leader election
> ---------------------------
>
>                 Key: POLYGENE-305
>                 URL: https://issues.apache.org/jira/browse/POLYGENE-305
>             Project: Polygene
>          Issue Type: New Feature
>            Reporter: Niclas Hedhman
>            Assignee: Niclas Hedhman
>            Priority: Major
>
> In distributed applications it is common to have something execute on only a single node, but with backup on other nodes if that node fails, or fails to execute the job.
> Although this may qualify for library-execution, that library is likely to be used often and we shouldn't have a dependency on Zookeeper for applications that don't need it, hence its own library.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)