The development version of Ruby on Rails has cool new internationalization features. Although the framework itself doesn’t provide a lot of I18N functionality, it does provide the necessary hooks for plugins to implement I18N however they see fit. Simon Tokumine has written an I18N demo application to show you what Rails is capable of, when used in combination with the localized_dates plugin.

We’ve deployed the demo application at http://i18n-demo.phusion.nl/. Check it out.

[Ruby on Rails ]
View original post|Add to del.icio.us | Share

Problem description and motivation

There is a lot of software (both Rails related and unrelated) which rely on servers or daemons. To name a few, in no particular order:

• Ultrasphinx, a Rails library for full-text searching. It makes use the Sphinx search software for indexing and searching. Indexing is done by running a command, while searching is done by querying the Sphinx search server.
• acts_as_ferret, another Rails library for full-text searching. It uses the Ferret search software. On production environments, it relies on the Ferret DRB server for both searching and indexing.
• BackgrounDRb, a Ruby job server and scheduler. Scheduling is done by contacting the BackgrounDRb daemon.
• mongrel_cluster, which starts and stops multiple Mongrel daemons.

Relying on daemons is quite common, but not without problems. Let’s go over some of them.

Starting daemons is a hassle

If you’ve used similar software, then you might agree that managing these daemons is a hassle. If you’re using BackgrounDRb, then the daemon must be running. Starting the daemon is not hard, but it is annoying. It’s also possible that the system administrator forgets to start the daemon. While configuring the system to automatically start a daemon at startup is not hard, it is an extra thing to do, and thus a hassle. We thought, why can’t such daemons be automatically started? Indeed, this won’t be possible if the daemon is to be run on a remote machine. But in by far the majority of use cases, the daemon runs on the same host as the Rails application. If a Rails application - or indeed, any application - is configured to contact a daemon on the local host, then why not start the daemon automatically on demand?

Daemon starting code may not be robust or efficient

We’ve also observed that people write daemon controlling code over and over again. Consider for example UltraSphinx, which provides a rake sphinx:daemon:start Rake task to start the daemon. The time that a daemon needs to initialize is variable, and depends on things such as the current system load. The Sphinx daemon usually needs less than a second before we can connect to it. However, the way different software handles starting of a daemon varies. We’ve observed that waiting a fixed amount of time is by far the most common way. For example, UltraSphinx’s daemon starting code looks like this:

system "searchd --config '#{Ultrasphinx::CONF_PATH}'" sleep(4) # give daemon a chance to write the pid file if ultrasphinx_daemon_running? say "started successfully" else say "failed to start" end

This is in no way a slam against UltraSphinx. However, if the daemon starts in 200 miliseconds, then the user who issued the start command will be waiting for 3.8 seconds for no good reason. This is not good for usability or for the user’s patience.

Startup error handling

Different software handles daemon startup errors in different ways. Some might not even handle errors at all. For example, consider mongrel_cluster. If there’s a typo in one of your application source files, then mongrel_cluster will not report the error. Instead, you have to check its log files to see what happened. This is not good for usability: many people will be wondering why they can’t connect to their Mongrel ports after issuing a mongrel_rails cluster::start — until they realize that they should read the log file. But the thing is, not everybody realizes this. And typing in an extra command to read the log file to check whether Mongrel started correctly, is just a big hassle. Why can’t the daemon startup code report such errors immediately?

Stale or corrupt Pid files

Suppose that you’re running a Mongrel cluster, and your server suddenly powers off because of a power outage. When the server is online again, it fails to start your Mongrel cluster because the PID file that it had written still exists, and wasn’t cleaned up properly (it’s supposed to be cleaned up when Mongrel exits). mongrel_cluster provides the –clean option to check whether the PID file is stale, and will automatically clean it up if it is. But not all daemon controlling software supports this. Why can’t all software check for stale PID files automatically?

Implementation problems

From the problem descriptions, it would become apparent that our wishlist is as follows. Why is this wishlist often not implemented? Let’s go over them.

A daemon should be automatically started on demand, instead of requiring the user to manually start it.

The most obvious problems are related to concurrency. Suppose that your web application has a search box, and you want to start the search daemon if it isn’t already started, then connect to. Two problems will arise:

