Akka http + circe

Нужен Client со своим пулом конекшенов

Какой пул, если он non blocking?

Или ты про пул коннекшнов?

Или ты про пул коннекшнов?

да про него

Akka HTTP Host-Level Client-Side API - лучший выбор в этой ситуации ?

host connection pool не то, чтобы прям самый высокоуровневый

host connection pool не то, чтобы прям самый высокоуровневый

А что тогда ?

А что тогда ?

ну singleRequest самый

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

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

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

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

его и HCP точно так же легко переполнитт

его и HCP точно так же легко переполнитт

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

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

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

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

если ты делаешь сразу много запросов, то там падает с max connection pool бла бла, я переписывал сингл реквесты на стримы, чтобы работало

если ты делаешь сразу много запросов, то там падает с max connection pool бла бла, я переписывал сингл реквесты на стримы, чтобы работало

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

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

может мы о разных вещах, но со стримами не падает в моих юз кейсах

Задача подразумевает много медленных GET запросов

может мы о разных вещах, но со стримами не падает в моих юз кейсах

ааа ну тогда прости, я не сразу понял, что весь наш диалог о твоих юзкейзах

ааа ну тогда прости, я не сразу понял, что весь наш диалог о твоих юзкейзах

извинения приняты

т.е. есть и ситуации, когда будет валиться с HCP и тогда нужно переписывать на connection level

поэтому одно и называется более высокоуровневым, чем другое. A реализовано поверх B, но всегда есть Александр, у которого юзкейзы сложнее, поэтому ему нужно закопаться поглубже в грязь

Вот например, Александр "Никпавлов" Собака, который закопал свои руки в netty

/toxic-morning

toxic friday

/toxic

Задача подразумевает много медленных GET запросов

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

Из одного куска

Из одного куска

Ну тогда естественным образом напрашивается HCP

Один кусок отвечает за взаимодействие с HTTP API

Один кусок отвечает за взаимодействие с HTTP API

если у тебя есть сервер, и тебе приходит кучища запросов

то каждый запрос - независимый кусок, только если у тебя там же нет low level akka http server или чего-то другого стримового

если же у тебя условно говоря high level, то твой сервер сам будет ограничивать количество одновременно обрабатываемых запросов, и это ограничение автоматически устанавливает нижнюю границу для настроек host connection pool а

если у тебя есть сервер, и тебе приходит кучища запросов

У меня Клиент, я из него дёргаю много серверов GET запросами (каждый выполняется около 0.8-1.2 сек)

У меня Клиент, я из него дёргаю много серверов GET запросами (каждый выполняется около 0.8-1.2 сек)

ну тогда игнорируй меня, и послушай @tvaroh

если же у тебя условно говоря high level, то твой сервер сам будет ограничивать количество одновременно обрабатываемых запросов, и это ограничение автоматически устанавливает нижнюю границу для настроек host connection pool а

Да вот такой вариант мне подходит, это Akka Http Connection-Level или Akka-Http Host-Level ?

второй

ок спасиба

Короче разница такая - connection level - на кажду материализацию создаётся новый коннекшон, в течение его ты можешь делать что хочешь внутри этого подключения. Ответы приходят согласно протоколу. В случае HTTP 1.0\1.1 они будут приходить в том же порядке, что и запросы. Количество подключений задаёшь сам делая там какие-то суб-стримы или flatMap ы внутри своего стрима. host connection pool - на уровне actor system в http плагине есть пул, который используется каждый раз, где-бы ты не материализовал пул. ты можешь запустить много запросов, количество одновременных не выростет больше нужного. Ответы приходят в произвольном порядке, чтобы ты потом мог понять на что идёт запрос, можешь прокинуть вместе с запросом любой объект, он придёт с ответом в качестве метки. Запросы, ждущие подключения, выстраиваются в буфер, когда он переполняется стрим начинает бэкпрешшить. Очевидно, если бэкпрешшить некуда, кидает эксепшоны. single request - возвращает простую фьючу, это просто единичный материализованный стрим из host connection pool. Бэкпрешшить некуда, поэтому если запросов отправлено слишком много - падает

так если к каждому серверу 1 запрос, то можно и singleRequest

да, host connection pool - один pool на domain name/protocol

отличный ликбез, Олег!

да, host connection pool - один pool на domain name/protocol

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

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

т.е. ты хочешь послать запрос на google.com, но хочешь для этого использовать уже открытое соединение для yandex.ru ? Боюсь, есть сложности с этим

)) я понял Похоже нужно смотреть в сторону singleRequest

