на данный момент адекватных инструментов в яве-скале для обслуживания сотен исходящих запросов в секунду - нет

http://square.github.io/okhttp/ смотрели?

если нужны просто запросы к какому-то апи - пойдет любой клиент, который будет тебе удобен)

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

но если обходишь интернет, то на плюсах с курлом у меня даже самая плюшевая нода в сотню мегагерц и парой сотен рамы - работает с нагрузкой в 0-2% цпу и память вобще не ест, кроме как для буферов приема

А то вы сначала говорите, что ничего нормального нет. А потом, что подойдет что угодно.

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

То есть okhttp тоже этот критерий не удовлетворяет?

нет

Почему? Как тестировали?

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

И сколько rps показывает okhttp?

конкретно окхттп я не тестировал, да и по другим либам - я цифры даже не запоминаю, потому что мне достаточно теста и того, что я их выкидываю после этого. но окхттп не подойдет - как минимум потому, что это обычная клиентская библиотека ( client for Android ) которая явно не ставила перед собой цель - перформанс в промышленных масштабах. ее рпс будет зависеть от ресурсов цпу в первую очередь (если конечно у нее боттлнека, иначе и цпу не поможет)

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

Короче вы не пробовали, но уверены что оно вам не подойдет)

да. потому что за 10 лет я перепробовал в этом направлении очень много всего и в итоге все равно вернулся к курлу.

да. потому что за 10 лет я перепробовал в этом направлении очень много всего и в итоге все равно вернулся к курлу.

Facepalm

понимаешь, даже если эта библиотека сможет обеспечить то же кол-во рпс (тобишь забить полосу полностью), но при этом будет кушать цпу > 20% - мне это уже не очень подойдет

Ты иди сперва попробуй

Facepalm

??

Вообще нужно netty юзать

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

Дык юзай и как клиента

но клиентсайд у них ужасный - как у собаки пятая нога

В смысле

и неоптимизированный ужасно

Я все понял, спасибо

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

Никто случайно не работал с асинхронными ssh библиотеками под яву-скалу, которые хорошо многопоток держат и не используют heavy loading cpu и не устраивают сетевое слайдшоу?

ну и чтобы реализация ssh полноценная была, а не урезанная)

А есть такие?

https://github.com/eBay/parallec

Даже не видел такого, как мир меняется то, не все к jsch сводится

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

Jsch ж blocking

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

http://www.parallec.io/docs/api-overview/ - все таки все к jsch сводится)))

