Re: Interoperability problems with ORBit2

[Michael Meeks <michael ximian com>]

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.

-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot