A Noted Path by Theodore Nguyen-Cao

rsvp.theoandpat.com had boolean flag to marked whether or not a visitor was going to be able to make it to our wedding. Unfortunately, if you selected you were not able to make it and submit the form, the application would return saying it could not process your submission because you have to say that you are going to make it. I argued, this is an RSVP form so you have to accept if you are RSVPing. That’s the point of the RSVP! Only people RSVP would bother submitting the form!  Pat wasn’t too happy about that and ask/told me to fix it. 

Digging into it, it turns out the way  for validates_presence_of relies on Object#blank which of course when sent

false.blank? # returns true

Reading up on the documentation, it is suggested to use validates_inclusion_of when dealing with booleans.

The one line change solved the problem:

validates_inclusion_of :accepted, :in => [true, false]

Following up on my previous post , I’ve been experience slow load times (10-15 secs) on the initial request after application restarts. This has to do with the way mod_rails manages application instances (Although, I experienced this when using mongrel_cluster and proxy balancers). It will spin up instances on page request and each instance has an idle timeout. This just means after the timeout expires, mod_rails will shutdown that instance to conserve memory allocation. While you can change timeout value (see PassengerPoolIdleTime), this will only cause all instances that get spin up to live longer. After high load times, these instances will stick around longer than neccessary.

For low traffic sites (like mine), this idle timeout may be reached causing the next visitor to our website to experience a really long delay before page load. What we really want is an option to set a minimum number of instances. This would allow us to automatically spin up an instance during start up and keep it around. Unfortunately at this time, it doesn’t look like there is a way to set this.

As a workaround, I’ve setup a crontab that makes a request to my application every 5 minutes to prevent mod_rails from killing off all application instances.

To do this just run:

crontab -e

And then specific the following cron

*/5 * * * * wget -O /dev/null http://www.myapp.com 2>/dev/null

You can verify this is working correctly but just tailing your application logs and verify every 5 minutes you get a request.

You can also run

 passenger-status

You should see at least the count variable to be at least 1 instance.

Note, this workaround will not immediate start up an instance upon restart. You can add an initial request as part of your post deploy capistrano task though. You probably should be making sure your application is up after deploying or restarting the application anyways.

I had heard of mod_rails awhile back but never had the time to take a closer look at it. While setting up a new rails app, I was getting frustrated with all of the configuration I needed to do to get the mongrel clusters and proxy balancers setup. So I decided to give passenger a chance. I’m a fan now

The process was dead simple.

1. Install the passenger gem

   sudo gem install passenger

2. Install passenger as an Apache module

   passenger-install-apache2-module

3. Load the passenger apache module by editing the Apache config

   LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.0.5/ext/apache2/mod_passenger.so
   PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.0.5
   PassengerRuby /usr/bin/ruby1.8
   

4. Restart Apache

If all things went well, you have everything installed you need. If there were some missing dependencies, you should be presented with how to install those dependencies.

In the installation output, it tells you how to mod_railsify your apps by creating a vhost as such:

<VirtualHost *:80>
    ServerName www.mywebsite.com
    DocumentRoot /home/deploy/mywebsite/public
</VirtualHost>

That’s it! No more of this proxy balancer and mongrel_cluster.yml configuration.

There’s some magic going on in the background. As requests come in, passenger will spin up more application instances. For more tweaking your configuration options check out the user guide.

Go to your website and you should see your rails app up and running.

So now we have your app up and running, how do we update or restart our app? Passenger provides two ways for us to do this.

The first is whenever apache is restarted, your application is restarted.

The second way allows us to restart a specified application without affecting Apache. Whenever passenger detects tmp/restart.txt, it will restart the application instances for us. We can integrate this into our Capistrano deploy flow by adding the following our config/deploy.rb

namespace :passenger do
  desc "Restart Application"
  task :restart do
    run "touch #{current_path}/tmp/restart.txt"
  end
end

after :deploy, "passenger:restart"

This will create that restart.txt after the cap:deploy task gets executed, causing the application to restart.

