[omniORB] Strange IOR

[Frederic Prin]

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:010000001f00000049444c3a49536d617274566965772f5356496e74657266616365
3a312e300000010000000000000060000000010102000c00000031302e36362e31302e31
3300008100000e000000fec79cf2400000544d0000000000000002000000000000000100
000001000000010000001c00000001000000010001000100000001000105090101000100
000009010100

	Type ID: "IDL:ISmartView/SVInterface:1.0" 
Profiles: 
1. IIOP 1.2 10.66.10.13 33024 ".... at ..TM....." <mailto:.... 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/41004301/attachment.htm