• Suppose that Rails process A is still starting the daemon. At the same time, another visitor tries to search something, and Rails process B notices that the daemon is not running. If B tries to start the daemon while it’s already being started by A, then things can go wrong. A robust daemon starter must ensure that only one process at the same time may start the daemon.
• It’s not a good idea to wait a fixed amount of time for the daemon to start, because you don’t know in advance how long it will take for it to start. For example, if you wait 2 seconds, then try to connect to the daemon, and the daemon isn’t done initializing yet, then it will seem as if the daemon failed to start.

These are the most probable reasons why people don’t try to write auto-starting code, and instead require the user to start the daemon manually.

These problems, as well as several less obvious problems, are closely related to the next few points.

The daemon starter must wait until the daemon is done initializing, no longer and no shorter

Because only after the daemon is fully initialized, is it safe to connect to it. And because the user should not have to wait longer than he really has to.

During startup, the daemon will have to be continuously checked whether it’s done initializing or whether an error occured. Writing this code can be quite a hassle, which is why most people don’t do it.

The daemon starter must report any startup errors

If the daemon starting command — e.g. “sphinx -c config_file.conf”, “apachectl start” or “mongrel_rails cluster::start” — reports startup errors, then all is fine as long as the user is starting the command from a terminal. A problem occurs when the error occurs after the daemon has already gone into the background. Such errors are only reported to the log file. The daemon starter should also check the log file for any startup errors.

Furthermore, it should be able to raise startup errors as exceptions. This allows the the application to decide what to do with the error. For less experienced system administrators, the error might be displayed in the browser, allowing the administrators to become aware of the problem without forcing them to manually check the log files. Or the error might be emailed to a system administrator’s email address.

The daemon starter must be able to correct stale or corrupted PID files If the PID file is stale, or for some reason has been corrupted, then the daemon starter must be able to cope with that. It should check whether the PID file contains a valid PID, and whether the PID exists. Introducing daemon_controller

daemon_controller is a library for managing daemons in a robust manner. It is not a tool for managing daemons. Rather, it is a library which lets you write applications that manage daemons in a robust manner. For example, mongrel_cluster or UltraSphinx may be adapted to utilize this library, for more robust daemon management.

daemon_controller implements all items in the aforementioned wishlist. It provides the following functionalities:

Starting a daemon

This ensures that no two processes can start the same daemon at the same time. It will also reports any startup errors, even errors that occur after the daemon has already gone into the background but before it has fully initialized yet. It also allows you to set a timeout, and will try to abort the daemon if it takes too long to initialize.

The start function won’t return until the daemon has been fully initialized, and is responding to connections. So if the start function has returned, then the daemon is guaranteed to be usable.

Stopping a daemon

It will stop the daemon, but only if it’s already running. Any errors are reported. If the daemon isn’t already running, then it will silently succeed. Just like starting a daemon, you can set a timeout for stopping the daemon.

Like the start function, the stop function won’t return until the daemon is no longer running. This makes it save to immediately start the same daemon again after having stopped it, without worrying that the previous daemon instance hasn’t exited yet and might conflict with the newly started daemon instance.

Connecting to a daemon, starting it if it isn’t running Every daemon has to be connected to using a different way. As a developer, you tell daemon_controller how to connect to the daemon. It will then attempt to do that, and if that fails, it will check whether the daemon is running. If it isn’t running, then it will automatically start the daemon, and attempt to connect to the daemon again. Failures are reported. Checking whether a daemon is running This information is retrieved from the PID file. It also checks whether the PID file is stale. All failures are reported via exceptions So that you can exactly determine how you want to handle errors. Lots and lots of error checking So that there are very few ways in which the system can screw up.

daemon_controller’s goal is to make daemon management less of a hassle, and as automatic and straightforward as possible.

Tutorial #1: controlling Apache

Suppose that you’re a Phusion Passenger developer, and you need to write tests for the Apache module. In particular, you want to test whether the different Phusion Passenger configuration directives are working as expected. Obviously, to test the Apache module, the Apache web server must be running. For every test, you will want the unit test suite to:

1. Write an Apache configuration file, with the relevant configuration directive set to a specific value.
2. Start Apache.
3. Send an HTTP request to Apache and check whether the HTTP response matches your expectations.
4. Stop Apache.

That can be done with the following code:

require 'daemon_controller' File.open("apache.conf", "w") do |f| f.write("PidFile apache.pid\n") f.write("LogFile apache.log\n") f.write("Listen 1234\n") f.write(... other relevant configuration options ...) end controller = DaemonController.new( :identifier => 'Apache web server', :start_command => 'apachectl -f apache.conf -k start', :ping_command => lambda { TCPSocket.new('localhost', 1234) }, :pid_file => 'apache.pid', :log_file => 'apache.log', :timeout => 25 ) controller.start .... apache is now started .... .... some test code here .... controller.stop

