EEP proposal - Delayed restarts of supervisor children

[Adam Lindberg]

There was a similar example made by Fred a few years ago: https://gist.github.com/ferd/c86f6b407cf220812f9d893a659da3b8

Cheers,
Adam

> On 22 Jun 2021, at 20:09, Maria Scott <maria-12648430@REDACTED> wrote:
> 
> I was just thinking... Could we do something like this as a rebar/erlang.mk template maybe? Like, a gen_statem with batteries included? That would leave the maximum degree of freedom to users while providing a good starting point from which to customize, and without burdening any technical debt on us or anybody else in OTP.
> 
> Kind regards,
> Maria
> 
> -------- Ursprüngliche Nachricht --------
> Von: Maria Scott <maria-12648430@REDACTED>
> Datum: 22.06.21 16:20 (GMT+01:00)
> An: Viktor Söderqvist <viktor@REDACTED>, eeps@REDACTED
> Betreff: Re: EEP proposal - Delayed restarts of supervisor children
> 
> Hi Viktor,
> 
> hm, the idea sounds interesting. A bit like a specialized gen_statem, at first thought.
> 
> But I guess I won't be easy to find something that is special enough to warrant not using a gen_statem itself, but general enough to be able to cover most of the common use cases with it.
> Depending on the characteristics of the external service, the requirements for the client, and the behavior of connection between the two, many possibilities exist which the hypothetical gen_client should be able to account for.
> 
> Let's hear what Fred thinks ;)
> 
> > A different note regarding automatic reconnects in clients: They may be 
> > problematic, since there may be some state associated with the 
> > connection (such as an ongoing database transaction) which is lost if 
> > automatic reconnect is done without care. Crashing instead of 
> > reconnecting makes this handling way simpler (or at least it moves the 
> > problem to somewhere else). How would you best solve this using the 
> > hypothetical gen_client behaviour?
> 
> Automatic reconnecting is not a problem in itself if you ask me. It is a problem if it happens _transparently_, ie if processes using the client have no way of noticing it. I think it should even be made _impossible_ to use a reconnected client without the user process being informed and performing some extra steps in order to use it again.
> What I'm imagining (without having given it too much thought) is to let the client manage a token (a reference maybe) which users can ask for and have to provide together with requests. On reconnect, the client changes that token, thus invalidating all requests made with the old one. Like this:
> 
> * client C is connected, his current token is T1
> * user U wants to use C and asks it for its token, receives T1
> * U sends {T1, Request1} to C; C accepts as T1 matches its own token
> * C's connection fails, he changes the token to T2 and reconnects
> * U, unaware of C having reconnected, sends {T1, Request2} to C; C rejects because T1 does not match its own token
> * thus, U knows that C has reconnected and that any connection-related state is lost; if he decides to continue using C, he must ask for the current token, and receives T2
> * U sends {T2, Request2} to C; C accepts as T2 matches its own token
> * etc
> 
> Kind regards,
> Maria
> _______________________________________________
> eeps mailing list
> eeps@REDACTED
> http://erlang.org/mailman/listinfo/eeps
> _______________________________________________
> eeps mailing list
> eeps@REDACTED
> http://erlang.org/mailman/listinfo/eeps