I recently switched from Heroku's Bamboo stack to the Cedar one (Rails 3.1.4, Ruby 1.9.2, Thin gem for web server). Since then I keep getting 500 errors such as this, where it seems that the query is not acting right:
207 <13>1 2012-05-06T16:10:51+00:00 d. app web.1 - - ActiveRecord::StatementInvalid (Mysql::Error: : SELECT `foos`.* FROM `foos` WHERE `foos`.`id` = ? LIMIT 1)
It's not an error in the code though because the page eventually renders successfully (ie status 200) when I refresh the page. Sometimes it is 1 refresh, but can get up to 4 refreshes before I get a 200.
I thought it was the database because I was on ClearDB's free plan, but I upgraded to ClearDB's next plan with better I/O performance and it still happens
this never happened when I was on Bamboo
it happens on just about every page that does queries on the DB
it doesn't always happen, but I'd say it happens on at least 1 in 5 pages views
the model/query doesn't matter, the same error occurs (just indicating a different model/fields then the example above)
Do you get the same errors if you are in console heroku run console ? I've never seen this before. Try upgrading your Mysql gem, which one are you using http://api.rubyonrails.org/classes/ActiveRecord/StatementInvalid.html i think the correct one is mysql2 https://rubygems.org/gems/mysql2
Related
I am currently running capybara specs that test different functionality of an app. When running my specs, it appears that the page is not being reached fast enough to test. I have three specs currently, and it takes 9 minutes to end up having them all fail with this same error. Here is the result of running the specs
Randomized with seed 38457
Capybara starting Puma...
* Version 3.11.4 , codename: Love Song
* Min threads: 0, max threads: 4
* Listening on tcp://127.0.0.1:50109
FFF
Failures:
1) Successful source is created
Got 0 failures and 2 other errors:
1.1) Failure/Error: visit ('/clients/new')
Net::ReadTimeout:
Net::ReadTimeout
# ./spec/qa/variables.rb:12:in `login_user'
# ./spec/qa/successful_source_spec.rb:7:in `block in (root)'
1.2) Failure/Error: #io.to_io.wait_readable(#read_timeout) or raise Net::ReadTimeout
Net::ReadTimeout:
Net::ReadTimeout
Also note that I am using selenium with chrome headless.
Is there anything I can do to have the page load faster so that I can test? This is also the first time these specs are being run.
I decided to go with a quick fix for this problem. It turns out that the rails server was not connecting to the page fast enough before the test would time out. I decided to change the default wait time in the spec_helper.rb to 120 seconds. It will take a lot longer the first time you run the specs, but they eventually will connect and run smoothly from then on. I do not think this is best practice, but it does provide a quick fix to begin testing your specs.
My shop works perfect, it has nice response, quick loading times, etc....
except for homepage, index or whatever you call it. It always (after loooong loading) finishes with Error 500 - Server error.
Rest of the website works really well.
Did I mess up something?
Thanks
When I am sending a a GET request to rails server it takes too long time to respond (29 minute)
Below is the log snippet
Log says that there is an error in code, it is ok, but why take so long to respond (1723579 ms) I am unable to find any reason of such kind of behavior. Previously when server was working fine this js request only take 9 ms to respond. but suddenly it started to behave like this. How should i debug the application to trace the root cause of such unexpected behavior.
Started GET "/my-server/jobs/workers?_=1356363515400" for 27*.*.*.* at 2012-12-24 21:08:35 +0530
ActionView::Template::Error ():
1: <% #jobs.each do |job| %>
2: $('#cron_<%= job.id %>').attr('data-content', '<%= distance_of_time_in_words_to_now(job.next_fire_info, true) %>');
3: <% end %>
4:
5: <% #workers.each do |worker| %>
app/models/job.rb:16:in `next_fire_info'
app/views/jobs/workers.js.erb:2:in `block in _app_views_jobs_workers_js_erb__101155230_81985760'
app/views/jobs/workers.js.erb:1:in `_app_views_jobs_workers_js_erb__101155230_81985760'
Rendered jobs/workers.js.erb (1718348.7ms)
Completed 500 Internal Server Error in 1723579ms
I am on Rails 3.1.3,
Ruby 1.9.3p194,
MongoDB version v2.2.0, pdfile version 4.5,
32 bit Ubuntu (12.04) with 2 gb ram
Versions of rails 3.1 before 3.1.5 have a bug whereby when an exception is raised from a view rails takes a very long time to generate the exception message.
If you can't update to 3.1.5, the fix is very simple (see the commit that fixes it) - you just need to monkey patch inspect:
module ActionDispatch
module Routing
module RouteSet
alias to_s inspect
end
end
end
I used to dump this in an initializer. There's also a gem (safe_inspect) that claims to do this for you although I never tried it.
Finally i have found the reason for taking so long time to respond. The workers are running periodically based on cron expression.Root cause of this particular issue is one cron expression for job was entered erroneously. that's why at the time of executing "distance_of_time_in_words_to_now" took too much time.
I had similar problem and it was caused by authentication, so this is just for record if someone has the same problem in the future. The server did not let the user in and then redirected to the page which was restricted as well etc. etc.
This is a strange bug that we started seeing about a year ago. At first, I only occasionally noticed it on my dev machine, but now it's been starting to appear in production, which is problematic.
We use Ubuntu (11.04), and Mono 2.6.7 in production (I can also repro with Mono 2.10.x), inside apache, using mod_mono.
Basically, sometimes (very hard to reproduce), when apache starts the application, SolrNet decides to lower case the entire URL it transmits to the solr server. If the application is in this state, it stays this way until it is restarted (and occasionally requires a couple of restarts to clear up.) We might go for 20 - 50 or more restarts without seeing this problem come up. or sometimes it will happen every 2 or 3.
A good url looks like this:
INFO: [] webapp=/solr path=/select params={sort=Creative.PromotionalScore+desc&start=0&q=*:*&?=&qt=standard&fq={!tag%3DCreative.GalleryReviewStatus}Creative.GalleryReviewStatus:Approved&fq={!tag%3DCreative.SectionIncludedTarget}Creative.SectionIncludedTarget:220358+OR+(NOT+Creative.SectionIncludedTarget:[*+TO+*]+*:*)&fq={!tag%3DActive}Active:true&fq={!tag%3DCreative.ShowInGallery}Creative.ShowInGallery:true&fq={!tag%3DCreative.Size}Creative.Size:"Rectangle"&fq={!tag%3DRecordType}RecordType:FiveToOne.Gallery.Rmx.Creative&rows=12}
A bad url looks like this:
http://solrServer:8080/solr/select?qt=standard&fq=%7b!tag%3dcreative.galleryreviewstatus%7dcreative.galleryreviewstatus%3aapproved&fq=%7b!tag%3dcreative.sectionincludedtarget%7dcreative.sectionincludedtarget%3a306433+or+(not+creative.sectionincludedtarget%3a%5b*+to+*%5d+*%3a*)&fq=%7b!tag%3dactive%7dactive%3atrue&fq=%7b!tag%3dcreative.showingallery%7dcreative.showingallery%3atrue&fq=%7b!tag%3dcreative.size%7dcreative.size%3a%22rectangle%22&fq=%7b!tag%3drecordtype%7drecordtype%3afivetoone.gallery.rmx.creative&sort=creative.promotionalscore+desc&rows=18&start=0&q=*%3a*&?
(first, I apologize, these two URLs are extracted from different stages of the pipe, all I have access to at the moment.)
When the bad url is submitted, Solr throws a fatal exception, complaining of an unknown field:
HTTP Status 400 - can not sort on undefined field: creative.promotionalscore
type Status report
message can not sort on undefined field: creative.promotionalscore
description The request sent by the client was syntactically incorrect (can not sort on undefined field: creative.promotionalscore).
Having used Solr and SolrNet in production for four years now, all I can say is that I've never seen this on .NET, so I'm guessing it's a bug in Mono.
In order to pinpoint where exactly the URL is becoming lowercase, I'd put several logging points, for example here, here, and here.
After this logging is in place, once the bug occurs, the log should be analyzed, logging should be probably refined, etc, until the exact source of the bug is located.
Hopefully then the bug can be reproduced, reported, fixed, etc.
I'm writing a book on Rails 3 at the moment and past-me has written in Chapter 3 or so that when a specific feature is run that a routing error is generated. Now, it's unlike me to go writing things that aren't true, so I'm pretty sure this happened once in the past.
I haven't yet been able to duplicate the scenario myself, but I'm pretty confident it's one of the forgotten settings in the environment file.
To duplicate this issue:
Generate a new rails project
important: Remove the public/index.html file
Add cucumber-rails and capybara to the "test" group in your Gemfile
run bundle install
run rails g cucumber:skeleton
Generate a new feature, call it features/creating_projects.feature
Inside this feature put:
This:
Feature: Creating projects
In order to value
As a role
I want feature
Scenario: title
Given I am on the homepage
When you run this feature using bundle exec cucumber features/creating_projects.feature it should fail with a "No route matches /" error, because you didn't define the root route. However, what I and others are seeing is that it doesn't.
Now I've set a setting in test.rb that will get this exception page to show, but I would rather Rails did a hard-raise of the exception so that it showed up in Cucumber as a failing step, like I'm pretty sure it used to, rather than a passing step.
Does anybody know what could have changed since May-ish of last year for Rails to not do this? I'm pretty confident it's some setting in config/environments/test.rb, but for the life of me I cannot figure it out.
After I investigate the Rails source code, it seems like the ActionDispatch::ShowExceptions middleware that responsible of raising exception ActionController::RoutingError is missing in the test environment. Confirmed by running rake middleware and rake middleware RAILS_ENV=test.
You can see that in https://github.com/josh/rack-mount/blob/master/lib/rack/mount/route_set.rb#L152 it's returning X-Cascade => 'pass' header, and it's ActionDispatch::ShowExceptions's responsibility to pick it up (in https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/middleware/show_exceptions.rb#L52)
So the reason you're seeing that your test case is passing because rack-mount is returning "Not Found" text, with status 404.
I'll git blame people and get it fix for you. It's this conditional here: https://github.com/rails/rails/blob/master/railties/lib/rails/application.rb#L159. If the setting is true, the error got translated right but we got error page output. If it's false, then this middleware doesn't get loaded at all. Hold on ...
Update: To clearify the previous block, you're hitting the dead end here. If you're setting action_dispatch.show_exceptions to false, you'll not get that middleware loaded, resulted in the 404 error from rack-mount got rendered. Whereas if you're setting action_dispatch.show_exceptions to true, that middleware will got loaded but it will rescue the error and render a nice "exception" page for you.