м, значит хоть что-то я могу изменить в этом мире.

oxgrouby: осторожнее, слышал про эффект бабочки?

да, осторожность не помешает )

ни кому один чел не нужен в команду для участия clojure cup?

Кто-нибудь может проконсультировать по использованию очередей? У меня в приложение есть задача -- рассылка почты. Формат письма один и тот же, и есть несколько функций которые производят эти письма и сохраняют их в очередь. И у этой очереди есть один отдельный поток-потребитель который забирает из неё письма. Вопрос: как правильно инициализировать этого потребителя? Ну то есть хотелось бы чтобы это был какой-то управляемый поток, подчинённый какому-нибудь пулу и т.д. (я в пулах и executors ноль, почитал бы сурцы).

Ты хочешь в один поток рассылать?

ага

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

ognivo: заюзай агенты. Они для этого, можно сказать, и созданы.

Ага

turtle: сейчас посмотрю примеры и вернусь

turtle: То есть мне надо обернуть очередь в агента, и с помощью посылаемых функций и параметров туда добавлять элементы. А как управлять вытаскиванием и отсылкой?

Т.е. кто будет посылать агенту функцию send-email-from-queue?

ну агент же сам себе очередь, ты в него засылаешь функцию, он ее выполняет. Если в момент отправки занят, то выполнит ее как доберется

то есть тебе в него нужно не send-email-from-queue отправлять, а send-email

ну в агент надо что-то положить же?

а вот кстати практический вопрос - как с такой очередью переживать рестарты? получается все равно придется сделать сторадж job с параметрами функции и остальным хламом? чем тогда лучше standalone очереди?

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

это, как говорится, упражнение со звездочкой

ну да, только почему так выходит то? агенты кул, но на практике надо делать как делают

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

(.start (Thread. (loop []  (get-jobs) (do-jobs) (recur)))))

Агенты нужны чтобы синкать несколько потоков

@nicola: я сейчас так уже делаю, я хочу управление этим отдельным потоком отдать на аутсорс какому-нибудь экзекутору.

Зачем если он один

Ну он же может умереть.

еще агенты нужны чтобы IO делать для атомов и рефов

@ognivo: ну вот, получается реальный ответ на вопрос про рассылку это второй ответ Коли, а не первый 😕

поставь try catch

Да, я так и живу

если он погибнет, все равно тебе решать что делать

Но хочу идиоматично

@nicola: а я думал, что нас сейчас будут тролить, что нету let it fail

с агентами в случае exception, нужно пул ресетить - там хитро

но все же, вот эта шняга, что на практике ответы другие - меня беспокоит

еще раз - агенты для синхронизации

если есть внешняя очередь, то она синкает

если не жалко потерять несколько писем при рестарте, можно через агенты

без внешней очереди

на деле общаться через агентов с внешним миром довольно стремно, внешний мир недружелюбен

второе применение агентов, это io после STM транзакций - Agents are integrated with the STM - any dispatches made in a transaction are held until it commits, and are discarded if it is retried or aborted.

У меня сейчас это всё внутри приложения на ztellman/lamina, и там даже есть какой-то executor, но я пока не добрался до него.

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

А что тебя смущает, что ты лишний поток займешь?

Меня смущает что я его сам создаю, да ещё и с коленочным решением вида try catch

они все так внутри устроены

разница лишь в том сам ты этот блок обработки напишешь или кто-то за тебя

так thread pool не решает задачу падения, он занимается распределением потоков

а создание новых потоков?

лучше сказать выделение из пула

как ты вотчишь свою очередь?

полишь?

Просто у меня получается по монолиту размазано это создание потоков, как-то не оч.

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

В lamina так можно.

те ты используешь какую-то внутренюю очередь lamina и сам ее не персистешь?

Да. Но кстати, персистить тоже надо бы, это упущение моё.

Я смотрю она на core.async вроде

и те тебе пофиг на потерянные мэйлы

Тогда скорее всего нужно посмотреть, что там внутри и в go-loopе рассылать

Она аналог core.async, по-моему даже появилась до него.

Ага, я вижу

Теперь автор её бросил, и написал новую библиотеку manifold

Ну тогда надо встраиваться в ее thread pool

либо тоже ее бросить

