Nullpointer exception from Blaze pipeline
Hey.
We are having this error pop up in our log every now and then using http4s 0.20.11.
Exception in thread "pool-8-thread-1618" java.lang.NullPointerException
at org.http4s.blaze.pipeline.MidStage.removeStage(Stages.scala:351)
at org.http4s.blaze.pipeline.MidStage.removeStage$(Stages.scala:345)
at org.http4s.blazecore.IdleTimeoutStage.removeStage(IdleTimeoutStage.scala:12)
at org.http4s.blazecore.IdleTimeoutStage$$anon$1.run(IdleTimeoutStage.scala:30)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Any pointers to what we might be doing wrong, or what is actually happening?
I am happy to answer if there is any other information needed that could be relevant.
Hi @amumurst Are you using BlazeClient or BlazeServer, HTTP1 or HTTP2? Do you have any custom code manipulating Stages directly? Do you have any custom setup regarding blaze's scheduler?
Would it be possible for you to run the application with org.http4s.blazecore and (org.http4s.client.blaze or org.http4s.server.blaze) loggers on DEBUG level, and share with us the logs around this exception?
@amumurst Do you have any more information?
Sorry, seems like my github notifications went to spam..
We did "fix" it for our use case some time ago. There was a config-error in our BlazeClient on our part. We basically had:
BlazeClientBuilder[IO](ec)
.withConnectTimeout(500.millis)
.withIdleTimeout(500.millis)
.withResponseHeaderTimeout(500.millis)
.withRequestTimeout(500.millis)
.resource
which resulted in this at startup
[ WARN] 15:38:17 [pool-18-thread-1] responseHeaderTimeout (500 milliseconds) is >= idleTimeout (500 milliseconds). It is recommended to configure responseHeaderTimeout < requestTimeout < idleTimeout or disable some of them explicitly by setting them to Duration.Inf. []
[ WARN] 15:38:17 [pool-18-thread-1] requestTimeout (500 milliseconds) is >= idleTimeout (500 milliseconds). It is recommended to configure responseHeaderTimeout < requestTimeout < idleTimeout or disable some of them explicitly by setting them to Duration.Inf. []
After making some changes so that the numbers in the timeouts made more sense, the null pointer stopped appearing too.
I'm glad your issue is fixed, but that still seems buggy that bad timeout configurations can lead to NPEs instead of the wrong kind of timeouts firing.