|
|
|
akka да. снова.
|
|||
|---|---|---|---|
|
#18+
andreykaT, Повезло тебе. Архитектора на премию выдвинуть обязательно. П. С. Жесть то какая..отличный пример когда люди гонятся за хайпом, а потом у них технология говно.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2020, 20:40 |
|
||
|
akka да. снова.
|
|||
|---|---|---|---|
|
#18+
забыл ник andreykaT, Повезло тебе. Архитектора на премию выдвинуть обязательно. П. С. Жесть то какая..отличный пример когда люди гонятся за хайпом, а потом у них технология говно.. там стек ваадин+акка+кафка. причем смотрю такой зууу. акка шлет мессадж чтоб кафка послала в кафку мессадж а в мессадже... СКЛ мать его запрос ))) на который приходит ответ в хмле. даа. даа. дааааааа!!! имхо яркий пример того когда прикрутили то не зная что ради того чтоб было потому что модно и хочется попробовать. а ты бибись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2020, 21:27 |
|
||
|
akka да. снова.
|
|||
|---|---|---|---|
|
#18+
Apache Camel в данном случае был-бы надежнее. Субъективно. Мы с ним работали и ни один месседж внутри java-процессов не терялся. Разумеется не с сетевыми протоколами а "vm://" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2020, 10:19 |
|
||
|
akka да. снова.
|
|||
|---|---|---|---|
|
#18+
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.04.2020, 12:16 |
|
||
|
akka да. снова.
|
|||
|---|---|---|---|
|
#18+
забыл ник, в неком гипотетическом сценарии давай представим что мы убрали Akka и заменили ее на BlockingQueue. Есть два независимых асинхронных потока и между ними буфер сообщений в BQ. Producer-BQ-Consumer. Можем ли мы терять сообщения? Да легко!! Вряд-ли мы сделаем двух-фазную работу как Amazon SQS. Потребитель прочитал сообщение - и 3.14дец. Больше никто этой информацие не владеет. Она - ушла из поля зрения всех. И если Consumer падает по RuntimeException то мы месседж навсегда потеряли и Producer об этом не знает тк у нас нет никакого протокола треканья этого сообщения. Вот с такого софистического примера я и предлагаю начать обсуждение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2020, 12:45 |
|
||
|
akka да. снова.
|
|||
|---|---|---|---|
|
#18+
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.04.2020, 12:51 |
|
||
|
akka да. снова.
|
|||
|---|---|---|---|
|
#18+
Давай я закину третью ситуацию. Я думаю что Андрейка с ней воевал. Консьюмер залип по таймауту. Бывает такое. Интеракция с медленным ендпоинтом или БД. Вот в этом случае ты пишешь Producer должен делать retry пока не получит acknowledge. Какой смысл? Закидывать его ретрайми. Ему только хуже станет. Нет может я недочитал документацию по Akka и там есть еще одна конфигурация связанная с временем реакции на сообщение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2020, 12:57 |
|
||
|
akka да. снова.
|
|||
|---|---|---|---|
|
#18+
mayton Какой смысл? Закидывать его ретрайми. Ему только хуже станет. Нет может я недочитал документацию по Akka и там есть еще одна конфигурация связанная с временем реакции на сообщение. Акка тут не при чем, имплементация протокола лежит на программисте, и как он реализует так и будет(expo backoff, старт нового косьюмера или еще как) Вопрос про смысл не понятен - если нам нужен at least once какие еще есть варианты кроме как постоянно ретраить? Как в общем то в любом сетевом протоколе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2020, 13:21 |
|
||
|
akka да. снова.
|
|||
|---|---|---|---|
|
#18+
Топик начался с этого крика о помощи авторгде то в этой конченной цепочке из четырех теллов и четырех слушателей мессадж теряется. может ли такое быть? Я тоже думаю что Акка здесь непричем. А "причем" здесь наша реакция на протокол. Мы где-то неправильно его использовали. Беконечный таймаут потока либо RuntimeEx который был утерян. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2020, 13:37 |
|
||
|
|
start [/forum/topic.php?fid=59&startmsg=39952577&tid=2120819]: |
0ms |
get settings: |
25ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
183ms |
get tp. blocked users: |
2ms |
| others: | 297ms |
| total: | 597ms |
| 0 / 0 |
