polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (POLYGENE-305) Library for leader election
Date Sat, 28 Apr 2018 06:42:00 GMT

     [ 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

View raw message