host connection pool можешь просто открыть несколько штук для всех серверов, что у тебя есть

https://doc.akka.io/docs/akka/current/stream/stream-substream.html#groupby

т.е. ты хочешь послать запрос на google.com, но хочешь для этого использовать уже открытое соединение для yandex.ru ? Боюсь, есть сложности с этим

Погоди, но HTTP протокол же не держит открытым соединение, отправил и закрыл, или нет ?

Погоди, но HTTP протокол же не держит открытым соединение, отправил и закрыл, или нет ?

HTTP 1.1 держит

HTTP 2.0 держит

в этом, в общем-то и весь замут

https://en.wikipedia.org/wiki/HTTP_persistent_connection

Спасибо Олег, вобщем буду думать singleRequest VS host connection pool per serverAPI

singleRequest можно же выполнить прямо из актора ?

вполне, получишь future

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

ой

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

кажется, наши интеграционные тесты показывали, что с ЧСВ-акторами тоже работает

ЧСВTestKit?

Вот например, Александр "Никпавлов" Собака, который закопал свои руки в netty

Ну че ты начинаешь то

Спасибо Олег, вобщем буду думать singleRequest VS host connection pool per serverAPI

а большая планируется нагрузка?

а большая планируется нагрузка?

не очень, это бот для трейдинга на криптобиржах ) RPS ограничен со стороны биржи (1 запрос в сек) 10-20 бирж

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

А ха ха ) Те несколько проектов на акторах которые я видел, там либо акторы несильно нужны, либо их криво используют.

А ха ха ) Те несколько проектов на акторах которые я видел, там либо акторы несильно нужны, либо их криво используют.

ЧСВ тест подразумевает в акторе наличие изменяемого состояния (var или become) :)

Или location transparency

ERROR: S client not available

Mutable state - имхо недостаточная причина юзать акторы

ЧСВ тест подразумевает в акторе наличие изменяемого состояния (var или become) :)

val a = 2 //... becomeVar(a) a = 3 // now legit

Mutable state - имхо недостаточная причина юзать акторы

Почему ?

я знал, что придёт Олег, и всё ... улучшит

Почему ?

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

Другие, более простые средства

Всегда есть другие средства

Другие, более простые средства

Опять адепт го пришел?)

Ты с кем то меня спутал ?

Другие, более простые средства

Какие ?

Какие ?

Really? ?

Mutable state - имхо недостаточная причина юзать акторы

если стэйт атомарен - может быть, а если размазан по акторам, но вполне :)

Behaviors.defer( ctx => @volatile var become = MVar(new AtomicReference(2)) ... )

если стэйт атомарен - может быть, а если размазан по акторам, но вполне :)

А какую проблему могут решить акторы в этом случае лучше чем AtomicRef например?

А какую проблему могут решить акторы в этом случае лучше чем AtomicRef например?

лучше чем N AtomicRef в смысле? Ну они могут динамически создаваться и т.п.

ща Олег правду скажет всю

А какую проблему могут решить акторы в этом случае лучше чем AtomicRef например?

ну ты не можешь ставить в очередь обработки атомиков, если состояние достаточно волатильно, твои CAS внезапно начинают фэйлиться в 99% случаев...

не очень, это бот для трейдинга на криптобиржах ) RPS ограничен со стороны биржи (1 запрос в сек) 10-20 бирж

один мой любимый гений актьрных архитектур, сделал отдельный пул для внешних http ресурсов и запускает там 1 актор на 1 реквест, используя синхронный http клиент, на не больших нагрузках работает

один мой любимый гений актьрных архитектур, сделал отдельный пул для внешних http ресурсов и запускает там 1 актор на 1 реквест, используя синхронный http клиент, на не больших нагрузках работает

звучит как slick

ну значит это best practice

один мой любимый гений актьрных архитектур, сделал отдельный пул для внешних http ресурсов и запускает там 1 актор на 1 реквест, используя синхронный http клиент, на не больших нагрузках работает

ботлнек детектед

ну ты не можешь ставить в очередь обработки атомиков, если состояние достаточно волатильно, твои CAS внезапно начинают фэйлиться в 99% случаев...

Тогда pessimistic lock в помощь

Тогда pessimistic lock в помощь

это который лочит тред?

Как и актор?

актор и есть pessimistic lock

Как и актор?

нет

актор не лочит тред между сообщениями

А про "между" я и не говорил

т.е. я не фанат акторов, но опускать их до атомиков...

хоть бы мвары вспомнил

А про "между" я и не говорил

но тебя именно между и интересует

ботлнек детектед

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