| Summary: | timeout does not work with oneway calls | ||
|---|---|---|---|
| Product: | TAO | Reporter: | zhangw |
| Component: | other | Assignee: | ciju john <john_c> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.4.6 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Bug Depends on: | |||
| Bug Blocks: | 2574 | ||
| Attachments: | Original test for this problem | ||
Yes, this is a bug. accept This should be fixed with the changes we are currently working on in the branch "OCI_Oneway_Buffering". I'll post a follow-up note here once it's merge. Then we can test to make sure that it's actually fixed. Adam, can you take over this bug then and I think it would be usefull when you first merge the test to reproduce the problem on the head version and when all builds have ran the test (probably takes 2 to 3 days) then merge the fix in Reassign to Adam The changes have been merged. Wallace, please re-run your example and see if it passes. From reading bug 2574, it does seem like these changes will address those issues. Once the tests are a little more stable I'll ask the reporter of 2574 to confirm that it's fixed. added blocks take over the bug from Adam. Take over the bug from Wallace. Take over the bug from Wallace. Take over the bug from Wallace. Created attachment 895 [details]
Original test for this problem
Can you add the test to the repository? Is this fixed? (In reply to comment #16) > Is this fixed? > yes. Marking this fixed. Ciju |
I have a simple example to test if RelativeRoundTripTimeout policy can be set on the client who is making constant oneway calls. After I suspend the server, client got blocked too, which is reasonable because I think by default the oneway call is using Sync_With_Transport SyncScope policy. However,the timeout policy I set on the client side cannot break the blockage. Here are the call stack: (gdb) bt #0 0x00000036470be445 in __select_nocancel () from /lib64/tls/libc.so.6 #1 0x00002aaaab640e42 in ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token> >::wait_for_multiple_events (this=0x52a0c0, dispatch_set=@0x52a5f8, max_wait_time=0x0) at OS_NS_sys_select.inl:39 #2 0x00002aaaab6b15d1 in ACE_TP_Reactor::dispatch_i (this=0x52a0c0, max_wait_time=0x52a608, guard=@0x7fffffffecc0) at TP_Reactor.cpp:249 #3 0x00002aaaab6b16cf in ACE_TP_Reactor::handle_events (this=0x52a0c0, max_wait_time=0x0) at TP_Reactor.cpp:171 #4 0x00002aaaab3644a4 in TAO_ORB_Core::run (this=0x5155c0, tv=0x0, perform_work=1) at ORB_Core.cpp:1998 #5 0x00002aaaab347e5c in TAO_Leader_Follower_Flushing_Strategy::flush_transport (this=0xc, transport=0x52ebc0) at Leader_Follower_Flushing_Strategy.cpp:55 #6 0x00002aaaab3a6d2b in TAO_Transport::send_message_shared_i ( this=0x52ebc0, stub=0x52e670, message_semantics=5416600, message_block=0x7fffffffee30, max_wait_time=0x0) at Transport.cpp:1206 #7 0x00002aaaab3385b6 in TAO_IIOP_Transport::send_message_shared ( this=0x52ebc0, stub=0x52e670, message_semantics=0, message_block=0x52f160, max_wait_time=0x7ffffffff0e0) at IIOP_Transport.cpp:188 #8 0x00002aaaab337cab in TAO_IIOP_Transport::send_message (this=0x52ebc0, stream=@0x52f160, stub=0x52e670, message_semantics=0, max_wait_time=0x7ffffffff0e0) at CDR_Stream.inl:463 #9 0x00002aaaab337c25 in TAO_IIOP_Transport::send_request (this=0x52ebc0, stub=0x52e670, orb_core=0x52a608, stream=@0x52f160, message_semantics=0, max_wait_time=0x7ffffffff0e0) at IIOP_Transport.cpp:132 #10 0x00002aaaab37dbf5 in TAO::Remote_Invocation::send_message ( this=0x7ffffffff000, cdr=@0x52f160, message_semantics=0, ---Type <return> to continue, or q <return> to quit--- max_wait_time=0x7ffffffff0e0) at Profile_Transport_Resolver.inl:40 #11 0x00002aaaab38bcfb in TAO::Synch_Oneway_Invocation::remote_oneway ( this=0x7ffffffff000, max_wait_time=0x7ffffffff0e0) at Synch_Invocation.cpp:716 #12 0x00002aaaab33d144 in TAO::Invocation_Adapter::invoke_oneway ( this=0x7ffffffff250, details=@0xfffffffffffffdfe, effective_target=@0x7ffffffff140, r=@0x7ffffffff0b0, max_wait_time=@0x7ffffffff138) at Invocation_Adapter.cpp:347 #13 0x00002aaaab33ce80 in TAO::Invocation_Adapter::invoke_remote_i ( this=0x7ffffffff250, stub=0x2aaaab53ff70, details=@0x7ffffffff190, effective_target=@0x7ffffffff140, max_wait_time=@0x7ffffffff138) at Invocation_Adapter.cpp:273 #14 0x00002aaaab33cc9a in TAO::Invocation_Adapter::invoke_i ( this=0x7ffffffff250, stub=0x52e670, details=@0x7ffffffff190) at Invocation_Adapter.cpp:89 #15 0x00002aaaab33cace in TAO::Invocation_Adapter::invoke ( this=0x7ffffffff250, ex_data=0x0, ex_count=0) at Invocation_Adapter.cpp:48 #16 0x00000000004060eb in Messenger::send_message_oneway (this=0x52e840, user_name=0x408cdf "TAO User", subject=0x7ffffffff250 ")P", message=0x52dcb0 "Hello!") at MessengerC.cpp:204 #17 0x0000000000407c54 in main (argc=1, argv=0x52a608) at CORBA_String.inl:59 Is this a bug?