Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New EEP: Delayed restarts of supervisor children #28

Closed

Conversation

Maria-12648430
Copy link
Contributor

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.

eeps/eep-0057.md Outdated Show resolved Hide resolved
Co-authored-by: José Valim <jose.valim@gmail.com>
@Maria-12648430
Copy link
Contributor Author

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

@lhoguin
Copy link

lhoguin commented Jun 24, 2021

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
Copy link
Contributor Author

What do you think?

I'll think about it :)

@zuiderkwast
Copy link

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.

@Maria-12648430 Maria-12648430 deleted the sup_delayed_restart branch July 7, 2021 13:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants