Re: Interoperability problems with ORBit2

[Ansgar Radermacher <ansgar radermacher cea fr>]

Here is the trace of the connection attempt with omniORB's name server, 
without giop debug flags. By the way: contacting MICO's nameserver from 
ORBit fails as well (see below).

Best regards

Ansgar

Lookup '' (0x806cc40) == (nil)
Profiles: P-IIOP localhost:0x3039 '4e616d6553657276696365'
... [application output]
Initiated a connection to 'IPv4' 'localhost' '12345'
p12743 : ([0x80737f0])->_is_a (Align = 12
Marshal: id 0xbffff0c0
'logical_type_id' : kind - 18, i 
'IDL:omg.org/CosNaming/NamingContext:1.0')handling reply
=>: 1Clean demarshal on id 0xbffff0c0


trying: ref=0x8076080
p12743 : ([0x80737f0])->rebind (Align = 12
Marshal: id 0xbffff030
'n' : kind - 19, i seq[1]={ { 'test.ansgar', '' } },  'obj' : kind - 
14, i [0x80760e8]Marshal object '0x80760e8'
P-GIOP UNIX:/tmp/orbit-ansgar/linc-31c7-0-41c4024fa6e24:is002742
P-OS /tmp/orbit-ansgar/linc-31c7-0-41c4024fa6e24:0x0 
'00000000b51058c82f9928284d31282828282828010000002d82d86c'
P-<None>
)handling reply
We received an unexpected reply
Zap listener on dead cnx with buffer (nil)
No recv buffer ...
Sys exception incomplete on id 0xbffff030

[System exception comm failure] )
Profiles match:
'IDL:bench/Test:1.0':P-GIOP 
UNIX:/tmp/orbit-ansgar/linc-31c7-0-41c4024fa6e24:is002742
'IDL:bench/Test:1.0':P-GIOP 
UNIX:/tmp/orbit-ansgar/linc-31c7-0-41c4024fa6e24:is002742
system exception!

--------
I also checked against the MICO's (2.3.11) name server:

Initiated a connection to 'IPv4' 'localhost' '12345'
p12821 : ([0x8073800])->_is_a (Align = 12
Marshal: id 0xbffff0b0
'logical_type_id' : kind - 18, i 
'IDL:omg.org/CosNaming/NamingContext:1.0')Outg
oing IIOP data:
0x0000:   47 49 4f 50  01 01 01 00  6c 00 00 00  XX XX XX XX | 
GIOP....l...****
---
0x000c:   01 00 00 00  01 00 00 00  0c 00 00 00  01 01 01 01 | 
................
0x001c:   01 00 01 05  09 01 01 00  b0 f0 ff bf  01 00 00 00 | 
................
0x002c:   0b 00 00 00  4e 61 6d 65  53 65 72 76  69 63 65 00 | 
....NameService.
0x003c:   07 00 00 00  5f 69 73 5f  61 00 49 00  00 00 00 00 | 
...._is_a.I.....
0x004c:   28 00 00 00  49 44 4c 3a  6f 6d 67 2e  6f 72 67 2f | 
(...IDL:omg.org/
0x005c:   43 6f 73 4e  61 6d 69 6e  67 2f 4e 61  6d 69 6e 67 | 
CosNaming/Naming
0x006c:   43 6f 6e 74  65 78 74 3a  31 2e 30 00  XX XX XX XX | 
Context:1.0.****
---
Incoming IIOP header:
0x0000:   47 49 4f 50  01 00 01 06  00 00 00 00  XX XX XX XX | 
GIOP........****
---
dropping an unusual & unhandled input buffer 0x6Zap listener on dead cnx 
with bu
ffer (nil)
No recv buffer ...
Sys exception incomplete on id 0xbffff0b0

[System exception comm failure] )


Michael Meeks wrote:

> Hi Ansgar, 
>
> On Thu, 2004-05-13 at 11:49 +0200, Ansgar Radermacher wrote:
>  
>
> > I want to use ORbit2.10.1 in a small benchmark. ORBit clients can not 
> > connect to either the omniORB (4.0.3) or the TAO (1.2a) naming server. I 
> > get different error behaviors:
> >    
>
> 	Grief - that's pretty bad ;-(
>
>  
>
> > with TAO, trying to retrieve the reference blocks endless (output of 
> > client start with DebugFlags=giop:traces):
> >    
>
>  
>
> > ---
> > Exception: forward (0x8072e38)p23208 : ([0x80718a8])->_is_a 
> > ('IDL:omg.org/CosNaming/NamingContext:1.0')Outgoing IIOP data:
> >    
>
> 	So - it returns a rather unusual forward exception / reply - I guess
> we've just never/seldom tested this code path, and it's (perhaps) not
> obeying the forward at all - and just endlessly re-trying the request to
> the same place. That would suck, but - we tend not to see this
> situation; I guess the bug is (probably) in:
>
> 	src/orb/orb-core/corba-object.c (ORBit_handle_location_forward)
> 	or where it's called in orbit-small.c
>
>  
>
> > with omniORB, I get an exception:
> >    
> ....
>  
>
> > Incoming IIOP body:
> > 0x000c:   00 00 00 00  c0 f0 ff bf  00 00 00 00  01 00 00 00 | 
> > ................
> > 0x001c:   00 00 00 00  30 f0 ff bf  02 00 00 00  24 00 00 00 | 
> > ....0.......$...
> > 0x002c:   49 44 4c 3a  6f 6d 67 2e  6f 72 67 2f  43 4f 52 42 | 
> > IDL:omg.org/CORB
> > 0x003c:   41 2f 42 41  44 5f 49 4e  56 5f 4f 52  44 45 52 3a | 
> > A/BAD_INV_ORDER:
> > 0x004c:   31 2e 30 00  18 00 54 41  01 00 00 00  XX XX XX XX | 
> > 1.0...TA....****
> >    
>
> 	That's rather curious; it'd be interested to see a trace without the
> GIOP dumping perhaps - to see what call that's happens during; are there
> not several incoming bits processed while that outgoing call was
> happening ?
>
> 	Regards,
>
> 		Michael.
>
>  


--
Ansgar Radermacher              CEA/DRT/LIST
http://www-drt.cea.fr/fr/prog/list.htm
http://ist.unibw-muenchen.de/external/People/ansgar/
phone: +33 16908 4889
mailto: ansgar radermacher cea fr