7

I see quite a few of these. I understand what they mean, which is why I can't understand why it is happening. Is very inconsistent, and does not appear to be a timeout issue.

Relevant stuff:

  • Php/laravel/Postgres Heroku
  • I force SSL
  • I route / to /anotherroute
  • I can't replicate with any client myself
  • The route is not always the same, sometimes a simple load of an asset
  • I have seen no application errors reported
  • sock=client
  • The service time is always < 1 second

Some log data:

Oct 29 18:22:12 myapp-web-production heroku/router: sock=client at=error code=H18 desc="Request Interrupted" method=GET path="/aroute" host=... request_id=... fwd="##.##.##.###" dyno=web.1 connect=2ms service=34ms status=503 bytes=3816

Oct 29 18:22:13 myapp-web-production heroku/router: sock=client at=error code=H18 desc="Request Interrupted" method=GET path="/aroute" host=... request_id=... fwd="##.##.##.###" dyno=web.1 connect=1ms service=538ms status=503 bytes=3822

Oct 29 18:22:14 myapp-web-production heroku/router: sock=client at=error code=H18 desc="Request Interrupted" method=GET path="/aroute" host=... request_id=... fwd="##.##.##.###" dyno=web.1 connect=1ms service=406ms status=503 bytes=13927

I'm stuck. Any help would be appreciated.

Community
  • 1
  • 1
Nick
  • 1,194
  • 1
  • 10
  • 18

1 Answers1

8

I take the sock=client attribute to mean that the client is just disconnecting before the server can respond. We can reproduce this by adding an artificial 10s delay to the handler and then, for example, requesting the endpoint in a web browser and closing it before the server can respond.

We just filter all H18s with sock=client out of our logs.

Riley Lark
  • 20,660
  • 15
  • 80
  • 128
  • 1
    That's the feedback I got from Heroku as well. Was just a bit surprising to see how many client disconnects given the response never takes more than 1000ms for any request. Thx for the answer. – Nick Nov 12 '14 at 04:50
  • @Nick: I'm also surprised at how many that is in our case. Did you ever dig deeper about this or did you just accept it and move on? I'm wondering about how to actually dig deeper there... – hendrikbeck Jan 06 '15 at 14:55
  • @hendrikbeck I just accepted it as we never got any reports of issues from users and never witnessed any issues myself. If I were to take time to investigate I would run a network diagnostic program like "Charles", throttle the connection and tail the log to try to reproduce the issue. It could be a simple as analytics (google, woopra etc) polling disconnect on loss of mobile network. – Nick Jan 06 '15 at 18:27
  • Is there a way to figure this out on code so that the app will retry the request? It happens sporadically on my login API and I want the app to automatically retry when this happens. – oky_sabeni Apr 25 '15 at 02:10
  • @Yko You should be able to detect disconnects on the client, and then retry from there. If this is really a client-side issue, then the server won't be able to retry anything - the client will have to. – Riley Lark May 03 '15 at 01:51