When we are deploying new code to Heroku we are often finding the first request (or couple) to hit get an application error back. After that everything runs fine.
They appear to be request timeouts:
2012-06-19T21:54:42+00:00 heroku[router]: Error H12 (Request timeout) -> GET www.mydomain.com/ dyno=web.2 queue= wait= service=30000ms status=503 bytes=0
We are using 'unicorn' with 3 processes if that has any possible connection (yes I should probably just run a test myself, but since it's intermittent and hard to pin down I'm hoping others have seen this.). Perhaps increasing the unicorn timeout value will help avoid this but I'm wondering if there is a way to deploy that doesn't result in such large delayed responses after deployment for the first few clients.
Indeed there is such a way to get deploy that may avoid this problem. You can use the Heroku preboot labs feature.
Also check out this Dev Center article on dealing with H12 request timeouts.
Related
Whenever a request times out to a dyno, it's automatically retried. Looks like it's managed by the dyno according to this article https://devcenter.heroku.com/articles/http-routing. How can I set/change this setting myself?
It's not possible to modify the behaviour of the router. If you need certain requests to be refused for whatever reason, this logic would need to be carried out within your application.
Details on how Heroku's routing works is available in the Dev Center article: HTTP Routing. The section on Dyno connection behavior on the Common Runtime is probably most relevant to your question.
PS: This was the response of heroku support when I raised a ticket for same issue.
It's a Node.js app serving a React app. I'm using free dynos so the app should sleep after not receiving any request, but it seems to be always on. I checked the billing on Heroku and it's consuming a significant amount of hours.
I would be fine waiting for the app to load up, but it won't sleep. Perhaps it has something to do with socket.io constantly pinging the server while no client is connected?
I only find topics on how to prevent sleeping, totally opposite of my intention. I also have another socket.io app on Heroku, but that one does sleep like expected.
Edit: The app logs tell that there are two socket connections made at the same time every 30 minutes, my app seems to be pinged by a pinger. How to stop unknown pinger?
My Heroku app was actually being pinged by a pinger. I freed the app from the pinger by changing the app name. Isn't it bad that anyone can add an app to a pinger and the publisher has to change the app name?
I have a video that is about 2 minutes long and 6.32MB in size. When I run a local server (using Python), the video loads just fine. However, when I try opening it on my website (hosted on Heroku), the video does not load.
This is the associated Heroku log:
sock=client
at=warning code=H27 desc="Client Request Interrupted"
method=GET path="/video.mp4" host=somewhere.com
dyno=web.1
connect=0ms service=26ms
status=499
bytes=
protocol=http
This StackOverflow answer states,
HTTP 499 in Nginx means that the client closed the connection before
the server answered the request. In my experience is usually caused by
client side timeout.
Heroku's description of the 'H27 - Client Request Interrupted' error is,
The client socket was closed either in the middle of the request or
before a response could be returned. For example, the client closed
their browser session before the request was able to complete.
What does this mean in terms of Heroku? What can I do so that my video loads?
The solution seems to be to host the video elsewhere =/
From this page,
There are two approaches to processing and storing file uploads from a
Heroku app to S3: direct and pass-through.
Direct upload
This is the preferred approach if you’re working with
file uploads bigger than 4MB. The idea is to skip the hop to your
dyno, making a direct connection from the end user browser to S3.
I am running a rails application on Heroku. I've been getting H12 Request Timeout Errors every few hours as such:
heroku/router: at=error code=H12 desc="Request timeout" method=GET path="/assets/application-c280172e4ef44cbe29d1fc72c6dfcd00.js" host=www.justvacay.com request_id=8e570b7c-0470-47b7-9f3b-41c1158b448d fwd="66.249.79.111" dyno=web.1 connect=4ms service=30005ms status=503 bytes=0
This started happening after I installed unicorn-worker-killer.
Does anyone know how to fix this?
Heroku doesn't process HTTP requests for over 30seconds, so if you are trying to host an application that does a heavy duty task (for instance, access a working API or something else that takes a long time) it is best to create worker dynos that can do the heavy coding in the background.
Here are the steps to do this:
https://devcenter.heroku.com/articles/background-jobs-queueing
Another (potential) solution would be to go into the application that is taking a long time and create sessions within every function to avoid having heroku time running out. Here is an example on how to do this:
https://help.heroku.com/AXOSFIXN/why-am-i-getting-h12-request-timeout-errors-in-nodejs
This is not 100% guaranteed to work though.
Hope that this is helpful and good luck!
I'm trying to diagnose an issue whereby an embedded device running an HTTP client to issue requests to a Node.js Web application running on Heroku is receiving empty responses with status code 400.
The problem I'm facing is that the presumably failing requests do not even appear in the Heroku logs, so it's certainly not the Web application code returning those 400s.
On the other hand issuing requests to the Web application from a browser works just fine and the requests do appear in the Heroku logs.
I'm trying to figure out whether the embedded client is really sending requests at all and I'm wondering if there are any reasons why Heroku might send back those 400s without the requests even appearing in the logs.
The cause was related to a badly implemented HTTP client in the device that was issuing requests omitting the host header.
Adding the header solved the problem.