The File.open line is obvious: it writes the relevant Apache configuration file.

The next line is for creating a new DaemonController object. We pass a human-readable identifier for this daemon (”Apache web server”) to the constructor. This is used for generating friendlier error messages.
We also tell it how Apache is supposed to be started (:start_command), how to check whether it can be connected to (:ping_command), and where its PID file and log file is. If Apache failed with an error during startup, then it will be reported. If Apache failed with an error after it has gone into the background, then that will be reported too: the given log file is monitored for new error messages.
Finally, a timeout of 25 seconds is given. If Apache doesn’t start within 25 seconds, then an exception will be raised.

The ping command is just a Proc which returns true or false. If the Proc raises Errno::ECONNREFUSED, then that’s also interpreted by DaemonController as meaning that the daemon isn’t responding yet.

After controller.start has returned, we can continue with the test case. At this point, we know that Apache is done with initializing.
When we’re done with Apache, we stop it with controller.stop. This does not return until Apache has fully stopped.

The cautious reader might notice that the socket returned by the ping command is never closed. That’s true, because DaemonController will close it automatically for us, if it notices that the ping command proc’s return value responds to #close.

From this example, it becomes apparent that for daemon_controller to work, you must know how to start the daemon, how to contact the daemon, and you must know where it will put its PID file and log file.

Tutorial #2: Sphinx indexing and search server management

We at Phusion are currently developing a web application with full-text search capabilities, and we’re using Sphinx for this purpose. We want to make the lives of our developers and our system administrators as easy as possible, so that there’s little room for human screw-up, and so we’ve developed this library. Our Sphinx search daemon is completely managed through this library and is automatically started on demand.

Our Sphinx config file is generated from an ERB template. This ERB template writes different values in the config file, depending on whether we’re in development, test or production mode. We will want to regenerate this config file every time, just before we start the search daemon.
But there’s more. The search daemon will fail if there is no search index. If a new developer has just checked out the application’s source code, then there is no search index yet. We don’t want him to go through the pain of having to generate the index manually. (That said, it isn’t that much of a pain, but it’s just yet-another-thing to do, which can and should be automated.) So before starting the daemon, we will also want to check whether the index exists. If not, then we’ll generate it, and then start the daemon. Of course, no two Rails processes may generate the config file or the index at the same time.

When querying the search server, we will want to automatically start it if it isn’t running.

This can be achieved with the following code:

