Long gen_server init question (not about order of messages :)
Jesper Louis Andersen
Tue May 18 16:07:08 CEST 2021
On Sat, May 15, 2021 at 8:55 PM Stanislav Ledenev <s.ledenev@REDACTED>
> mod_api accepts requests and transforms them to calls to mod_x, mod_y.
> mod_func is crucial for the application but it needs a time consuming
> of initialization. IRL it is some cryptography related stuff.
While mod_func is in the initialization state, mod_api must return
> 'not_ready' for all requests.
> While mod_func initializing it is not available for any requests.
I'd definitely go with Roger's idea.
Spawn mod_func as part of a supervision tree. This starts out as the proxy.
It spawns mod_func_bg which does the block and the initialization. While
initialization is ongoing, mod_func responds not_ready, and will do so with
a low latency. Once mod_func_bg is done, it sends its data to mod_func. Now
mod_func "becomes" the real process, and can answer requests. This avoids
the proxy in the common path.
In this solution the "notification" *is* the data.
A crash of mod_func repeats the process. You will go back to the not_ready
state. And once you are ready for processing, the state will flip with a
new notification from mod_func_bg. Failure in mod_func_bg can be detected
by a link (or monitor). I'd probably just link them. The two processes'
lifetimes are following each other anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions