Clearer semantics for idleTimeout on server

[rossabaker]

What should an idle timeout on the server do?

• Is it only when a request is active?
  • When is a request "active"? Once the request line is received?
  • Should we write anything if we timeout waiting for a request line?
    • A 408?
      • On initial connection, or on all subsequent connections?
  • Should we write anything if a request is active?
    • Could be a 408, if we're stuck waiting on more body.
    • Could be a 503, if we're stuck processing.
    • But how can we tell? This is more complicated than the server.
• Or is it how long we should keep a persistent connection? This is the current.
  • If so, our default is probably way too short.
  • If not, should that be a new setting, or should we rely on channel options?
  • All the same questions about what to write apply.

Discuss.

[pavulonx]

As far as i know timeout for idle connection in Play Framework is something around 2 minutes. Maybe change of the default value will be sufficient.

[ngbinh]

I have seen a bunch of when using http4s client (0.20.0-M3)

ondorAppServer 2018-11-14 23:27:39 ERROR [stargazer-service-system-akka.actor.default-dispatcher-8] [akka.actor.ActorSystemImpl(stargazer-service-system)] [Slf4jLogger.scala:69] - Error during processing 
of request: 'This stage 'IdleTimeoutStage' isn't connected!'. Completing with 500 Internal Server Error response. To change default exception handling behavior, provide a custom ExceptionHandler.          gondorAppServer java.lang.Exception: This stage 'IdleTimeoutStage' isn't connected!                                                                                                                          
gondorAppServer         at org.http4s.blaze.pipeline.Tail._stageDisconnected(Stages.scala:218)                                                                                                               
gondorAppServer         at org.http4s.blaze.pipeline.Tail.channelRead(Stages.scala:90)                                                                                                                       gondorAppServer         at org.http4s.blaze.pipeline.Tail.channelRead$(Stages.scala:85)                                                                                                                      
gondorAppServer         at org.http4s.blazecore.IdleTimeoutStage.channelRead(IdleTimeoutStage.scala:12)                                                                                                      gondorAppServer         at org.http4s.blazecore.IdleTimeoutStage.readRequest(IdleTimeoutStage.scala:35)                                                                                                      
gondorAppServer         at org.http4s.blaze.pipeline.Tail.channelRead(Stages.scala:88)                                                                                                                       gondorAppServer         at org.http4s.blaze.pipeline.Tail.channelRead$(Stages.scala:85)                                                                                                                      
gondorAppServer         at org.http4s.blazecore.ResponseHeaderTimeoutStage.channelRead(ResponseHeaderTimeoutStage.scala:13)                                                                                  
gondorAppServer         at org.http4s.blazecore.ResponseHeaderTimeoutStage.readRequest(ResponseHeaderTimeoutStage.scala:35)     

and the request actually fails with 500. Not sure if it is intended

[rossabaker]

No, this was reported on Gitter as well. This looks like a regression in M3.

[cquiroz]

Yeah, I'm seeing it too in M3

[rossabaker]

This ticket is about the server. Please open this as a separate bug to track.