Implement subscription timeout on the server side in HTTP triggering if request entity was not read in time

[ktoso]

Issue by jrudolph Thursday Aug 20, 2015 at 07:30 GMT Originally opened as https://github.com/akka/akka/issues/18274

---

See http://stackoverflow.com/questions/32085345/how-to-configure-akka-http-to-return-http-503-in-case-of-request-timeouts

Not sure which publisher timed out in that specific case but if we are able to return a 500 response we should be able to deliver a 503 as well.

/cc @sirthias

[jphelp32]

@jrudolph, is this still a non-solved issue today? If it's already been solved, or if there are workarounds, can you point me in the right direction? thanks

[jrudolph]

What's the issue you are seeing?

[jphelp32]

We're using akka-http 10.1.14 btw.

The issue we are having is that the response produced by the application appears to never be materialized. I'm having a difficult time reproducing it however. I think it is occurring in this order of events after the request is received:

1. client disconnects (assumed)
2. application produces a response and complete(response) is called (there's log evidence of this)
3. the 6hr server request timeout elapses (there's log evidence of this)

I wasn't able to find any code in the akka-http server that would indicate the server performs any automatic materialization of the response that passed to complete(). However, I'm also struggling to reproduce as I said, so something is materializing it in the scenario I described, some of the time. I know akka http client does auto-subscribe for the purpose of the subscription timeout. Idk what happens under the covers w/curl which is what I've been using to try and reproduce.

[jrudolph]

Yes, there is no guarantee that a response entity will be materialized. Not sure how the 6hr server request timeout is related, it shouldn't apply to a connection that has already been closed. If there was a bug in 10.1.x that connections might have stayed open even the client disconnected (unlikely), in any case, it might have changed with 10.2.x.

The expected outcome would be this:

• Client sends request
• Application starts processing request
• Client disconnects and all low-level connection processing is torn down
• Application completes response, which completes a future that is not tracked anywhere any more

[jphelp32]

@jrudolph thanks for the confirmation. That describes what we're observing. The caveat is that I don't really know for sure that the client has disconnected, rather than still connected but just never consuming the response. I mention the server request timeout b/c we do see evidence that the withRequestTimeoutResponse directive is executed at the 6hr mark when the request timeout duration is reached. Should I take that as evidence that the client connection is still active at that point? Either way, we can see that the application's response is never materialized, and that is the piece that is an issue for us and that I ultimately want to solve. Given your confirmation that indeed there is no guarantee the response entity will be materialized, I will want to implement that ourselves.