GlassFishV2.1のクラスタでおこる、ふたつのバグと回避策

GlassFishのバグを見つけたので詳細報告。OSS版でも同じ現象が起こるかもしれない。

現象詳細
GlassFish V2.1系でインメモリーレプレケーションでクラスタを構築、ロードバランサープラグインを使いApacheなどのWebServerからロードバランシングを行う。このとき、セッション内容とスティッキー性が失われる場合がある。

■セッションの消失
   新しいSessionIDが発行され、それまでのセッション内容が保持できない
   F5キーを押下し続けて連続でリロードを行った場合に再現される
■ スティッキー性の消失
  同一クライアント、同一セッションでアクセス中に接続されているインスタンスが固定されない

上記、現象が併発した場合、同一SessionIDにもかかわらずインスタンスごとに違う内容のセッションを保持しているケースも確認された。

原因
■ セッションの消失

複数のクライアントから同時に同じSessionIDへアクセスした場合に、SessionIDが変わることがある。F5押下(KeyPress-Keep)による連続リロードや複数のAjaxによる同一SessionIDへアクセスした場合などに発生する。

Cookie情報であるJSESSIONIDVERSIONがセッション情報のキャッシュを管理している。通常、同一セッションへのアクセスごとに連続した値(プラス1づつカウントアップ)を返すが、同時に同じセッションIDへアクセスした場合に、不正な値を返す場合がある。

JSESSIONIDVERSIONが不正な値を返した場合に、それまでのSessionIDが無効と判断され新しいSessionIDが発行される。

■ スティッキー性の消失

Cookie情報のうちJROUTEの値が稼動しているインスタンスの識別子となる。アクセスしているインスタンスが停止した場合、稼動中のインスタンスに対応する識別子に変更される。

JROUTEを書き換えるのはロードバランサプラグインが行うが、設定ファイルであるloadbalancer.xmlがCookie情報の書き換え禁止するオプションで出力されている。アクセス中のインスタンスが停止した場合、JROUTEが設定されずスティッキー性が失われる。

回避策

■セッションの消失への対応
relaxCacheVersionSemanticsを設定する。ただし、9.1U2P05以降でのみ有効

配備するsun-web.xmlに非公開パラメータである以下を記述
  <session-config>
    <session-manager persistence-type=”replicated”>
      <manager-properties>
        <property name=”relaxCacheVersionSemantics” value=”true”/>
      </manager-properties>
この設定によりJSESSIONIDVERSIONが正しい値を返すようになる。

実は、このrelaxCacheVersionSemanticsは非公開パラメータ。マニュアルに載せて欲しいとは言っておいたがどうなるのだろう。

■ スティッキー性の消失への対応

一時的な回避策としてloadbalancer.xmlに以下を記述する(falseからtrueに変更)。
または、設定を削除する。

 <property name=”rewrite-cookies” value=”true”/>

この設定によりアプリケーションサーバでCookie情報(JROUTE)の書き込みを許可する。ただし、現在、Oracleが対応しているバグ修正では、GlassFishでJROUTEへの書き込みを行うため、修正版のリリース後は、上記設定は不要になるはず。

V3での対応は不明だがお願いはしておいた。たぶん、ちゃんと対応してくれるはず。
オマケ GlassFishのコードを簡単にカスタマイズする

GlassFishで使用されている同名クラスを作成して、jarにまとめる。

GlassFishの管理GUIからConfiguration->server-config->JVM Settings->Path Settingsへと進む。Classpath Prefixにjarファイルを設定後、GlassFishを再起動

オリジナルのコードが既存のJavaクラスに上書きして使用される。

大学院ではロボットを研究しているんだ

中間発表のスライドをUPしたよ。

ついでにテーマ発表のスライド。
半年前から進展しているんだろうか……

リッツパリー

いつもお世話になっているエンジニアライフの皆さんとライトニング大会を開きました。
プレゼンのネタ、実はやりきれなかったネタがもうひとつがあったんだぜい。

当日の模様はこんな感じ
http://www.ustream.tv/channel/engineerlife-lt2010

自己紹介

http://www.ustream.tv/recorded/9803901
17分50秒あたり

ライトニングトーク本編

http://www.ustream.tv/recorded/9805582
9分20秒あたり

パネルディスカッションまとめ

http://www.ustream.tv/recorded/9806749
5分40秒あたり

Javaでシリアル通信

Java Communications API というライブラリがあるがメンテされていない。が、その仕様に準じたRXTXというOSSがある。

http://www.rxtx.org/

配布先からダウンロードして解凍。

RXTXcomm.jar と、各種OS用のドライバをclasspathの通っているディレクトリに置く。

eclipseならプロジェクトごとにクラスフォルダを作ってそこに配置

ちゃんと調べてないけど、多分、JNIで実装されているっぽいので
WindowsならDLL、Linuxなら.soとOSごとに異なるライブラリが必要になのだと。

で、Javaでシリアル通信ができて何がうれしいかというと、ArduinoとJavaでお話ができちゃうのだ。送信のほうは簡単だけど、受信はイベント駆動なので少し手間っぽい。今の段階では送信さえできていればロボットの操作ができるのでOKとしよう。

追記
RXTXcomm.jarのプロパティから、「ネイティブライブラリのロケーション」でdllを置いたパスを指定する

babelを使ってeclipseを日本語化する

eclipse起動後
[Help]-[Install New Software…]からダイアログを開く

Name: Babel
Location: http://download.eclipse.org/technology/babel/update-site/galileo

babel Language Packs in Japanese を選択、から日本語ランゲージパックを取得してeclipseを再起動

OpenCV2.1のインストール

コンパイルが不要のOpenCV-2.1.0-win32-vs2008.exe をダウンロード

インストーラを起動してインストール

デフォルトで

c:\OpenCV2.1\

に展開される。

c:\OpenCV2.1\include\opencv インクルードファイル
c:\OpenCV2.1\lib ライブラリファイル

をVisualStudioのパスに設定。

ライブラリファイル名にバージョンナンバーの追加と
デバッグモード用のライブラリ(~d.lib)が用意されている。

2.0→2.1への移行はヘッダを変更する。

#include "cv.h"
#include "highgui.h"

#ifdef _DEBUG
  #pragma comment(lib,"cv210d.lib")
    #pragma comment(lib,"cxcore210d.lib")
    #pragma comment(lib,"cvaux210d.lib")
    #pragma comment(lib,"highgui210d.lib")
#else
  #pragma comment(lib,"cv210.lib")
    #pragma comment(lib,"cxcore210.lib")
    #pragma comment(lib,"cvaux210.lib")
    #pragma comment(lib,"highgui210.lib")
#endif

はじめての電子工作

モーターの制御がわかったので、TA7291をarduinoと連携できるように組み込んでみた。
ここらへんとか参考にする。

違いといえば、ノイズ対策にコンデンサを追加したぐらい。

で、適当なメモをで書くぐらいで電子工作ができちゃった。意外と敷居が低い。

Fritzingというソフトを導入して、モーター制御のブレッドボードを整理。実際のボードとは違うけど、テキトーな感じで

2つ、モータが制御できれば、戦車が作れるのだ。

SimbadをEclipseで使う場合のメモ

simbad実行中

Java3Dをインストール

Simbadをダウンロード

Eclipseプロジェクトにjarを登録
j3dcore.jar
j3dutils.jar
vecmath.jar
simbad-1.4.jar

ビジョン

数名ほど、ロボット関係者にお会いしてみた。

具体的な名前はだせないけど、
個々の要素技術は素晴らしい。

どうやら、足りないのはそれらをまとめ、具体的なコンセプトとしてまとめることみたいだ。
ロボットの難しいところは、それが複合技術であること。要素技術の組み合わせでひとつのロボットで作られる。それが組み合わさったときにどういう形を見せるのか。

エンジニアが自前でWebサイトを作ると、原色バリバリ使っちゃったり、妙にヘンな動きをするJavaScriptを実装してがっかりすることがあったりする。それと似ているのかもしれない。

エンジニアとデザイナが分業としているように、ロボットの要素技術を作ることと、要素技術を組み合わせてロボットを作ることは、まったく別のスキルなのだろう。

ロボットを作りたくなってきた

レスキューロボットには大きくわけて2種類のタイプがある。

ひとつは、作業タイプ。瓦礫除去を目的とするパワー型。もうひとつは、調査タイプ。瓦礫の中にもぐりこんで要救助者の発見というミッションが与えられる。どちらも、試験的に現場に投入されることはあっても実用化にはいたっていない。

探索型ロボットは、1台のロボットが高機能、大型化していく傾向にあるようだ。

ここで仮定。

もし、低コストで安価な探索型レスキューロボットが作れるとしたら?100台ぐらいのロボットを使って探索エリアを網羅的に探索することができるかもしれない。