This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-08
Channels
- # bangalore-clj (5)
- # beginners (6)
- # boot (66)
- # cider (48)
- # cljsrn (14)
- # clojure (699)
- # clojure-austin (2)
- # clojure-berlin (1)
- # clojure-boston (5)
- # clojure-dev (3)
- # clojure-india (7)
- # clojure-italy (24)
- # clojure-nl (5)
- # clojure-russia (33)
- # clojure-spec (30)
- # clojure-uk (64)
- # clojure-ukraine (22)
- # clojurescript (123)
- # clojurewest (1)
- # cursive (18)
- # datascript (44)
- # datomic (12)
- # dirac (46)
- # figwheel (1)
- # gsoc (5)
- # hoplon (6)
- # immutant (29)
- # instaparse (1)
- # juxt (26)
- # lein-figwheel (5)
- # leiningen (4)
- # luminus (8)
- # mount (56)
- # off-topic (60)
- # om (67)
- # om-next (1)
- # onyx (8)
- # proton (28)
- # re-frame (125)
- # ring (3)
- # ring-swagger (3)
- # specter (22)
- # testing (2)
- # unrepl (1)
- # untangled (91)
I guess it’s covered by https://github.com/tolitius/mount/issues/63
@dm3: yea, there are options covered in this issue, but I would still like to find a solution and document it, since it is a valid concern. so ideas are very welcome
@dm3 there are also some related thoughts: https://github.com/tolitius/mount/issues/50
however in development the states are sometimes clobbered which prevents them from being stopped
it might then make sense to make stop
do best-effort of stopping everything that didn’t throw
I guess if we had something like reset
- Stop all started states unconditionally and clear the internal Mount state
> Stop all started states unconditionally and clear the internal Mount state
yea, that is what I had in mind for something like (mount/reset :ignore-errors true)
or just (mount/reset)
I’m still thinking what I’d like my system to do if one of the states fails to stop during shutdown
I think this decision (what to do on a failed stop) is best left to "a developer", since use cases are different, but stop as much as I can
could be a useful option
but yea, "reset" would work ok for things that just throw the exception, but do not tie up any resources
would still be good to return that reference after the internal mount references are "reset"
right, if we are talking about a "reset": i.e. stop everything, even if it has failed, the original reference to conn
would point to something like a NotStartedState
vs. the actual problem state
so I am thinking it would make sense to still return (new) references to failed states
yeah, that’s fine by me because you have a chance to “force disconnect” after mount/stop
failed
no, it is lost if stop
succeeds 🙂 but if we are to do a "reset" regardless, the reference would be lost
> it is lost if stop
succeeds
it would point to a DerefableState
or NotStartedState
after a successful call to "stop"
yea, it's good food for thought. I'll start adding a "reset" this would prompt me to think more about it. thanks for bringing it up
what I’m trying to say is that
a) reset
is mostly useful in the development workflow
b) reset
shouldn’t be used instead of stop
, rather you use start/stop
and when stop
fails you do reset
once you clean stuff up
However, I see how you could return a set of Vars which failed to stop on reset
which might be helpful