[omniORB] omniORB <--> ORBit

Sai-Lai Lo S.Lo@uk.research.att.com
14 Jul 2000 00:41:39 +0100


>>>>> Garret Thomson writes:

> 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 strange. I replay your message to an omniORB (2.8 or 3.0) server
and I don't get the MessageError reply you are seeing. The omniORB server
handles this message properly. Also, the request message
from ORBit is well-formed, assume that there is no argument in the
operation getstatior.

I wonder if there is anything problematic with your build. I'm afraid there
is too little information to work on. To investigate further, you have to
look at why the MessageError reply is triggled. Trace your server by
putting a break point at <top>/src/lib/omniORB2/orbcore/giopServer.cc line
341, that is the point where the server thread reaches when it receive the
reply. 

Sai-Lai

-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND