여기서 문제는 corba 호출이 반환되지 않고 corba 서버가 중지되었을 때 예외가 발생하지 않는 것입니다. 필자의 경우 하나의 다중 스레드 corba 프록시 (Window)만이 하나의 백엔드 corba 서버를 모니터링합니다. corba 서버의 IDL은 다음과 같습니다.corba 서버 프로세스가 중지되었을 때 클라이언트 호출이 차단되었습니다.
void run()
void echo();
프록시는 echo heartbeat 호출을 통해 백엔드의 상태를 검사합니다. echo는 corba 예외가 발생하면 프록시는 DEND 상태로 백엔드를 분류합니다. 이 절차는 대부분의 시간 동안 작동하지만 백엔드는 종료됩니다.
1) 내가 백엔드 시스템을 종료하면 에코가 예외를 즉시 throw합니다.
2) 백엔드 프로세스를 중지하면 에코 호출이 중지되고 클라이언트 측에서 예외가 발생하지 않습니다. 클라이언트는 더 이상 갈 수 없습니다.
위의 두 경우에서 실행 호출이 발생하지 않습니다.
'ORBDebugLevel 10'은 프록시가 에코 요청을 완료했다는 것을 보여 주며, netstat는 백엔드 corba 서버 프로세스가 중지되었지만 프록시와 백엔드 시스템간에 하나의 TCP 연결을 수행함을 보여줍니다 (백엔드 서버가 불규칙하거나 잘못 프로그래밍됨을 인정합니다). 그러나 프록시로서, 반환하지 않거나 예외를 throw하지 않으면 개별 호출 실패로 차단되는 것을 방지하는 방법은 무엇입니까?
다음은 기본 전략으로, 두 로그입니다
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 배타적 "
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 배타적 -ORBClientConnectionHandler RW"
이 문제의 발생 빈도를 줄일 수 있지만, 문제는 완전히 해결할 수 없습니다.
6 년 전의 경험과 비슷합니다. 이 경우 클라이언트의 한 스레드에서 호출이 전송됩니다. 응답을 받기 전에이 스레드는 원자로 패턴으로 인해 다른 CORBA 요청을 보내는 데 다시 사용됩니다. 이 사례는 단지 하나의 코바 호출이기 때문에 여기의 사례 게시물과는 다른 것으로 보입니다. 스레드 스택의 내 인상은 다소 같다 :
server.anotherInvocation() //the thread is used for another invocation.
...
server::echo() //send 1st corba invocation
....
orb-run()
이 정책을 사용하면 지정된 시간 초과 값에서 서버가 응답하지 않으면 클라이언트가 강제로 연결을 종료합니까? 전에 ORBPolicy를 백업하고 호출이 완료된 후에 다시 복원해야합니까? 또한 "set orb policy"와 "set thread policy"사이에 차이가 있습니까? –
정책 백업 및 복원의 목적은 에코 호출이 3 ~ 4 밀리 초를 완료하는 동안 실행 호출이 거의 60 초 동안 지속될 수 있다는 것입니다. –
_set_policy_overrides를 사용하여 객체 참조에 정책을 설정할 수도 있습니다.이 정책은 echo 작업을 호출하는 객체 참조에만 설정됩니다. –