[erlang-questions] Dependencies, included applications and supervision
Jay Nelson
jay@REDACTED
Wed Jun 25 23:03:17 CEST 2014
On Jun 25, 2014, at 1:50 PM, Loïc Hoguin <essen@REDACTED> wrote:
> On 06/25/2014 10:42 PM, Jay Nelson wrote:
>> Why does crypto code always do this?
>
> Not sure what you mean? crypto is a library it doesn't need to be started.
I misspoke. Take a look at pg2:ensure_started. I don’t want to write code like that to make
sure that an application is running. I thought I recalled similar things in ssh and others
that depend on crypto but I guess I was wrong.
>
>> What if your application goes down but doesn’t take the VM with it?
>
> If you configure the VM to do that you probably have good reasons and *don't* want it to restart. For example to debug things out.
>
> Configuring the VM to crash, and it failing to do so, has about the same chances of happening as your supervisor not restarting the included_application.
I thought it was apparent from the context, but I meant, what if your required
essential dependency of an application goes down and you didn’t configure
it as a permanent application (because it’s a hammer and you want something
less than the entire node to go down and still recover). The fact that you have
two choices: kill the node or ignore, is limiting when dealing with complex
dependency constraints. Especially in continuous realtime services where the
loss of a database connection is an essential dependency but not sufficient to
immediately turn off all access to the node.
>
>> If there is a dependency, you must ensure that the required application
>> is started, not just when you start your application, but at any time later
>> after which it may have subsequently failed.
>
> Only if you want to restart it, which you don’t.
I wasn’t aware that you were familiar with my code. In my case I do want
to restart. But you as library or reusable application developer can’t possibly
know what I will use it for in the future. And arbitrary restrictions on reuse
shouldn’t be built in unless there are good reasons for doing so.
jay
More information about the erlang-questions
mailing list