[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