I'm hoping to use the type consistency features in v5, they don't seem to be working though. The IDLs are pretty big, so I'm adjusting the type_object_max_serialized_length QoS setting. I've also (tried) to disable the older TypeCodes completely by setting type_code_max_serialized_length to 0 (as described in http://community.rti.com/rti-doc/500/ndds.5.0.0/doc/pdf/RTI_CoreLibrariesAndUtilities_GettingStarted_ExtensibleTypesAddendum.pdf)
I deliberately removed some fields from an IDL at the writer end to ensure that DDS would catch the error and give me an inconsistent topic callback. This is what I get instead from the DDS logs:
DISCBuiltinTopicSubscriptionDataPlugin_serializeParameters:Problems sending the type code information associated with the topic <MyTopic>. Check type_code_max_serialized_length parameter in <domainQos>.resource_limits
PRESPsService_assertRemoteEndpoint:TypeObject succesfully stored (topic: 'N/A', type: 'N/A')
DDS_DataReader_enableI:enabled
PRESPsService_linkToRemoteWriter:assert remote 0XA9047CA,0X4463,0X1,0X80000002, local 0x80000007 in reliable reader service
Command: PRESCstReaderCollator_storeSampleData:!deserialize
I've disabled type code, so I think the first line is OK. It looks like I got the TypeObject in the second line, though not sure why it says 'N/A'. But I don't get an inconsistent topic notification, I only get a deserialize error, which indicates to me that DDS didn't realize the types were not compatible.
Any settings I'm missing?
Thanks
Hello,
Before version 5.0.0, the middleware was only checking the names of the data-types associated with a DataReader/DataWriter; the "structure" of the datatyp was not being checked.
Starting with version 5.0.0 the middlware is adressing type-checking. If you look at the RTI Connext User's manual, section 7.6.6 ALLOW_TYPE_COERCION is enabled by default.
I am not sure why your example is not working. Did you try by any chance to run a simpler example?
--
Gianpiero
Thanks for the response. I ran into the same issue with small IDLs. My IDLs were using valuetype rather than structs. It turns out, after I changed everything to struct it just worked. I thought in v5 structs and valuetypes were equivalent.
Hello again,
thanks for coming back to me: would it be possible to have the Small IDL you are using? I would like to try to reproduce the issue and investigate further.
Best,
Gianpiero
Sure. The situation is I have two processes publishing/subscribing to an topic. One process is using an older version of the IDL while the other is using a newer version. The newer version has one new field appended to the end. As I understand it, they should be assignable in RTI v5, and both process should be able to read/write samples even though though IDL is slightly different.
To test this, I create two applications using the different IDLs and rtiddsgen. One application's IDL looks like:
module Testing
{
valuetype BaseMessage
{
public long foo;
public long bar;
public long baz;
};
};
and the other's looks like:
module Testing
{
valuetype BaseMessage
{
public long foo;
public long bar;
};
};
I generate publishers and subscribers using: rtiddsgen -namespace -example x64Linux2.6gcc4.4.5 -replace Example.idl (they are both named Example.idl, in separate directories).
Let's say process X is using the longer IDL while process Y is using the shorter IDL. If process X publishes a sample, process Y can read it fine. Process Y obviously doesn't see the additional field. BUT, if process Y publishes a sample, process X gets the following error:
PRESPsReaderQueue_storeSampleData:!deserialize
If I simply change valuetype to struct (and remove the public qualifiers), then everything works as expected and I get no deserialize errors.
Thanks for the detailed explaination!
I was able to reproduce your issue and to verify that we had a bug in the codegenerator (aka rtiddsgen).
The bug number is CODEGEN-527 and it has been already fixed (I was able to run your example successfully against an internal build). The fix will be available in the next release.
The workaround you found (use struct instead of valuetypes), is the one suggested in the bug report.
Let me know if there is something else I can help with.
Best,
Gianpiero
Good to know. Thanks for taking a look at the problem!