[omniORB] omniORB <--> ORBit

Garret Thomson gthomson@targetnet.com
Thu, 13 Jul 2000 17:11:34 +0000


Witness this error msg my (ORBit) client gets:

** WARNING **: Unexpected 0-length IIOP message


This is a C client, using ORBit as the orb, to a C++/OmniORB server.

The OmniORB trace shows: 

tcpSocketMTfactory Rendezvouser: unblock from accept()
tcpSocketMTfactory Rendezvouser: accept new strand.
tcpSocketMTfactory Rendezvouser: block on accept()
tcpSocketMTfactory Worker: start.
connect from titan.tor1.targetnet.lan
ll_recv: 60 bytes
4749 4f50 0100 0100 3000 0000 0000 0000 GIOP....0.......
78d4 bfbf 0100 0000 0c00 0000 396c 59f2 x...........9lY.
3ce0 3c0c 0000 0003 0b00 0000 6765 7473 <.<.........gets
7461 7469 6f72 0000 0000 0000           tatior......
ll_send: 12 bytes
4749 4f50 0100 0106 0000 0000           GIOP........
tcpSocketMTfactory Worker: #### Communication failure. Connection closed.
tcpSocketMTfactory Worker: exit.
...
...
...

I have been told that this is omniORB sending a MessageError, and ORBit hak'ing on it.

This is the structure of my interfaces/classes:

I have one interface, Control, that is used on the client side as a Control object. My
servant is an interface called Reciever, which is inherited off the Control interface.
(And yes, I know Reciever is spelled wrong .. it adds character to my class ;)

getstatior is the method in question, on the Control interface (and, subsequently the
Reciever interface), and is defined and implemented in the Reciever servant
implementation.

Some have suggested it might have been caused by out-of-sync idls on server and client
side, but I've gone over everything, and nothing should be out of sync. I've successfully
had my omniORB/C++ componant, which also contains client code, talking to copies of itself
fluently and without problems.

Someone on the orbit list has suggested it might be: 

>an unknown GIOP version, or a reserved bit being non-zero.

And suggests that it probably has nothing to do with the idl:

>IDL differences should result in MARSHAL system exceptions instead.

Versions: omniORB 2.8.0, orbit 0.5.1
FreeBSD: FreeBSD 3.4-20000609-JPSNAP

I suspect that it comes down to some sort of un-interoperability of the ORBit/omniORB
combination, but maybe it has something to do with the heirchy of my interfaces as well?

Has anyone encountered this problem and/or done something similar (ie, orbit <--> omniORB,
or similar interface heirarchy) to what I'm doing and has had no issues? I need to start
somewhere, and at this point, I'm not entirerly sure compiling a debug build of omniORB is
feasible (unless I can convince my co-developers that its worth the trouble.)

Mucho thanks,
G
-- 
- Garret Thomson ---- Programmer/Analyst ------------------------
TargetNet.Com Inc | [416]-306-0466 x 919 | gthomson@targetnet.com
"Master of my own domain. Even my subdomains."
-----------------------------------------------------------------