определите структуру семинара в виде процессов:
- менеджер семинара
- процессы пользователей
- монитор процессов пользователей
- состояние семинара - процесс или ETS
- регистрируйте всех через Registry или ему подобный
- поставьте всех под supervision tree для семинара

можно так, если влоб, трудно выбрать оптимальный вариант, не вникая в задачу

ммм, не не, все, что связанно с самим бизнесом, хендлит rails app. У феникса тут сугубо техническая роль – обеспечивать стриминг логов со всех клиентов в PaperTrail (реализовано) и следить за зрителями (на стороне клиента уже реализовано PhoenixPresence). Нужно только выполнять некие действия с базой рельсов, когда зритель открывае таб / закрывает таб. Так как отследить нормально убийство канала из процесса самого канала невозможно, то есть вот такой внешний процесс, который подписан на презенс_дифф и что-то там считает.  

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

Еще немного контекста: сама контора чисто рельсовая, на эликсире там пока никто не пишет (хотя core бизнес  –вебинары – там очень хорошо бы с эликсиром пошел), и эта феникс аппа там последний раз запускалась в апреле. Это чтоб было примерно понятно, какие пожелания к мейнтененсу (другими словами – желательно, чтоб его не было вообще)

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

С учетом, что на процессах лучше не экономить

Мне кажется наоборот. Синтаксис в Хаскелле ну очень простой.

> насколько логичнее и проще будет тот или другой вариант

вариант с одним процессом естественно проще, да и как бы сами падения не настолько критичны, это службная инфа, если она пропадет, зрителям все равно от этого не жарко, не холодно – даже нам самим эти дубли про второй джоин в БД не особо критичны

Аргумент про то, что если упадет один семинар, то могут упасть и другие – вот тут я действительно задумался. Там в коде по сути только парсинг/апдейт мапов и запись в БД. И если у БД проблемы, то скорее всего действительно упадут все, кто пытается в нее сейчас инсертить что-то

Но падение может быть вызвано не чем-то общим для всех процессов, типа базы, а чем-то частным, типа действий клиента или свойств семинара. Тогда разделение даст некоторую изоляцию.

Кстати, быть может будет проще иметь по процессу на зрителя, а не на семинар. По крайней мере не придётся искать семинары в registry, стартовать, регистрировать их и вот это всё.

я в оригинальном посте написал, почему нужен внешний процесс. Процесс на зрителя был бы вообще не нужен, у нас же есть channel process

> ем-то частным, типа действий клиента или свойств семинара.
Это вряд ли, этот внешний процесс слушает только презенс_дифф, сам семинары целиком ответственность рельс. Так что мне кажется, они абсолютно одинаковы должны выглядеть все

Ок, я имел виду по процессу на channel process.

А, понял. Ну да, это было бы идеально, но Крис сам писал, что с одним процессом надёжно сделать не получится

привет
может кто подскажет
у меня есть релиз
в нем все апликейшны указаны как перманентные
но при этом елси апликейшн падает в ините то релиз не падает
есть идеи?

привет, я пытаюсь воткнуть либу money в Ecto, наткнулся на ишью связанный с этим и там запостили вот этот фикс: https://github.com/elixirmoney/money/issues/65#issuecomment-299425697
куда мне нужно вставлять этот кусок кода?

В новый файл

просто рядом в проекте положить?

да

и получается cast вызывать из этого модуля?

а не из репо

cast вызывать из репы

а этот модуль тогда где использовать? я его положил рядом но чет ничего не меняется