OpenRTM-aistにおいて、以下の手順でCOMM_FAILURE_WaitingForReply例外を発生させることができる。
- OpenRTM-aistをインストールする。Windows、Ubuntuのどちらでも再現可能。
> bash <(curl -s https://raw.githubusercontent.com/OpenRTM/OpenRTM-aist/master/scripts/openrtm2_install_ubuntu.sh)
> /usr/share/openrtm-2.0/components/c++/examples/ConsoleInComp
ここでOpenRTM-aistのバージョンによっては-o "-ORBclientCallTimeOutPeriod 10000"のオプションが必要である。10000の部分は1以上であればほかの数値でも再現できる。この設定はDefaultConfigurationで設定しているが、Macで問題を再現できなかったのはOpenRTM-aistのバージョンが古かったためと推測。
- rtc_consoleout.confを以下の内容で作成する。
corba.args: -ORBinConScanPeriod 10
manager.components.preactivation: ConsoleOut0, rtcname://localhost:2809/*/ConsoleIn0
manager.components.preconnect: ConsoleOut0.in?port=rtcname://localhost:2809/*/ConsoleIn0.out
> /usr/share/openrtm-2.0/components/c++/examples/ConsoleOutComp -f rtc_consoleout.conf
- ConsoleInのターミナルで数値を1回入力後、10秒以上後にもう一度数値を入力すると、データポートの接続が切断される
omniORBのログは以下の通り。
ConsoleInのログを比較すると、COMM_FAILURE_WaitingForReplyが発生するが再接続してエラーなしの場合のログは以下の通り。
omniORB: (?) 2026-03-25 16:22:55.773562: sendChunk: to giop:tcp:192.168.240.12:41099 80 bytes
omniORB: (?) 2026-03-25 16:22:55.773617:
4749 4f50 0102 0100 4400 0000 0600 0000 GIOP....D.......
0300 0000 0000 0000 1700 0000 ff73 686f .............sho
7274 6375 74fe 3a8d c369 0100 6adb 0000 rtcut.:..i..j...
0000 0000 0400 0000 7075 7400 0000 0000 ........put.....
0c00 0000 0000 0000 0000 0000 ae08 0000 ................
omniORB: (?) 2026-03-25 16:22:55.773674: inputMessage: from giop:tcp:192.168.240.12:41099 12 bytes
omniORB: (?) 2026-03-25 16:22:55.773678:
4749 4f50 0102 0105 0000 0000 GIOP........
omniORB: (?) 2026-03-25 16:22:55.773683: Orderly connection shutdown: giop:tcp:192.168.240.12:41099
omniORB: (?) 2026-03-25 16:22:55.773684: throw giopStream::CommFailure from giopImpl12.cc:187(1,NO,COMM_FAILURE_WaitingForReply)
omniORB: (?) 2026-03-25 16:22:55.773717: Client connection giop:tcp:192.168.240.12:41099 refcount = 0
omniORB: (?) 2026-03-25 16:22:55.773731: Client close connection to giop:tcp:192.168.240.12:41099
omniORB: (?) 2026-03-25 16:22:55.773740: Send codeset service context: (ISO-8859-1,UTF-16)
omniORB: (?) 2026-03-25 16:22:55.773744: Client attempt to connect to giop:tcp:192.168.240.12:41099
omniORB: (?) 2026-03-25 16:22:55.773805: Client opened connection to giop:tcp:192.168.240.12:41099
omniORB: (?) 2026-03-25 16:22:55.773818: sendChunk: to giop:tcp:192.168.240.12:41099 104 bytes
omniORB: (?) 2026-03-25 16:22:55.773832:
4749 4f50 0102 0100 5c00 0000 0200 0000 GIOP....\.......
0300 0000 0000 0000 1700 0000 ff73 686f .............sho
7274 6375 74fe 3a8d c369 0100 6adb 0000 rtcut.:..i..j...
0000 0000 0400 0000 7075 7400 0100 0000 ........put.....
0100 0000 0c00 0000 0100 0000 0100 0100 ................
0901 0100 0000 0000 0c00 0000 0000 0000 ................
0000 0000 ae08 0000 ........
omniORB: (?) 2026-03-25 16:22:55.774125: inputMessage: from giop:tcp:192.168.240.12:41099 28 bytes
omniORB: (?) 2026-03-25 16:22:55.774149:
4749 4f50 0102 0101 1000 0000 0200 0000 GIOP............
0000 0000 0000 0000 0000 0000 ............
COMM_FAILURE_WaitingForReplyが発生してコネクタが切断されるの場合のログは以下の通り。
omniORB: (?) 2026-03-25 16:21:38.727879: sendChunk: to giop:tcp:192.168.240.12:40147 80 bytes
omniORB: (?) 2026-03-25 16:21:38.727936:
4749 4f50 0102 0100 4400 0000 0600 0000 GIOP....D.......
0300 0000 0000 0000 1700 0000 ff73 686f .............sho
7274 6375 74fe f18c c369 0100 65c5 0000 rtcut....i..e...
0000 0000 0400 0000 7075 7400 0000 0000 ........put.....
0c00 0000 b0fe ad9f ff7f 0000 de00 0000 ................
omniORB: (?) 2026-03-25 16:21:38.727983: Error in network receive (start of message): giop:tcp:192.168.240.12:40147
omniORB: (?) 2026-03-25 16:21:38.727997: throw giopStream::CommFailure from giopStream.cc:849(0,MAYBE,COMM_FAILURE_WaitingForReply)
omniORB: (?) 2026-03-25 16:21:38.728043: Client connection giop:tcp:192.168.240.12:40147 refcount = 0
omniORB: (?) 2026-03-25 16:21:38.728056: Client close connection to giop:tcp:192.168.240.12:40147
omniORB: (?) 2026-03-25 16:21:38.728063: throw COMM_FAILURE from omniObjRef.cc:707 (MAYBE,COMM_FAILURE_WaitingForReply)
必要最小限のログをそれぞれ抜き出すと以下の通り。
//以下でコネクション削除の通知(12byte)を受信、その後再接続処理を実行している。
omniORB: (?) 2026-03-25 16:22:55.773674: inputMessage: from giop:tcp:192.168.240.12:41099 12 bytes
omniORB: (?) 2026-03-25 16:22:55.773678:
4749 4f50 0102 0105 0000 0000 GIOP........
omniORB: (?) 2026-03-25 16:22:55.773683: Orderly connection shutdown: giop:tcp:192.168.240.12:41099
//以下で受信エラーとなり、その後,COMM_FAILURE_WaitingForReplyの例外を発生している
omniORB: (?) 2026-03-25 16:21:38.727983: Error in network receive (start of message): giop:tcp:192.168.240.12:40147
omniORB: (?) 2026-03-25 16:21:38.727997: throw giopStream::CommFailure from giopStream.cc:849(0,MAYBE,COMM_FAILURE_WaitingForReply)
ログの情報から、以下のRecv関数の戻り値がORBclientCallTimeOutPeriod の設定で異なると考えられる。
https://github.com/diegoreico/p2p-corba/blob/8a81e0a24714a7d6374cbae4b6045f9444d41217/servidor/omniORB-4.2.0/src/lib/omniORB/orbcore/giopStream.cc#L798-L812
Recv関数について、ORBclientCallTimeOutPeriod を0にした場合はblocking、1以上の場合はnonblockingで動作する。
このため、if (t.tv_sec || t.tv_usec) {の分岐のどこかで0以下を返す処理になっていると考えられますが、これ以上はデバッグ作業が必要になるので原因の特定は諦めます。
https://github.com/diegoreico/p2p-corba/blob/8a81e0a24714a7d6374cbae4b6045f9444d41217/servidor/omniORB-4.2.0/src/lib/omniORB/orbcore/tcp/tcpConnection.cc#L135-L158
OpenRTM-aistにおいて、以下の手順でCOMM_FAILURE_WaitingForReply例外を発生させることができる。
ここでOpenRTM-aistのバージョンによっては
-o "-ORBclientCallTimeOutPeriod 10000"のオプションが必要である。10000の部分は1以上であればほかの数値でも再現できる。この設定はDefaultConfigurationで設定しているが、Macで問題を再現できなかったのはOpenRTM-aistのバージョンが古かったためと推測。omniORBのログは以下の通り。
-o "-ORBclientCallTimeOutPeriod 0"の設定の場合trace_consoleout_noerror.txt
trace_consolein_noerror.txt
-o "-ORBclientCallTimeOutPeriod 10000"の設定の場合trace_consoleout_error.txt
trace_consolein_error.txt
ConsoleInのログを比較すると、COMM_FAILURE_WaitingForReplyが発生するが再接続してエラーなしの場合のログは以下の通り。
COMM_FAILURE_WaitingForReplyが発生してコネクタが切断されるの場合のログは以下の通り。
必要最小限のログをそれぞれ抜き出すと以下の通り。
ログの情報から、以下のRecv関数の戻り値が
ORBclientCallTimeOutPeriodの設定で異なると考えられる。https://github.com/diegoreico/p2p-corba/blob/8a81e0a24714a7d6374cbae4b6045f9444d41217/servidor/omniORB-4.2.0/src/lib/omniORB/orbcore/giopStream.cc#L798-L812
Recv関数について、
ORBclientCallTimeOutPeriodを0にした場合はblocking、1以上の場合はnonblockingで動作する。このため、
if (t.tv_sec || t.tv_usec) {の分岐のどこかで0以下を返す処理になっていると考えられますが、これ以上はデバッグ作業が必要になるので原因の特定は諦めます。https://github.com/diegoreico/p2p-corba/blob/8a81e0a24714a7d6374cbae4b6045f9444d41217/servidor/omniORB-4.2.0/src/lib/omniORB/orbcore/tcp/tcpConnection.cc#L135-L158