This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-16
Channels
- # atlanta-clojurians (8)
- # beginners (103)
- # boot (22)
- # boot-dev (1)
- # cider (36)
- # cljs-dev (55)
- # cljsrn (3)
- # clojars (25)
- # clojure (104)
- # clojure-brasil (1)
- # clojure-dusseldorf (2)
- # clojure-italy (8)
- # clojure-norway (9)
- # clojure-russia (15)
- # clojure-spec (6)
- # clojure-uk (26)
- # clojurescript (246)
- # cursive (26)
- # data-science (1)
- # datomic (22)
- # dirac (11)
- # editors (1)
- # emacs (8)
- # fulcro (50)
- # graphql (11)
- # hoplon (1)
- # jobs-discuss (27)
- # leiningen (44)
- # luminus (33)
- # lumo (2)
- # mount (1)
- # off-topic (8)
- # onyx (5)
- # parinfer (4)
- # reagent (94)
- # ring-swagger (14)
- # shadow-cljs (37)
- # spacemacs (10)
- # specter (3)
- # tools-deps (4)
- # unrepl (14)
- # yada (5)
I'm curious how onyx handles restart with stateful tasks. I understand why the number of peers assigned to a stateful task can't change while the job is running, but what happens when you kill and restart. Can it redistribute the tasks to a different number of peers?
It does not currently have the ability to re-partition state. It’s been on our backlog for a while.
It wouldn’t really be all that hard to implement a feature which would use the resume-point functionality to recover and repartition state.
That would be a great feature.
Agreed. Our current suggestion is to over-partition your stateful peers to begin with. We know it’s not great.