Fork me on GitHub
#mount
<
2017-03-08
>
dm317:03:51

I sometimes run into issues where a state gets corrupted after start so stop throws

dm317:03:12

then I’m unable to restart as stop always fails

dm317:03:33

what’s the best way to avoid the cleanup-if-dirty phase?

tolitius20:03:24

@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

dm322:03:53

I don’t think Mount should be doing anything to manage failures in non-dev deployments

dm322:03:58

this can be built as convenience on top

dm322:03:27

however in development the states are sometimes clobbered which prevents them from being stopped

dm322:03:31

and currently there’s no way out

dm322:03:03

so I’d vote for something like reset

dm322:03:32

hm, does it even make sense to stop the stop action if something throws?

dm322:03:04

you can’t do much at this point

dm322:03:12

it might then make sense to make stop do best-effort of stopping everything that didn’t throw

dm322:03:35

I guess if we had something like reset - Stop all started states unconditionally and clear the internal Mount state

dm322:03:05

stop could keep its current behaviour

dm322:03:12

@tolitius what do you think?

tolitius22:03:47

> 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)

dm322:03:55

I’m still thinking what I’d like my system to do if one of the states fails to stop during shutdown

dm322:03:36

on start it’s easy - I don’t want the system to start up in a broken state

dm322:03:49

on stop it seems I’d like to stop as much as I can cleanly

tolitius22:03:29

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

dm322:03:44

that’d probably be my default

tolitius22:03:01

resources that are still "connected" would be a problem though

dm322:03:28

yeah, you could still throw an “accumulated” exception once stop is done

tolitius22:03:25

but yea, "reset" would work ok for things that just throw the exception, but do not tie up any resources

dm322:03:42

reset is for development

tolitius22:03:32

might make sense to not lose references to "states" in a bad "state" though..

dm322:03:07

what do you mean?

tolitius22:03:42

i.e. say you have a conn to db that threw on stop: i.e. could not disconnect

tolitius22:03:07

would still be good to return that reference after the internal mount references are "reset"

tolitius22:03:31

since something may still be possible at repl time: i.e. to force disconnect it

dm322:03:55

I’d think you would work with start/stop

dm322:03:03

then once stop failed you’d try reset

tolitius22:03:25

right, but it would mean a stale reference to something that is still connected

dm322:03:27

so after stop fails you can still do whatever is needed

tolitius22:03:40

you can, but you would not be able to reconnect

tolitius22:03:54

due to, say, a bound port

dm322:03:13

could you not do force disconnect after stop failed?

dm322:03:27

or is the state lost at that point?

tolitius22:03:42

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

tolitius22:03:20

so I am thinking it would make sense to still return (new) references to failed states

dm322:03:21

yeah, that’s fine by me because you have a chance to “force disconnect” after mount/stop failed

dm322:03:27

unless I misunderstand something

tolitius22:03:32

right, as long as you have a reference

dm322:03:51

when do you lose the reference?

dm322:03:59

is it lost after mount/stop fails?

tolitius22:03:59

no, it is lost if stop succeeds 🙂 but if we are to do a "reset" regardless, the reference would be lost

tolitius22:03:41

> it is lost if stop succeeds it would point to a DerefableState or NotStartedState after a successful call to "stop"

tolitius22:03:02

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

dm322:03:25

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

tolitius22:03:57

yep, exactly

tolitius22:03:33

or should I say precisely.. always confuse the two