require 'daemon_controller' class SearchServer SEARCH_SERVER_PORT = 1234 def initialize @controller = DaemonController.new( :identifier => 'Sphinx search server', :start_command => "searchd -c config/sphinx.conf", :before_start => method(:before_start), :ping_command => lambda { TCPSocket.new('localhost', SEARCH_SERVER_PORT) }, :pid_file => 'tmp/pids/sphinx.pid', :log_file => 'log/sphinx.log', end def query(search_terms) socket = @controller.connect do TCPSocket.new('localhost', SEARCH_SERVER_PORT) end send_query(socket, search_terms) return retrieve_results(socket) end private def before_start generate_configuration_file if !index_exists? generate_index end end ... end

Notice the :before_start option. We pass a block of code which is to be run, just before the daemon is started. This block, along with starting the daemon, is completely serialized. That is, if you’re inside the block, then it’s guaranteed that no other process is running this block at the same time as well.

The query method is the method for querying the search server with search terms. It returns a list of result. It uses DaemonController#connect: one passes a block of that method, which contains code for connecting to the daemon. If the block returns nil, or if it raises Errno::ECONNREFUSED, then DaemonController#connect will automatically take care of auto-starting the Sphinx daemon for us.

A little bit of history

The issue of managing daemons has been a thorn in our eyes for quite some time now. Until now, we’ve solved this problem by equipping any daemons that we write with the ability to gracefully handle being concurrently started, the ability to initialize as much as possible before forking into the background, etc. However, equipping all this robustness into our code over and over is a lot of work. We’ve considered documenting a standard behavior for daemons so that they can properly support auto-starting and such.

However, we’ve recently realized that that’s probably a futile effort. Convincing everybody to write a lot of code for a bit more robustness is probably not realistic. So we took the pragmatic approach and developed a library which adds more robustness on top of daemons’ existing behavior. And thus, daemon_controller was born. It is a little bit less efficient compared to when the daemon is designed from the beginning with such abilities in mind, but it’s compatible with virtually all daemons, and is easy to use.

Availability

The source code is available on Github: http://github.com/FooBarWidget/daemon_controller/tree/master
Detailed API documentation is available in the form of inline comments in lib/daemon_controller.rb.

[Software ]
View original post|Add to del.icio.us | Share

A few days ago, the Ruby core team has announced several newly discovered security vulnerabilities. Ruby versions prior to 1.8.6-p285 and 1.8.7-p70 are vulnerable. The previous version of Ruby Enterprise Edition is also vulnerable because it’s based on 1.8.6-p114.

Earlier Ruby releases had some crash bugs and incompatibility problems. It goes without saying that such problems are unacceptable in production environments, so we’ve been careful and took the time to test 1.8.6-p286 against various test suites:

• We tested it against the Ruby on Rails test suite (edge). All tests passed.
• We tested it against the RubySpec test suite (git HEAD from yesterday). All tests passed. In fact, Ruby 1.8.6-p114 fails a few tests, so p286 is more Ruby-compliant.
• We tested it against Typo 5.0.3’s test suite. All tests passed.
• We tested it against the test suite of various of our internal applications. All tests passed.

So our conclusion is that Ruby 1.8.6-p286 is indeed stable and compatible. Kudos to the Ruby core developers for this excellent release!

We’ve prepared a new Ruby Enterprise Edition release, based on Ruby 1.8.6-p286. The official Ruby on Rails wiki has been running on this Ruby Enterprise Edition version since yesterday (in addition to Phusion Passenger git HEAD), and everything seems to be rock-solid so far.

This Ruby Enterprise Edition release not only includes upstream Ruby’s security vulnerability fixes and other bug fixes, but also some Ruby Enterprise Edition-specific improvements and fixes:

MySQL headers are autodetected Many people have problems installing the MySQL gem, especially on non-Linux platforms. That’s because the gem cannot find the MySQL development headers. The Ruby Enterprise Edition installer now autodetects the MySQL headers, for much better MySQL gem installation success rate. Bug fix: don’t overwrite shebang lines for non-Ruby scripts Normally, the installer changes the shebang lines of all scripts in $PREFIX/bin to the correct location of the Ruby Enterprise Edition binary. ($PREFIX is the location that one installs Ruby Enterprise Edition to) However, this would change all shebang lines, even for non-Ruby scripts. This has been fixed: only the shebang lines of Ruby scripts will now be changed. sqlite3-ruby gem permissions fixed The sqlite3-ruby gem installed itself with the wrong permissions. Its files would be world-writable by default. The installer now fixes this problem. ‘PassengerRuby’ instead of ‘RailsRuby’ The installer used to instruct the user to change the ‘RailsRuby’ option for Phusion Passenger. ‘RailsRuby’ has been deprecated since Phusion Passenger 2.0 in favor of ‘PassengerRuby’, so the installer now instructs the user to change ‘PassengerRuby’ instead. Upgrade instructions Via the source tarball

Please download the source tarball from the download page and run the built in installer, as instructed on the download page. To upgrade, please install Ruby Enterprise Edition to the same location that you specified last time.

Via the Debian package

Please install the Debian package by downloading it from the download page. (click on the “Linux” tab)

[Ruby Enterprise Edition ]
View original post|Add to del.icio.us | Share

2.0.3 is a minor release containing non-intrusive bug fixes and optimizations.

Changes Vendor Rails optimization Some people vendorize Ruby on Rails. In previous versions, Phusion Passenger creates a new framework spawner which caches the code for the vendorized Rails framework. This step has now been removed because it’s redundant. As a result, Phusion Passenger now uses less memory when serving applications that have vendorized Rails. It is therefore especially adviced that shared hosts upgrade to this version. ‘passenger-memory-stats’ now works on non-Linux systems The ‘passenger-memory-stats’ didn’t work correctly on non-Linux platforms. This has been fixed. However, ‘passenger-memory-stats’ is only capable of displaying the real memory usage of processes when running on Linux. Other operating systems don’t provide a way to query the real memory usage, unfortunately. So on non-Linux platforms, ‘passenger-memory-stats’ will display the Resident Set Size instead. WSGI fixes WSGI support in Phusion Passenger is mostly a proof of concept. Nevertheless, we find it worthwhile to fix any WSGI-related bugs that we may encounter. 2.0.3 fixes Python 2.4 compatibility (previous versions require at least Python 2.5), and fixes some WSGI compliance bugs. Thanks to Weyert de Boer for contributing the latter fix. How do I upgrade to 2.0.3? Via a gem

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Please don’t forget to copy & paste the Apache config snippet that the installer gives you.

Via a native Linux package

Neil Wilson from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb instruction, and then run ‘apt-get update‘).

