и он медленный потому что не может быть быстрым по определению

это лишь означает что _любые_ будут медленные, можно и не играться со словами :)

что за определения такие? в них прям написано 60рпс?

В общем осторожнее там с JDBC на кассандре, оно может сказаться, нужно это учитывать.

Ну и прочитайте документацию её предварительно.

И используейте не JDBC что бы ходить в касандру :) а хотя бы https://github.com/datastax/java-driver

>осторожнее там с JDBC на кассандре ???

так не было же речи о jdbc для кассандры

> Кто-нибудь использует akka-persistence-jdbc в продакшн?

> jdbc

ладненько, я афк

так там поддержка только реляционных баз данных

для cassandra есть отдельный плагин для akka persistence

Ну он перепутал

очень может быть, я ничо не знаю про akka-persistence. Просто говорю быть осторожнее с Cassandra и JDBC.

А вы ходите в касандру из JDBC?

Нет

Народ может кто подскажет, есть плей 2.3 и акка, в conf лежит logger.xml формат лога настроен по человечески, но акка откуда-то берёт дерьмовый формат по умолчанию. Я уже и в conf положил logback.xml эффекта нет. Хочется нормальных логов

логгер для классов акки не включен явно?

вроде нет

Врачи рекомендуют добавить: akka { loggers = ["akka.event.slf4j.Slf4jLogger"] loglevel = "DEBUG" logging-filter = "akka.event.slf4j.Slf4jLoggingFilter" }

case x => log.info("RECEIVED EVENT:\n"+x)мдя, это провал

оказывается, это не форматирование, это умельцы с руками которые некуда девать

забавно

Вы можете написать свой Rejection Heandler

создатели акки, ну как так можно было то, должны же понимать

ладно пока этого хватает, всем спасибо

Вас смущает перенос строки?

лучше писать log.info("RECEIVED EVENT: [{}]”, x)

зря на акку наехал) это наш кривой код. тепрь всё ок

Таки всётаки скажите что вызвало у вас боль? перенос строки или то как формируется строка логгирования, Денис прав рекомендуется через {} передавать параметры в логирование

лучше писать log.info("RECEIVED EVENT: [{}]”, x)

в плее скорей всего scalalogging так что до лампочки

перенос строки это печаль

Да, это боль для ELK стека

сорри за глупый вопрос. В Play уже есть что-то, чтобы отдавать форматированный JSON без написания вручную Json.prettyPrint? Возможно какой-нибудь имплисит или что-то в этом роде

есть

у Controller'а это внутри, там импортить даже ничего не надо

эм… и как же? Если вручную, то так работает: implicit def writeableOf_JsValue(implicit codec: Codec): Writeable[JsValue] = { Writeable(a => codec.encode(Json.prettyPrint(a))) }

в DefaultWritables есть то что ты написал

так там Writeable(a => codec.encode(Json.stringify(a))), а нужно prettyPrint :)

ааа

ну тогда фиг знает, видимо ток писать самому

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

Полезно для разработки фронтенда. А то втыкаешь в json-лапшу, нифига не понимаешь и идешь форматировать каким-нить jq

Народ, а кто с DynamoDB работает? Посоветуйте нормальную либу для работы с ней. Просмотрел уже кучу всяких, но в каждой какой-то косяк. Требования у меня следующие - Асинхронная. - Простая, без сильной магии и всяких там scalaz. Хочется при возможности доковырятся до внутренностей либы без боли. - Поддерживаемая.

Полезно для разработки фронтенда. А то втыкаешь в json-лапшу, нифига не понимаешь и идешь форматировать каким-нить jq

есть расширения для браузера, форматирующие json автоматически

есть расширения для браузера, форматирующие json автоматически

Можно сделать переключатель в конфиге что бы на dev env отдавать pretty printed, а на проде компакт

как думаете, почему в Play есть GlobalSettings и ApplicationLoader - в смысле, почему эти классы не объеденены в один? Мне кажется логичным видеть весь их функционал в одном классе, а не в разных

deprecated GlobalSettings

антипаттерн

спасибо, тогда понятно

https://telegram.me/AndroidResId/65

там же android recipes. или релевантно тем не менее?

ребят кто использовал nondeterminism из scalaz; такой вопрос: допустим есть процесс тасков и все таски привязаны к пулу pool; используя по дефолту: nondeterminism.njoin(maxOpen = 8, maxQueued = 8) { process } ; вообще имеет смысл привязывать все таски к отдельному пулу? или не имеет (т.е. вроде njoin сам регулирует все)

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

Котаны, я на этой неделе разработчик бэкенда https://twitter.com/backendsecret приходите в каменты тереть за скалу.

круто)

Класс

Молодец. Несёшь, так сказать, в мир голос русскоговорящего scala-разработчика

Кто знает как останавливать работающую таску в сбт, не выходя из сбт?

Или может можно как-то заставить сбт обрабатывать ^C по-другому

Kill -9 JAVA

killall наверное, и это убьет сбт

re-start / re-stop ?

ERROR: S client not available

@tjugo не понял

О, я нашел

> val cancelable = SettingKey[Boolean]("cancelable", "Enables (true) or disables (false) the ability to interrupt task execution with CTRL+C.", BMinusSetting)

cancelable in Global := true

Правда оно не работает :D

бага есть, всисит открытая с 14 года

скала ван лав

sbt беспощаден к людским судьбам

ну, ничего удивительного для программы с "бэта" в названии

ctrc+c это провал в сбт. постоянная боль

*ctrl

Ну оказывается даже настройка от этого есть

ток не работает

я тоже год назад ее находил

может быть интерактивность sbt - это провал?

я знаю к чему это идет

мавен?)

sbt без интерактивности это тот же мавен или градле так что интерактивность это просто дополнительная плюшка

cancellable у нас работает, но надо указывать конкретную задачу. Только работает оно странно во многих ситуциях, особенно с тестами. Что ожидаешь, нажимая Ctrl-C, когда запускаются тесты? Прально, отмену запуска ВСЕХ тестов. Но "замечательный" SBT берет на себя слишком много, а именно: представляет интерфейс для тестовых фреймворков и ЗАСТАВЛЯЕТ их писать каждый тест как задачу в sbt. Из-за этого Ctrl-C вызывает отмену текущего теста.

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

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

Какая должна быть архитектура?

Создать пул из N акторов и они будут обрабатывать все запросы?

Или же

На каждый запрос от пользователя создавать новый актор?

И если создавать каждый раз актор, то как их потом удалить из системы?

Ведь они забьют память

Зависит от требуемого размаха, почитайте о akka consistent hashing pool или вот это http://doc.akka.io/docs/akka/current/scala/cluster-sharding.html

Судя по тому что вы пишите кластер шардинг ваш выбор

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

Ну например это рекламная система, и каждую секунду стучится по несколько десятков тысяч пользователей