Ошибка Inappropriate blocking method call при http запросе в Kotlin. В чем проблема?

Question

[Сергей]

Изучаю корутины и возник вопрос. Набросал простую функцию для получения данных из сети. Но в Intelij IDEA выделяет желтым URL(url).openConnection() и выводит предупреждение "Inappropriate blocking method call"

Пробовал вызывать так

runBlocking { 
    getHttp("http://link.ru")
}

Ставил модификатор suspend для fun main - один фиг выделяет. В чем ошибка?

suspend fun getHttp(url: String): String {
    var txt = ""
    withContext(Dispatchers.IO) {
        with(URL(url).openConnection() as HttpURLConnection) {
            try {
                txt = inputStream.bufferedReader().readText()
            } catch (e:Exception) {
                e.printStackTrace()
            }
        }
    }
    return txt
}

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

Answer 1

[Денис Загаевский]

Когда ты так делаешь, весь смысл корутин теряется. Фишка в том, что когда корутина саспендится, поток не блокируется. А ты внутри корутины используешь блокирующий метод. Возьми другой http клиент, ktor, он, вроде как, умеет нормально это делать.

Comments

[Сергей]

Я примерно так и подумал. Но при подключении корутин более ранней версии такая ошибка не вылезает.
А если я не хочу использовать библиотеки сторонние, есть в Java асинхронный httpurlconnection? Или может стоит использовать в корутинах async await который возвращает Deferred?
Прошу прощения за такие вопросы, я просто второй день только ковыряю корутины, после основной работы.

[Денис Загаевский]

Сергей, возможно раньше линтер по-другому работал, а правила приезжают с либой. Не знаю точно. Async await это то же самое. Посмотри это.

[Сергей]

Денис Загаевский, Спасибо, почитал про HttpClient из java 11. думаю пригодится.

Answer 2

[Владимир]

Если по каким-то причинам нет возможности заменить блокирующий код неблокирующим аналогом (например, драйвер БД, для которого асинхронной версии просто не успели ещё написать), то можно использовать такое решение:
1. Создаёте отдельный тредпул
2. Все вызовы блокирующего кода оборачиваете в блок

suspendCoroutine { continuation ->
    //
}

3. Внутри этого блока создаёте Runnable, который и будет выполнять ваш блокирующий код. После выполнения блокирующего кода вызываете либо continuation.resume(result), либо continuation.resumeWithException(e)
4. Скармливаете полученный Runnable тредпулу.

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

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

Из очевидных минусов:

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

.

Насколько я помню, еще ~1.5 года назад примерно такая схема применялась в котлиновских обёртках над спринговыми драйверами то ли к монго, то ли к редису (там было 3 версии драйвера - блокирующая, реактивная, и блокирующая, но обёрнутая в отдельный тредпул, как я описал). Как сейчас - не знаю.

Comments

[Владимир]

Сергей, нет под рукой котлина, что бы набросать пример, но можете посмотреть вот тут (методы callStringDetail и callByteArrayDetail).

OkHttpClient все запросы выполняет в своём собственном тредпуле. В приведённом коде создаётся новый Request и отправляется в очередь на выполнение. Вместе с запросом дополнительно передаётся коллбек, который будет вызван, когда запрос завершится. В случае ошибки корутина будет возоблена с эксепшеном ConnectionException, а в случае успеха, она будет возоблена с полученным HttpResponse

Answer 3

[Fox Code]

Вот тут есть несколько решений - ссылка