eclipse-cyclonedds
Cyclone DDS Python fails to communicate with Cyclone DDS C and Open DDS
Hi, I'm trying to interoperate between Cyclone DDS (Python bindings) (0.11.0) and OpenDDS (3.22).
Recently interoperability was fixed between Cyclone (C/C++) and OpenDDS when using enums in the IDL (issue #1345).
I am using i11eperf to test interoperability, varying encoding and extensibility in the IDL and have found the following (judging success by whether data is transferred in i11eperf:
IDL data: xcdr1 final
Cyclone C <-> OpenDDS OK Cyclone Python <-> OpenDDS OK
IDL data: xcdr2 appendable
Cyclone C <-> OpenDDS OK Cyclone Python <-> OpenDDS OK
IDL data: xcdr2 appendable with an enum
OpenDDS -> Cyclone DDS (C) OK Cyclone DDS (C) -> OpenDDS Maybe OpenDDS -> Cyclone Python FAIL Cyclone DDS (C) -> Cyclone Python FAIL
It seems like Cyclone Python isn't handling IDL containing an enum.
I'll attached my Python receive test app, and IDL with enum. Thanks
Attached files - simple Python subscriber, idl file using XCDR2, Appendable and with an enum.
subPython.txt i11eperf.idl.xcdr2_appendable_enum.txt
Hi @smnrgrs,
Thanks for the quality bug report with reproducer, that is always appreciated! I quickly narrowed it down to the fact that the IDL backend for Python did not keep the appendable annotation around. This is fixed by https://github.com/eclipse-cyclonedds/cyclonedds-python/pull/153 but you can also fix your test by going into the generated Python code and adding the @annotate.appendable to the enum type manually.
Thank you for your quick response, I now get data transfer so the issue as reported seems to be fixed.
My next issue (happy to raise a different ticket) is: Late-comer python subscriber doesn't get any samples, even though QoS = set qos.durability.kind = TRANSIENT_DURABILITY_QOS / Policy.Durability.Transient I'm starting the opub from i11eperf, doing 5 writes and then sleeping to keep the DataWriter in existence.
If I start the python cyclone subscriber after the writes have happened I get no data.
With this QoS I would expect the subscriber to get the samples delivered, but I might be doing something wrong.
Thank you for your quick response, I now get data transfer so the issue as reported seems to be fixed.
My next issue (happy to raise a different ticket) is: Late-comer python subscriber doesn't get any samples, even though QoS = set qos.durability.kind = TRANSIENT_DURABILITY_QOS / Policy.Durability.Transient I'm starting the opub from i11eperf, doing 5 writes and then sleeping to keep the DataWriter in existence.
If I start the python cyclone subscriber after the writes have happened I get no data.
With this QoS I would expect the subscriber to get the samples delivered, but I might be doing something wrong.
You want TRANSIENT_LOCAL, not TRANSIENT, the latter isn't supported by Cyclone. It is very much on the roadmap for Cyclone — I personally think it is the key differentiator between DDS and just about every other middleware, so no way we're not going to do that, but yes, unfortunate circumstances beyond our control have caused it to be delayed ...
It doesn't return an error when you try to you use and that's pretty bad ... we should fix that.
