Http4s: blaze-server error logs on shutdown

Created on 4 Feb 2019  路  5Comments  路  Source: http4s/http4s

Using 0.20.0-M5 blaze-server via the BlazeServerBuilder.

On shutdown I can find the following entries in my logs.

ERROR org.http4s.blaze.channel.nio1.NIO1HeadStage - Abnormal NIO1HeadStage termination
java.nio.channels.ShutdownChannelGroupException
at org.http4s.blaze.channel.nio1.SelectorLoop.killSelector(SelectorLoop.scala:224)
at org.http4s.blaze.channel.nio1.SelectorLoop.org$http4s$blaze$channel$nio1$SelectorLoop$$runLoop(SelectorLoop.scala:184)
at org.http4s.blaze.channel.nio1.SelectorLoop$$anon$1.run(SelectorLoop.scala:67)
 at java.base/java.lang.Thread.run(Thread.java:844)

ERROR org.http4s.server.blaze.Http1ServerStage$$anon$1 - Fatal Error: Error in requestLoop()
 java.nio.channels.ShutdownChannelGroupException
at org.http4s.blaze.channel.nio1.SelectorLoop.killSelector(SelectorLoop.scala:224)
at org.http4s.blaze.channel.nio1.SelectorLoop.org$http4s$blaze$channel$nio1$SelectorLoop$$runLoop(SelectorLoop.scala:184)
at org.http4s.blaze.channel.nio1.SelectorLoop$$anon$1.run

This happens during an integration test for which the server is shutdown while the client side is still running (blaze-client).

The server is running with the default configuration.

BlazeServerBuilder[Task]
    .bindHttp(port, interface)
    .withoutBanner
    .withHttpApp(myRouter)
    .resource
    .use(...)
bug

Most helpful comment

@agourlay Doesn't BlazeServerBuilder[Task].withNio2(true) solves the problem?

We had the same issue in our tests with a WebSockets http4s server and it went away with the above option.

All 5 comments

This is not fatal, but is unacceptably noisy. I'd still like to squash this.

@agourlay Doesn't BlazeServerBuilder[Task].withNio2(true) solves the problem?

We had the same issue in our tests with a WebSockets http4s server and it went away with the above option.

@igor-ramazanov I just gave it a try and you are correct; the stacktraces are now gone!

Thanks a lot for the tip 馃檱

A long, long time ago, nio2 didn't do as well as nio1 on benchmarks. I don't remember it being hugely different, but it's the reason that nio1 remained the default. If you're in a high load situation, it may be worth a round of performance testing.

@rossabaker thanks a lot for adding this important precision 馃憤

Performance is not critical for my use case therefore I am fine switching to nio2.

Was this page helpful?
0 / 5 - 0 ratings