[omniORB] interoperability : omniORBpy 3.2 and Visibroker 8.0 - omniORB.MARSHAL_InvalidIndirection error

[eLAN]

Hello,
I encountered an interoperability issue, and I was wandering if anyone can
help.
I using omniORBpy 3.2 (windows XP), trying to connect to Visibroker 8.0
server.

I get a marshal error on response, I tried several initialization options,
but none solved the issue.
this is the output:
-----
['-ORBtraceLevel', '5', '-ORBuseTypeCodeIndirections', '0',
'-ORBstrictIIOP', '0', '-ORBlcdMode', '1']
omniORB: Configuration file "C:\OMNIORB.CFG" either does not exist or is not
a file. No settings rea
d.
omniORB: Version: 4.1.4
omniORB: Distribution date: Sun Jul 19 18:35:23 BST 2009 dgrisby
omniORB: Warning: unable to create an IPv6 socket. Unable to obtain the list
of IPv6 interface addre
sses (10047).
omniORB: Information: the omniDynamic library is not linked.
omniORB: omniORBpy distribution date: Thu Jul 16 16:16:19 BST 2009 dgrisby
<CosNaming._objref_NamingContextExt instance at 0x00EA6558>
==== Start ======
Traceback (most recent call last):
File "D:\workspace\pyCorbaTest\corba.py", line 145, in <module>
tester.DOgetCustomerByID()
File "D:\workspace\pyCorbaTest\corba.py", line 104, in DOgetCustomerByID
RC = servantObject.GetCustomerById(Hconnect,ExternalId)
File "D:\workspace\pyCorbaTest\CustomerMaintenance_idl.py", line 468, in
GetCustomerById
return _omnipy.invoke(self, "GetCustomerById",
_0__GlobalIDL.CorbaCustomerMaintenance._d_GetCust
omerById, args)
omniORB.CORBA.MARSHAL: CORBA.MARSHAL(omniORB.MARSHAL_InvalidIndirection,
CORBA.COMPLETED_YES)
----

The response type is a e sequence in the following format:

struct TupleItem {
string sName;
any aValue;
};
typedef sequence<TupleItem> Tuple;

any idea on how to solve the problem, or next steps for finding the problem
will be welcomed.

Thanks,
Ilan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100306/b8bf53b9/attachment.htm

[Duncan Grisby]

Post by eLAN
I encountered an interoperability issue, and I was wandering if anyone
can help.
I using omniORBpy 3.2 (windows XP), trying to connect to Visibroker
8.0 server.

[...]

Post by eLAN
CORBA.MARSHAL(omniORB.MARSHAL_InvalidIndirection, CORBA.COMPLETED_YES)

Are the client and server definitely using the same IDL definitions? If
they have a difference, that could cause that kind of error.

If that's not the issue, please come up with a minimal example call that
demonstrates the problem. Then, post your complete IDL, and the output
from omniORB run with -ORBtraceLevel 40

Cheers,

Duncan.

[eLAN]

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: CorbaDof.idl
Type: application/octet-stream
Size: 1946 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100310/02effff5/CorbaDof-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CustomerMaintenance.idl
Type: application/octet-stream
Size: 188983 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100310/02effff5/CustomerMaintenance-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testInOp.log
Type: application/octet-stream
Size: 21613 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100310/02effff5/testInOp-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testInOp.py
Type: application/octet-stream
Size: 2946 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100310/02effff5/testInOp-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TransactionManager.idl
Type: application/octet-stream
Size: 1228 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100310/02effff5/TransactionManager-0001.obj

[Duncan Grisby]

1. Yes, The IDL definitions are the same.
2. Since the IDLs are rather large, I'm attaching the test code, log
and the relevant IDL (plus relevant includes)

Is there any way you can come up with a smaller example? With that much
data, it is very hard to manually decode the GIOP data. Can you return a
much smaller sequence of data from GetCustomerById?

Cheers,

Duncan.

[eLAN]

Well, the GetCustomerById return a bunch of data and I cant touch it.
However, I managed to reproduce the problem with a different API which
return a much smaller data set.
see "GetMarketByName" in the attached IDL, a corresponding log is attached.

BTW, I don't know it it relevant, but the IDLs had to be complied with
the "-nc" flag

1. Yes, The IDL definitions are the same.
2. Since the IDLs are rather large, I'm attaching the test code, log
and the relevant IDL (plus relevant includes)

Is there any way you can come up with a smaller example? ?With that much
data, it is very hard to manually decode the GIOP data. Can you return a
much smaller sequence of data from GetCustomerById?
Cheers,
Duncan.
--
?-- Duncan Grisby ? ? ? ? --
? -- http://www.grisby.org --

--
eLAN
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestInOP_Market.log
Type: application/octet-stream
Size: 12349 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100321/82f966bd/TestInOP_Market-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MarketManager.idl
Type: application/octet-stream
Size: 19643 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100321/82f966bd/MarketManager-0001.obj

[Duncan Grisby]

Post by eLAN
Well, the GetCustomerById return a bunch of data and I cant touch it.
However, I managed to reproduce the problem with a different API which
return a much smaller data set.
see "GetMarketByName" in the attached IDL, a corresponding log is attached.

OK. That's still big and complicated and hard to manually unpick, I'm
afraid. Please can you apply the attached patch. It will output some
extra logging about the indirection that it thinks is invalid, which
will make it much easier to track down.

Post by eLAN
BTW, I don't know it it relevant, but the IDLs had to be complied with
the "-nc" flag

No, that shouldn't be relevant.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org/ --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pyTypeCode.patch
Type: text/x-patch
Size: 723 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100322/66fd2379/pyTypeCode.bin

[eLAN]

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: testInOp_25032010.log
Type: application/octet-stream
Size: 12062 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100412/4bad87e9/testInOp_25032010-0001.obj

[Duncan Grisby]

The attached log contains the logging with the patch.

My apologies for the very long delay in replying to this. Diagnosing it
involves unpicking the GIOP data in the log, and that's a painful and
time consuming activity that I've only just had time for.

My conclusion is that it is a bug in Visibroker. The server is sending a
sequence of TupleItem structs, each of which contains an Any. The first
Any contains an OID struct, and the TypeCode and value are sent
correctly. The next sequence item contains an ObjectNumberForAny struct,
and again the TypeCode and value are correctly transmitted. The next
item is clearly also meant to contain an ObjectNumberForAny struct, but
Visibroker does not send a full TypeCode for it. Instead, it sends an
indirection pointing to the already-sent ObjectNumberForAny TypeCode.
Indirections are a negative number giving an offset to a previously-sent
TypeCode.

Unfortunately, it is not permitted to do that in this situation! The
CORBA 2.6 specification, section 15.3.5.1 says:

... CDR provides a constrained indirection to resolve this
problem:

* The indirection applies only to TypeCodes nested within some
'top-level' TypeCode. Indirected TypeCodes are not
'freestanding', but only exist inside some other encoded
TypeCode.

Although the indirection TypeCodes that Visibroker is sending are all in
the same response, they are not all nested within a top-level TypeCode,
and they are therefore illegal. omniORB is right to throw a MARSHAL
exception.

I'm not sure what to suggest, other than to report it as a bug in
Visibroker.

Cheers,

Duncan.