Once you’ve done this then you can install Phusion Passenger by running:

apt-get install libapache2-mod-passenger

(Note that Neil is currently packaging 2.0.3, so it might take a while before this release shows up in the apt repository.)

[General ]
View original post|Add to del.icio.us | Share

Just in case you haven’t noticed yet, http://wiki.rubyonrails.org/ is now running Phusion Passenger and Ruby Enterprise Edition. We migrated them a few days ago, and other than a MySQL failure yesterday, it had been rock solid ever since. People have complained about wiki.rubyonrails.org being down often, but the uptime should be a lot better now.

[General ]
View original post|Add to del.icio.us | Share

Phusion Passenger’s development continues on. A few bugs have been found and fixed. These fixes are deemed to be important enough to backport to the 2.0.x series, so today we present you with Phusion Passenger 2.0.2.

Changes Fixed a file descriptor leak If a system error occurs while receiving the response data from a Rails application, then the file descriptor that connects Apache to the Rails application is not properly cleaned up. This has been fixed. Thanks to TonyLa for reporting and analyzing this problem. Fixed a memory leak Due to an unfortunate little mistake, each time a client disconnects from the ApplicationPoolServerExecutable will result in a small memory leak. In practice, it means this: if your Apache is configured to restart* worker threads or worker processes often (say, every 10 requests or so), then each time that happens, a small memory leak will occur. For most people this is not a problem, because by far most Apache servers are configured to never restart worker threads/processes, or only restart a worker thread/process after several hundred thousand requests. This leak didn’t catch our attention because we used a standard Apache configuration (Ubuntu default).
Once again, many thanks to TonyLa for reporting and analyzing this problem.
(* = This has got nothing to do with the ‘apachectl restart’ or ‘apachectl graceful’ command. These commands restart Phusion Passenger entirely, and will not result in any memory leaks. We were only referring to Apache’s internal process of restarting worker threads and worker processes.) Fixed a compilation problem for some people This has been fixed. How do I upgrade to 2.0.2? Via a gem

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Please don’t forget to copy & paste the Apache config snippet that the installer gives you.

Via a native Linux package

Neil Wilson from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb anstruction, and then run ‘apt-get update‘).

Once you’ve done this then you can install Phusion Passenger by running:

apt-get install libapache2-mod-passenger

(Note that Neil is currently packaging 2.0.2, so it might take a while before this release shows up in the apt repository.)

[Phusion Passenger ]
View original post|Add to del.icio.us | Share

Phusion Passenger version 2.0.1 has been officially released. Not much has changed since 2.0 RC 2: only some documentation has been updated.

See the announcements for versions 2.0 RC 1 and 2.0 RC 2 for a full list of changes compared to version 1.0.x.

How do I upgrade to 2.0.1?

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Please don’t forget to copy & paste the Apache config snippet that the installer gives you.

[Phusion Passenger ]
View original post|Add to del.icio.us | Share

For those who don’t know, a number of security vulnerabilities in Ruby have recently been discovered. Affected Ruby versions are:

• All versions prior to 1.8.5
• All 1.8.5 versions prior to patch 231
• All 1.8.6 versions prior to patch 230
• All 1.8.7 versions prior to patch 22
• All 1.9.0 versions prior to 1.9.0-2

The CVE links on the Ruby website don’t disclose any information on the vulnerabilities, but Peter Cooper from RubyInside has posted more details.

Unfortunately, Ruby 1.8.7 is incompatible with all Rails versions prior to 2.1, according to the official Rails blog. Ruby 1.8.6-p230 isn’t much better: it breaks a number of applications and libraries. For example, Frédéric de Villamil, author of the well-known Typo blogging software, hosts a number of Typo blogs, and they have all been broken by the 1.8.6-p230 update.

Needless to say, nobody wants to choose between “leaving a security hole wide open” and “my apps don’t work”.

Ruby Enterprise Edition to the rescue

