Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
 Re: akka да. снова.  [new]
забыл ник
Member

Откуда:
Сообщений: 3289
andreykaT,

Повезло тебе.
Архитектора на премию выдвинуть обязательно.
П. С. Жесть то какая..отличный пример когда люди гонятся за хайпом, а потом у них технология говно..
28 апр 20, 20:40    [22124492]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
забыл ник
andreykaT,

Повезло тебе.
Архитектора на премию выдвинуть обязательно.
П. С. Жесть то какая..отличный пример когда люди гонятся за хайпом, а потом у них технология говно..

там стек ваадин+акка+кафка. причем смотрю такой зууу. акка шлет мессадж чтоб кафка послала в кафку мессадж а в мессадже... СКЛ мать его запрос ))) на который приходит ответ в хмле. даа. даа. дааааааа!!!

имхо яркий пример того когда прикрутили то не зная что ради того чтоб было потому что модно и хочется попробовать. а ты бибись.
28 апр 20, 21:27    [22124532]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Apache Camel в данном случае был-бы надежнее. Субъективно.
Мы с ним работали и ни один месседж внутри java-процессов не терялся.
Разумеется не с сетевыми протоколами а "vm://"
29 апр 20, 10:19    [22124722]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
забыл ник
Member

Откуда:
Сообщений: 3289
mayton
Apache Camel в данном случае был-бы надежнее. Субъективно.
Мы с ним работали и ни один месседж внутри java-процессов не терялся.
Разумеется не с сетевыми протоколами а "vm://"

Подозреваю что в данном случае был бы надежнеетупой синхронный колл в базу данных. А Camel и Akka один хрен. К тому же нету там никких проблем с недоставкой, это проблема кодинга настроне команды ТС.
В Акке есть два момента -1) кто-то не слушает определенный формат мессаджа и тогда оно идет в dead letter queue(но его надо настроить и слушать) 2) семантика доставки ослаблена до at-most once(это дефолт если не используется persistent actors) - и там таки да, советуют retry.

https://stackoverflow.com/questions/29075136/akka-message-delivery-guarantees
https://www.lightbend.com/blog/how-akka-works-at-most-once-message-delivery
https://doc.akka.io/docs/akka/current/general/message-delivery-reliability.html
29 апр 20, 12:16    [22124808]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
забыл ник, в неком гипотетическом сценарии давай представим что мы убрали Akka
и заменили ее на BlockingQueue.

Есть два независимых асинхронных потока и между ними буфер сообщений в BQ.
Producer-BQ-Consumer.

Можем ли мы терять сообщения? Да легко!! Вряд-ли мы сделаем двух-фазную работу
как Amazon SQS. Потребитель прочитал сообщение - и 3.14дец. Больше никто этой
информацие не владеет. Она - ушла из поля зрения всех. И если Consumer падает
по RuntimeException то мы месседж навсегда потеряли и Producer об этом не знает
тк у нас нет никакого протокола треканья этого сообщения.

Вот с такого софистического примера я и предлагаю начать обсуждение.

Сообщение было отредактировано: 29 апр 20, 12:44
29 апр 20, 12:45    [22124827]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
забыл ник
Member

Откуда:
Сообщений: 3289
mayton
забыл ник, в неком гипотетическом сценарии давай представим что мы убрали Akka
и заменили ее на BlockingQueue.

Есть два независимых асинхронных потока и между ними буфер сообщений в BQ.
Producer-BQ-Consumer.

Можем ли мы терять сообщения? Да легко!! Вряд-ли мы сделаем двух-фазную работу
как Amazon SQS. Потребитель прочитал сообщение - и 3.14дец. Больше никто этой
информацие не владеет. Она - ушла из поля зрения всех. И если Consumer падает
по RuntimeException то мы месседж навсегда потеряли и Producer об этом не знает
тк у нас нет никакого протокола треканья этого сообщения.

Вот с такого софистического примера я и предлагаю начать обсуждение.

Ну так это классика и об этом напсианы талмуды. Вся соль в протоколе. и зависит от нужной семанткии доставки сообщений, и без разницы акка это или очередь
1) At most once, отвественность на Producer - если он сделал put()(либо послал мессадж) и код вернул управление, дело сделано.
2) At least once. В этом случае отвественность делится. Producer должен делать retry пока не получит acknowledge. Consumer же должен обеспечить логику идемпотентности
29 апр 20, 12:51    [22124832]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Давай я закину третью ситуацию. Я думаю что Андрейка с ней воевал.

Консьюмер залип по таймауту. Бывает такое. Интеракция с медленным ендпоинтом или БД.

Вот в этом случае ты пишешь
Producer должен делать retry пока не получит acknowledge.

Какой смысл? Закидывать его ретрайми. Ему только хуже станет.

Нет может я недочитал документацию по Akka и там есть еще одна конфигурация
связанная с временем реакции на сообщение.
29 апр 20, 12:57    [22124837]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
забыл ник
Member

Откуда:
Сообщений: 3289
mayton

Какой смысл? Закидывать его ретрайми. Ему только хуже станет.

Нет может я недочитал документацию по Akka и там есть еще одна конфигурация
связанная с временем реакции на сообщение.

Акка тут не при чем, имплементация протокола лежит на программисте, и как он реализует так и будет(expo backoff, старт нового косьюмера или еще как)
Вопрос про смысл не понятен - если нам нужен at least once какие еще есть варианты кроме как постоянно ретраить? Как в общем то в любом сетевом протоколе.
29 апр 20, 13:21    [22124857]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Топик начался с этого крика о помощи

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


Я тоже думаю что Акка здесь непричем. А "причем" здесь наша реакция на протокол.
Мы где-то неправильно его использовали. Беконечный таймаут потока либо RuntimeEx
который был утерян.
29 апр 20, 13:37    [22124872]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
Все форумы / Java Ответить