这里的问题是 Corba 调用不会返回，并且当 corba 服务器停止时不会抛出任何异常。在我的例子中，只有一个多线程 corba 代理（窗口），监控一个后端 corba 服务器。corba 服务器的 IDL 为：
void run()
void echo();
代理通过 echo heartbeat 调用检查后端的运行状况。如果在 echo 中抛出 corba 异常，代理会将后端分类为 DOWN 状态。此过程在大多数情况下都有效，但后端已关闭。
1）如果我关闭后端机器，回显会立即抛出异常。
2）如果我停止后端corba进程，回显调用挂起并且没有返回，而不是客户端异常。客户不能再去未来了。
以上两种情况均未发生运行调用。
带有“ORBDebugLevel 10”的日志显示代理完成了回显请求发送，并且 netstat 显示尽管后端 corba 服务器进程已停止，但代理和后端机器之间存在一个 TCP 连接（我承认后端服务器无序或编程错误）。但是作为代理，如果它既不返回也不抛出异常，如何避免被个别调用失败阻塞？
以下是两个日志，采用默认策略：
TAO (276|1592) - Invocation_Adapter::invoke_i, making a TAO_CS_REMOTE_STRATEGY i
nvocation
TAO (276|1592) - Transport_Cache_Manager_T::is_entry_available_i[828], true, sta
te is ENTRY_IDLE_AND_PURGABLE
TAO (276|1592) - Cache_IntId_T::recycle_state, ENTRY_IDLE_AND_PURGABLE->ENTRY_BU
SY Transport[828] IntId=00A64ABC
TAO (276|1592) - Transport_Cache_Manager_T::find_i, Found available Transport[82
8] @hash:index {-1062676757:0}
TAO (276|1592) - Transport_Connector::connect, got an existing connected Transpo
rt[828] in role TAO_CLIENT_ROLE
TAO (276|1592) - Muxed_TMS[828]::request_id, <4>
TAO (276|1592) - GIOP_Message_Base::dump_msg, send GIOP message v1.2, 60 data by
tes, my endian, Type Request[4]
GIOP message - HEXDUMP 72 bytes
47 49 4f 50 01 02 01 00 3c 00 00 00 04 00 00 00 GIOP....<.......
03 00 00 00 00 00 cd cd 1b 00 00 00 14 01 0f 00 ................
52 53 54 00 00 00 6c 00 06 9c b5 00 00 00 00 00 RST...l.........
00 00 01 00 00 00 01 cd 05 00 00 00 65 63 68 6f ............echo
00 cd cd cd 00 00 00 00 ........
TAO (276|1592) - Transport[828]::drain_queue_helper, sending 1 buffers
TAO (276|1592) - Transport[828]::drain_queue_helper, buffer 0/1 has 72 bytes
TAO - Transport[828]::drain_queue_helper (0/72) - HEXDUMP 72 bytes
47 49 4f 50 01 02 01 00 3c 00 00 00 04 00 00 00 GIOP....<.......
03 00 00 00 00 00 cd cd 1b 00 00 00 14 01 0f 00 ................
52 53 54 00 00 00 6c 00 06 9c b5 00 00 00 00 00 RST...l.........
00 00 01 00 00 00 01 cd 05 00 00 00 65 63 68 6f ............echo
00 cd cd cd 00 00 00 00 ........
TAO (276|1592) - Transport[828]::drain_queue_helper, end of data
TAO (276|1592) - Transport[828]::cleanup_queue, byte_count = 72
TAO (276|1592) - Transport[828]::cleanup_queue, after transfer, bc = 0, all_sent
= 1, ml = 0
TAO (276|1592) - Transport[828]::drain_queue_helper, byte_count = 72, head_is_em
pty = 1
TAO (276|1592) - Transport[828]::drain_queue_i, helper retval = 1
TAO (276|1592) - Transport[828]::make_idle
TAO (276|1592) - Cache_IntId_T::recycle_state, ENTRY_BUSY->ENTRY_IDLE_AND_PURGAB
LE Transport[828] IntId=00A64ABC
TAO (276|1592) - Leader_Follower[828]::wait_for_event, (follower), cond <00B10DD
8>
使用静态 Client_Strategy_Factory "-ORBTransportMuxStrategy EXCLUSIVE"
2014-Sep-03 16:34:26.143024
TAO (6664|5612) - Invocation_Adapter::invoke_i, making a TAO_CS_REMOTE_STRATEGY
invocation
TAO (6664|5612) - Transport_Cache_Manager_T::is_entry_available_i[824], true, st
ate is ENTRY_IDLE_AND_PURGABLE
TAO (6664|5612) - Cache_IntId_T::recycle_state, ENTRY_IDLE_AND_PURGABLE->ENTRY_B
USY Transport[824] IntId=00854ABC
TAO (6664|5612) - Transport_Cache_Manager_T::find_i, Found available Transport[8
24] @hash:index {-1062667171:0}
TAO (6664|5612) - Transport_Connector::connect, got an existing connected Transp
ort[824] in role TAO_CLIENT_ROLE
TAO (6664|5612) - Exclusive_TMS::request_id - <3>
TAO (6664|5612) - GIOP_Message_Base::dump_msg, send GIOP message v1.2, 60 data b
ytes, my endian, Type Request[3]
GIOP message - HEXDUMP 72 bytes
47 49 4f 50 01 02 01 00 3c 00 00 00 03 00 00 00 GIOP....<.......
03 00 00 00 00 00 cd cd 1b 00 00 00 14 01 0f 00 ................
52 53 54 00 00 00 55 00 0d 7a 85 00 00 00 00 00 RST...U..z......
00 00 01 00 00 00 01 cd 05 00 00 00 65 63 68 6f ............echo
00 cd cd cd 00 00 00 00 ........
TAO (6664|5612) - Transport[824]::drain_queue_helper, sending 1 buffers
TAO (6664|5612) - Transport[824]::drain_queue_helper, buffer 0/1 has 72 bytes
TAO - Transport[824]::drain_queue_helper (0/72) - HEXDUMP 72 bytes
47 49 4f 50 01 02 01 00 3c 00 00 00 03 00 00 00 GIOP....<.......
03 00 00 00 00 00 cd cd 1b 00 00 00 14 01 0f 00 ................
52 53 54 00 00 00 55 00 0d 7a 85 00 00 00 00 00 RST...U..z......
00 00 01 00 00 00 01 cd 05 00 00 00 65 63 68 6f ............echo
00 cd cd cd 00 00 00 00 ........
TAO (6664|5612) - Transport[824]::drain_queue_helper, end of data
TAO (6664|5612) - Transport[824]::cleanup_queue, byte_count = 72
TAO (6664|5612) - Transport[824]::cleanup_queue, after transfer, bc = 0, all_sen
t = 1, ml = 0
TAO (6664|5612) - Transport[824]::drain_queue_helper, byte_count = 72, head_is_e
mpty = 1
TAO (6664|5612) - Transport[824]::drain_queue_i, helper retval = 1
TAO (6664|5612) - Leader_Follower[824]::wait_for_event, (follower), cond <009009
10>
我知道这可能是线程和 ORB 模型问题。我尝试了一些客户策略：
静态 Client_Strategy_Factory "-ORBTransportMuxStrategy EXCLUSIVE -ORBClientConnectionHandler RW"
这可以减少问题发生的频率，但不能完全解决问题。
这与我 6 年前的经历相似。在这种情况下，调用会在客户端的一个线程中发送。在收到响应之前，由于反应器模式，该线程被重用于发送另一个 corba 请求。这个案例似乎与这里的案例帖子不同，因为它只是一个 corba 调用。我对线程栈的印象有点像：
server.anotherInvocation() //the thread is used for another invocation.
...
server::echo() //send 1st corba invocation
....
orb-run()