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

Откуда:
Сообщений: 2794
угораздило меня в проект попасть где все на акке.
собссно дебажить ее это то еще удовольствие. ну ладно.

есть очень трудновоспроизводимый баг. уже весь код перелопатил. по цепочке морда ходит на репозиторий 2 сообщения туда 2 сообщения обратно (итого 4 да), и штук 5 мест где что то может пойти не так и никто об этом не узнает. (за такой код руки ломать надо, 100500 мутаторов 100500 сайдэффектов, всё на войдах). я все варианты отбросил и остановился на таком:
где то в этой конченной цепочке из четырех теллов и четырех слушателей мессадж теряется. может ли такое быть? насколько вероятно? как отдебажить где искать? как такое вообще явно воспроизвести? (кроме как закомментить телл).
25 апр 20, 10:47    [22122517]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Метод mayton-а

LOGGER.trace("::> fucken checkpoint #1 received message {}", msg);
...
LOGGER.trace("::> fucken checkpoint #2 received message {}", msg);

Тупняк конешно но это последний вариант. Потом грепнешь лог(и) и смотришь.

Вот в коде из 1000 методов за 10 итераций изменения кода и отладки
ты выйдешь на 1 строку которая виновата.
25 апр 20, 12:24    [22122542]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
забыл ник
Member

Откуда:
Сообщений: 3289
Прочеекай dead letter queue
25 апр 20, 12:55    [22122555]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
У негож не SQS а Akka
25 апр 20, 13:15    [22122569]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
Да но у меня проблема еще в том что оно работает. Я не могу воссоздать момент чтоб сообщение потерялось. Как то можно это сделать? Ну.. При каких обстоятельствах акка начинает терять месседжи?
25 апр 20, 13:24    [22122575]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Сорян чел. Я не специалист в Акке. Но вот тут есть теория по поводу надёжности сообщений.

https://doc.akka.io/docs/akka/current/general/message-delivery-reliability.html
25 апр 20, 13:46    [22122595]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
Sergunka
Member

Откуда: Bay Area, CA
Сообщений: 2245
mayton
Сорян чел. Я не специалист в Акке. Но вот тут есть теория по поводу надёжности сообщений.

https://doc.akka.io/docs/akka/current/general/message-delivery-reliability.html


документ
Discussion: What does “at-most-once” mean?
When it comes to describing the semantics of a delivery mechanism, there are three basic categories:

at-most-once delivery means that for each message handed to the mechanism, that message is delivered once or not at all; in more casual terms it means that messages may be lost.

at-least-once delivery means that for each message handed to the mechanism potentially multiple attempts are made at delivering it, such that at least one succeeds; again, in more casual terms this means that messages may be duplicated but not lost.

exactly-once delivery means that for each message handed to the mechanism exactly one delivery is made to the recipient; the message can neither be lost nor duplicated.

The first one is the cheapest—highest performance, least implementation overhead—because it can be done in a fire-and-forget fashion without keeping state at the sending end or in the transport mechanism. The second one requires retries to counter transport losses, which means keeping state at the sending end and having an acknowledgement mechanism at the receiving end. The third is most expensive—and has consequently worst performance—because in addition to the second it requires state to be kept at the receiving end in order to filter out duplicate deliveries.


Ага зачотный зоопарк - любо-дорого почитать
25 апр 20, 18:51    [22122738]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Sergunka, я не понял сарказма. Акка в этом смысле ничем не отличается от других систем на базе JMS.
25 апр 20, 18:56    [22122741]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
Ну там скорее всего эт мост уанс заюзано. Но. Какого лешего тогда требовать чтоб оно работало?
Представьте стандартный бэк где есть контроллер сервис репозиторий. И вот короче юзер делает запрос контроллер шлет месседж сервису сервис репозиторию и обратно
. И тут типа по цепочке посередине сообщение одно из 4х теряется и всё. Запрос юзера остался без ответа. Это прекрасно когда в синхронщине пытаются при винтить асинхронщину.

И снова вопрос вдруг кто знает как сделать так чтоб акка потеряла месседжи?
25 апр 20, 20:00    [22122783]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Тут может смысл в другом. Актор его принял. Но в процессе обработки упал.
Тоесть надо искать необработанное исключение в прикладном коде.
25 апр 20, 20:15    [22122793]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
mayton
Тут может смысл в другом. Актор его принял. Но в процессе обработки упал.
Тоесть надо искать необработанное исключение в прикладном коде.

