Home Index Changes Prefs Log in »
View Info

Ruby/JRuby Process Models Explained (by Arun Gupta 8/20/07)

JRuby Hackday にて、Nick Sieger は以下に Rails アプリケーションを配備した際のプロセスモデルを解説しました。

本ブログエントリで、私はイベント後の頭の中のダンプをとります。以下の画像は上で述べた各アプローチのプロセスモデルです。各画像のに含まれている箱はプロセスでなく、アプリケーションロジックを表します。画像の凡例は次のようなものです。

最初のアプローチでは、C ベース Ruby on Rails アプリケーションは、フロントに HTTP ライブラリ、Mongrel を置いています。典型的なアプリケーションは Mongrel サーバのクラスタ (Mongrel_cluster プラグイン で提供される) に配備されます。


このプラグインは複数の Mongrel サーバを設定し、制御します。Mongrel は概ね Ruby で書かれていて、HTTP リクエストのパースに ネイティブ C を使っています。Mongrel の各インスタンスはサーバソケットをリッスンする Ruby インタプリタを起動します。Ruby スクリプトには Mongrel ハンドラがあり、クライアントからの複数のリクエストをキューに置き、状態を一つずつ Rails インスタンスに渡します (これはシングルスレッドで設計されています)。

Mongrel クラスタでは、複数の Ruby インタプリタは OS の単一プロセスとして起動されます。



二つ目のアプローチは、Rails アプリケーションを JRuby を使って配備するかを示します。これは、C Ruby + Mongrel 配備と JRuby + GlassFish 配備の間の過渡的なアプローチです。


Mongrel JCluster は JRuby のみで動作する Mongrel_cluster のアップデートです。最大の違いは JVM インスタンスを一つだけ起動し、複数の Mongrel を同一の JVM 内でスレッドとして複数の JRuby プロセスとして起動することです。伝統的なアプローチと同様、各 Mongrel はサーバソケットをリッスンし、リクエストの状態を Rails に渡します。







Mongrel JCluster では、OS プロセスとしては、JVM が一つ起動されるのみです。

最後のアプローチは JRuby アプリケーションをどう GlassFish に配備するかを示します。このアプローチでは、アプリケーションを配備する上で二つのモードがあります。


一つ目の場合、Goldspike プラグイン が標準的な Rails アプリケーションにインストールされます。このプラグインは "war:*" rake ターゲットを Rails プロジェクトに追加します。rake ターゲット "war:standalone:create" を実行すると、依存性のある JRuby と Rails ライブラリを全て含む WAR ファイルを生成します。そうすると、この WAR ファイルを GlassFish に配備できます。この WAR ファイル内の "web.xml" には、Servlet リクエストから Rails ディスパッチャへデータを変換する Servlet (org.jruby.webapp.RailsServlet) が載っています。








二つ目の場合では、Grizzly コネクタ がリクエストの形式を理解し、直接、事前に設定された JRuby インストール (Rails gem で更新されます) にディスパッチします。両方の場合で、GlassFish としては単一の JVM が OS プロセスとして動いています。二つ目のアプローチの主な利点は、web アプリケーション処理をバイパスし、リクエストを直接 Rails フレームワークに委任することです。







最初の GlassFish のケース (Goldspike/JRuby) に関する詳しいスクリーンキャストはこちら で、二つ目のケース (Grizzly/JRuby) はこちら にドキュメントされています。

日本語翻訳: ogino

英文

« Home Attachments Info Index Changes Prefs
This page (revision-2) was last changed on 12-May-08 22:11 PM, -0700 by Shinya Ogino