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

[Gary Duzan]

In Message <3F5F4672.5050204 at polbox.com> ,
   Tomasz Bech <tbech at polbox.com> wrote:

=>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.

   The last chunk is a fragment which completes the previous reply. The
'02' in the seventh byte of the previous message indicates that there are
more fragments to follow.

=>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 ;)

   Visibroker is not handling the fragments that OmniORB is returning
properly. GIOP 1.0 didn't have fragments, which is why the flag fixes
(or works around) the problem. The issues sounds familiar, so I believe
it is a known bug in Visibroker.

					Gary Duzan
					BBN Technologies
					A Verizon Company