это когда хотя бы аск. но когда телл? да еще и стейтлесс? он не знает результат своего запроса.
25 апр 20, 20:39    [22122804]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
... ну или вкарячивать ретрай паттерн и долбить актор пока что то не прилетит ))
25 апр 20, 20:45    [22122809]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
mayton
Тут может смысл в другом. Актор его принял. Но в процессе обработки упал.
Тоесть надо искать необработанное исключение в прикладном коде.

мне очень тяжело срепродьюсить этот кейс. оно иногда не работает. так вот это вот иногда я смотрел в логи и ничего не увидал. ща проставил везде логирование где только можно. и... эта гнида работает и не падает.
26 апр 20, 01:10    [22122901]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
Sergunka
Member

Откуда: Bay Area, CA
Сообщений: 2245
mayton
Sergunka, я не понял сарказма. Акка в этом смысле ничем не отличается от других систем на базе JMS.


На моей памяти потерять сообщение может только еще Кафка и то скорее всего там выскочит эксепшин, что сообщение не прошло от продьюсера после третьей попытке или что-то навроде того. Но там хотя бы осознанный выбор
acks = 0 - the producer won't wait for the confirmation from the leader replica.

P.S. С Аккой не работал всех прелестей не знаю и скорее всего не пойму - прошу строго не судить. Но то, что прочитал заценил.
26 апр 20, 02:17    [22122924]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
andreykaT
mayton
Тут может смысл в другом. Актор его принял. Но в процессе обработки упал.
Тоесть надо искать необработанное исключение в прикладном коде.

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

Будем наблюдать.
26 апр 20, 10:17    [22122969]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
andreykaT
... ну или вкарячивать ретрай паттерн и долбить актор пока что то не прилетит ))

Убежден что этот ретрай-паттерн должен быть частью Akka. Тоесть не должно быть с нашей
стороны дополнительно пихать какую-то логику. По идее конфигурации "guardian" должно быть достаточно
чтоб закрыть эти все вопросы.
26 апр 20, 11:59    [22123001]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
mayton
andreykaT
... ну или вкарячивать ретрай паттерн и долбить актор пока что то не прилетит ))

Убежден что этот ретрай-паттерн должен быть частью Akka. Тоесть не должно быть с нашей
стороны дополнительно пихать какую-то логику. По идее конфигурации "guardian" должно быть достаточно
чтоб закрыть эти все вопросы.

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

ну в общем лирика.

А что за такой конфигурация гуардиан?
26 апр 20, 12:14    [22123007]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Ну я вот по этой картинке. Над прикладными акторами есть смотрящий.
И наверное есть под ним како-то тоже прикладной смотрящий. И у его
(в соотвествии с акторными принципами) должна быть прописана
стратегия что делать если актор упал.

Картинка с другого сайта.
26 апр 20, 13:04    [22123032]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
а может такое быть что мессадж просто пропал и всё тут.?
26 апр 20, 17:05    [22123157]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
andreykaT
а может такое быть что мессадж просто пропал и всё тут.?

Я - ХЗ. Яж говорю с позиции теории. Из того что смотрел в лекциях Яндекса по Акке.
26 апр 20, 17:22    [22123164]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
Sergunka
Member

Откуда: Bay Area, CA
Сообщений: 2245
andreykaT
а может такое быть что мессадж просто пропал и всё тут.?


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

Так же понятно может быть эксепшин на уровне консьюмера если при обработке сообщения срабатывает ран тайм эксепшин (скажем по какой-то причине делите на ноль) то с точки зрения уровня приложения сообщени так же пропадет.
26 апр 20, 18:06    [22123190]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
эксепшенов точно нет. но там еще и код многопоточный типа

class Clazz {
private Optional(X) x = Optional.Empty;
public void whateverConstruct () {
x = new Cocococ(...)
}
public getX(){
return x;
}
}

и вот короче один поток делает whateverConstruct() а второй делает getX()

и в методе второго такая дичь:
public void whateverDo() {
n.getX().map(x-> akkaTell(x));
}

хэй-хэй, мазафака. чтоб ты сдох кто это написал.

плак-плак моде офф.

т.е. акка может и не причем.

Сообщение было отредактировано: 26 апр 20, 23:14
26 апр 20, 23:12    [22123316]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
Sergunka
Member

Откуда: Bay Area, CA
Сообщений: 2245
andreykaT,

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

Вообще как Вы пытаетесь определить, что сообщение прошло или потерялось?
27 апр 20, 02:00    [22123336]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
логирую факт отправки в продюссере и кетч в консумере. в общем логично да. пока все работает. дефект не воспроизводится.
27 апр 20, 09:51    [22123392]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Баг Шредингера...
27 апр 20, 10:17    [22123409]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
mayton
Баг Шредингера...

