Size: a a a

Scala User Group

2020 January 21

🔝P

🔝Ivan Popovich 🔝 in Scala User Group
λλ
да Олег про дедупликацию а мы про грейсфул шутдаун и апдейт стейта основываясь на предыдущих евентах
предусмотрев решение дедупликации, вторая задача решена автоматически - разве нет?
источник

V

Vλadimir in Scala User Group
🔝Ivan Popovich 🔝
предусмотрев решение дедупликации, вторая задача решена автоматически - разве нет?
прерванное выполнение обработки с изменением внешнего стейта?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Ну я так понял, что Кирилла беспокоил грейсфул с упоминанием дедупликации т.к. есть некоторый стейт дедупликации, который не должен персиститься на каждое сообщение.
Притом, чтобы восстановить этот стейт нужно прочитать больше сообщений, чем те, что уже отражены в основном стейте
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Получается, что либо нужно два разных сорта офсета либо, гарантировать, что при шатдауне помимо комита офсета запишется доп стейт дедупликации
источник

KS

Kirill Shelopugin in Scala User Group
Изначально мой вопрос был про повторную обработку события, изменяющего стейт (и, возможно, не один). Таким образом, если обработка события влечет за собой изменение нескольких стейтов (например, апдейт нескольких таблиц), то не-грейсфул шатдаун посередине обработки события приведет к тому, что какие-то стейты будут обновлены, а какие-то нет, и повторная обработка события повлечет за собой повторное изменение стейтов, которые уже были изменены.
источник

V

Vλadimir in Scala User Group
либо при этих ваших "дедупликациях" - не будут изменены стейты которые не успели обновититься из за шатдауна
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Kirill Shelopugin
Изначально мой вопрос был про повторную обработку события, изменяющего стейт (и, возможно, не один). Таким образом, если обработка события влечет за собой изменение нескольких стейтов (например, апдейт нескольких таблиц), то не-грейсфул шатдаун посередине обработки события приведет к тому, что какие-то стейты будут обновлены, а какие-то нет, и повторная обработка события повлечет за собой повторное изменение стейтов, которые уже были изменены.
Думаю, принципиально этот кейс неразрешим, т.к. грейсфул шатдаун гарантировать невозможно.
Насколько я понимаю, вместо этого предполагается использовать дополнительную обработку сообшений.
Т.е. из топика перекладывать, агрегируя и насыщая, в специализированные топики для отдельных стейтов
источник

SA

Sergey Alaev in Scala User Group
Kirill Shelopugin
Изначально мой вопрос был про повторную обработку события, изменяющего стейт (и, возможно, не один). Таким образом, если обработка события влечет за собой изменение нескольких стейтов (например, апдейт нескольких таблиц), то не-грейсфул шатдаун посередине обработки события приведет к тому, что какие-то стейты будут обновлены, а какие-то нет, и повторная обработка события повлечет за собой повторное изменение стейтов, которые уже были изменены.
непонятно. т.е. есть желание обработать грейсфул, но не хочется обрабатывать жесткое выключение?
источник

VS

Valeriy Shinkevich in Scala User Group
Kirill Shelopugin
Изначально мой вопрос был про повторную обработку события, изменяющего стейт (и, возможно, не один). Таким образом, если обработка события влечет за собой изменение нескольких стейтов (например, апдейт нескольких таблиц), то не-грейсфул шатдаун посередине обработки события приведет к тому, что какие-то стейты будут обновлены, а какие-то нет, и повторная обработка события повлечет за собой повторное изменение стейтов, которые уже были изменены.
по-моему нужно стейт делать с учетом этой фигни, а не надеяться на транспорт
источник

N

Nik in Scala User Group
Всем привет
Кто-то писал скрипты для gatling?
источник

N

Nik in Scala User Group
Очень нужна помощь
источник

AS

Aλeχander Semenov in Scala User Group
На первый-второй рассчитась :)
источник

N

Nik in Scala User Group
Выполняю обращение к методу api
Запрос - post
Вопрос, как в цикле в .body подставить все json файлы из некоторой директории?
источник

N

Nik in Scala User Group
В гугле к сожалению так и не смог найти внятный пример
источник

N

Nik in Scala User Group
Мой код:
var fileHere = (new java.io.File("/LoadTest/Templates/JSON")).listFiles()
     for ( i <- 0 to fileHere.length - 1)
...
.exec(http("send document").post("/api/document")
                           .header("Token","${Token}")                            
                           .body(RawFileBody(fileHere(i).getPath())).asJson
                           .check(status is 200)
       )
источник

N

Nik in Scala User Group
Там где ... получаю токен, там ничего интересного и все работает
источник

AO

Alexey Otts in Scala User Group
Копай в сторону multipart form request
источник

N

Nik in Scala User Group
Alexey Otts
Копай в сторону multipart form request
Посмотрю, спасибо!
источник

AS

Artem Sokolov in Scala User Group
можно задам тупой вопрос
если поставить -Xfatal-warnings
то может ли быть ситуация когда из-за этого будет валиться компиляция (например standalone/одномодульного sbt проекта) из-за зависимости на какую-то уже скомпиленую библиотеку?
источник

KS

Kirill Saksin in Scala User Group
Artem Sokolov
можно задам тупой вопрос
если поставить -Xfatal-warnings
то может ли быть ситуация когда из-за этого будет валиться компиляция (например standalone/одномодульного sbt проекта) из-за зависимости на какую-то уже скомпиленую библиотеку?
deprecated разве что
источник