Finally, passenger comes with some pretty useful utilities.

Check out passenger-status which produces output showing current passenger server statuses.

Sample output:

----------- General information -----------
max      = 6
count    = 1
active   = 0
inactive = 1
Using global queue: no
Waiting on global queue: 0

----------- Applications -----------
/home/deploy/www.myapp.com/releases/20081206183156:
  PID: 30784     Sessions: 0

Another utility passenger-memory-status gives you insight into how much memory is being used by apache and passenger.

Sample output:

-------------- Apache processes ---------------
PID    PPID   Threads  VMSize    Private  Name
-----------------------------------------------
12841  1      1        225.9 MB  0.0 MB   /usr/sbin/apache2 -k start
28294  12841  1        248.4 MB  21.4 MB  /usr/sbin/apache2 -k start
28300  12841  1        243.7 MB  0.5 MB   /usr/sbin/apache2 -k start
28306  12841  1        248.4 MB  4.4 MB   /usr/sbin/apache2 -k start
28357  12841  1        249.1 MB  19.8 MB  /usr/sbin/apache2 -k start
29400  12841  1        249.4 MB  3.7 MB   /usr/sbin/apache2 -k start
29788  12841  1        249.3 MB  21.7 MB  /usr/sbin/apache2 -k start
29834  12841  1        245.8 MB  18.9 MB  /usr/sbin/apache2 -k start
29836  12841  1        245.8 MB  9.3 MB   /usr/sbin/apache2 -k start
29868  12841  1        245.8 MB  2.4 MB   /usr/sbin/apache2 -k start
29870  12841  1        246.5 MB  5.2 MB   /usr/sbin/apache2 -k start
### Processes: 11
### Total private dirty RSS: 107.44 MB

--------- Passenger processes ----------
PID    Threads  VMSize    Private  Name
----------------------------------------
28031  10       15.3 MB   0.1 MB   /usr/lib/ruby/gems/1.8/gems/passenger-2.0.5/ext/apache2/ApplicationPoolServerExecutable 0 /usr/lib/ruby/gems/1.8/gems/passenger-2.0.5/bin/passenger-spawn-server  /usr/bin/ruby1.8  /tmp/passenger_status.12841.fifo
28032  2        48.7 MB   0.6 MB   Passenger spawn server
29161  1        114.8 MB  0.7 MB   Passenger FrameworkSpawner: 2.1.2
30461  1        122.8 MB  32.3 MB  Passenger ApplicationSpawner: /home/deploy/www.myapp.com/releases/20081206183156
30784  1        129.3 MB  33.4 MB  Rails: /home/deploy/www.myapp.com/releases/20081206183156
### Processes: 5
### Total private dirty RSS: 67.08 MB

Pretty sweet.

I was looking for where mysql.sock was since running rake db:bootstrap was complaining with “No such file or directory – /tmp/mysql.sock”. Rails looks for the mysql.sock file under /tmp/mysql.sock by default. Ubuntu using an apt-get install of mysql puts the mysql.sock file at /var/run/mysqld/mysqld.sock.

I always forget where it is. So, I’m writing it down.

/var/run/mysqld/mysqld.sock

You can also grep for it from mysql like so

>>  mysql -? | grep mysqld.sock
socket                            /var/run/mysqld/mysqld.sock

I was writing some code in an erb template that looked like this:

<% if @user && not @user.errors.empty? -%>
#do stuff
<% end -%>

This resulted in a syntax error. Huh? What’s wrong with this?

Turns out it’s an outstanding Core Ruby bug.

As shown in the ticket if we have a method foo

def foo(parameter)
  puts parameter.to_s
end

using the ! and the not operator on various method calls show us that the ! and not operator are not interchangeable in practice.

foo(!(1 < 2)) # works fine
foo(not(1 < 2)) # generates syntax error
foo(not 1 < 2) # generates syntax error
foo((not 1 < 2)) # works fine

Changing the my code to the following fixed my issue:

<% if @user && !@user.errors.empty? -%>
#do stuff
<% end -%>