FutureAsyncHttpClientHandler hangs the application about sttp HOT 9 CLOSED

Another way to keep AsyncHttp from blocking jvm shutdown is to pass in your own thread factory to the netty timer and make the timer thread a daemon thread.

See also apache/druid#5076

Example config:

  private def defaultClient(options: SttpBackendOptions): AsyncHttpClient =
    new DefaultAsyncHttpClient(
      new DefaultAsyncHttpClientConfig.Builder()
        .setConnectTimeout(options.connectionTimeout.toMillis.toInt)
        // use a daemon thread for the netty timer
        // see also https://github.com/apache/incubator-druid/pull/5076
        .setNettyTimer(new HashedWheelTimer(new ThreadFactoryBuilder().setDaemon(true).build()))
        .build())

from sttp.

Try calling handler.close.

from sttp.

As @aeons mentioned, I think you need to close the handler as well. Could you paste your full example?

Also, instead of creating a custom ExecutionContext, you can use the global one by importing ExecutionContext.Implicits.global

from sttp.

I think I'm running into something similar:

import com.softwaremill.sttp._
import com.softwaremill.sttp.okhttp._
import scala.concurrent.Future
import scala.concurrent._
import scala.concurrent.duration._

object Evaluate extends App {
  implicit val handler = OkHttpFutureHandler()

  val response: Future[Response[String]] =
    sttp
      .post(uri"http://localhost")
      .send()

  println(Await.result(response, 500.millis))
}

This prints the expected response, then hangs:

• for ~= 60 seconds before quitting
• forever if I swap okhttp out for async handler (in its Future mode)

from sttp.

At the suggestion of @aeons , I've added a hander.close call at the end:

• ok http: nothing changes
• async http: it takes a while to close, but it does (about 4 seconds on my local computer)

from sttp.

Indeed, however this only happens for OkHttpFutureHandler. When using OkHttpSyncHandler, the app finishes immediately

from sttp.

I think with async http client taking 4 seconds to close - not something we can influence, sttp is just calling the client's close() method. I suppose terminating and joining all the threads for some reason takes up so much time.

from sttp.

This is caused by the internal dispatcher of OkHttp, which is used only for async operations, like OkHttpFutureHandler and OkHttpMonixHandler. I just created a PR #32 that fixes this

from sttp.

OkHttp should be fixed in 0.11. AsyncHttp should use close() :)

from sttp.