We released Ruby Enterprise Edition 1.8.6-20080621 yesterday, which is based on Ruby 1.8.6-p230. This breaks some apps.

Today we backported the security patches to Ruby 1.8.6-p111, and made a special Ruby Enterprise Edition release based on that. This release:

• doesn’t break your apps since it’s based on p111. Frédéric is happily running it on his production servers right now.
• doesn’t suffer from the security vulnerabilities.
• works with your exiting Mongrel setup. Ruby Enterprise Edition works best in combination with Phusion Passenger, but you don’t have to go for that combo.
• includes the usual Ruby Enterprise Edition features, such as reduced memory usage and improved performance.
• comes with an easy-to-install source tarball (which includes an installer).
• comes with an Ubuntu 8.04 package. For convenience, this packages bundle many common gems so that you don’t have to (re)install them manually. Multiple Rails versions are included. The full gem list is: actionmailer (2.1.0, 2.0.2, 1.3.6, 1.2.5) actionpack (2.1.0, 2.0.2, 1.13.6, 1.12.5) actionwebservice (1.2.6, 1.1.6) activerecord (2.1.0, 2.0.2, 1.15.6, 1.14.4) activeresource (2.1.0, 2.0.2) activesupport (2.1.0, 2.0.2, 1.4.4, 1.3.1) cgi_multipart_eof_fix (2.5.0) daemons (1.0.10) eventmachine (0.12.0) fastthread (1.0.1) gem_plugin (0.2.3) haml (2.0.0) hpricot (0.6) mongrel (1.1.5) mongrel_cluster (1.0.5) mysql (2.7) passenger (1.9.1) postgres (0.7.9.2008.01.28) rack (0.3.0) rails (2.1.0, 2.0.2, 1.2.6, 1.1.6) rake (0.8.1) rspec (1.1.4) sqlite3-ruby (1.2.2) thin (0.8.1)

Download & usage

You can download it from the Ruby Enterprise Edition website.

Everything in Ruby Enterprise Edition is self-contained, and switching to Ruby Enterprise Edition is only a matter of changing the commands that you normally run. In other words, if you’re using Mongrel on your production servers, then type:

/opt/ruby-enterprise-x.x.x/bin/ruby -S mongrel_rails cluster::start

instead of:

mongrel_rails cluster::start
[Ruby Enterprise Edition ]
View original post|Add to del.icio.us | Share

A new version of Ruby Enterprise Edition has been released, with the following changes:

MacOS X support A number of people have been waiting for this. Upgraded to RubyGems 1.2.0 A number of VPS users have reported that RubyGems 1.1.1 uses an excessive amount of memory, which causes their servers to swap to death. RubyGems 1.2.0 should solve this problem. No need to reinstall already-installed gems The RubyGems installation provided by Ruby Enterprise Edition will now reuse the gems that you have already installed (with regular Ruby). So if you have lots of gems installed, then you don’t need to reinstall them separately for Ruby Enterprise Edition. Merged with Ruby 1.8.6-p230 This solves the recent security vulnerabilities. How do I upgrade?

Go to the download page and follow the installation instructions. (*note*: RubyForge is still updating their mirrors, so the download might not be immediately available. In that case, please wait a few hours before trying again.)

[Ruby Enterprise Edition ]
View original post|Add to del.icio.us | Share

Harris Jacob has started working on Solaris support for Phusion Passenger, and he’s looking for testers. Please lend him a hand if you have a Solaris machine and would like to run Phusion Passenger in the future.

[Phusion Passenger ]
View original post|Add to del.icio.us | Share

Man, hardest talk ever, glad it went okay, now I can head off to bed… soon
For those of you guys that didn’t have the chance to attend Ruby en Rails 2008, we’ve taken the liberty of uploading our presentation files.

PDF Version
SWF Version (with toned down animations)

Getting back to Charles Nutter’s talk now

[General ]
View original post|Add to del.icio.us | Share

It’s a little bit late (this should have been done during RailsConf, sorry), but it’s finally here. We’re pleased to announce Phusion Passenger 2.0, release candidate 1. If no major issues are found, this will become version 2.0.1. We’re also pleased to announce the long-awaited Ruby Enterprise Edition.

RailsConf 2008 presentation

Our RailsConf 2008 presentation about Phusion Passenger and Ruby Enterprise Edition went extremely well. The sheets are available in the following formats:

• PDF (15 MB)
• Flash, with animations (32 MB)

The presentation includes a screencast (23 MB) created by Soocial.

