[openrtm-users 00908] ネームサービスの頑健性( ver 0.4.2におけるnon-blocking modeの不具合)

2 個の投稿 / 0 new
最終投稿
root
オフライン
Last seen: 6日 3時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00908] ネームサービスの頑健性( ver 0.4.2におけるnon-blocking modeの不具合)

栗原さん

松坂です。

2009/8/5 kurihara shinji :
> ver 1.0.0では、OrbRunnerでのManager::shutdown()呼び出しは行われ
> ないようになっておりますので、ver 0.4.2でも、OrbRunnerでの
> Manager::shutdown()呼び出しを行わないように修正して頂けますでしょ
> うか。

上記の件、了解しました。そのようにして使います。
ざっと他の実装も見てみたところ、0.4.1のpython版などももう対応済みだった
ようですね。1.0.0でも問題ないようで安心しました。
もし、また不具合が出ましたら報告します。

話は少し変わるのですが、現在OpenRTM-aistを遊びで使うフェーズから本格的な開発に
使わせてもらうフェーズに移っています。
本格的な開発、といってもその実態はコンポーネント上に複雑で重いアルゴリズムを実装し
はじめているということなのですが、そのような場合、特にデバッグ中に、execution loopの
中でSegmentation Faultが発生する等、コンポーネントが行儀よく終われないことが多いです。
CORBAは分散システムであるため、一つのコンポーネントが落ちたからといって
全体に影響することは少ないはずですが、OpenRTM標準の構成(omniORBベース)ですと、
コンポーネントの異常終了に引きずられてネームサービスもフリーズしてしまうことがあり、
他のコンポーネントが相互に参照できなくなる->システム全体を立ち上げ直す、という面倒な
作業をする必要がちょくちょくあります。

ネームサービスがCORBA分散システムのsingle point of failureになってしまう問題は
CORBA一般の問題として認識されているようで、それに対応した頑健なネームサーバの
実装というのもあるようですが、もし、このネームサーバは強いぞ、などのノウハウが
ありましたら教えてください。

未定義
root
オフライン
Last seen: 6日 3時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00919] ネームサービスの頑健性( ver 0.4.2におけるnon-blocking m

産総研の松坂です。

2009/8/6 Yosuke Matsusaka :
> ネームサービスがCORBA分散システムのsingle point of failureになってしまう問題は
> CORBA一般の問題として認識されているようで、それに対応した頑健なネームサーバの
> 実装というのもあるようですが、もし、このネームサーバは強いぞ、などのノウハウが
> ありましたら教えてください。

個人的に興味があったので、CORBAの頑健性について、もう少し深く調べてみました。
他の方にも役に立つかもしれない情報だと思いますのでシェアします。

CORBAの性能を測る場合、多くの場合、通信スピード(marshaling/demarshaling速度)が
注目されるようですが、以下のページの「IIOP Robustness Testing Tool」という節で面白いデータ
とテストプログラムが公開されています。
http://dsrg.mff.cuni.cz/projects.phtml?p=mbench&q=2

IIOPはCORBAオブジェクト間の通信プロトコルですが、このテストプログラムは、規格外のIIOP
プロトコルを用いて各CORBA実装と通信(=攻撃)してみて、その通信に対する頑健性を計って
います。
レポートでは、ORBacus, Orbix, MICOの3実装のテストが示されているのですが、アボートや
ハング等の異常動作だらけでかなり散々な結果だったようです。
2002年のレポートですし、omniORBはテスト対象ではないので、確たることを言うにはまたテストを
やり直さなければいけません(テストプログラムのomniORBへのポーティング作業も片手間で進めている
ので結果が出たらまたシェアします)が、よくよく考えればスピード重視のCORBA実装は、プロトコル
チェックや異常対応等の処理をうまくはしょることによってその速度を実現しているはずなので、
ある程度の脆弱さはやむなしというところなのかもしれません。

CORBAを頑健にしようという方法の一つに、Fault Tolerant CORBA (FT-CORBA)があり、これは
現在アクティブなオブジェクトだけでなく、アクティブなオブジェクトが応答しなくなったときの
バックアップとなる複数のオブジェクトを同時に起動しておき、クライアントから活性に応じて
接続先を切り替えるというもののようです。
この規格を実装したものにgrouppacがあり、頑健なネームサービスの実装も含んでいるとのこと。
http://sourceforge.net/projects/grouppac/
ただ、不安定であれば複数起動すればよいというアプローチはやや力技でメモリも食うので、ロボットへ
の応用を考えるとあまり適さないかもしれません。

2002年のテストで苦杯をなめたMICOですが、最近はSecure性能を売りにしているようで、
feature listを見ると、かなり魅力的な売り文句が並びます。
http://www.mico.org/
MICOはGPLであるため、ライセンスにLGPLを含むomniORBに比べると使いにくい部分もある
かもしれませんが、ネームサーバを使わせてもらうだけでも良いことがあるかもしれません。

コメントを投稿するにはログインまたはユーザー登録を行ってください

ダウンロード

最新バージョン : 2.0.1-RELESE

統計

Webサイト統計
ユーザ数:2195
プロジェクト統計
RTコンポーネント307
RTミドルウエア35
ツール22
文書・仕様書2

Choreonoid

モーションエディタ/シミュレータ

OpenHRP3

動力学シミュレータ

OpenRTP

統合開発プラットフォーム

産総研RTC集

産総研が提供するRTC集

TORK

東京オープンソースロボティクス協会

DAQ-Middleware

ネットワーク分散環境でデータ収集用ソフトウェアを容易に構築するためのソフトウェア・フレームワーク