[omniORB] Strange IOR

[Serguei Kolos]

May be the timeout is too short. Could you try to increase it and check 
what happens?

Frederic Prin wrote:

> Hi Sergei,
> Thanks for your response, unfortunatly the machine on which this IOR 
> had been generated is still alive. I can even ping it (it atkes about 
> 20us, and my timeout is set to 2000ms).
> but it has certainly be rebooted after the IOR had been generated 
> killing all running servers... I don't think it's the reason why the 
> narrow call throw a TRANSIENT__CallTimedout .
> Furthermore, when I step into the _narrow call, and did step by step 
> debug, I found the line that generate the exception:
>
>     void
>     giopStream::CommFailure::_raise(CORBA::ULong minor,
>         CORBA::CompletionStatus status,
>         CORBA::Boolean retry,
>         const char* filename,
>         CORBA::ULong linenumber)
>     {
>     // cut...
>       throw CommFailure(minor,status,retry,filename,linenumber);  //
>     here minor=0x41540008 or minor=0x41540002
>     }
>
> which is caught and rethrown as a TRANSIENT  exception (with same 
> minor code) by
>  
>
>     void
>     omniObjRef::_invoke(omniCallDescriptor& call_desc, CORBA::Boolean
>     do_assert)
>     {
>     // cut...
>     CORBA::TRANSIENT ex2(ex.minor(), ex.completed());
>      if( !_omni_callTransientExceptionHandler(this, retries++, ex2) )
>        OMNIORB_THROW(TRANSIENT,ex.minor(),ex.completed());        //
>     here minor=0x41540008 or minor=0x41540002
>     // cut...
>     }
>
> What is strange is that if I step by step debug down to the throw 
> CommFailure, I get a correct minor code = 0x41540002 which is "Connect 
> failed "
> But if I only put a breakpoint on the throw CommFailure line and wait 
> for the debuger to stop, I get a minor code = 0x41540008 which is 
> "Call timed out"
>  
> The pb is that my Name Service will become polluted by dangling 
> reference... and that my clients can no more discriminate a real dead 
> server from server blocked in a debugger or eavily loaded.
>  
> I do use omniORB-4.0.3 release snapshot. I will try soon the 
> omniORB-4.0.4!
>  
> If someone has another idea, I thank him in advance!
>  
> Thanks fro reading.
>  
> FredP
>
>     -----Original Message-----
>     From: omniorb-list-bounces at omniorb-support.com
>     [mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of
>     Serguei Kolos
>     Sent: vendredi 30 juillet 2004 09:16
>     To: omniorb-list at omniorb-support.com
>     Subject: Re: [omniORB] Strange IOR
>
>     If the computer (on which this dead IOR has been generated) is
>     switched off then the
>     only way to terminate a remote call is the timeout. TCP/IP (and
>     therefore CORBA) can't
>     tell anything apart from there were no reply in certain amount of
>     time.
>     If you switch that machine on then most probably you will get
>     another minor code.
>
>     Cheers,
>     Sergei
>
>     Frederic Prin wrote:
>
>>     Hi all,
>>
>>     I have some IOR registered on my Name Service that are dangling
>>     (the corresponding server is dead).
>>     When a clients tries to resolve + _narrow it I catch a TRANSIENT
>>     exception when trying to narrow (that is good) but with a bad
>>     minor code = 0x41540008
>>
>>     Which is omni::TRANSIENT_CallTimedout !
>>
>>     Indeed, I do set a setClientCallTimeout() before the narrow call
>>     but since the IOR points on a dead server the servant cannot be
>>     contacted so I am expecting another minor code.
>>
>>     I tried to get more information on those IOR with catior but
>>     unfortunatly it fails with a MARSHALL exception...
>>
>>           meije{ bin }:14 > catior
>>           IOR:010000001f00000049444c3a49536d617274566965772f5356496e746572666163653a312e300000010000000000000060000000010102000c00000031302e36362e31302e313300008100000e000000fec79cf2400000544d0000000000000002000000000000000100000001000000010000001c00000001000000010001000100000001000105090101000100000009010100
>>
>>           Type ID: "IDL:ISmartView/SVInterface:1.0"
>>           Profiles:
>>           1. IIOP 1.2 10.66.10.13 33024 ".... at ..TM....."
>>
>>           Invalid stringified IOR supplied.
>>           (CORBA::MARSHAL: minor = MARSHAL_PassEndOfMessage)
>>
>>     (I copy/paste the IOR from a kind of Name Service explorer (not
>>     of my own) maybe it is wrongly displayed)
>>
>>     Any ideas
>>
>>     Thanks
>>
>>     Fred
>>                                   (
>>          Frédéric Prin          )
>>          Senior Software Engineer /
>>               S I L V A C O      (
>>          Grenoble REsearch CEnter \
>>          Tel 04 56 38 10 33        )
>>         __________________________/___
>>        /__/__/__/__/__/__/__/__/__/__/
>>       /__/__/__/__/__/__/__/__/_____/
>>      /__/__/__/__/__/__/__/__/__/__/
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>omniORB-list mailing list
>>omniORB-list at omniorb-support.com
>>http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>>  
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20040730/0dfb4c86/attachment.htm