当corba服务器进程停止时，将阻止客户机调用

时间：2014-09-03 14:16:48

标签： multithreading client corba tao

这里的问题是当corba服务器停止时，Corba调用不会返回，也不会抛出任何异常。 在我的例子中，只有一个多线程corba代理（Window），监视一个后端corba服务器。 corba服务器的IDL是：

           void run()
           void echo();

代理通过echo heartbeat调用检查后端的运行状况。如果在echo中抛出corba异常，代理会将后端分类为DOWN状态。此过程在大多数时间有效，但后端关闭。

1）如果我关闭后端机器，echo会立即抛出异常。

2）如果我停止后端corba进程，则echo调用挂起且不返回，在客户端没有异常。客户不能再继续前进了。

在上述两种情况下都不会发生运行调用。

带有'ORBDebugLevel 10'的日志显示代理完成回送请求发送，并且netstat显示代理和后端机器之间有一个TCP连接虽然后端corba服务器进程已停止（我承认后端服务器无序或编程错误） 。但作为代理，它如何避免被单个调用失败阻止，如果它既不返回，也不抛出异常？

以下是两个日志，默认策略为：

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年前的经历类似。在这种情况下，调用在客户端的一个线程中发送。在接收响应之前，由于reactor模式，该线程被重用于发送另一个corba请求。这种情况似乎与此处的案例不同，因为它只是一个corba调用。我对线程堆栈的印象有点像：

 server.anotherInvocation()   //the thread is used for another invocation.
 ... 
 server::echo()    //send 1st corba invocation
 ....
 orb-run()

1 个答案:

答案 0 :(得分：0)

问题是，当网络堆栈检测到服务器断开连接时，它依赖于操作系统，有时它永远不会发生。更好，更安全的是设置RELATIVE_RT_TIMEOUT_POLICY_TYPE策略以强制调用超时，请参阅ACE_wrappers / TAO / tests / Timeout以获取此操作的示例。

相关问题
最新问题