Some people have been distributing our old, outdated sheets, which contain lots and lots of bullet points and almost no graphics. Please download the sheets on this page instead: these are the sheets that we used during the presentation.

Introducing Rack support

2 months after the release of Phusion Passenger 1.0, we present you with Rack support. It is now possible to host arbitrary Ruby web applications (e.g. Merb and Camping) on Phusion Passenger! We provide this feature with the same ease of use that many people have come to love.

The following screencast, created by Ryan Bates of RailsCasts fame, demonstrates the ease of deploying a Rack application on Phusion Passenger:

But that’s not all. We’ve done our homework. Our Users guide provides a comprehensive list of Rackup specifications for all Ruby web frameworks that we could find, so that you don’t have to hunt this information down yourself!

We received some Rack-related contributions shortly after Rack support had been pushed to the public git repository. We’d like to thank _why and remi for contributing documentation and full Rackup DSL support.

Introduction Python WSGI support

Not only do we support Rack, we now also support Python WSGI! In theory, Phusion Passenger can now run Django.

Don’t get us wrong. Phusion Passenger’s main focus is still on Ruby and Ruby on Rails. WSGI support is meant to be a show case of Phusion Passenger’s flexible architecture.

Optimizations Much better stability This new release is much more stable than the 1.0.x series. Many stability issues have been fixed. In fact, Dreamhost and iLike are using this version in production environments. So if you were experiencing stability problems, please upgrade to this version, as it may solve your problem. Much faster graceful restart Some hosts gracefully restart Apache often, so to them, high graceful restart speed is essential. Phusion Passenger 2.0 RC 1 is much, much faster at graceful restarts. Less memory usage: reduced VM size

Process monitoring tools tend to use the “VM size” of a process as an indication of the actual memory usage. This is not correct, because the VM size only indicates the amount of memory that a process can access, not the amount of memory that it actually uses.

Nevertheless, having a large VM size poses problems. Some servers, virtual private servers in particular, have artificial VM size limits in order to prevent processes from using too much memory. Phusion Passenger 1.0 makes Apache’s VM size very large (more than 100 MB), even though the actual memory usage is only several MB.

In Phusion Passenger 2.0, the VM size has been reduced by ten fold, as shown by the following diagram:

Fair load balancing (as opposed to round-robin load balancing)

One of the traditional problems of Mongrel Cluster behind Nginx is, in Ezra’s words:

“My only complaint was that the proxy modue was round robin only. This means that if you had 3 mongrels and one of them performed and action that took say 20 seconds, for that 20 seconds every 3rd request would get stuck in line behind the mongrel doing the long blocking request. This is because nginx was merrily doing round robin and didn’t care if a mongrel was busy or not.”

Phusion Passenger now supports fair load balancing. It will forward a request to the Rails instance with the least number of requests in its queue. Fair load balancing is turned on by default, without the need to configure anything.

See also page 53 of the presentation sheets.

Upload buffering

In Phusion Passenger 1.0, a (long) file upload will block a Rails application instance. Usually this is not a big problem, because Phusion Passenger will spawn more Rails instances if existing ones are blocked. But it becomes a problem if your website handles many simultaneous file uploads (read: more than 10 concurrent file uploads at any time).

Phusion Passenger 2.0 supports upload buffering. File uploads that are sufficiently large, are stored into a temporary file. Only when the file upload is done, will it be forwarded to the Rails application. This means that your Rails applications will not be blocked while a large file upload is in progress.

See slide 86 of the presentation sheets.

Default timeouts changed, in favor of virtual private servers

The default timeout values in Phusion Passenger 1.0 were optimized for shared hosts, which host many applications and need to free resources quickly. But most of our users seem to be using virtual private servers. These servers usually don’t get a lot of traffic, so the default timeouts are easily reached. So we’ve changed the default timeout values in favor of virtual private servers. Shared hosts and people running Phusion Passenger on dedicated servers should adjust the timeouts.

What Default in Phusion Passenger 1.0 Default in Phusion Passenger 2.0

RailsMaxPoolSize	20	6
RailsPoolIdleTime	120	300
ApplicationSpawner server idle time	120	600

Other improvements Ruby on Rails 1.0 compatibility Phusion Passenger is now compatible with Rails 1.0 applications as well. Improved application compatibility: conservative spawning

By default, Phusion Passenger preloads the Ruby on Rails framework and application code. This allows Phusion Passenger to reduce the startup time of Ruby on Rails applications and to save memory. Using this technique, startup time can be decreased by as much as 90%!

