-
Notifications
You must be signed in to change notification settings - Fork 397
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
Read start_permanent
from mix.exs
#118
Comments
The top-level application in a release will always be started as permanent, so this setting doesn't actually apply to releases. Was there a specific issue you encountered? |
In some of our workers when connection pool is overloaded, GenServer (it is added to a application supervisor as worker) will fail due to pool connection timeout. This failure results in |
@AndrewDryga Do you have an example app I can use to reproduce? |
Unfortunately I don't have ways to reproduce it, but I have logs from production:
mix.exs:
rel/config.ex:
Container is built with MIX_ENV=prod env. |
At this moment its a Kubernetes Docker container with stopped application supervisor but Erlang VM is alive. So it's neither working, nor restarting. |
Another one:
|
It seems that this is not Distillery's fault, rather unexpected (for me) behaviour of transient supervisor. |
Right now Distillery (and exrm) ignores
start_permanent
option in mix.exs and this behavior is ambiguous for most of developers that I know (few project in production have issues because of it).Of course, we can add bold text that "you should set application type in
rel/config.ex
", but other option is more developer-friendly - to read application start type from Mix.exs and use it as default value.The text was updated successfully, but these errors were encountered: