日々の破片

_ じゅんく堂トークセッションJRubyKaigi前夜祭

じゅんく堂で、大場夫妻、橋本さん、なぜかなひさんのトークセッション。

最初に大場さんから、なぜなひさんが最（向かって）右翼にいるのか説明。おっかない人、見た目通り、だからこちら側に置いておいた方が安全。ひでぇ言いようだが、そのあたりはasakusarbの和気藹々とした雰囲気乗りということなのだろう、きっと。

で、本の紹介から。

JRuby on Railsシステム構築入門 (DB Magazine SELECTION)(橋本 吉治)

橋本さんは、DBマガジンの（日本でも最初期の）Ruby連載がいつの間にかこうなってこうなった、と紹介。

企業人が1週間程度かけてJRuby on Railsの評価（採用するかとか）をするときに手元に置くのにふさわしい本なのは、おれもよーく読んだから知っているけど事実。

でも、良く話を聞いていると、JRubyが使い物にならなかった時の押さえにMRIとSOAP4Rを用意しておいたとか言っていたけど、それはどうなのかなぁ。コンポーネントはできるだけ使いまわしたほうがお得だという事実を考えれば、MRI＋rjb＋JAX-WSのほうが遥かに良いと思うのだが（速度的な面で。測ってないけど、パーズの速度はMRIよりJavaのほうが高速だと思うんだよなぁ。というのは、SOAPで一番のボトルネックはXMLマーシャリング/アンマーシャリングだから（これは.NETでの経験だけど、JavaでもXMLマーシャリング/アンマーシャリングは結構な時間が必要だし、SOAP4RがどれだけうまくやったとしてもMRIの速度に制限されるわけだからなぁ、とかは思った。

一方、大場夫妻はオラビニ本の翻訳だが、とにかくオラビニは頭が切れるらしく妙に詳細から詳細へ話が飛ぶので読みにくいことこの上ないので、そこは思いっきり日本語化するときに読みやすく変えたとか言っていた。それで、内容がそれなりに深掘りしたりしているのに読みやすいのかな。

JRuby on Rails実践開発ガイド (Professional Ruby Series)(Ola Bini)

ウリは、巻末のJRubyリファレンスだとか。手元のやつを読むと、java.lang.Runnableに追加した（Rubyから扱いやすいように）メソッドのto_procとか、プリミティブ型配列のto_java（大場さんの好きなメソッドらしい）とかのことかな。確かに日本語ドキュメントとしてはコンパクトにまとまっている。

で、JRubyKaigi（RubyKaigi2010の2日目）の紹介と、Tシャツ買ってくれ（サーブレットガール（でも20世紀のことだからサーブレット姫と呼ぶらしい）の来日費用になるらしい）のお願いとか。

懇親会で、なひさんとJMSの記述についての問答。

JMSで投げるとこまで（橋本本）、結果をスリープしながらポーリング（オラビニ本）、どっちも中途半端と思う。どう実装する？

おれだったら（橋本本のは読んだがオラビニ本のその部分は読んでいないので半分想像だが）、別にプロセス立ててそっちで待たせる。戻ってきたら127.0.0.1:80へPOSTしてRails側へ渡す。（または、J2EE規約では非推奨または反則だが、受信スレッドを別立てしてそこでキュー待ちさせる）とか答える。

が、今になって考えると、橋本本のほうはともかくオラ本のほうがそういう変な待ち方をするということはそもそもインターフェイスがまずいのだろう。

つまり、クライアント→サーバ→JMS（どこか）JMS→サーバ→クライアント という処理をしようとしているに違いない。

これはまったく良くない。

クライアント→サーバー→JMS（どこか）

クライアント←サーバー（投げた）

として、ポールするならクライアントにやらせるべき問題だ。

クライアント→サーバー（受信していたらその旨返答）

以前はこういうことをやろうとするとREFRESHみたいな野蛮な方法しかなかったが、今ならAjaxでこっそりやれるのだから、そのほうが良い。

この時、JMS経由の応答はやはり別プロセスか別スレッドで応答を受信したという状態をDBにストアしておく。

だが、もしクライアント−サーバのネットワークトラフィックが問題となるようなシステムだったら本当にポールは正しい方法か？

それはたぶん異なる。であればトラフィックを減らす工夫、たとえばCOMETを使うとかする。この方法だと、別プロセスから受信したという状態をRailsに回せば、そこでCOMETのキューをキックできる。

あるいは、クライアントが応答を必要としているのだから、JMSを使わずに確定応答な通信を上位サーバと行うか、だ。

それでもクライアント、上位サーバの仕組みがどうにもレガシーで、クライアント側は上位サーバの結果を一連の動作として表示したく、しかも上位サーバとはJMSを使う必要があるとすればどうするのが良いだろうか？

その場合も別プロセスでJMSのキュー待ちさせて受信したら、127.0.0.1:80を叩き、その中でsynchronized, notifyAll, すれば良い。つまり、JMSへキューした元のリクエスト処理スレッドはタイマー付でwaitさせておく。もちろんスレッドを1つ占有するのだからろくでもない仕組みだが、周り（クライアントは応答を待ちたく、上位サーバはJMSでリクエストを要求する）がそれを要求しているのだから、そのほうが良い。

で、こういう場合はJMS経由の応答待ちの最大スレッド数を決めておき、サーブレットコンテナにはそれ以上のスレッドを割り当てて、待ち状態のスレッド数が上限だったらビジーを即座にクライアントへ返す処理をコントローラの先頭に入れておけば良い。

とかいろいろ方法はあるなぁ。