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.
Related
I have a weird issue that just started popping up for our customers. The portal they've been using for years has started freezing on some of the pages that the user navigates to. I tried restarting the IIS Server, the site within and the Application Pool under which the site is site is running. No difference.
In Chrome Dev Tools I can see that it is always one of these three calls that take time to complete:
When it happens, one of those three calls will report that the request is not finished, like this:
When eventually the call completes, I can see that the Content Download took 3.8 minutes. Not sure whether it is relevant or not, but it is always 3.8 minutes:
Did anyone else encounter a similar situation? Is there a suggestion on how to figure out what is happening all of a sudden that triggers these type of behaviours?
TIA,
Ed
Edit: The resource that fails to load after 3.8 minutes always generates a net::ERR_CONNECTION_RESET error:
Edit2: Thanks to all of you trying to help. A little update: I was able to isolate to problem to an issue with the server not serving some of the files. either *.css or *.js. The setting is that of two identical servers placed behind a load balancer. Apparently, the load balancer software was recently updated and right after that we started having these issues. I am working closely with the IT department of our client, trying to figure out what is the impact of the newer version that seems to have triggered all this drama.
We have a web-app here that makes hundreds of calculations with money and other very specific numbers. It has been developed in Rails 3, which I have not much experience.
Recently, I have noticed that even in Digital Ocean server, where it runs for production, whenever an user requests to open some page for example, that does any query to get data from the database, everyone else gets stuck until the processing finishes.
It just looks like rails is running on a "single-threaded" mode, similar to running the same scenario with Tomcat in development mode in Eclipse.
Is there any trick to make it work "multi-threaded"?
I don't see any reason or even logic for it to run like this, there's no sense in making everyone wait until the request of another user finishes.
Thanks in advance to everyone!
Well, I've found the solution.
To enable Rails with WEBrick to work in a "multi-threaded" way, you'll have to simply go to the config file, and add :
# Enable threaded mode
config.threadsafe!
After that, restart the server and the trick is done. It "solved" my problem, but ended up creating a thousand others, cause the application wasn't developed thinking about a "threadsafe" scenario, which means, that everytime I try to run similar requests at the same time, the application mixes up everything in memory, crashing.
Well, one problem at once!
The original from this topic is solved.
Just wondering how everyone pushes updates to their production server on Heroku, without bringing the app down for a few couple of seconds?
Pushing to Heroku (especially using something like Unicorn), takes a while for the web app to load. Especially when there are end-users trying to access the site. They end up with 503 pages.It takes up to 30 secs to a minute for Unicorn processes to load.
There are TWO things you need to accomplish this, and it's not trivial.
1) Migrations need to be backwards compatible (i.e., run while the app is live). See this article about that: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/
2) Deploy using TWO heroku apps. I opened a ticket with Heroku on this topic and this was their reply:
We're currently working on a solution to provide a zero-downtime
deploy but do not have an ETA on when this might be available.
In the meantime a workaround that might be possible would be to deploy
to two separate apps. You can push new code to the second app, spin it
up, then move the domain names over to the second app. Wash and repeat
on the next deploy. This is less than ideal but might get you the
desired result in the interim.
If you do this, you will want to automate as much as possible since there's a lot of ways to mess that up. Here's an article on that topic: http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/
Why?
These two solutions must both be done because the database migrations must work in BOTH (live and to-be-live) versions of the code. Once you have that working, THEN you can solve the second problem of having the application itself not seem like it went down. There is no supported way to spin up and spin down individual dynos once a push is started.
UPDATE:
There is a beta feature available with Heroku now. To use do the following prior to pushing:
heroku labs:enable -a APP_NAME preboot
This will change the behavior of the app during pushes. It will push up a parallel instance that will warm up for two minutes. Almost exactly two minutes after the push, all traffic will route to the new app. Be careful with migrations, as I mentioned above, as they are still an issue.
Heroku is currently testing their new preboot feature in beta. You might wanna check it out. Unfortunately it only works for ≥2 web dynos. And it also doesn't seem to work for heroku scale web=… which would be important to make it work with HireFireApp.com.
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.
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.