OSGI:felix:bundleIDの戻し方(GFv3)

uninstallしても、bundleIDがインクリメントされてしまう。同じIDを再利用できなかと調べてみたら、以下のファイルに保存されているようだ。

osgi-cache/felix/bundle0/bundle.id

このファイルを編集して番号を戻し、以前と同じIDを使用できるようにしようと思ったのだが、単に変更しただけではだめだった。

refresh かけた ＝＞ だめ
update 0 ＝＞ GlassFish自体が落ちてしまった
再起動 ＝＞ うまくいった

結果オーライだが、くれぐれも既存のbundleを上書きしないように注意しよう。

OSGI:bundleの不思議な挙動

OSGIのbundle(モジュール)をインストールしたところ、新しく追加したリソースが見えていないような症状となった。

[#|2012-01-11T14:49:15.740+0900|WARNING|glassfishv3.0|net.korabo.cmt.spord.svc.msg.plugin.FireSubscriberPluginWRpldChk|_ThreadID=187;_ThreadName=Thread-1;|ErrorInCheckOF:[net.korabo.cmt.spord.svc.msg.CommonMsg@152886a]
com.ibatis.sqlmap.client.SqlMapException: There is no statement named MSGACCEPTANCE_ALT.selectTsRpldByPrimaryKey in this SqlMap.
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.getMappedStatement(SqlMapExecutorDelegate.java:231)

実際のパッケージ(jar)やGlassFishV3 の domains/domain1/osgi-cache/felix/を見てもファイルは更新されているはず、、、

telnet localhost 6666 (felixの場合)でOSGIのコンソールに入って様子を見ると、、、

ps
[ 219] [Active ] [ 1] spord-controll-osgi (1.0)
[ 223] [Active ] [ 1] spord-appstarter-osgi (1.0)

inspect package requirement 223
spord-appstarter-osgi [223] imports packages:
---------------------------------------------
ibatis; version=0.0.0 -> spord-appstarter-osgi [220]
org.osgi.framework; version=1.5.0 -> org.apache.felix.framework [0]
..........

となっており、PSでは見つからない220番を参照していることになっている！？

ちなみに osgi-cache/felix/bundle220 は存在しており、MANIFESTでの定義は、

Import-Package: ibatis;resolution:=optional

となっていた。

手順としては　220番が存在していた時に unistall して、同じパッケージを新たなbundleとして install しただけ。

じつは、これだけだと変更がコミットされていなかった！ 変更後に refresh をかけることが必須である。

参考：http://d.hatena.ne.jp/IkeT/20090325/1237945826

んで、推奨手順：

# 新規のみ
# install xxxxx.jar
# 更新時
stop
update file:///xxxxx.jar
# 共通
refresh
start

パフォーマンスチューニング

実行速度のパフォーマンスが悪いと感じる場合の対処法をまとめる。
■前提として
　実行速度や処理効率の目安として以下の２つを想定する
　　・反応速度：ある処理を起動してから応答が返るまでの時間
　　・スループット：単位時間あたりに処理できる件数
　単独で測定している場合は、反応速度を見ていることになるのだが、
同時複数の処理をさせる場合にはスループットが重要になる。システムが
理想的なスケーラブル性を持っている場合は、規模を調節することで
スループットを自由に変更できることになるのだが、実際には様々
な要因により、反応速度が速くても、ある件数以上になるとスループット
が落ちてしまうのが普通である。
　速度の早い、遅いは相対的なものであり、絶対的な指標は存在しない。
対象とするシステムにおいて妥当な値から見てどれくらい劣化しているか
と考える必要がある。慣用的に用いられる4秒ルールなどは、人間相手の
反応速度としては妥当であろう。(ちなみに、この4秒はTV放送などの世界で
は黙っていられる限界と思われているようで、これ以上沈黙が続くと視聴者
が違和感を感じる長さのようだ)

■解決のための一般的ステップ
　以下のような順序で対応すれば解決への糸口が見つかるであろう。
１）調査：詳細な情報の収集
２）対象範囲確定：関連のありそうな部分とそれ以外を分離
３）データ収集：ログや設定値など
４）問題個所の推定：３）との繰り返し
５）再現：環境や条件をなるべく合致させて
６）対処：設定変更やコード修正
７）確認：

■調査
　できる限り詳しく状況を聞き取る。早い、遅いは個人的・相対的な値である
場合が多いので、数値の表わせるものとして取得すること。ポイントは下記のもの。

・処理状況：
　　どんな状況で、どの処理や操作をした場合にパフォーマンス劣化を認められたか
・データ
　　特定のデータを使用した場合に発生するか
・繰返し：
　　特定の回数繰り返した場合に発生するか、単独で発生するか
・時系列的推移：
　　いつからそうなったのか
・他の処理との関連：
　　特定の時間帯でないと発生しないか
　　他の処理を同時に行った場合にのみ発生するか

■対象範囲確定
　関連しない部分を切り離し、関連する部分を明らかにする。
・ネットワーク
　　実行環境でネットワークに依存する部分がある場合
・データベース
　　実行環境がデータベースを使用している場合
・マシン
　　該当するマシンすべて

■データ収集
　設定値一覧やログファイルなどの処理実行の定義と経過に関するデータを取得する。
　当該アプリケーションそのものだけでなく、その動作環境において調査対象とした
すべての部分を考慮する必要がある。例を以下に示す。

・システム設定、システムログ
・サーバ設定、ログ：アプリケーションがAppServerなどで動作している場合
・データベース設定、ログ：DBを使用している場合
・ネットワーク設定、ログ：ネットワークを使用していて関連がある場合

　もし、有用な情報が取得できない場合は、フラグを設定して詳細情報を出力するように
変更してから再現させてログを取得するべきである。

■問題個所の推定
　収集したデータから問題となりそうな対象と無関係な対象を切り分けていく。
　関連がある対象に関しての情報を精査し、問題個所を推定する。
・ネットワーク
　　同じネットワークを使用する別のアプリケーションの動作状況などを調査して問題性の有無を確認
・データベース
　　同じデータベースを使用する別アプリケーションなどを調べる
・マシン
　　同じマシンで稼働する別のアプリケーションや、システムログの情報から

　対象がしぼれてくれば、フラグを追加して詳細ログを取ったり、ソースを調査して原因と
なりそうな部分を見つけるなどの方法を試す。