Простой неблокирующий HTTP-стек для Java

а тут пускаем кучу потоков, жрём память
Интересует и сервер

Представляем сервер работающий с реляционной базой, использован connection pool который держит 20 соединений с DB на готове для параллельного исполнения запросов. В случае синхронного сервер 1000 запросов породят 1000 потоков, 20 из них захватят по коннекшену и будут ожидать I/O, оставшиеся 980 будут ожидать разделяемого ресурса т.е. коннекшена с базой данных.

Асинхронный подход: 1 поток обрабатывает входящие соединения, 20 потоков весят с I/O wating. Итого 21 поток на обработку 1000 запросов.

Странно слышать от тебя такой вопрос. Чем не устраивает 5-й реактивный спринг на nio контейнерах?

В первую очередь интересен Android.

Чем не устраивает 5-й реактивный спринг на nio контейнерах?

/0

Спринг на андроиде? Серьезно?

Spring webflux использует Reactor, Reactor похож на RxJava, только последний не умеет ламбды т.к. заточен под андроид, где лямб на старые дроиды не завезли. Это мое поверхностное понимание.

Асинхронный подход: 1 поток обрабатывает всё, никто не висит с I/O waiting :) Правда если перестанет хватать одного потока, то станет сложней, но популярность ноды говорит, что это не такая уж серьёзная проблема.

Расскажи, где в спринге реализован асинхронный DNS? Как мне узнать IP-адрес linux.org.ru не блокируя поток и не запуская дополнительных потоков.

там же вроде как в принципе должны все экономить циклы

Экономить циклы нужно разве что на микроконтроллерах. Или в сильно вложенных циклах (pun unintended).

Ты определись, тебе нужен именно http под андроид или весь сетевой стек. Потому что классический dns как бы не поверх http работает, вот dns-over-http да, работает поверх http.

А так разве retrofit2 и okhttp недостаточно?

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

Почему бы для этой задачи не взять Go?

Ты определись, тебе нужен именно http под андроид или весь сетевой стек. Потому что классический dns как бы не поверх http работает, вот dns-over-http да, работает поверх http.

Мне нужно делать HTTP-запросы без блокировки. В реальном мире HTTP-запрос подразумевает DNS-разрешение, поэтому DNS это часть любого HTTP-стека, что ты прекрасно увидишь в любом адекватном API: ты туда можешь передавать имя сервера, а не только IP-адрес (честно говоря я даже уверен, что в подавляющем большинстве API ты IP и не сможешь передать отдельно от Host).

А так разве retrofit2 и okhttp недостаточно?

Так - мне и HttpUrlConnection или обёртки над ним в виде Volley достаточно. Но удивляет сам факт. Ладно бы в андроиде API было неполноценное, так нет, поддерживается там nio которое через select или poll будет работать, который в линуксе с бородатых годов прекрасно поддерживается. Зачем на крошечном телефончике пускать кучу потоков и городить кучу синхронизаций и межпоточных взаимодейтсвий, если можно было бы обойтись без этого.

С JDBC понятно, там особо вариантов нет кроме как выкидывать его и переписывать драйверы.

Может быть когда-нибудь и увидим в нашей жизни: https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ

netty?

Netty это Фреймворк для протоколов. Рабочий вариант, но хочется попроще чего-то, без абстракций над абстракциями. Просто реализующий HTTP/1.0 без лишних свистелок. Мегабайты жарок у нетти это многовато для такого простого протокола.

Вместо netty можно взять undertow, у которого есть http/1.1, http/2 и вебсокеты.

А, нет. Извиняюсь, «тред не читай @ сразу отвечай».

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

Перекидывая исполнение на другой поток, запустивший его поток всё-равно остается заблокированным в большинстве реализаций. Но да, ты это знаешь, а я зачем-то к словам придираюсь.
Действительно, про асинхронный DNS мне сказать нечего. Я в принципе с трудом представляю, как это может работать. Если только твой http клиент не будет нести свою реализацию для резолвинга доменов.
Без троллинга, мне правда интересно, ты же не just for fun интересуешься? Занимаешься микрооптимизациями, или что ты такое интересное пилишь?

Напишите сами, сколько там того http протокола, день два за кодингом
Вместо словоблудия на лоре

А что тут представлять? Обычный юдп запрос ответ через неблокирующие вызовы. Днс это же обычный протокол. Хз как вытащить серверы, которых спрашивать, видимо тут будет платформозависимый код, но это мелочи. Интересуюсь, потому что искренне не понимаю, почему так сделали (точней не сделали). Причём в новой платформе, которая вроде как могла выкинуть старый мусор.

На гитхабе смотрел https://github.com/search?q=asyn http ? Вот, мне сразу выдало https://github.com/loopj/android-async-http Вроде даже HTTP запросы асинхронные, про DNS не знаю.

Ой, это HTTP клиент... Но вот дальше https://github.com/koush/AndroidAsync вроде оно.

Вместо netty можно взять undertow, у которого есть http/1.1, http/2 и вебсокеты.

Для андроида думаю оверхед (а он там работает?), хотя я его в Pine64 с 1ГБ памяти планирую внедрять для петпроекта. А самсунг смарты с 12 ГБ рам поставляет и ядренный наверное на все 100500... Но это не нормально.

Первая ссылка - совсем не то.

An asynchronous, callback-based Http client for Android built on top of Apache's HttpClient libraries.
HTTP requests happen outside the UI thread
Requests use a threadpool to cap concurrent resource usage

Тот же Volley, только ещё хуже. А вот AndroidAsync надо посмотреть, спасибо.

А апачевскую MINA смотрел? Там вроде есть http-кодек из коробки.
Правда я им не пользовался.

Вот MINA не советую, у них большая проблема с разработчиками (считай их там нет), поэтому развитие там практически некакого. И она более высокоуровневая, чем тот же netty.

поэтому развитие там практически некакого

Ну судя по мейл-листу жизнь теплится.

И она более высокоуровневая, чем тот же netty.

Так это как я понял и надо. Человек не хочет самостоятельно реализовывать http поверх netty.

https://github.com/koush/AndroidAsync вроде оно.

В общем хорошо подумав я пришёл к выводу, что прям как я хочу, без поддержки разработчиков андроида видимо не сделать. Потому что мне надо вмешиваться в главный цикл и в нём постоянно проверять состояние сокетов. Если я просто буду это крутить нон-стопом, то это просто будет глупая нагрузка на CPU. Если я буду это постить с таймером (если вообще такое есть в андроиде), то соединения будут подлагивать как раз на задержку этого таймера, что не есть идеально. Единственный адекватный вариант это таки пускать второй поток и в нём уже крутить свой цикл по Selector-у. Собственно так этот AndroidAsync и работает. Пожалуй единственная существенная претензия к нему - он заточен под андроид. Если я захочу использовать общий код на сервере и на телефоне, это может быть затруднительно. Но это мелочи.

PS а где можно посмотреть реализацию этого самого главного цикла андроида? Может туда таки можно влезть как-нибудь?

можешь мой jweblib допилить