Whenever I hit my application on Heroku for the first time (over a period of about 10 minutes), it fails. Something went wrong error. But a refresh, always fixes the problem? Any ideas what might be causing this? Thanks for your help!
If you are running with 1 dyno (the free way) then your dyno will shut down after some period of inactivity and get started back up upon the next request. So, when you leave it alone for 10 minutes it gets shutdown and tries to spin back up on that first request. That process is usually pretty fast and you will see a 3-5 sec startup lag but not enough to time you out.
Do you have anything going on during startup that would take a long time?
Also, if it is worth paying a little bit per month you can bump it up to 2 dynos and they will not spin it down on paid apps.
I was having the same issue when I added the compass framework to my application. In my error logs I was getting this error:
Errno::EACCES (Permission denied - /app/public/stylesheets/screen.css)
Following these instructions solved the problem
http://devcenter.heroku.com/articles/using-compass
To build on #Ben's answer, which is 100% correct, there's one issue: it doesn't seen you're getting a timeout error. The "Something Went Wrong" error indicates a 500 error, so your app is being loaded, but something is throwing an exception. If it only happens on the first request, then there is something that is being loaded/executed only on the first request which is causing the problem.
If this is the case, then to see the error, check your logs:
$ heroku logs
Or sign-up for an error-reporting add-on, like Exceptional (it's free!):
$ heroku addons:add exceptional
You can then access Exceptional from your Heroku dashboard for your app - once there, use the "Add-ons" menu in the upper-right.
This has happened to me on all my apps for the past couple years. I never was annoying enough to really figure it out until now.
In my logs on the first request, I get this: Errno::EACCES (Permission denied - /app/public/stylesheets/screen.css)
The second, and sequential, requests work fine without this error. I can't think of anything wrong with my screen.css file.
Related
My heroku app occasionally experiences long run times, on the order of 8 seconds (which is the trigger point to recieve email warnings about long response times). I originally assumed the issue was related to dyno sleeping, but our new production environment has redundant dynos, and shouldn't sleep.
The issue doesn't occur on any specific route -- even a route as simple as the 'ping' route used by the front-end to keep a session alive can produce it. I don't think it changes anything, but the latest example occured in an 'options' request -- and the followup request didn't experience any delay at all.
How can I further diagnose this issue? I've examined the logs around the request in question, there were few log entries in that time period, most chatter from the POSTGRES DB that -- if I'm reading it right -- was saying that it was up, running, and had no connections currently running code. For some reason, the request just... randomly... took forever.
I currently have my Rails app deployed on one heroku app and everything works fine.
I also have another version deployed on another heroku app.
When I try to deploy my updated code on the second app I get the error:
Application Error
An error occurred in the application and your page could not be served. Please try again in a few moments.
Here are the logs where I am getting an error. Sorry for the screen grab, no copy/paste.
EDIT: The app also works perfectly on local
Looks like you have having traffic which is more than current heroku dynos can handle. Increase that up, may be that will solve the problem. To find the exact problem use newrelic, it shows the request queuing time. If that time is big enough you should consider adding more dynos. The timeout also occurs when we have long running process in controller action. Use rake-timeout gem so if that process crosses the peak waiting time, you should get Rake::Timeout which you can rescue it somewhere and determines its backtraces.
Hope this helps.
I've been helplessly observing this problem for a couple months now, and have decided this is my best shot.
I'm not sure what the cause of the problem is, but I can list some of the things I'm doing. I have an iOS app that uses AFNetworking to connect to a remote server hosted by Google App Engine using HTTP POST requests.
Now, everything works great, but sometimes, very very sporadically and random, I get failed requests. The activity indicator spins and spins for about a minute, and I get no feedback at the end - just a failed request. I check my server logs, and I don't see any errors. After the failed request, I try again, and it works fine. It works fine for the whole day. And then another time randomly the issue repeats itself, sometimes spinning for 10 seconds with a fail, or a minute.
Generally, what can possibly be the cause of this? Is it normal to have some failed connections randomly? Is that something on my part?
But the weird thing is, is that while on my iPhone the app is running, and the indicator is spinning, and it's trying to connect, I try connecting on the iOS simulator, and the connection works just fine. I try again on the iPhone, and it doesn't work.
If I close the app completely and start again, then it works again. So it sounds like it may be a software issue rather than connection issue, but then again I have no evidence or data what so ever.
I know it's vague, but I'm hoping someone may have had a similar problem. Anything helps.
There is a known issue with instance start on GAE for Java. You can star http://code.google.com/p/googleappengine/issues/detail?id=7706 issue.
The same problem was reported for Python but it is not such a big problem.
I think you should check logging level you use on appengine and monitor all your calls. Instance start usually takes more time, so you will be able to see how much time do you use on start and is it really a timeout problem.
For Java version you could try to change log level to debug:
.level = DEBUG
in your logging.properties file. It will give you more information about instance start process.
We have a customer complaining about a long running request. I found the request in the production.log but am not sure how to dig deeper into figuring out why it took so long. Is there any artifacts in the log that I should look for?
Also the DB and View times don't add up to the total request time.
Try newrelic rpm. It can parse your logs and show you the slowest requests and a lot of other information. It shows live statistics about the app too. The trial should be enough for you to fix your application.
I am running a rails app on Dreamhost.
Today, a strange thing happened.
A page is almost loaded (it seems to be fully loaded but the status is not 'Done') and after that, the app didn't respond on any page.
I checked out the log and even the log was not complete.
How do I know it?
There are 3 missing images on the problem page and the log showed only 2 missing images and stopped there.
So I guess that something happened between the 2nd and the 3rd missing images.
I couldn't even start 'script/console production'.
After 14 minutes, it began to behave normally.
I asked the hosting company and they said that the process was killed due to over-use of memory.
Probably something was running heavily during the period.
The same thing happened one more time.
I had to kill the process to unlock the stucked app.
Passenger version is 2.2.4 and rails version is 2.3.2.
I am afraid that I can't give more specific info.
What do you guess cause such a problem?
Thanks.
Sam
As theIV stated, look at the last action called. Start this up locally and try to go through what was happening on the server to see if it's reproducable, or if you just get any sort of general hiccups. I've run Rails apps on Dreamhost for a while, and have not experienced this before, so I would guess that it's not Dreamhosts fault, but there is no 100% on that.
Good luck!
This sounds pretty app specific. I would start by looking at what action was last hit before the process started hoggin' and then work backwards from there to see if there are any calls that might be doing something you weren't expecting. Other than that, no clue. :(
Try using NewRelic RPM or TuneUp Lite to see what process is chunking most of your memory. You can run them locally but it would be better to test it on production.