@scala_ru

Страница 748 из 1499
 
Denis
20.06.2017
09:51:27
Это известная проблема в ивентсорсинге :)

 
Set validation

 
Arthur
20.06.2017
09:51:33
может не очень круто получиться, ибо пока у тебя этот менеджер будет занят записями встреч, запросы на созданные проксироваться не будут
так я пока не обработаю команду в акторе, следующая не пойдет исполнятся, разве не так?

 
Denis
20.06.2017
09:51:57
nfr

Google
 
Denis
20.06.2017
09:51:58
так

 
Arthur
20.06.2017
09:52:39
Это известная проблема в ивентсорсинге :)
ну это не то чтобы больно, в принципе если встреча была создана, актор полюбому в скором времени прийдется подымать, главное что все миллиарды встречь в теории не прийдется подымать при запуске сервера

 
Vadim
20.06.2017
09:54:32
все так, просто вся производительность будет упираться только в один этот актор

 
Denis
20.06.2017
09:54:41
да

 
Arthur
20.06.2017
09:55:08
в будущем можно партишенинг запилить

 
как решение проблемы

 
у меня пока до 100к примерно нужно держать

 
но ожидание пока 100к подымется на старте сервера меня не радует поэтому хочу лениво делать

 
спасибо за помощь ?

 
Denis
20.06.2017
09:57:55
ну и еще если ты будешь не в одном экземпляре сервис поднимать, то не забудь сделать своего менеджера синглтоном

 
Arthur
20.06.2017
09:58:48
а разве кластер актор система не менеджит это сама?

 
тоесть я ей скажу, сделай мне такой-то актор

 
и она не проверит существует ли он уже?

Google
 
Denis
20.06.2017
10:01:59
Уникальность актора менеджит ClusterSharding

 
Если ты его юзаешь то ок

 
Arthur
20.06.2017
10:04:06
Я пока не дошёл до кластера, и опыта небыло, поэтому у меня в основном догадки что это должно работать так) окей, спасибо

 
KrivdaTheTriewe
20.06.2017
10:10:12
Снглтон, он только объект на кластере один, поэтому только шард

 
Nikita
20.06.2017
11:05:54
и она не проверит существует ли он уже?
кластер шардинг умеет это

 
но надо за сплитбрейнами смотреть

 
и за тем как ты кластер поднимаешь

 
Arthur
20.06.2017
11:06:45
сплитбрейнами - это когда два кластера подымается вместо одного целого?

 
Nikita
20.06.2017
11:06:49
да

 
ну и не только поднимается, может еще сеть разделиться

 
тогда тоже будут два кластера

 
Arthur
20.06.2017
11:08:15
есть какой-то common way для мониторинга такого дерьма?

 
чтобы если че, положить все

 
Denis
20.06.2017
11:08:36
Есть SplitBrainResolver от Lightbend, который платный для прода

 
Nikita
20.06.2017
11:08:43
мы написали свой split brain resolver

 
Arthur
20.06.2017
11:08:50
ок, понял

 
Nikita
20.06.2017
11:08:51
и смотрим на наличие majortity

 
Arthur
20.06.2017
11:09:02
majority?

 
Denis
20.06.2017
11:09:07
Но фактически он пишется легко, и они добавили API для этого

 
Nikita
20.06.2017
11:09:14
это не очень сложно, нужно просто подписаться на ивенты кластера и смотреть текущее состояние нод

Google
 
Denis
20.06.2017
11:09:42
Исходники SplitBrainResolver есть в свободном доступе, можно вдохновиться ими

 
Arthur
20.06.2017
11:09:58
ясн, решаемо короче)

 
а кто как деплоит кластеры акки

 
докер?

 
там же просто отдельно группу сидов надо создавать как я понял

 
я пытался обойти это, но не вышло

 
Nikita
20.06.2017
11:10:29
ясн, решаемо короче)
ага, только проблема заинтергировать с aws и оттестировать

 
докер?
докер, да

 
кстати, говоря про акка персистенс, никто не встречал что eventsByTag пропускает ивенты иногда?

 
Denis
20.06.2017
11:13:18
встречал

 
страдал

 
https://github.com/akka/akka-persistence-cassandra/issues/166

 
Denis
20.06.2017
11:13:55
Fixed

 
Не самая приятная вещь в проде :)

 
но решалось сбросом оффсетов

 
Nikita
20.06.2017
11:14:12
ок, надо обновиться :)

 
кстати как прошло обновление плагина? ничего не ломается?

 
Denis
20.06.2017
11:15:03
ну мы подождали немного

 
там вышло еще два хотфикса )

 
и потом обновились

Google
 