@gordon: @nicola вот кстати в связи с этой моей болью, которую вы кажется не понимаете или привыкли, есть идея - есть персистентные структуры - есть концепция event-sourcing которая впринципе может быть встроена в процессы типа swap - почему бы не симулировать persistent memory тем, что мы 1) заставляем писать миграции для данных в памяти 2) на время поднимаем второй экземпляр приложения 3) стримим поток событий на него 4) в момент, когда поток приостановился (т.е. мы балансером перестали пускать на конкретный сервер) - состояние в какой-то момент времени должно совпасть 5) выключаем старый инстанс, запросы идут на новый значимый плюс этого как мне кажется - возможность программировать не усложняя архитектуру, просто полагаясь, что у нас persistent memory возможно я пропустил и это есть или имеет фатальные недостатки?

Ну redis или очереди и есть персистентная память с интроспекцией

Я планирую переезжать с lamina на manifold или core.async. Но кор.асинк мне не нравится в плане его нотации со стрелочками и т.д. К этому надо привыкать, видимо.

@ognivo: ну если говорить про идеоматичность, то core.async - идеоматичен

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

поцоны, а можно в слаке тему поменять?

всмысле цвета

@nicola: видел https://github.com/alandipert/enduro? я о том же только глобально

@razum2um: беться человечество над этим - http://avout.io/ тудаже

@nicola: а с персистентностью что заюзать? Redis, RabbitMQ? Редис уже стоит и подключён, я там сессии храню.

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

redis вполне

@ognivo: в редисе есть паб-саб это будет лучше полла

спасибо, сэр.

Вон даже какаято либа есть - https://github.com/ptaoussanis/carmine

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

я пробовал, она ок, но вот это и есть accidental complexity архитектуры, а еще кроме avout?

Можно @prepor для ревизии вызвать

@nicola: у меня через неё сессии и работают, дальше не изучал.

@razum2um: спасибо за инфу про паб-саб.

я не понимаю ревизии чего ) зачем мне перзистить оперативную память?

чтобы проще писать приложения. рассылка? очередь? редис? - просто агент и все

стейт в базе? датомик? - атом который переживает рестарты

если уж и делать что-то в этом направлении, то совсем на другом уровне.

убирает разделение между оперативной и перзистетной памятью https://en.wikipedia.org/wiki/HP_Labs#The_Machine

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

@prepor Я больше про рассылку на redis

@prepor: так смотри выше. event-sourcing должен спасти. у тебя будет все в оперативе. всегда (пока ты сам этого хочешь и сколько хочешь)

Но про глобальную память тоже интересно

> @prepor: так смотри выше. event-sourcing должен спасти. у тебя будет все в оперативе. всегда ну и что ты будешь делать если твой процесс сдохнет просто? )

Акку или erlang

@prepor: берем начальное состояние (дампится или снапшотится раз в ..) и “догоняем” его

вот у тебя и появился диск

хех, ну ты сказал, что процесс умер

ну да, а нафига еще перзистить?

это не каждый день, это чс, а про рестарт смотри выше

а просто диска не достаточно, нужно write ahead log

> @prepor Я больше про рассылку на redis ну пабсаб вполне работает. только не скейлится (включая редис кластер). ну и carmine так себе либа

и получим postgresql или kafka

дада, kafka как event-source сторадж

а потом еще гарантии консистентности по кластеру

короче, то что ты хочешь это datomic

куда правильнее чем то что ты хочешь

все всегда в памяти

кстати, действительно близко к live indexам датомика

А ещё у меня с "детства" такая идея -- выбросить редис и юзать иннодб через HandlerSocket, но я не знаю с чем я столкнусь в таком случае.

Какая интересная штука этот

ну это очень старая либа. ну и не думаю что удачная

http://www.onyxplatform.org/?

иннодб - mysql?

Ну мы для ненагруженных приложений все очереди в postgresql делаем

Да, к иннодб же можно напрямую обращаться через HandlerSocket, и возможно через Memcached Daemon (от Оракла)

эта тема с HandlerSocket вроде как уже несколько лет как протухла. ну оверхеда на sql парсинг и query planning не так много. а когда ты используешь prepared statements так нет и вовсе

при этом плюшки которые дает редис от этого совсем даже не появляются

А какие плюшки у редиса? Вообще, что почитать на тему фундаментальных различий между реляционными БД, редисами, КЗ-хранилищами, персистентными очередями?

например атомарные операции, протухание записей, блокирующий и неблокирующий интерфесы