правда с документацией беда конечно((( по ссх похоже только этим ограничивается https://github.com/eBay/parallec-samples/blob/master/sample-apps/src/main/java/io/parallec/sample/app/ssh/SshApp.java

похоже на очередную узкоспециализированную обертку((

@notxcain я попробовал заимплементить на cats твой пример про Onion (2х дневной давности) http://scastie.org/22926 у меня собсвенно возникла проблема c транспайлером не понимаю какой по факту у нее должен быть тип, Lambda[TweetOp ~> Free[HttpOp, ?]] кайнд проджектором не понимается, ему нужно чтобы там была функция. а с просто (TweetOp ~> Free[HttpOp, ?]) тоже, что то не выходило val tweetToHttp: Lambda[TweetOp ~> Free[HttpOp, ?]] = new Lambda[TweetOp ~> Free[HttpOp, ?]] { def apply[A](fa: TweetOp[A])(implicit d: Decoder[Tweet]): HttpOp[A] = fa match { case GetTweets(userId) => HttpOp.get(s"user/$userId/tweets", d) } как все таки должно быть?

Lambda[TweetOp ~> Free[HttpOp, ?]] { case GetTweets(userId) => HttpOp.get(s"user/$userId/tweets", Decoder[List[Tweet]]) } превращается в new (TweetOp ~> Free[HttpOp, ?]) { def apply[A](fa: TweetOp[A]): Free[HttpOp, A] = fa match { case GetTweets(userId) => HttpOp.get(s"user/$userId/tweets", Decoder[List[Tweet]]) } }

https://github.com/non/kind-projector#polymorphic-lambda-values

http://square.github.io/okhttp/ смотрели?

Reading the response body may still block. OkHttp doesn't currently offer asynchronous APIs to receive a response body in parts.

Одно это уже делает конкретно в моем случае библиотеку неподходящей) Последствий у этого выше крыши)

@notxcain хм, new (TweetOp ~> Free[HttpOp, ?]) пробовал вроде бы, что то не пошло - ладно, еще раз попытаюсь

получилось вроде бы http://scastie.org/22948

только декодер у тебя странный

это что то типа io.circe.Decoder

ну я собстевенно не задумывался над ним, лишбы что то было пока меня вот другое волнует еще там в статье еще было такое: These interpreters can be composed horizontally, by feeding the output of one interpreter into a second interpreter, or vertically, by feeding values to two interpreters and then appending or choosing one of the outputs. то что у нас это вроде как горизонтальный случай а как вот осуществляется вертикальная композиция?

должна быть операция def zip[F[_], G[_], H[_]](g: F ~> G, h: F ~> H): F ~> Product[G, H, ?], где case class Product[G[_], H[_], A](g: G[A], h: H[A])

тогда ты можешь зипнуть основной интерпретатор с логирующим и потом заигнорить результат логирующего

я кажется только что сам ответил на свой вопрос к статье :))

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

я кажется только что сам ответил на свой вопрос к статье :))

)

повторите ссылку плиз на статью

http://degoes.net/articles/modern-fp-part-2

спс

@notxcain в cats чатике еще фигурировала по этой теме такая ссылка https://github.com/ProjectSeptemberInc/freek#onion-stack-of-monadstraverses ты не знаешь что это за проект такой, всмысле стоит на него внимательно смотреть или это что то сильно эксперементальное такое?

@notxcain в cats чатике еще фигурировала по этой теме такая ссылка https://github.com/ProjectSeptemberInc/freek#onion-stack-of-monadstraverses ты не знаешь что это за проект такой, всмысле стоит на него внимательно смотреть или это что то сильно эксперементальное такое?

Да хорошая либа, я с ней игрался и в ближайшее время буду юзать на работе. (там onion с onion architecture не связан, он там про контейнеры для результата)

сами чуваки которые ее пишут ее активно используют

так или иначе придется что то использовать для написания программ с использованием разных Free DSL

можно обойтись cats.data.Coproduct для начала

где то была статья

но смысл тот же

спасибо за развернутые разъяснения

ERROR: S client not available

всегда рад помочь

ну что, насколько у кого покрытие тестами выросло?

Меньше стало даже

тоже самое. нужно код удалять чтобы оно росло

а я пишу

В этом есть смысл

Одно это уже делает конкретно в моем случае библиотеку неподходящей) Последствий у этого выше крыши)

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

попробуй скачать одновременно 100 документов по 5 мегабайт при кол-ве оперативки 256мб

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

причем тут блокировка?

по памяти не влезешь)

Так я и прошу объяснить, в чем конкретно по вашему проблема

Так, а при чем здесь память. Там речь о том, что прочтение тела ответа синхронная.

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

asynchronous APIs to receive a response body in parts.

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

Ок, а как curl позволяет с этим справиться?

пришли пакеты - вызывается коллбек

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

и так по шаг за шагом - по мере получения пакетов

А что внутри коллбека делать если так только часть ответа?

*там

складировать в стрим, а стрим в файл

Интересно

А curl тоже вызывается из джавы в этом случае?

нет, на плюсах. на них писать почти ровно также как на яве, если не писать больших программ

А что за устройства?

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

А что за устройства?

??

попробуй скачать одновременно 100 документов по 5 мегабайт при кол-ве оперативки 256мб

я про это

Ну вообще при количестве оперативки в 256мб вообще сомнительна идея использовать jvm на всем этом