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* etcKind
regards,Maria_______________________________________________eeps mailing
[email protected]http://erlang.org/mailman/listinfo/eeps_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