нет никакого неблокирующего интерфейса у редиса

у него текстовый протокол, который не умеет асинхронных операций по определению

> А какие плюшки у редиса? ооочень быстрый, транзакционное выполнение lua-скриптиков, вполне неплохой "stdlib" из разных структур данных

expire тоже полезная тема, да

@prepor: https://github.com/redis/hiredis

и? )

> The library comes with multiple APIs. There is the synchronous API, the asynchronous API рубишная и кажется скаловская (как минимум, что юзал) либы на нем построены, оно же асинхронное

оно не асинхронное

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

и то почти ни одна либа не умеет делать это автоматически

@prepor: секунду а https://github.com/redis/hiredis/blob/master/async.c#L650

от того что ты с сокетом на уровне клиента будешь общаться неблокирующе у тебя интерфейс работы с базой асинхронным не станет. т.е. ты не получишь ответ на запрос 2. до тех пор пока не получил 1.

т.е. я вижу, что там pub-sub

но все же это написано и видимо багов в нем меньше чем в велосипедах

что "это"?

я говорю что асинхронного интерфейса к редису нет

ладно, забей, я понял о чем ты

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

@kamilogorek: > Вообще, что почитать на тему фундаментальных у Ричи в его списке книжек есть много про БД http://www.amazon.com/Clojure-Bookshelf/lm/R3LG3ZBZS4GCTH. Но я сам толком не читал так что советовать не могу )

Foundations of Databases например (но там в основном про даталог таки)

Principles of Database & Knowledge-Base Systems

вот тут про всякое и много про реляционные БД

@prepor: хорошего поста в блоге хватило бы.

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

нууу, это скучно, ок )

и да, корректно было бы сказать - хорошие неблокирующие либы

а их тоже нет, гг

найди ту что умеет работать неблокирующе и с редис кластером? )

@prepor: лучше скажи, почему avout не торт?

и умеет всякие луа-скриптики

https://github.com/mp911de/lettuce например ломается при фейловере )

> лучше скажи, почему avout не торт? ну ооочень мееедленный распределенный stm тебе может быть нужен только для координирующих действий между серверами. типа выбора лидера, ребалансировки или еще чего-то подобного. и тут вроде как удобнее пользоваться голым ZK-интерфейсом (или библиотеками рецептов сверху него типа curator), чем вот такими конструкциями.

Ок, господа, спасибо, пойду теперь наконец всё пробовать. Наверно, сначала займусь экзекутором из manifold.

manifold же стремный )

я ещё не знаю этого) А что с ним? Я просто использую aleph для http/websockets, он идёт вместе с manifold теперь.

https://github.com/ztellman/aleph/blob/master/src/aleph/http/client.clj#L327

как это вообще все работает?

мне кажется core.async куда правильнее задизайнен.

Пока не знаю, сегодня планировал разведку боем. У меня есть рабочий функционал на lamina, всё работает аналогично кор.асинку, насколько я понимаю.

не аналогично, просто задачи те же решают

поэтому в некоторых местах похоже

да, я так и хотел сказать.

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

Полагаю что в манифолде так же.

Сейчас ещё раз посмотрю core.async, но мне пока все эти стрелочки и подмигивания не нравятся)))

Или там есть обычные имена для операций?

да какая разница стрелочки или не стрелочки

суть не в этом

суть то, конечно, не в этом. но сканируемость и понятность кода -- это одна из метрик проекта.

и стрелочки на это вообще ни разу не влияют

дело привычки и соглашений

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

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

> и как ты ее словишь это к вопросу о манифолде

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

ognivo: ну можешь явашный тредпул заюзать...

А так send же меняет стейт агента потом. Можно им пренебречь.

Просто (send queue send-mail message)

И усё. Как он доберётся, так выполнит, причём выделением потоков будет сам заниматься.

Но обработку ошибок нужно будет тебе всё равно делать, внутри try .. catch - от него не избавиться.

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

Новый стейт.

a.espolov: а это ты про кложа кап спрашивал?

Там Никита вроде ищет поанов в тиму

https://twitter.com/nikitonsky/status/671976209664880640

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

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

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

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

@ilshad: спасибо за предложение, буду иметь в виду, если с паб-сабом у редиса не получится.

> ну и carmine так себе либа @prepor: а почему?

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

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

@prepor: спасибо!