было бы смешно если бы я смог его репродакшн сделать стабильно :)
27 апр 20, 11:08    [22123436]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Есть у меня своя слабая теория. О том что логгирование слегка
замедляет race conditions. Вот как-то так.. Включил логгирование - все нормас.
Выключил - херак... стрельнул баг.
27 апр 20, 11:12    [22123439]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5288
mayton
Есть у меня своя слабая теория. О том что логгирование слегка
замедляет race conditions. Вот как-то так.. Включил логгирование - все нормас.
Выключил - херак... стрельнул баг.


У вас Kafka?
Помниться у меня был прикол с Kafka.
Работал на домашнем ноутбуке с HDD. У меня постоянно в приложение вылетало с ошибкой.
У других был SSD - все было нормально.
В конце концов выяснилось, что нужно было увеличит в настройках тайминги записи.
Грубо говоря hdd не успевал записать, а клиент Kafka уже проверял запись.
Возможно у вас подобная ситуация.
27 апр 20, 12:07    [22123481]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Нет. Я юзал только Apache-MQ. И гонки за состояниями я наблюдал вобщем не в мессенжинговых системах.
А вообще. В любых. Очень похоже на мистику, когда ты смотришь на проблему с измерительным прибором
- проблема прячется.
27 апр 20, 12:12    [22123490]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
mad_nazgul

В конце концов выяснилось, что нужно было увеличит в настройках тайминги записи.
Грубо говоря hdd не успевал записать, а клиент Kafka уже проверял запись.

А это очень похоже на некорректную работу с файлами. Грубо говоря с файлом
пытались работать как с базой данных. А он - не таков.
27 апр 20, 12:14    [22123493]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
С точки зрения файловой системы даже close() файла еще не гарантирует
полной конситентности. Нужно форсировать fsync.

http://man7.org/linux/man-pages/man2/fsync.2.html

А это накладные расходы для все файловой системы в целом.
Вобщем Роберт Лав в своей книжке по Linux Kernel пишет про это.

А если мы работаем с файлом который постоянно открыт и просто
что-то дописывает в хвост то здесь работает как минимум несколько
логических буферов. И очень сложно формально доказать что
то что один процесс записал - второй уже может видеть.
27 апр 20, 12:48    [22123518]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
mayton
С точки зрения файловой системы даже close() файла еще не гарантирует полной конситентности.
Если требуется только возможность прочитать записанное, то нужна не консистентность, а доступность изменений. И тут начинаются разные ньюансы.
Нужно форсировать fsync.
Чтобы уронить производительность ниже плинтуса? Да, нужно. Во всех остальных случаях надо смотреть разные ньюансы.
27 апр 20, 13:07    [22123533]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
andreykaT
а может такое быть что мессадж просто пропал и всё тут.?

Попробую глянуть на этот смотрящий актор.

Вот здесь даже красивая форма для печенек есть https://developer.lightbend.com/start/?group=akka&project=akka-quickstart-java
27 апр 20, 13:30    [22123549]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
В туториале этот момент не акцентирован.

Вот в документации есть упоминание о двух стратегиях. Это где-то инкапсулируется в конфиг всей системы.

К сообщению приложен файл. Размер - 72Kb
27 апр 20, 13:59    [22123565]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Почему меня это заинтересовало. В смежом топик я ковырял протокол DHT/KAD (на сетевом уровне - это UDP).
Вот. И работа с ним очень похожа на акторную модель. Клиент DHT слушает эфир. Принимает пакеты. Ретранслирует.
И отдает контент файлами если его попросят. Файлы там уже передаются по другому протоколу но это не суть важно.

Основная логика поиска нодов и хешей которые они хранят реализована буквально в 4 командах протокола.
И у меня как-то была рассеянная идея о том что эту штуку переписать под Akka. Сценарии когда пакет битый
и его невозможно обработать - можно спокойно игнорировать. Тоесть как-бы есть налицо такая-себе отказоустойчива
парадигма.
27 апр 20, 14:25    [22123587]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mad_nazgul
Member

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

В конце концов выяснилось, что нужно было увеличит в настройках тайминги записи.
Грубо говоря hdd не успевал записать, а клиент Kafka уже проверял запись.

А это очень похоже на некорректную работу с файлами. Грубо говоря с файлом
пытались работать как с базой данных. А он - не таков.


Да в старых версиях клиента Kafka, он посылал на запись, а потом проверял записано или нет.
В общем какая-то корявая эмуляция синхронной/транзакционной записи.
В настройках стоял таймаут, когда проверить записано или нет.
Неделю потратил, чтобы догадаться что и где поменять.
Причем ошибка ни разу не понятная.
27 апр 20, 14:47    [22123597]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
А Dead-Letter-Queue все таки есть в Akka.
27 апр 20, 23:45    [22123871]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
забыл ник
Member

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