Denis
20.06.2017
11:15:17
все ок

 
Nikita
20.06.2017
11:15:46
0.29 можно смело юзать?

 
Denis
20.06.2017
11:16:02
да

 
Nikita
20.06.2017
11:17:19
ок, спасибо

 
Nikita
20.06.2017
12:07:19
вопрос по акка персистанс, у меня есть актор встречи и актор который находится над всеми встречами чтобы роутить команду куда надо и делать валидации типо "встреча должна иметь уникальное имя". У меня есть два варианта работы с менеджером встречь, первый это создавать акторы встречь во время проигрывания событий или делать это on demand. Какой вариант предпочтительней? Насколько долго подымается персистанс актор в случае если в нем до 100 ивентов?
если будешь использовать ClusterSharding - то тебе менеджер не нужен будет чтобы валидировать имя (и вообще все что угодно касательно одной встречи), валидацию можно перенести в самого актора Встреча - он поднимется, загрузит свое состояние из базы (если оно было), выполнит твою команду, и ответит результатом валидации, профит этого подхода в том что тебе не надо будет держать в памяти (особенно одной jvm) Сет непредсказуемого размера

 
Arthur
20.06.2017
12:10:03
мне не нравится идея спрашивать 100к акторов для валидации

Admin
ERROR: S client not available

 
Nikita
20.06.2017
12:10:15
почему 100к? только одного же

 
Arthur
20.06.2017
12:10:24
ну у меня есть 100к встречь

 
у каждого имя

 
Denis
20.06.2017
12:10:36
Это если имя - первичный ключ

 
Arthur
20.06.2017
12:10:47
ноуп, имя это как пример

 
Denis
20.06.2017
12:10:50
А если это просто свойство - не поможет

 
Arthur
20.06.2017
12:10:53
там могут быть более сложные валидации

 
не больше 10 на пользователя

 
Nikita
20.06.2017
12:11:13
ну так как у тебя имя уникальное уже - это и есть ключ - persistanceId

 
Arthur
20.06.2017
12:11:13
итд

 
я понимаю, по ключу это вполне вариант

 
но таким образом я ограничиваю себя в том как я могу валидировать данные

 
Nikita
20.06.2017
12:12:14
просто валидация не больше 10 на пользователя - это часть пользователя а не событий)

Google
 
Arthur
20.06.2017
12:13:47
само собой) сеичас идея прорабатывается и будет часто меняться, поэтому я выбрал самый легко кастомизируемый вариант

 
потому-что если че, то купить тачку с кучей оперативки будет не проблема, на период пока будет переписываться вся эта штука на партишенинг дабы иметь сеты данных поменьше

 
Igor
20.06.2017
12:16:09
Привет, подскажите насколько реально перейти с Пайтона(менее 2 лет опыта) в Скалу. Проходил какие-то курсы(Одерский), читал литературу, но не уверен, есть ли смысл что-то искать без опыта в JVM?

 
Arthur
20.06.2017
12:16:22
я с пхп переходил, так что с пайтона думаю реально)

 
зависит от желания и свободного времени

 
ну и от того чем хотите заниматься, бигдата, веб, микросервисы

 
Igor
20.06.2017
12:17:25
Артур, какие знания требовались? Долго пришлось искать?

 
Nikita
20.06.2017
12:17:28
потому-что если че, то купить тачку с кучей оперативки будет не проблема, на период пока будет переписываться вся эта штука на партишенинг дабы иметь сеты данных поменьше
тогда и акторов тут не обязательно использовать, ибо может оказаться что надо будет полностью переписывать, я просто думал что ты сейчас закладываешь дизайн и будешь скоро шардить акторов встреч

 
Arthur
20.06.2017
12:17:51
я месяцев 5 писал в стол, потом на фрилансе нашел веб проект

 
@nikitamatveenko мне интересен евенсорсинг, так как благодаря нему, я могу максимально менять предоставляемые данные

 
и без акторов это сущий ад

 
Igor
20.06.2017
12:18:47
Проект был в команде? Или сами работали?

 
Arthur
20.06.2017
12:19:08
Проект был в команде? Или сами работали?
три человека, удаленка, через пол года надоело ушел в офис без проблем

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

 
Nikita
20.06.2017
12:22:16
@nikitamatveenko мне интересен евенсорсинг, так как благодаря нему, я могу максимально менять предоставляемые данные
это интересный путь, так у тебя актор встреча персистент? я бы делал его таким а потом можно было бы любые агрегации собрать для валидаций, и менеджера бы разгрузил, он бы просто роутил сообщения и хранил какие-то кэши для валидации

 
Arthur
20.06.2017
12:23:12
это интересный путь, так у тебя актор встреча персистент? я бы делал его таким а потом можно было бы любые агрегации собрать для валидаций, и менеджера бы разгрузил, он бы просто роутил сообщения и хранил какие-то кэши для валидации
да, конечно персистент, у меня на данный момент менеджер тоже персистент чтобы иметь кеш для валидаций

 
Nikita
20.06.2017
12:23:17
мы писали свой солюшен на прошлой работе, для евентсорсинга, в итоге уперлись в то что немогли впилить валидацию данных без optimistic locking что уже было не очень, неговоря уже о том, что все это выглядело как недоакторы, ибо была точка куда закидываешь команды и точка где паттернматчишь события
а на это смотрели http://rbmhtechnology.github.io/eventuate/ ?

 
Arthur
20.06.2017
12:23:53
я пришел уже когда это самопильное дерьмо уже год пилили и на нем написан проект был из 8 микросервисов

Страница 748 из 1499