у редиса вроде как нет

хазел в принципе же на jvm по моему

да

и атомик референсами всё разруливается

ну кроме примитивов)

в общем странный выбор

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

Как раз

Ну и да, редис у нас раньше появился прост)

без сериализации/десериализации (ну по идее)

Ну и да, редис у нас раньше появился прост)

«исторически так сложилось» обычно просто говорят в таких случаях

сериализация там есть точно

а если на apache ignite глянуть и сравнить

Не надо

вопрос в том, наскок она эффективная

Это боль, половина фишек только в гридгейне работает

к примеру?

я прост не юзаю его

Норм умеет только key value

дык эт основная цель

Ну это просто такой комбайн

Редис лучше

Мы юзаем распределенные очереди

Они не оч

а с кафкой не сравнивали?

И не рекомендуется их в прод тащить самими разработчиками

кафка то здесь каким боком?

Для очередей

Кафка в каком ключе здесь сравнивается?

про очереди уже терки

посоны вы чо

Я не тестил

Тестили джобы

У нас кв нужно было чистить

Решили что джоба рядом данными круть

Но в итоге не оправдались ожидания

Ну и клиентское апи бывает странное, типа возвращает нул если не смог приконектится к ноде

Даже не эксепшен, Карл

прикольно, у hz совместимость с java collections)

а вот это не то же примерно для редиса? https://github.com/redisson/redisson

не юзал

никто, случайно, reactive-kafka не пользовался?

Юзаю ее для snowplow

Вместо kinesis

никто, случайно, reactive-kafka не пользовался?

А в чем вопрос?

вопрос в том, что producer этой самой реактивной кафки периодически пытается открыть ооочень много соединений с кафкой

сниппет или не было

раньше грешили на fork-join-pool с неограниченным по дефолту количеством потоков, поставили макс 64 потока вчера - сегодня история повторилась

Не встречал такого в проде

дело в том, что продюсер простой как палка. и в реактив кафке и в самой кафке

если есть воспроизводимый пример могу помочь

если есть воспроизводимый пример могу помочь

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

Ab?

cat /dev/zero?

ну там не просто поток рандомных байт, а конкретные пакеты, которые разбираются с akka-streams

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

А как в продюсер отправляются сообщения из каждого tcp коннекта? Через materialize консюмера или единый mergehub?

mergehub не используется

А как тогда происходит отправка в producer? Есть снипет?

вот как-то так val kafkaSink = Sink.fromGraph(GraphDSL.create() { implicit builder => { import GraphDSL.Implicits._ val recordProducer = Flow[TrackerMessage].log("to json") .map(elem => new ProducerRecord[Array[Byte], String](topic, elem.toJson)).log("to sink") val sink = Producer.plainSink(producerSettings) val input = builder.add(recordProducer) val output = builder.add(sink) input ~> output SinkShape(input.in) }

ERROR: S client not available

Он материализуется на каждый коннект?

val connections: Source[IncomingConnection, Future[ServerBinding]] = Tcp().bind(ip, port) def main(args: Array[String]) { connections runForeach { connections => connections.flow .joinMat(handlerGraph)(Keep.right).run() } }

он на выходе handlerGraph

совсем днище, да?(

эт тут чел так написал)

хех

Это еще цветочки.

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

val connections: Source[IncomingConnection, Future[ServerBinding]] = Tcp().bind(ip, port) def main(args: Array[String]) { connections runForeach { connections => connections.flow .joinMat(handlerGraph)(Keep.right).run() } }

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

ну и шейдить переменные не оч =) (rename connections)

да, есть косяк.

по поводу отдельных стримов - max-pool-size-max = 64 разве не должно было ограничить кол-во активных потоков?

так потоков (Thread) скорее всего и есть 64 а вот объектов RunnableGraph на каждый запрос по штуке

val connections: Source[IncomingConnection, Future[ServerBinding]] = Tcp().bind(ip, port) def main(args: Array[String]) { connections runForeach { connections => connections.flow .joinMat(handlerGraph)(Keep.right).run() } }

на каждый коннект, да. попробуй http://doc.akka.io/docs/akka/2.4/scala/stream/stream-dynamic.html#Using_the_MergeHub, который добавили в 2.4.10

там весь код в монадах, просто ты не заметил уже привыкаешь, это хорошо

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

так нужно смотреть правильные стримы: https://github.com/functional-streams-for-scala/fs2

и https://monix.io/docs/2x/intro/hello-world.html

А как в фс2 с такими штуками как результат материализации? Всякий киллсвитчи и прочее

по действию на строку - да.

а зачем?

лишние скобки

джавистами одобренно, надо тоже хэллоу ворлд сделать на мониксе)

на самом деле сравнение тут не оч объективное на акковских стримах тот же хэллоу ворлд будет почти аналогичен

в примере с проблемой, делался кастомный этап и цеплялся еще к серверу

не совсем понял почему хеллоу ворлд валидная метрика для продакшена

тогда лучше сравнить бизнесс задачу челеком, где уже и видно будет разница с джавой =)

тут не про джаву сравнение, а про либы стримовые