В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Scala User Group

2220 membersпожаловаться на группу
2021 January 19

AS

Alex Sh in Scala User Group
Ilya
Ох. Сколько такого пришлось хлебнуть. И в чистой java, и на скале с akka и с zio. И главное что я запомнил из этого опыта - параллельная обработка сообщений в рамках одной партиции почти всегда зло. Особенно если нельзя терять сообщения.
Надо параллелить - добавь ещё партицию.
Ну я в итоге сделал produce(record).flatten как раз чтобы избежать таких отхлёбов 🙂
источник
16:27пожаловаться#1

ЮБ

Юрий Бадальянц... in Scala User Group
Alex Sh
Такая логика не ломает ordering между исходящими сообщениями?
Я прям сча этим же занимаюсь
Точно не ломает. parEvalMap работает асинхронно, но сохраняет порядок. Есть ещё parEvalMapUnordered. Вот в нём порядок теряется.
источник
19:45пожаловаться#2

ЮБ

Юрий Бадальянц... in Scala User Group
Alex Sh
Ну я в итоге сделал produce(record).flatten как раз чтобы избежать таких отхлёбов 🙂
Это подойдёт для тестов, но никак не для прода
источник
19:45пожаловаться#3

ЮБ

Юрий Бадальянц... in Scala User Group
Anton Velichko
Ломает
Это не так
источник
19:45пожаловаться#4

ЮБ

Юрий Бадальянц... in Scala User Group
Alex Sh
Ну я в итоге сделал produce(record).flatten как раз чтобы избежать таких отхлёбов 🙂
Ещё в принципе можно самому батч копить через какой-нибудь groupWithin. И разом весь батч слать. В таком варианте нормально делать flatten, потому что ожидаться будет весь батч. Но это намного странный способ, потому что продюсер и так уже батчует из коробки.
источник
19:48пожаловаться#5

AS

Alex Sh in Scala User Group
Юрий Бадальянц
Ещё в принципе можно самому батч копить через какой-нибудь groupWithin. И разом весь батч слать. В таком варианте нормально делать flatten, потому что ожидаться будет весь батч. Но это намного странный способ, потому что продюсер и так уже батчует из коробки.
Такое видел в доках... Решил начать с наиболее простого варианта
источник
19:49пожаловаться#6

ЮБ

Юрий Бадальянц... in Scala User Group
Ilya
Ох. Сколько такого пришлось хлебнуть. И в чистой java, и на скале с akka и с zio. И главное что я запомнил из этого опыта - параллельная обработка сообщений в рамках одной партиции почти всегда зло. Особенно если нельзя терять сообщения.
Надо параллелить - добавь ещё партицию.
Не путайте параллельную и асинхронную обработку. Да, строго паралелить внутри патриции нельзя. Но асинхронно делать какой-то шаг с парализмом больше 1 вполне можно. Главное, чтобы на входе и выходе этого шага стрима сохранялся порядок. И именно так работает parEvalMap
источник
19:50пожаловаться#7

AS

Alex Sh in Scala User Group
Юрий Бадальянц
Точно не ломает. parEvalMap работает асинхронно, но сохраняет порядок. Есть ещё parEvalMapUnordered. Вот в нём порядок теряется.
Я правильно понимаю, что из этого утверждения следует то, что порядок отправки сообщений в кафку строго определяется порядком добавления этих сообщений в буфер?
источник
19:51пожаловаться#8

ЮБ

Юрий Бадальянц... in Scala User Group
Alex Sh
Я правильно понимаю, что из этого утверждения следует то, что порядок отправки сообщений в кафку строго определяется порядком добавления этих сообщений в буфер?
Да
источник
19:51пожаловаться#9

ЮБ

Юрий Бадальянц... in Scala User Group
Мы там выше с лолкэтом это обсуждали кстати. В 1.2.0 эту гарантию сломали, а в 1.3.0 починили.
источник
19:52пожаловаться#10

AV

Anton Velichko in Scala User Group
Юрий Бадальянц
Это не так
ну как это, порядок результатов гарантируется, но не порядок выполнения, у тебя parEvalMap(6) на выходе даст тот же порядок что на входе но порядок выполнения  io не гарантируется
источник
19:59пожаловаться#11

ЮБ

Юрий Бадальянц... in Scala User Group
Anton Velichko
ну как это, порядок результатов гарантируется, но не порядок выполнения, у тебя parEvalMap(6) на выходе даст тот же порядок что на входе но порядок выполнения  io не гарантируется
Так вопрос не про это был, а про порядок на выходе
источник
20:01пожаловаться#12

AV

Anton Velichko in Scala User Group
ну так порядок отправки тождественен порядку выполнения msg.publish что в итоге не совсем равен порядку на выходе
источник
20:04пожаловаться#13

AV

Anton Velichko in Scala User Group
из parEvalMap
источник
20:04пожаловаться#14

AV

Anton Velichko in Scala User Group
Anton Velichko
ну так порядок отправки тождественен порядку выполнения msg.publish что в итоге не совсем равен порядку на выходе
точнее он может быть равен но без гарантий
источник
20:05пожаловаться#15

AV

Anton Velichko in Scala User Group
это как с mapAsync в акка стримах
источник
20:06пожаловаться#16

AV

Anton Velichko in Scala User Group
порядок событий на выходе равен порядку на входе, но внутри они могут выполняться как им удобно
источник
20:06пожаловаться#17

I

Ilya in Scala User Group
λoλcat
Я в кафку посылаю то, что ждать не обязательно
Ну вот исходя из этого можно просто положится на порядок добавления сообщений в драйвер Кафки. Он сам по себе достаточно умный. Я правда не уверен что зио-кафка так умеет
источник
20:07пожаловаться#18

ЮБ

Юрий Бадальянц... in Scala User Group
Что? Если ты посмотришь на мой сниппет, то msg.publish запускается без параллелизма, а вот ожидание второго F уже делается с парализмом. Я там писал, как это работает и я точно уверен, что это корректно. Я с этим уже давно на проде живу и куча тестов с порядком есть
источник
20:08пожаловаться#19

ЮБ

Юрий Бадальянц... in Scala User Group
Anton Velichko
ну так порядок отправки тождественен порядку выполнения msg.publish что в итоге не совсем равен порядку на выходе
Я вот про это
источник
20:08пожаловаться#20