Само собой есть, иначе бы я не просил его проверять)
Касаемо топика то проблема на 99 процентов в прикладном коде, но за неимением оного трудно телепатировать
28 апр 20, 00:05    [22123885]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
API SQS предполагает двухфазную работу с месседжами. Сначала вычитал. Потом обработал
и потом дал команду delete для тех ID msg которые обработал.

На время вычитки месседжи скрыты и другие потоки их не могут видеть. Если в течение
таймаута (задается) ты не дал delete, то они возвращаются обратно в очередь и становятся
видны для других lambda-функций или просто логики AWS API.

Преимущество этой схемы таково что неправильно обработанное сообщение будет бесконечно
кувыркатся в исходной очереди пока вы не обратите на это внимание.
28 апр 20, 10:11    [22124004]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5288
-

Сообщение было отредактировано: 28 апр 20, 11:46
28 апр 20, 11:46    [22124080]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
mayton
Если в течение таймаута (задается) ты не дал delete, то они возвращаются обратно в очередь и становятся
видны для других lambda-функций или просто логики AWS API.
Гонка между "закончил обработку" и "удалил сообщение".
Поймать сложно, но уж если поймаете - будет весело избавляться от повторной обработки одного и того же сообщения.
28 апр 20, 11:56    [22124091]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Basil A. Sidorov
mayton
Если в течение таймаута (задается) ты не дал delete, то они возвращаются обратно в очередь и становятся
видны для других lambda-функций или просто логики AWS API.
Гонка между "закончил обработку" и "удалил сообщение".
Поймать сложно, но уж если поймаете - будет весело избавляться от повторной обработки одного и того же сообщения.

Там нет гонок. Там есть аномалия - сообщение повторно зашло в цикл обработки.
28 апр 20, 12:05    [22124103]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
mayton
Там нет гонок. Там есть аномалия - сообщение повторно зашло в цикл обработки.
Аномалия и есть следствие гонок.
28 апр 20, 12:07    [22124106]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
короче плюнул на эту дичь и просто прикрутил еще одно событие на которое отсылается мессадж. если не заработает - примотаю ретрайпаттерн. приложение на ваадине. оно переживет
28 апр 20, 12:15    [22124115]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
andreykaT, это говнокод.
28 апр 20, 12:40    [22124140]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
mayton
andreykaT, это говнокод.

а юзать общение между слоями через методы которые не гарантируют ответа норм? пихать асинхронку там где нужна синхронка но так как асинхронка не подходит превращать ее в синхронку это норм? )

Сообщение было отредактировано: 28 апр 20, 12:51
28 апр 20, 12:51    [22124148]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Подожди-подожди... Ты решил реформировать государство - но начал с парикмахерской.

Мы-же не видели твой код. Я согласен что там может быть треш-угар и содом. Тогда его
просто надо переписать.

Но ретрай-паттерн предназначен для неустойчивого сетевого соединения в основном или
когда логика написана так что даёт отлуп по загрузке или по таймауту.

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

P.S. Вот повесишь на 1 человека 2 одинаковых кредита...
28 апр 20, 13:20    [22124157]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
если вкратце там тупо комбобокс со списком доступных опций юзеру который щас залогинен.

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

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

решение номер один - найти где затык и устранить его.
решение номер два (проще) - слать дозапрос если список пуст.

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

решение номер три - пилим ретрай и долбим мессаджами до тех пор пока не придет или пока долбилка не устанет.
28 апр 20, 20:11    [22124464]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
я как то в проде встречался с фиксом гонок таким образом, что чел просто в методе вызов нескольких нестед методов (рейс изза которых и возникал) просто подвинул поближе друг к другу :) оно заработало. гонки в корне конечно такое решение в принципе убрать не могло. но оно их вероятность снизило до удовлетворительного уровня.

зы. согласен - решение не очень.
28 апр 20, 20:13    [22124467]     Ответить | Цитировать Сообщить модератору
 Re: akka да. снова.  [new]
andreykaT
Member

Откуда:
Сообщений: 2794
mayton
Есть у меня своя слабая теория. О том что логгирование слегка
замедляет race conditions. Вот как-то так.. Включил логгирование - все нормас.
Выключил - херак... стрельнул баг.

да блин да. тоже такое чувство что эта теория вовсе не теория. до логирования оно хоть как то повторялось. после - перестало.
28 апр 20, 20:15    [22124471]     Ответить | Цитировать Сообщить модератору
 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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Java Ответить