[omniORB] transient exception handler and call timeout problem

Lazar Stricevic lucky at uns.ns.ac.yu
Thu Jul 26 20:36:43 BST 2007


Hi everyone,

We've got server/client application that is now using omniORB 4.1.0
Problem that is bothering us is described in messages of Vladislav 
Vrtunski (April 2005) and is still present in current version of omniORB.
Here is partial quote of the first posting in the thread describing the 
problem:
> Hi,
>
>    We are trying to limit call duration to 2 seconds and if the 
> timeout is reached we want to repeat the call, hoping that it won't 
> last that long the second time. This is part of an attempt to make a 
> fault tolerant system. In order to achieve that, we have set client 
> call timeout and installed both transient and comm_failure exception 
> handlers. Each of these handlers is written to allow ORB to retry the 
> operation once in case exception occurs.
>    Here is the problem. When the timeout is reached and 
> TRANSIENT_CallTimedout exception is thrown, our transient exception 
> handler is called and it returns 1 so that ORB repeats the call. 
> Immediately after that TRANSIENT_ConnectFailed is thrown without 
> server side method being called, although we can see in omniORB trace 
> that the server has accepted the second connection from client. Is 
> this the expected behavior? We would expect the second call to at 
> least reach the server method.

Here are the actual postings:
http://www.omniorb-support.com/pipermail/omniorb-list/2005-April/026612.html
http://www.omniorb-support.com/pipermail/omniorb-list/2005-April/026633.html
http://www.omniorb-support.com/pipermail/omniorb-list/2005-May/026668.html
http://www.omniorb-support.com/pipermail/omniorb-list/2005-May/026685.html

Is this behavior considered to be a bug or not?

Anyway, we solved the problem by changing 
src/lib/omniORB/orbcore/omniObjRef.cc
Actually, only two lines ("if" section, lines 731 and 758) are commented 
out, but it does the trick.
The patch file is attached.

Patch files for omniORB 4.0.5, 4.0.6 and 4.0.7 are available upon request.

Regards,
Lazar

-------------- next part --------------
diff -cr ../omniORB-4.1.0/src/lib/omniORB/orbcore/omniObjRef.cc src/lib/omniORB/orbcore/omniObjRef.cc
*** ../omniORB-4.1.0/src/lib/omniORB/orbcore/omniObjRef.cc	Tue Jan 10 13:59:38 2006
--- src/lib/omniORB/orbcore/omniObjRef.cc	Mon Jul  9 16:55:59 2007
***************
*** 727,734 ****
  
      if( orbParameters::verifyObjectExistsAndType && do_assert )
        _assertExistsAndTypeVerified();
! 
!     if (!(abs_secs || abs_nanosecs)) {
        if (pd_timeout_secs || pd_timeout_nanosecs) {
  	omni_thread::get_time(&abs_secs,&abs_nanosecs,
  			      pd_timeout_secs, pd_timeout_nanosecs);
--- 727,736 ----
  
      if( orbParameters::verifyObjectExistsAndType && do_assert )
        _assertExistsAndTypeVerified();
! ////////////////////////////////////////////////////////////////
! // Change by Lazar Stricevic, invoke(), 09.07.2007 16:50
! // "if" is commented out to allow promptly timer reset
! //    if (!(abs_secs || abs_nanosecs)) {
        if (pd_timeout_secs || pd_timeout_nanosecs) {
  	omni_thread::get_time(&abs_secs,&abs_nanosecs,
  			      pd_timeout_secs, pd_timeout_nanosecs);
***************
*** 755,761 ****
  			      orbParameters::clientCallTimeOutPeriod.nanosecs);
        }
        call_desc.setDeadline(abs_secs,abs_nanosecs);
!     }
  
      try{
        omni::internalLock->lock();
--- 757,763 ----
  			      orbParameters::clientCallTimeOutPeriod.nanosecs);
        }
        call_desc.setDeadline(abs_secs,abs_nanosecs);
! //    }
  
      try{
        omni::internalLock->lock();



More information about the omniORB-list mailing list