erlang / eep

Erlang Enhancement Proposals
http://www.erlang.org/erlang-enhancement-proposals/
264 stars 66 forks source link

New EEP: Delayed restarts of supervisor children #28

Closed Maria-12648430 closed 3 years ago

Maria-12648430 commented 3 years ago

We use 57 as temporary EEP number here, aware that there are already two other candidates for it. The number will be changed accordingly if and when this EEP has been accepted.

Maria-12648430 commented 3 years ago

Following the discussion on the eeps mailing list in which (mainly) @ferd voiced valid concerns, we decide to retire this EEP.

lhoguin commented 3 years ago

Weak.

I understand the concerns, and perhaps this is not the appropriate solution, but I don't believe "roll your own via gen_statem" is appropriate either. We are lacking a component in OTP that would sit between the supervisor and the code that must be delayed.

Perhaps now that we are able to change the gen_statem callback module (via change_callback_module), there could be a gen_statem added to OTP that would deal with delays, retries, backoff, jitter and whatever other common strategy for dealing with these issues. When the process starts, it goes through your own gen_statem as normal. When the connection (or other resource) is eventually dropped, you switch to the wait_gen_statem module (for lack of better name). It could have different options to select the strategy. Then once the wait is done, wait_gen_statem switches back to your own module.

Because we have handle_event, the wait_gen_statem does not need to change the current state, so it is up to your module to keep track of which state it's supposed to be in.

This approach would mean that the state data must be shared between the two. A convention could determine how wait_gen_statem can access its own state I suppose. Alternatively your module could provide a callback function that it can call to get/set its own state.

This approach would only work for gen_statem processes, but that's probably fine as converting a gen_server to a gen_statem is trivial, and processes that need to do this are most likely already implemented using gen_statem.

The wait_gen_statem module would either have to reply to calls with an error, or to defer them for when the wait is done. Perhaps it can be made configurable.

What do you think?

Maria-12648430 commented 3 years ago

What do you think?

I'll think about it :)

zuiderkwast commented 3 years ago

I think the EEP should be merged even if it is (or will be) rejected, for the record. It's a proposal that has been sent out to the mailing list already.