Category Archives: rails_errors

json (1.8.3) and rubyracer gems aren’t compatible with ruby 2.4.0

Posted on by

PS: This is moot anyway because it looks like Rails 4.2 doesn’t fully support Ruby 2.4.0 yet

Ran into this problem trying to upgrade a Rails app to use the new version of Ruby.

make "DESTDIR="
compiling generator.c
generator.c:861:25: error: use of undeclared identifier 'rb_cFixnum'
} else if (klass == rb_cFixnum) {
^
generator.c:863:25: error: use of undeclared identifier 'rb_cBignum'
} else if (klass == rb_cBignum) {
^
generator.c:975:5: warning: division by zero is undefined [-Wdivision-by-zero]
rb_scan_args(argc, argv, "01", &opts);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Yikes!

Turns out this is because of Bignum/Fixnum integration that rolled out in ruby 2.4.0

after that I hit another fugly stack trace caused because I hadn’t upgraded therubyracer gem to 0.12.3

I had to include the gems and specific versions in my gemfile

gem 'json', '~> 1.8.6'
gem 'therubyracer', '~> 0.12.3'

then run

bundle update json

Unfortunately, as I mentioned above, I was unable to run Rails 4.2.7 anyway, because it looks like it hasn’t been fully prepped to incorporate Ruby 2.4.0’s integer changes.

Using rails and having trouble getting Mysql’s wait_timeout to work? read this.

Posted on by

tldr; mysql2 gem specifies a default wait_timeout of 2147483 seconds that overrides whatever you set on a mysql server

I spent a whole day yesterday trying to debug why updating mysql’s wait_timeout wasn’t working.

Initially, we were having some trouble with a small mysql ec2 instance that was running out of memory because

  1. it had less ram than other boxes doing the same thing (we’d forgotten to upgrade it)
  2. it would spawn too many connections (12k or so) which take up memory and because there was no swap specified, when mysql grew too big, it would get killed by the os.

All pretty silly really. It could have been solved by just getting a bigger box, but there were a bunch of reasons why that wasn’t possible right at that second. And there were similar boxes that had been overlooked but were doing fine, difference was they had fewer connections … about 8k vs our 12k.

In checking out the connections, I realized almost 80% of them were sleeping and had been sleeping for a long time. I figured that setting a low enough wait_timeout (something like 120 seconds or so … average user session limit) on that box would solve the problem. I was worried about “mysql server has gone away” airbrake errors showing up, but I figured it was worth a shot to see if it relieved the memory pressure enough to stop worrying about this particular mysql server dying every few days.

We updated the settings from the mysql console (setting the GLOBAL wait_timeout there), restarted the server, and waited …but the mysql connections just traipsed past the wait_timeout limit.

odd.

Initially I thought It’d been done incorrectly, so I manually edited the my.cnf file and restarted the mysql process again, which was painful because even though this was a small box, it had about 11G of mysql in memory that it had to flush.

Again the connections came back up and went past the limit we set.

After investigating for a while, I remembered having encountered a similar problem a few months ago when I tried to do the same thing on a personal project. I had been able to set the wait_timeout on my production server but never got it to work on my local environment.

I raced home and started looking around to see what the difference was between the two. That’s when I realized that I had specified a wait_timeout in the database.yml of my production box but not my dev box. After googling for a bit I finally pieced it all together.

It turns out that the mysql2 gem does this thing …

ConnectionPool uses wait_timeout to decide how long to wait for a connection checkout on a full connection pool, and it defaults to 5 seconds.

mysql2_adapter uses this same wait_timeout , but passes it directly to mysql, and defaults to a much larger 2592000!!

Things have changed a little from that github issue being filed, but essentially it substitutes a default wait_timeout value of about 25 days (2147483s) of its own as the wait_timeout value (probably the session version of wait_timeout) that the mysql connection uses, basically overriding whatever setting we specify on the server.

By setting a wait_timeout: value in config/database.yml the timeout works as it should. When the connection gets killed, however, you get the infamous “mysql server has gone away” errors.

By specifying an accompanying
reconnect: true
option in database.yml, this is fixed, but in a quirky way.

Everytime the connection is reused, say you run an active record command at the console … then run another one, the connection’s timer is reset, BUT after that the connection it uses the wait_timeout setting that you configured from mysql directly.

So if you specified a 10 second timeout in your database.yml, and 15 seconds in your my.cnf file, then you logged into the console and ran an Active Record command.

Mysql would spawn a connection that would sleep after it was done for 10 seconds before being closed by mysql.

If before the end of that 10 seconds you ran another command, it would execute it and then start to sleep again, but now (and every time after) it would sleep for the 15 seconds specified in my.cnf before being killed by mysql.

Hope that piece of trivia brightens up your day 😀

Minitest Spec giving you lots of “duplicate key” type errors? Read this

Posted on by

We just moved to the latest Test::Unit, which uses MiniTest under the hood. Because of that, I wanted to take advantage of the new MiniTest::Spec DSL to get RSpec-like syntax in Test Unit.

The problem is, when I went to the try using it, I started getting all sorts of strange duplicate key/column errors.


At first I thought it was because of a recent upgrade I had done from Postgres 9.1 to 9.2, but as I dug in deeper, I realized it was my new Spec Test. We are running our tests in transactions that we rollback on the completion of each test, MiniTest::Spec wasn’t doing this and causing all the test errors.

After hours of digging I finally found the solution to the minitest duplicate key issue here. I hope it saves you some time. Definitely did for me!

PS: The other alternative that was pointed out to me was to simply use the minitest-rails gem. I tried it but it didn’t work cleanly right out-the-box for our setup (errors in tests, etc). I was too tired to fix it up, so I’ll kick the can down the road till I need to revisit this issue, probably in upgrading to Rails 4.

How to get Ruby Native gems to install on your windows machine

Posted on by

The bane of any ruby/rails developer on a windows box (apart from piddling performance) is seeing the dreaded …
‘gem install error – ‘cl’ is not recognized as an internal or external command’

No more!
Devkit, a tool used by the folks who create the Windows Ruby Installer of each version of ruby helps you with (most) gems that need to be built natively.
Muchos Gracias to them for graciously providing it to us.

How to turn off Length Error messages on Password Confirmation fields in Authlogic

Posted on by

In Authlogic, if you use a password confirmation field (when creating a new user perhaps), there is an error message that shows up for that field if the User model does not validate.
Something like

is too short (minimum is 4 characters)

Seems simple enough to turn off, but I almost went mad trying to figure out how do this without completely turning off password authentication.

class User < ActiveRecord::Base
    acts_as_authentic do |c|
         c.merge_validates_length_of_password_confirmation_field_options  :allow_blank => true
    end
end

PS: It’d be nice to get all the configuration options for Authlogic in one place, with better documentation for each one.
Maybe I should get on that … it is open source software after all

rake aborted! development database is not configured.

Posted on by

You might have been happily running migrations on your development box for weeks and go to get the application set up on a production server.
And all might even have been going well until you ran

rake db:migrate

only to see it crash and burn like this.

** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
rake aborted!
development database is not configured

Fear not ye intrepid developer!
This happens when you leave out the development specifications in your database.yml.
(If you don’t define development.rb, you’ll get a weirder “No such file or directory – …../development.rb” error)

Apparently rake db:migrate runs in development mode no matter what environment you’re in (still looking into the reason for this).
So what you have to do is call migrate like this

rake db:migrate RAILS_ENV=production <—- or whatever your environment is

That should get you back on the path to true happiness.