его футура не завершается

А супервайзор печатающий exception'ы есть?

не уверен, но тело runFoldAsync продолжает вызываться успешно

а с чем оно вызывается если complete пришёл уже?

в смысле, что внутри?

кто-нибудь сталкивался с тем, что Source.queue не завершает стрим, когда делаешь queue.complete()?

2.5.7?

2.5.7?

2.5.9

в смысле, что внутри?

то, что через queue.offer продолжает слаться

ребят, кто со скала spb митапа, нашел кто интернет? пишу с помощью голубиной почты

Source.actorRef то же поведение, хм...

Source.actorRef то же поведение, хм...

а какой тредпул?

дефолтный

Ну давай гист запускаемый.

480p максимум - так задумано?

Мы в лайфе https://www.youtube.com/c/ScalaRussia/live

Можно камеру зазумить, а то вообще код не видно?

480 это полная беда (

@leammas в тему вчершнего разговора, немного маркетинга от лайбенда

мда, код вообще не видно =/

Фомкин специально открыл Королёв

Ну давай гист запускаемый.

Простой вариант у меня заработал. Но у меня данные из Source проходят через Flow, я попробовал это как-то сэмулировать в гисте. Вот такой вариант продолжает бесконечно работать, хотя complete() вызывается https://gist.github.com/Tvaroh/93236714ca989e260d51ce00206510c6

Простой вариант у меня заработал. Но у меня данные из Source проходят через Flow, я попробовал это как-то сэмулировать в гисте. Вот такой вариант продолжает бесконечно работать, хотя complete() вызывается https://gist.github.com/Tvaroh/93236714ca989e260d51ce00206510c6

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

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

обновил гист (ошибка закралась)

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

Простой вариант у меня заработал. Но у меня данные из Source проходят через Flow, я попробовал это как-то сэмулировать в гисте. Вот такой вариант продолжает бесконечно работать, хотя complete() вызывается https://gist.github.com/Tvaroh/93236714ca989e260d51ce00206510c6

при первом рассмотрении вот что сразу могу сказать - нельзя так возвращать пару future и source. source - переиспользуемая штука, а фьюча твоя глобальная на все стримы запущенные с этого сорса. нужно сначала runnablagraph слепить, потом его запускать, а потом оттуда вытаскивать материалзованные значения.

это понятно, такая фьюча используется только один раз

480 это полная беда (

Потом будут видосы в норм качестве

это понятно, такая фьюча используется только один раз

мы ожидаем done увидеть. так?

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

по следам лайтбендовского вебинара: https://github.com/lightbend/kafka-streams-scala https://github.com/lightbend/kafka-offset-monitor

@leammas в тему вчершнего разговора, немного маркетинга от лайбенда

ага, я как раз наткнулся на цитатку As the leading online fashion retailer in Europe, Zalando uses Kafka as an ESB (Enterprise Service Bus), which helps us in transitioning from a monolithic to a micro services architecture.

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

я думаю там просто антиоперация и все

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

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

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

выглядит... энтерпрайзненько

cosaga pattern %)

выглядит... энтерпрайзненько

Что тут интерпрайзного? Пом норм

норм (вроде бы), но большая обвеска получается

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

С event sourcing подходом оно естественным образом так выходит при обнаружении конфликта

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

На митапе сейчас такой пожар что обои отклеиваются.

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

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

это распределенная транзакция, либо руками резолвят

либо долбят до тех пор, пока не будет в итоге согласовано

Я в алишечке это наблюдал. Купил какую то хрень, сняли деньги, а потом пришло письмо, что сорян, мол аут оф сток, бабло вернем в течении недели.

Вот компенсационное действие откатило все транзакции. Вернее компенсировало

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

это взгляд из далека какой-то

это классно выглядит, если действий 1-2 и ясно как откатывать

а если их десяток, между ними промежуток пара дней и факапящий курьер (например), все приобритает интересный оборот :)

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

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

Ну извините, чем выше связаность сервисов, тем больше проблем

это распределенная транзакция, либо руками резолвят

на ивент сорсинге распределенная транзакция как будет выглядеть?

кто-то должен следить опять же за её исполнением и таймаутами

на ивент сорсинге распределенная транзакция как будет выглядеть?

не знаю

эту тему сам начал недавно ресерчить

говорят проще

это решается

Ну извините, чем выше связаность сервисов, тем больше проблем

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

/stat@combot

combot.org/chat/-1001034178083

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

Это сложный проход, надо понимать это. Мы реализовали систему с использованием cqrs+es, но механизм резолва конфликтов не дошел до прода. Решили без него, может дойдет когда то. Конкретно для решения такой проблемы в рамках 1го сервиса, который распределен и возможны конфликты - мы спрототипировали резолвер конфликтов основанный на CRDT

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

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

Ребята

Заберите Олега

Заберите Олега

сам вернется

Я вижу отчаяние в глазах людей

Лучше давайте про водку

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

это интуитивное правило или есть какие-то основания?

Я вижу отчаяние в глазах людей

?

Кривда по-моему умер

Основание одно - очень высокая сложность, и их часто можно избежать

Да вроде бы ничего сложного, после того, как переключились в скалу с дотти.

первую часть я не догнал)

Это сложный проход, надо понимать это. Мы реализовали систему с использованием cqrs+es, но механизм резолва конфликтов не дошел до прода. Решили без него, может дойдет когда то. Конкретно для решения такой проблемы в рамках 1го сервиса, который распределен и возможны конфликты - мы спрототипировали резолвер конфликтов основанный на CRDT

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

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

В инете полно инфы, с ходу не вспомню ресурсы.

Моноиды в помощь ?

Это сложный проход, надо понимать это. Мы реализовали систему с использованием cqrs+es, но механизм резолва конфликтов не дошел до прода. Решили без него, может дойдет когда то. Конкретно для решения такой проблемы в рамках 1го сервиса, который распределен и возможны конфликты - мы спрототипировали резолвер конфликтов основанный на CRDT

имхо основной вопрос, как скомпенсировать сайд-эффекты вне своей системы, а не как вернуть консистентность в нее (может и возвращать ничего не нужно,, просто оставить в статусе фейлд)

Моноиды в помощь ?

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

имхо основной вопрос, как скомпенсировать сайд-эффекты вне своей системы, а не как вернуть консистентность в нее (может и возвращать ничего не нужно,, просто оставить в статусе фейлд)

Ну так же, отправив соответствующую команду. Например заслать в банк перевод, который был по ошибке списан. Грубо

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

В акке кстати был модкль distributed data

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

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

Касаемо конкретного примера, у нас есть персистент акторы, которые представляют некоторые заявки. Они умеют работать в параллель и потом с помощью crdt мержить логи событий. Если смержить нельзя принимается решение о посылке команды на переход заявки в определенный статус, в зависимости от текущего состояния. В том числе отправка сообщений во внешние системы, что бы это учли.

Но тут пипец скока нюансов

Прямая трансляция с SPb Scala Meetup 2018.1 https://www.youtube.com/c/ScalaRussia/live

Спасибо за трансляцию, посоны!

А что там с Олегом было?

как обычно подпалил мозги

были тайплевел дсл на дотти, на имплиситах и макросах