И писать им в личку, из-за кого же их забанили.

элита

Но не смогут, потому что будут забанены.

хочешь сделать популярным сделай дорогим

(с) Стив Джобс

(нет)

Но не смогут, потому что будут забанены.

Пусть попробует ещё раз

А мы понаблюдаем

))

http://nuclearsecrecy.com/nukemap/

Эмулятор атомной бомбы

как накроет

полезная штука

/start@BucklerBot

/stat@combot

combot.org/chat/-1001061355522

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

Как это сделатЬ?

Или даже лучше вопрос - что, если супервизоры на двух нодах попытаются запустить воркер с одним и те же глобальным именем?

Или даже лучше вопрос - что, если супервизоры на двух нодах попытаются запустить воркер с одним и те же глобальным именем?

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

Честно, понятия не имею как в супервизор перед запуском добавлять логику

в init() что-то дописать, нет?

В инит вроде как спеки добавляются

А тут вопрос, какой метод вызывать когда к примеру упал воркер

в init() что-то дописать, нет?

даже и не думай инит чем-то "тяжким" нагружать!

даже и не думай инит чем-то "тяжким" нагружать!

поясни

поясни

Все просто. Если инит проседает, то ты проваливаешь ВЕСЬ старт. (по времени)

в чём проблема сходить в ets, что-то проверить и, в случае, если проверка не удалась, вернуть {error, _}?

ну мне как бы и нужно в таком случае провалить старт =D

етс создает и держит какй-то процесс (достук к ней и прочее зависит от парамов создания ЕТС), проще послать мессадж процессу о "состоянии ЕТС"

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

Если не получается, то следует логику прилаги в целом пересматривать... что-то идет не так. (вновь, имха)

бесспорно, но в целом, как задизайнишь,

бесспорно, но в целом, как задизайнишь,

?согласен на 100%! ?

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

Если какой то красаучег решит одно и то же приложение запустить на кластере

А если нода, на которой бот, упадёт - то соответственно запустить на следующей живой

@Virviil А задача решение сделать самому или взять библиотеку тоже рассматривается? ( К примеру: bitwalker/swarm ). Достаточно просто можно, но и больше кода, используя wooga/locker сделать.

У меня задача, чтобы моё решение никто не мог в конфигах поломать

Т.е. например, не бвло конфликтов к примеру в Registry или syn

Или чтобы кто-то случайно не залупил такую же ets

Как у меня есть

Я просто боюсь что если возьму одну либу, ктото возьмёт другую - и в проете будет пиздзец

так соединяй все узлы в кластер. а gproc умеет в кластере работать

Я gproc не хочу

В принципе меня и global устраивает

есть стандартный механизм резервирования запуска приложения в кластере. когда одна нода с приложением падает - оно запускается на другой ноде

Вот вопрос - как вырубить один из моих supervision tree если после коннекта в кластер станосится понятно, что запущено две приложеньки

К примеру

я ж говорю. там штатный механизм ОТПшный есть

когда приложение работает в кластере

Да, но получается что приложение не работает

Сделать этот supervision tree динамическим, динамически стартовать и динамически удалять, когда не нужен

А если амбрелла к примеру

И все приложения кроме одного могут работать параллельно в кластере

К примеру феникс и бот

Феникс можно на двух нодах параллельно запустить

Поэтому резервирование не канает

вроде как...

У супервизора есть stop_child. Можно сделать так, на каждой ноуде будет один главный супервизор, который стартуется на каждом ноуде и по одному процессу, которые в конечном итоге например обмениваются данными и решают, на каком ноуде запустить бота. Тогда через start_child/stop_child у главного супервизора можно будет динамически стартовать и динамически останавливать supervision tree отвечающий за бота.

Как вариант, если не использовать готовое решение.

А вот такой вопрос - если у меня супервизор с глобальным именем

И я сперва собираю кластер

А потом на каждом запускаю приложение

То супервизор запустится только на одном?

Или в глобальном регистре будут пиды всех процессов

Или последнего?

С global-ом запустится только первый.

На одном

Хм... А что другие? Будут спамить ошибки в трейс?

Или уронят приложение?

Уронят приложение.

Потому что не смогут запуститься

Вот суки

Ладно.

ЩА мы их...

Можно в старт_линке суперизора проверить, что такого пока нету

И если есть - то закрыться через normal

наверное

Осталось только придумать как заколлбэчить при падении одной из нод его запуск

{:shutdown, {:failed_to_start_child, Module, {:already_started, #PID<13609.203.0>}}} - с такой ошибкой вылетит из старта приложения, если попытаться стартовать global, когда он запущен на другой ноуде.

Походу придётся нафаршматчить хитрожопый Supervisor

Который ничего не стартует

Только спеки там задать

Ну и крутиться как хз как

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

Одна проблема, network split