Unfortunately, some applications and/or plugins don’t expect to be preloaded, and even assumes that no code is being preloaded. soap4r is one such plugin. Until recently, these applications/plugins didn’t work with Phusion Passenger.

Phusion Passenger 2.0 implements so-called conservative spawning. In conservative spawning mode, Phusion Passenger will not preload any code. In other words, it will emulate the way Mongrel loads Rails applications. Conservative spawning allows Phusion Passenger to be 100% compatible with all Rails applications.

Conservative spawning is less efficient than the default spawning strategy, though no less efficient than Mongrel Cluster. You should only use conservative spawning if you’re experiencing compatibility problems.

‘RailsEnv’ is now per-virtual host The RailsEnv configuration option used to be a global option. It’s now a per-virtual host option, so you can define a different environment for every Rails application. New resource control option: ‘PassengerMaxInstancesPerApp’

The PassengerMaxInstancesPerApp option allows you to define the maximum number of pool slots that a single application may use. This will prevent a single application from getting out of control and taking over the entire server.

Many thanks to Jochen Tuchbreiter for contributing this feature.

Support for worker MPM The Apache worker MPM is now supported. Analysis and system maintenance tools Phusion Passenger 2.0 includes new analysis and system maintenance tools. If you’re experiencing stability problems with Phusion Passenger or your Rails application, then please try these tools. How do I upgrade to 2.0 RC 1? Via a gem

Please download the 2.0 RC 1 gem, then install it with the command:

gem install passenger-1.9.0.gem

Next, run:

passenger-install-apache2-module

Please don’t forget to copy & paste the Apache config snippet that the installer gives you.

Via a native Linux package

Neil Wilson from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb anstruction, and then run ‘apt-get update‘).

Once you’ve done this then you can install Phusion Passenger by running:

apt-get install libapache2-mod-passenger

Finally, run the following command. This will tell you how to configure Apache.

passenger-install-apache2-module Ruby Enterprise Edition

Ruby Enterprise Edition has been officially launched. Check out http://www.rubyenterpriseedition.com/

So far, Ruby Enterprise Edition has mostly been tested on Linux (both 32-bit and 64-bit). MacOS X is not yet supported: support for it is planned for a future version.

That’s all folks

A lot of work has been put into this release. Enjoy. If you like our work, please consider getting an “enterprise license”.

[Phusion Passenger Ruby Enterprise Edition ]
View original post|Add to del.icio.us | Share

Today, we were invited by Laurent Sansonetti of Apple to visit them over there. Needless to say, IT, WAS, AWESOME! Laurent is an awesome guy, and we had a lot of fun hanging out with him and Thomas, so if you’re reading this, we’re looking forward to meeting up with you guys soon again!

Pictures probably say more than words, so see below.

More to come in the following days, as we’re currently heading off to bed.

Cheers,
Hongli Lai
Tinco Andringa
Ninh Bui

P.S. Yes, I’m aware of the fact that the thumbs up thing is going to become my trademark Just be happy that you haven’t seen a thumbs down yet

[General ]
View original post|Add to del.icio.us | Share

Hi guys.

RailsConf 2008 was great, and our talk on Phusion Passenger and Ruby Enterprise Edition went really well. Fabio Akita has some pictures of our talk. For other pictures, see Fabio’s .mac gallery!

We promised to release Passenger 2.0 and Ruby Enterprise Edition on the same day. Unfortunately we’ve been too optimistic about Internet access. We’re currently at the airport and we have limited internet access until we are back in the Netherlands (which should be in about 4 days or so), but in the meantime, the Passenger version with Rack and WSGI support has already been pushed to github, so feel free to tinker around with it. We’ve also put the latest Users Guide (with Rack support) online.
Thanks for the support Chad!

We’re trying our best to find a way to push out Ruby Enterprise Edition as well, and ask the hardcopy guys to not release it prior to the moment that we’re able to push it (which should be in about 4 days). This launch will also be accompanied by a site etc… Feel free to blog about it though, and the reason why we’re asking this is because we want to keep the support at Phusion related places. This will prevent any ‘noise’ in communication.

Thanks for the support mateys!

Cheers,
Hongli Lai
Tinco Andringa
Ninh Bui

[Phusion Passenger RailsConf Ruby Enterprise Edition ]
View original post|Add to del.icio.us | Share