@Y0zhig @shizzard А можно я опишу цель и может вообще

Question

@Y0zhig @shizzard А можно я опишу цель и может вообще

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

Но как быть если задачу уже повзаимодействовала с внешним миром. Условно по tcp что-то отправила, сохранила ответ в переменную и упала?
Можно ли как то продолжить выполнение с этой точки в случае падения. И можно ли если упала вся нода кластера?

#erlang #it #programming #russian

0

06.07.2024

6 ответов

25 просмотров

Дмитрий Спиридонов Автор вопроса

Lama Lover
Есть библиотеки которые это успешно делают. Но тут...

Стикер

0

3 месяца назад

Дмитрий Спиридонов Автор вопроса

Lama Lover
Есть библиотеки которые это успешно делают. Но тут...

Стикер

0

3 месяца назад

Lama Lover

Да такой прокси совсем не сложно и на Erlang/Elixir сделать. Я говорил только что готового решения нет

0

3 месяца назад

Дмитрий Спиридонов Автор вопроса

Lama Lover
Есть библиотеки которые это успешно делают. Но тут...

Стикер

0

3 месяца назад

Иванов

beam - виртуальная машина легковесных процессов обменивающихся сообщениями. erlang - функционально-образный язык управления этой виртуальной машиной

0

2 месяца назад

Lama Lover · Accepted Answer

Есть библиотеки которые это успешно делают. Но тут же всегда вопрос в том, что делать когда ты продвинулся дальше результата, какая нода будет исполнять с чекпоинта, как часто делать чекпоинт Как я понял, нужно чтобы контекст выполнения сохранялся при падении и потом исполнялся в другом месте (по возможности). Во-первых, это физически невозможно. Отказы бывают не только багами в коде, а бывают багами в рантайме, багами в ядре и просто выдернутой розеткой. Поэтому условный подход "ловить exception и сохранять стек" тут не работает в принципе. Во-вторых, перенести исполнение на другую ноду не возможно если, как вы пишете, вы читаете из TCP сокета. Сокеты привязаны к конкретному инстансу обычно. Можно попробовать поставить прокси перед сокетами и читать из разных инстансов, но это очень ненадёжно, потому что, во время передачи сокета другой ноде, клиент может просто отключиться. Но есть варианты, которые реализуют некоторый durability для вычислений и возможность исполнять их на разных нодах. Правда все эти либы на Elixir, но это считайте почти Erlang 1. Machinery. Это стейтфул акторы. То есть там все фичи обычных акторов Erlang, только они ещё транзакционно обновляют переходы между состояниями. Можно запустить такой под global (или swarm/horde/gproc/syn), например, и тогда при падении на одной ноде, он будет запускаться на соседней из стейта в базе. Для сценария передачи TCP сокета тут надо будет только самим реализовать общение с proxy и всё. 2. Oban. Это persistent job queue. То есть ты просто описываешь задачки, и они исполняются где-то в кластере. Тут уже сложнее смоделировать вашу задачу, но всё равно возможно, если описать взаимодействие с сокетом как последовательность задачек.

185 похожих чатов

@Y0zhig @shizzard А можно я опишу цель и может вообще

6 ответов

Похожие вопросы