поскольку события к нам приходят извне, в случае с genstage придётся их где-то накапливать. а хотелось бы не накапливать, а пушить их пулу воркеров

Они не будут накапливаться

Если ты разгребаешь быстрее чем генерируешь

я не могу в handle_demand ходить куда-то за данными, потому что данные мне пушит сторонний сервис

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

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

Что значит пушит сервис?

а не пул воркеров должен ходить и спрашивать, нет ли чего нового

ну пускай для простоты мне приходят запросы в контроллер феникса

Ну и либо кидаешь в стейт продюсера

А лучше - в етс

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

проще тогда взять erlang queue да и всё

Можно Задать пул воркеров и хешировать запрос

Единственный вариант

Без очереди

Но может неповезти

С хешом

ну вот я изначально смотрел poolboy, но к нему нельзя cast, только call

Ну наверное пулбой за счёт этого как раз и знает, какой из воркеров занят

Как иначе понять, какой нагружать то?

а что мешает из пулбоя получить pid процесса и к нему cast сделать самому

а что мешает из пулбоя получить pid процесса и к нему cast сделать самому

http://blog.elixirsips.com/2014/07/16/errata-dont-use-cast-in-a-poolboy-transaction/

Ну наверное пулбой за счёт этого как раз и знает, какой из воркеров занят

ага

http://blog.elixirsips.com/2014/07/16/errata-dont-use-cast-in-a-poolboy-transaction/

это лажа какая-то прямо слово

это лажа какая-то прямо слово

невероятно, но факт =)

не я про то что так заочно верить всему что написано в каких то блогах

по факту всё так

но это не полная правда

https://github.com/devinus/poolboy/blob/master/src/poolboy.erl#L73

вот код транзакции

не я про то что так заочно верить всему что написано в каких то блогах

ну я сначала попробовал, а потом уже нашёл эту статью

берешь вручную делаешь checkout, отправляешь воркеру сообщение, и коллбек в котором предаешь checkin которую воркер сам сделает как закончит полезную работу

придется конечно учесть это в воркере

ну или сделать обертку над ним какую-то

да это понятно что всю логику выбора воркеров и чекина-чекаута можно вынести к себе, один вопрос, зачем тогда пулбой))

он всё также будет контролировать пул

мне кажется тут вообще не избежать очереди никак

мне кажется тут вообще не избежать очереди никак

очередь - простое решение

но неверное архитектурно

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

очередь либо в mailbox процесса, либо в явном виде в ets либо ещё где-нибудь

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

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

а, вот оно как

поэтому я считаю очередь некоторым архитектурным оверхэдом

а обратное давление - неправильным механизмом

хотя я даже неправильно выразился. собыстия не просто допустимо терять, а недопустимо обрабатывать события старше чем 500-1000мс, то есть в этом уже нет ценности

а есть вред

о, это интересно

Если нужен cast - никак не узнать, насколько загружен worker, поэтому может быть имеет смысл сделать так, чтобы процессы сами выгребали события из какой-нибудь ets (можно хотя бы убедиться, что нагрузка планомернее распределяется по worker-ам, если они сами события эти достают), при том если туда писать timestamp когда событие пришло, чтобы игнорировать/удалять уже не нужные и не столкнутся с проблемой перегруженных mailbox-ов в случае того, когда нагрузка поднимется.

ну так почему бы не использовать mailbox процесса, который выгребает события, разрешает не более N сообщений в mailbox. если собщение старое -- пропускаем если есть свободный воркер -- отдаём ему сообщение если воркера нет, проверяем длину очереди. Если больше N -- пропускаем сообщение. если длина очереди меньше -- ждём свободного воркера

Если нужен cast - никак не узнать, насколько загружен worker, поэтому может быть имеет смысл сделать так, чтобы процессы сами выгребали события из какой-нибудь ets (можно хотя бы убедиться, что нагрузка планомернее распределяется по worker-ам, если они сами события эти достают), при том если туда писать timestamp когда событие пришло, чтобы игнорировать/удалять уже не нужные и не столкнутся с проблемой перегруженных mailbox-ов в случае того, когда нагрузка поднимется.

ets будет чем-то лучше erlang queue?

можно дёргать process_info(self(), message_queue_len)

