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

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

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

паррдон, должно быть безопасно

пытаюсь вспомнить, как же у меня sender оказывался в замыкании и с ходу не могу

да не, нормально же sender() сохранять в val

не нормально использовать sender() в коллбеке

но если есть возможность использовать pipeTo, то так и стоит сделать

Насколько нехорошо? Пытаюсь понять стоит ли бежать выпиливать это из остального кода

Вообще дофига кода видел, где так делают. Тоже интересно

не знал про pipe паттерн, он выглядит более идиоматично чем onComplete

спасибо i guess

не знал про pipe паттерн, он выглядит более идиоматично чем onComplete

Есть дока с примером?

http://doc.akka.io/docs/akka/current/scala/futures.html#Use_With_Actors

там очень лаконичный пример)

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

по вопросу тогда: стоит попробовать probe.send, вместо прямого вызова state.tell, иначе подставляется ImplicitSender - а он другой, в примере у них кейс несколько отличается: они сперва actorRefы передают

там очень лаконичный пример)

Хитро)

Вот такой вот грязный хак https://scalafiddle.io/sf/XllAWnj/4

@vpavkin

type dependent types ? ))

Ну по размеру кода не так уж страшно)

Доброго дня всем! :) Может кто посоветовать что-то для анализа и обработки логов? Есть желание их куда-нить отправлять где уже будет приниматься решение о том бить тревогу или не бить и вообще иметь там красивую статистику и прочее.

elk

+1 ELK https://www.elastic.co/webinars/introduction-elk-stack

datadog

как вариант )

@notxcain А это разве не частный случай Unapply, которым partial unification делали до фикса Майлса?

datadog

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

Ну кстати да )

Похоже на то

и вообще есть такая крутая штука https://prometheus.io/ для полного мониторинга

@ktimothy а у нас норм живет

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

в 4й графане кстати добавили алертинг

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

+1 ELK https://www.elastic.co/webinars/introduction-elk-stack

эм... смотрю но пока не очень понимаю... а что оно может то?

логи индексировать

кибана графики строить

Блин а может всетаки сделать сайт с нормальным форумом, где по темам можно смотреть ответы, а то тут сходил на обед а уже 160 сообщений, 80% которых простой флуд

но у нас например графана вместо ея

и вообще есть такая крутая штука https://prometheus.io/ для полного мониторинга

а что оно может? мне ведь надо не просто мониторить но еще и анализировать?

точнее графит с графаной

Блин а может всетаки сделать сайт с нормальным форумом, где по темам можно смотреть ответы, а то тут сходил на обед а уже 160 сообщений, 80% которых простой флуд

да форум то не проблема, но там сидеть никто не будет

вово, стековерфлоу есть для ответов же

эм... смотрю но пока не очень понимаю... а что оно может то?

https://www.elastic.co/products/kibana глянь сюда, там можно много чего сделать при желании

а что оно может? мне ведь надо не просто мониторить но еще и анализировать?

еластик нужен для хранения и индексации логов, логстеш собирает их(например logback умеет заливать логи прямо в логсташ), кибана умеет отображать и реагировать на события(но это можно и самому допилить)

можно и графану юзать вместо кибаны

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

по опыту логов обычно дохрена

для алертов поверх ELK есть elast_alert

для метрик нужен сервер отдельный да

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

Это правда, у нас были проблемы с перфомансом, пока не задеплоили хорошо

Хм... а сколько вообще машин нужно что бы нормально был деплой/тестирвоание/хранение/продакшн/логи(что еще забыл?) и в общем всё это дело?)

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

так же кучу места на жестком нужно будет

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

Примерные требования можно? И насколкьо правильно хранить исходники на той же машине на которой проводятся тесты?

неплохо бы один сервак под метрики и 1-2 под CI

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

отдельном от продакшна

Примерные требования можно? И насколкьо правильно хранить исходники на той же машине на которой проводятся тесты?

У нас ELK крутится на m3.large машине на AWS и подключено еще около 60 Гб EBS хранилища

тестирование делается в CI когда проект собирается в прод

тестирование делается в CI когда проект собирается в прод

это я знаю, но насколько верно на этой же машине держать тот же gitlab?

а ну то разное тестирование

да пофиг если машина мощная

бекапы все равно хранить нужно

одно дело прогнать тесты, другое дело прогнать через задплоенное тестеров :)

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

а ты говоришь о ручном

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

ERROR: S client not available

а то навернется что нибудь и куку

еластик нужен для хранения и индексации логов, логстеш собирает их(например logback умеет заливать логи прямо в логсташ), кибана умеет отображать и реагировать на события(но это можно и самому допилить)

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

и у логстеша, и у логбека есть интеграция с кафкой

ну это уже если у вас логи сами по себе бигдата :)

у нас например напрямую валится

хотя наверное если везде врубить loglevel debug то и будет бигдата :D

логи обычно становятся биг датой раньше самих данных )

ну не, если логать warn

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

Какие графики принято строить по логам? Хиты, пятисотки итп? Не проще/дешевле ли сразу метрики кидать в графит?

вот да, графит у нас для такого больше

у нас все графики завелись постепенно, когда понадобилось отвечать на вопросы из сапорта: response times, 5xx ошибки и т.п. Пока не понадобится, я бы не стал заморачиваться. Их легко построить какие угодно, если сами логи есть.

да форум то не проблема, но там сидеть никто не будет

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

Я знаю что будет с каналом "строго про скалу"

ггг

да

ну согласитесь сечас есть некоторый перебор тут с офтопом

имеет смысл конечно сам по себе слак) типа как у опен дата сайнс там флуд и филтровать можно и каналы менять однако некоторые каналы абсолютно мертвые но у скала чата слак не взлетел :o

Согласен, что с оффтопом перебор

ну согласитесь сечас есть некоторый перебор тут с офтопом

подумаешь, немного котлина в скала-чяте

Но сообщество живое, и я считаю более менее здоровое, это важнее чем общение на строго определённые темы

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

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

А там захотят по чату на каждый фреймворк.

Хотите больше скалы - отвечайте на вопросы по скале

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

Так они уже всю работу автоматизировали, скучают

в общем, нормально у нас все. оффтоп бывает, но прекращается так же быстро, как начинается. пижонства тоже нет, что кул

подумаешь, немного котлина в скала-чяте

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

</kotlin-discussion>

Посоветуйте redis драйвер пожалуйста. Нужно достаточно интенсивно работать с мепами, и делать часто очистку полную

http://redis.paluch.biz/