[Question] DYN_TYPES_Error: The container is full

[kteriusghub]

I built with 'feature/xtypes-dds' of SOSS-DDS, and gave 100 elements to each of two vector members through the 100-times push_back callings, and used the TCP transfer between the client and the server of SOSS. The result was good to send and receive the following customized ROS2 topic message type (as the LiDAR data)

float ranges[];
float intensities[];

But, when I gave the 200-times push_back callings to the both of vector member, the client side of SOSS showed the following message. And the message codes are found from DynamicData.cpp of Fast-RTPS.
"[DYN_TYPES Error] Error inserting data. The container is full. -> Function insert_sequence_data"

As we know, some LiDARs generate more than a thousand intensitie data, so these vector members need to have more than 1000 elements.
I want to know if it is the known issue of SOSS-DDS, or only my issue. If it is the know issue, was it fixed?

[richiware]

Are you defining your type in IDL format? In this case, can you copy it here?

Thanks.

[kteriusghub]

@richiware
No, I didn't define it on both of SOSS and SOSS-DDS, however, I included the ROS2 package name with the structure type to CMakeLists.txt, using soss_rosidl_mix( PACKAGES ...).
And then I mentioned 'types-from: ros2' to the yaml file without IDL description.
To prevent the overflow of dynamic data container, should I define the IDL to the yaml file and configure the remap?

[richiware]

Could you provide the msg file which causes the error?

[kteriusghub]

@richiware
This is the msg file.
--- std_msgs/Header header
--- float32[] ranges
--- float32[] intensities

And, I filled the vector elements and publish data as this way.
--- auto msg = LidarData();
--- for (int i = 0; i < 200; i++) {
------- msg.ranges.push_back(0.1);
------- msg.intensities.push_back(0.5);
------- }
--- LidarDataPublisher->publish(msg);

[ruimscarvalho98]

Was this issue solved? I am getting the same error using the integration-service for ROS2 WAN communication.

I am using a custom type which is basically a sequence of uint8_t and it also is not working for more than a 100 elements

[sirawats]

I have the same issue. How to resolve this?

[ruimscarvalho98]

Hi @ohsirawat,

I've managed to do a bit of a workaround which was to modify the generated idl for a larger maximum sequence size.

By modifying the files in root_ws/build/is/rosidl/ros/<interface_package>/include/is/rosidl/ros2/<interface_package>/msg/convert__msg__<your_message>.hpp directly you can set the maximum sequence size (altough this is a hotfix kind of solution)

For instance In my case I've modified the g_idl variable:

const std::string g_idl = R"~~~(
module cf_messages {
  module msg {
    struct Ping {
      sequence<uint8, 2048> data;
    };
  };
};

Note the 2048 in the the sequence field, this replaces the default 100 as maximum size.

I don't know if there is any way to change the maximum sequence size more elegantly (maybe in one of the cmake files?) or opting to use dynamic memory? Maybe the maintainers can shine some light on the matter? I think this could be a nice feature to add (if it is not already implemented and I just didn't see it :P )

[sirawats]

Thanks! that's very helpful @ruimscarvalho98

[marcus89]

Hi,
I experience the same problem when trying send String with length > 100 bytes.

In the source code of FastDDS-SH, I have checked that the "historyMemoryPolicy" parameter is used when creating a Datawriter ("historyMemoryPolicy" is provided by XML).
The error occurs even with this parameter.

Someone has solved this issue?

Thanks!

[cedricmelancon]

3 years and no solution... I'm facing the same issue and it's a roadblock. I'll have to consider an alternative to Integration Service...

[MiguelBarro]

It's not an integration service issue. Is a Fast-DDS one that we are trying to fix.
It turns out that Integration-Service relies on xtypes as an intermediate data format between System Handles.
xtypes is a partial implementation of the DDS-XTypes standard. It's partial because it lacks serialization capabilities.
In order to workaround that the ROS2-SH translates Integration-Service xtypes objects into Fast-DDS dynamic-types ones.
Fast-DDS dynamic-types is another implementation of the XTypes standard that has serialization capabilities.
Unfortunately, Fast-DDS dynamic-types implementation is bugged. We have been trying to fix this here for a while.
As you can see is a work in progress. When we managed to merge the fixes we will update the ROS2-SH to use the new v1_3 namespace and profit from the fixes.