Вообще, sbroker умеет делать

init(_) -> QueueSpec = {sbroker_timeout_queue, #{timeout => 200}}, {ok, {QueueSpec, QueueSpec, []}}. sbroker_example:start_link/0 will start an sbroker with queues configured by QueueSpec. This configuration uses the sbroker_timeout_queue callback module which drops requests when they have been in the queue for longer than a time limit (200 milliseconds). To use this sbroker:

Выбрасывать запросы, которые уже лежат в queue дольше чем нужно

При перегрузке.

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

и соответственно разом выбрасывать все протухшие переинициализировав стек

хотя я даже неправильно выразился. собыстия не просто допустимо терять, а недопустимо обрабатывать события старше чем 500-1000мс, то есть в этом уже нет ценности

sbroker

а, уже написали

sbroker

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

По-моему в mailbox все копится

Поэтому каст - неверное решение

Тогда лучше запускать таск со временем жизни

На каждое событие

И из него пытаться пойти в пул

Если пулл успевает - таск отработает

А иначе - сдохнет

И все

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

Привет! Столкнулся с проблемой при разработке феникса. У меня есть другое приложение (рельсы) и бд PG. Я делаю феникс приложение, которое использует существующую БД. Задал необходимые модели для использования существующих таблиц, миграций естественно нет. В режиме разработки приложение стартует нормально и ecto работает по тем таблицам. Но когда пытаюсь запустить тесты, то ругается, что бд не найдена и предлагает создать через ecto.create.

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

спасибо, попробую посмотреть

Привет! Столкнулся с проблемой при разработке феникса. У меня есть другое приложение (рельсы) и бд PG. Я делаю феникс приложение, которое использует существующую БД. Задал необходимые модели для использования существующих таблиц, миграций естественно нет. В режиме разработки приложение стартует нормально и ecto работает по тем таблицам. Но когда пытаюсь запустить тесты, то ругается, что бд не найдена и предлагает создать через ecto.create.

а в конфиге для test какая бд указана?

@vkosmos26 А что стоит в test.exs?

Там в config.exs - обычно стоит import "#{Mix.exs}.exs" - и для каждого env-а сконфигурирована своя база данных.

настройки подключения идентичный, что и в рельсовом database.yml. Т.е. тестовая база

если дропнуть тестовую бд, и создать ее под фениксом MIX_ENV=test mix ecto.create то база создается, и тесты начинают выполняться, но так как миграций нет и таблицы не созданы, то естестевнно не работает

@vkosmos26 Так какая база в test.exs сконфигурирована?

База данных в phoenix-е через файлы конфигурации config.exs и test.exs(для test-а) сконфигурированы.

в test.exs сконфигурирована тестовая база. Та же что и используется в рельсах для тестаов

Аааа, наверное рельсы создают базу данных и убивают её после тестов.

Поэтому её и не существует вне тестов приложения рельс.

не должно, но проверю на всякий случай )

Если бы база данных существовала, то mix ecto.create - её бы не создал.

У меня такая же нога и не болит (с)

Мигрировал базу из рейлс проекта

тесты гонял из феникс

всё было норм

может из-за докера конечно все

Logger.info "Test base need to be clean as schoolgirl ass" я вот так везде пишу, в сидах например, чтобы кто-нить сиды в тестовую базу не загнал)

Мигрировал базу из рейлс проекта

т.е. была создана отдельная бд для тестов, не тестовая рельсовая бд?

это не одно и тоже? Оо или что ты подразумаешь под “тестовая рельсовая бд”?

под тестовой рельсовой бд я понимаю ту бд, конфиги которой заданы в database.yml для test окружения.

В папке priv есть папка migrations?

Если база существует - и каждый раз при тестах ее нечем создавать, то в mix.exs из alias для теста можно удалить ecto.create

И ecto.migrate

В папке priv есть папка migrations?

Ecto.create & ecto.migrate без этой папки будут падать

Но думаю все согласятся, что это вообще не ок, что приложение зависит от какой-то тестовой бд рельс, и по хорошему фениксу надо сделать 1 миграцию, которая создаст всю бд. Если не ошибаюсь - pg_dump вернёт скл запрос, с помощью которого можно создать копию бд. Вот его можно в миграцию засунуть