Phusion Passenger and memcache

On January 1, 2010 By Chee Yeo

One of my recently deployed Rails app uses memcache with Phusion Passenger. I read on the Phusion documentation about the possibility of corrupted commands issued to memcache through the spawned processes within Passenger.

I added the declarations below within the config/environment.rb file to overcome this issue:


      begin
         PhusionPassenger.on_event(:starting_worker_process) do |forked|
             if forked
               # We're in smart spawning mode, so...
               # Close duplicated memcached connections - they will open themselves
                 CACHE.reset
             end
         end
     # In case you're not running under Passenger (i.e. devmode with mongrel)
     rescue NameError => error
   end

The CACHE constant is set within the cache_fu plugin. All the declaration does is similar to that outlined in the Appendix of the Phusion documentation with the addition of the ‘begin..rescue’ block to counteract exceptions which may arise.

I understand from comments on the Passenger google group that cache_fu causes problems with memcached. If anyone has any further information on the above please feel free to comment.

Tagged with: • • •
 
1 Comments
Leave A Response

Control your Nginx processes using signals

On September 11, 2009 By Chee Yeo

This is a follow up on my previous articles on using the NGINX server. On my older wordpress blog, I highlighted the steps involved in installing and getting NGINX running on your development environment. Here, I would like to share how I manage my nginx processes in the same development environment.

If you use Apache through the Passenger gem, you could type something like this to restart the server gracefully:

  
      sudo apachectl graceful

and to shutdown:

  
    sudo apachectl shutdown

To do the same in nginx, you would need to type the following:

  
     sudo kill -QUIT `cat /usr/local/nginx/logs/nginx.pid`

What the above command does is to do a graceful shutdown of the master process, which would in turn call shutdown on the worker processes. Note the backticks and the cat command. What it does is to run the cat command on the pid file to grab the pid value and pass it to the QUIT signal.

If you need to reload the server after making changes to the configuration file (i.e. nginx.conf), just do:

  
    sudo kill -HUP `cat /usr/local/nginx/logs/nginx.pid`

More command line options can be found on the NGINX wiki, which even details the sequence of events when signals are sent as well as how to upgrade an entire nginx executable on the fly with 0 downtime.

Sweet!

 
0 Comments
Leave A Response