[omniORB] [giop 1.2 interoperability] Is omniORB compatible with GIOP 1.2 ?!?

Tomasz Bech tbech at polbox.com
Wed Sep 10 18:42:42 BST 2003


Hi all,
I have Visibroker 4.5 in Delphi and omniORB 4.0.1 on server side (AIX).
It works together, but in case of long data (texts) client receives the 
BAD_INV_ORDER exception (it is thrown on client side, not server).
Server is giving following stream:

omniORB: sendChunk: to giop:tcp:129.184.99.192:4536 188 bytes
omniORB:
4749 4f50 0102 0201 0000 0664 0000 0121 GIOP.......d...!
0000 0000 0000 0000 0000 0007 0000 0000 ................
[cut]
0000 0005 0000 0000 0000 0006 0150 004c .............P.L
0000 0006 0000 0003 0000 02da           ............
omniORB: sendCopyChunk: to giop:tcp:129.184.99.192:4536 1460 bytes
omniORB:
0054 0068 0065 0020 0061 006d 006f 0075 .T.h.e. .a.m.o.u
[cut long text]
006d 006d 0069 0073 0073 0069 006f 006e .m.m.i.s.s.i.o.n
002e 0000                               ....

omniORB: sendChunk: to giop:tcp:129.184.99.192:4536 17 bytes
omniORB:
4749 4f50 0102 0007 0000 0005 0000 0121 GIOP...........!
00       

1. What is the last chunk? It is not part of my response. And it causes 
the problem in Visibroker - it is not expected.
2. When I switch the server with: -ORBmaxGIOPVersion 1.0 everything 
works fine and stream is similar but without the last chunk!!! - 
Visibroker is happy ;)

I'm not expert on GIOP level, so have no idea where the incompatibility 
with GIOP 1.2 is. Can someone explain it to me?
Thanks,
    Tomasz
For both 1.0 and 1.2 I have the same streaming of wstring, based on 
Voyager wstring contribution. And have BAD_INV_ORDER also when streaming 
big sequence of object pointers - no wstring there - so wstring is 
rather not an issue.





More information about the omniORB-list mailing list