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 <[email protected]> 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 <[email protected]> > Datum: 22.06.21 16:20 (GMT+01:00) > An: Viktor Söderqvist <[email protected]>, [email protected] > 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 > [email protected] > http://erlang.org/mailman/listinfo/eeps > _______________________________________________ > eeps mailing list > [email protected] > http://erlang.org/mailman/listinfo/eeps _______________________________________________ eeps mailing list [email protected] http://erlang.org/mailman/listinfo/eeps
