Когда использовать приложение erlang: запуск или включенные_приложения и супервизор?

У меня есть приложение Erlang, которое имеет зависимость в своем каталоге deps от другого приложения.

Насколько я понимаю, я тоже могу;

а) запустить мое зависимое приложение из моего включающего приложения, вызвав application:start(some_other_app), который запускает приложение и показывает, что оно работает автономно в Observer.

b) включить мое зависимое приложение в мой файл .app с помощью {included_applications, [some_other_app]}, чтобы приложение загружалось, а не запускалось, а затем запускать включенное приложение из моего собственного супервизора верхнего уровня. Это снова запускает включенное приложение и показывает, что оно работает ниже моей собственной иерархии контроля в Observer.

Мой вопрос в том, когда я должен использовать любой подход? Если я использую вариант «а», и мое зависимое приложение завершает работу, будет ли оно перезапущено, или мне следует использовать подход «б», чтобы все имеющиеся у меня зависимости контролировались соответствующим образом?

Кстати, я использую Rebar для упаковки и управления своими зависимостями.

Спасибо,

Энди.


erlang otp rebar
person Vivilar    schedule 21.06.2012    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Объявление ваших зависимостей в дескрипторе приложения — это то, что нужно, поэтому вам следует использовать вариант B в большинстве сценариев.

Контроллер приложения гарантирует, что все ваши зависимости присутствуют и запущены (по порядку) перед запуском вашего приложения, а также приведет к сбою вашего приложения, если оно завершится с ошибками. Кроме того, контроллер приложений отключит все, когда это необходимо.

Кроме этого, если вы выберете вариант A, при запуске приложения с помощью application:start/1 вы получите временное приложение по умолчанию, поэтому вам следует использовать application:start/2, передав постоянный атом в качестве второго аргумента.

РЕДАКТИРОВАТЬ: наличие ваших зависимостей в дескрипторе приложения также помогает наглядности, легко узнать ваши депо без сканирования исходного кода.

person marcelog    schedule 21.06.2012
comment
Спасибо marcelog, это помогает прояснить ситуацию. Я думал, что контроллер приложения просто обеспечит загрузку моей зависимости, и мой супервизор верхнего уровня должен запустить супервизор моего зависимого приложения, или я могу сделать это из своего дескриптора приложения? Хорошая мысль о application:start/2. Я буду помнить об этом, если мне придется использовать вариант а). - person Vivilar; 22.06.2012
comment
@Vivilar Привет, см.: erlang.org/doc/man/app.html заполнение параметра {applications, Apps} заставит эти приложения запускаться (и их приложения) раньше ваших. включенные_приложения их не запускают, а только загружают. Рад быть полезным, не забудьте принять ответ, если он был полезен. Ваше здоровье - person marcelog; 22.06.2012
comment
да, спасибо, я не знал, что приложения, добавленные в {applications, Apps}, также запускались, когда с помощью reltool создавался полноценный выпуск. Это не работает, если я просто запускаю свое приложение с помощью application:start(my_app) локально в erlide, но могу легко написать функцию, чтобы обойти это. Спасибо, приняв этот ответ :-) - person Vivilar; 22.06.2012
comment
Да, они запускаются при генерации релиза, но не должны быть include_applications, если вы используете релизы (что предпочтительнее) - person Peer Stritzinger; 05.07.2012

arrow_upward
4
arrow_downward

Вы, вероятно, не должны делать ни а), ни б)

Из Изучите Erlang

Посмотрите главу: Включенные приложения

Все чаще рекомендуется не использовать включенные приложения по простой причине: они серьезно ограничивают повторное использование кода. Подумайте об этом так. Мы потратили много времени, работая над архитектурой ppool, чтобы сделать ее такой, чтобы любой мог ее использовать, получить свой собственный пул и свободно делать с ним все, что захочет. Если бы мы поместили его во включенное приложение, то его больше нельзя было бы включить ни в какое другое приложение на этой ВМ, а если erlcount умрет, то ppool будет удален вместе с ним, разрушая работу любого стороннего приложения, которое хотело использовать ppool.

По этим причинам включенные приложения обычно исключаются из набора инструментов многих программистов на Erlang. Как мы увидим в следующей главе, релизы могут помочь нам сделать то же самое (и многое другое) в более общем виде.

В главе Релиз — это слово вы можете прочитать о том, как несколько приложений объединяются в релиз. и как они запускаются.

person Peer Stritzinger    schedule 05.07.2012

arrow_upward
0
arrow_downward

У меня был аналогичный вопрос: как вы включаете зависимости в проект erlang, а затем как вы их выпускаете?

Мне помогли несколько друзей и список рассылки erlang... и после повторного прочтения некоторых документов и проб и ошибок... я кое-что понял. Это долго, поэтому ознакомьтесь с сутью:

https://gist.github.com/3728780

-Тодд

person toddg    schedule 16.09.2012