I increased reader_user_data_max_length in my application to 65536, then I fill user_data_qos in my program with more than 256 limits.
I can send and receive data's in my applications currectly, but I can not use Recording Service, even I change it's xml configuration file.
this is my xml code:
...
<recording_service name="ABC">
...
<domain_participant name="Participant0">
<domain_id>0</domain_id>
<participant_qos>
...
<resource_limits>
...
<reader_user_data_max_length>65536</reader_user_data_max_length>
<writer_user_data_max_length>65536</writer_user_data_max_length>
</resource_limits>
...
</participant_qos>
</domain_participant>
...
</recording_service>
...
Recording Service works currectly when I don't fill user_data but if i fill user_data for my data_reader, Recording Service shows Error and crashes.
Error is :
DISCBuiltin_deserializeUserDataQosPolicy:unmatched max length in sequence: 256
PRESCstReaderCollator_storeSampleData:deserialize sample error in topic 'DISCSubscription' with type 'DISCSubscriptionParameter'
I think there is an inconsistency, could any one help me?
Well, the QoS settings that you show should allow the Recording Service participant to receive user_data for the discovery of DataReaders to 65536, so, it's unclear what the error is.
I would suggest
1) run Recording Service at a high verbosity level to see if other information is reported, and post the output with error message.
2) provide the full Recording Service configuation XML for review.
this is my xml configuration: <?xml version="1.0" encoding="UTF-8"?> <dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://community.rti.com/schema/6.0.0/rti_recording_service.xsd"> <!-- QoS LIBRARY SECTION --> <types> </types> <!-- <plugin_library> </plugin_library> --> <recording_service name="ABC_SERVICE"> <!-- Enable remote administration --> <administration> <domain_id>110</domain_id> </administration> <!-- enable monitoring --> <monitoring> <status_publication_period> <sec>1</sec> <nanosec>0</nanosec> </status_publication_period> <!-- Sampling period: 100 ms --> <statistics_sampling_period> <sec>0</sec> <nanosec>500000000</nanosec> </statistics_sampling_period> </monitoring> <!-- Top-level storage settings --> <storage> <sqlite> <storage_format>XCDR_AUTO</storage_format> <!-- <storage_format>JSON_SQLITE</storage_format> --> <fileset> <workspace_dir>/home/MyPC/RecordingServiceConfiguration/</workspace_dir> <execution_dir_expression>cdr_recording</execution_dir_expression> <filename_expression>rti_recorder_default.dat</filename_expression> <rollover> <enabled>true</enabled> <file_size_limit unit="KILOBYTES">5000000</file_size_limit> </rollover> </fileset> </sqlite> </storage> <!-- Top-level domain settings --> <domain_participant name="Participant0"> <domain_id>0</domain_id> <participant_qos> <!--transport_builtin> <mask>UDPv4</mask> </transport_builtin--> <discovery_config> <ignore_default_domain_announcements>false</ignore_default_domain_announcements> <participant_liveliness_assert_period> <sec>1</sec> <nanosec>0</nanosec> </participant_liveliness_assert_period> <participant_liveliness_lease_duration> <sec>10</sec> <nanosec>0</nanosec> </participant_liveliness_lease_duration> <!-- quickly detect the loss of liveness of remote participants --> <max_liveliness_loss_detection_period> <sec>5</sec> <nanosec>0</nanosec> </max_liveliness_loss_detection_period> <asynchronous_publisher> <disable_asynchronous_write>false</disable_asynchronous_write> </asynchronous_publisher> <publication_writer_publish_mode> <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind> </publication_writer_publish_mode> <subscription_writer_publish_mode> <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind> </subscription_writer_publish_mode> </discovery_config> <!-- Allow for quicker shutdown times for each participant. --> <database> <cleanup_period> <sec>0</sec> <nanosec>10000000</nanosec> </cleanup_period> </database> <resource_limits> <deserialized_type_object_dynamic_allocation_threshold>1024</deserialized_type_object_dynamic_allocation_threshold> <type_object_max_deserialized_length>LENGTH_UNLIMITED</type_object_max_deserialized_length> <type_object_max_serialized_length>65535</type_object_max_serialized_length> <participant_property_list_max_length>1024</participant_property_list_max_length> <participant_property_string_max_length>32768</participant_property_string_max_length> <contentfilter_property_max_length>2048</contentfilter_property_max_length> <writer_data_tag_list_max_length>256</writer_data_tag_list_max_length> <writer_data_tag_string_max_length>4096</writer_data_tag_string_max_length> <reader_data_tag_list_max_length>256</reader_data_tag_list_max_length> <reader_data_tag_string_max_length>4096</reader_data_tag_string_max_length> <reader_user_data_max_length>65536</reader_user_data_max_length> <writer_user_data_max_length>65536</writer_user_data_max_length> </resource_limits> <property> <!-- Increase the receive socket buffer size to improve performance. --> <value> <element> <name>dds.transport.shmem.builtin.received_message_count_max</name> <value>65536</value> </element> <element> <name>dds.transport.UDPv4.builtin.recv_socket_buffer_size</name> <value>16777216</value> </element> <element> <name>dds.transport.UDPv4.builtin.parent.message_size_max</name> <value>100000</value> </element> <element> <name>dds.transport.UDPv4.builtin.send_socket_buffer_size</name> <value>16777216</value> </element> <element> <name>dds.transport.shmem.builtin.receive_buffer_size</name> <value>2048576</value> </element> </value> </property> </participant_qos> </domain_participant> <session name="DefaultSession"> <subscriber_qos name="SubscriberQos"> <partition> <name> <element>*</element> </name> </partition> </subscriber_qos> <topic_group name="RecordAll" participant_ref="Participant0"> <allow_topic_name_filter>*</allow_topic_name_filter> <deny_topic_name_filter>rti/*</deny_topic_name_filter> <!-- <allow_type_name_filter>*</allow_type_name_filter> --> <!-- <deny_type_name_filter> </deny_type_name_filter> --> <datareader_qos name="ReaderQos"> <destination_order> <kind>BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS</kind> </destination_order> <!-- <reliability> <kind>RELIABLE_RELIABILITY_QOS</kind> </reliability> <history> <kind>KEEP_LAST_HISTORY_QOS</kind> <depth>1</depth> </history> --> <property> <value> <element> <name>dds.data_reader.history.memory_manager.fast_pool.pool_buffer_max_size</name> <value>3000000</value> </element> <element> <name>reader_resource_limits.dynamically_allocate_fragmented_samples</name> <value>true</value> </element> </value> </property> <!-- <time_based_filter> <minimum_separation> <sec>1</sec> <nanosec>1</nanosec> </minimum_separation> </time_based_filter> <deadline> <period> <sec>3</sec> <nanosec>0</nanosec> </period> </deadline> --> </datareader_qos> </topic_group> </session> </recording_service> </dds> I have seen lots of messages in terminal when I executed Recording service, some of them are: [/recording_services/ABC_SERVICE|CREATE|D0110|ENABLE|D0210|Pub(80000088)|T=PRESServiceRequest|CREATE Writer] PRESPsService_enableLocalEndpointWithCursor:RTI0x20d4026:[Local Participant: 10135b9 958b2be0 ec164b47 | Local Endpoint 20082] resulting max. RTPS overhead: 512 bytes and : DISCBuiltin_deserializeTypeObjectLb:RTI0x2000007:!TypeObject serializedSize exceeds DDS_DomainParticipantResourceLimitsQosPolicy's type_object_max_serialized_length DISCBuiltinTopicSubscriptionDataPlugin_deserializeParameterValue:RTI0x20c0009:Problems receiving type object information. Check type_object_max_deserialized_length parameter in .resource_limits add previous Error that I asked about it in the pastWhat version of RTI Connext are you working with?
I would recommend removing (deleting) these settings from your configuration:
the value above should be the default value. Not sure if setting it is triggering some issue.
<element> <name>dds.transport.UDPv4.builtin.parent.message_size_max</name> <value>100000</value> </element>the value above is larger than the largest UDPv4 message size of 65536. And the default value is already the largest size that DDS can fit into a single UDPv4 message.
(these are just suggested changes that probably don't actually fix your problem).
For the error messages, it's useful to have the entire log as log messages before and after the error messages can provide a context in which to interpret the actual error messages, e.g., which Topic the error message is related to.
You can attach as a zip file.
Thank you Mr.Howard.
I use version 6.0.0
I do what you recommend. But they don't fix my problem.
I attach a zip that contains these:
1. log.txt that contains the log when I run recording service with verbasity 6 in command line
2. xml file for configuration
3. two project for sending and receiving message
these two project works correctly.
If I comment userDataQos from receiverProject, RecordingService works correctly, but when I use userData, allways RecordingService crashes.
I tried c++ API for RecordingService, and it has the same issue.
Regards
Hi, thanks for uploading the files.
So, there are a couple of issues that you're running into.
1) Recording Service segfaults when USER_DATA is used by user application DataWriter or DataReaders.
This is a known issue with Connext 6.0.0 that was fixed in Connext 6.1.0. I verified with your example code and configuration that Connext 6.1.0 works with USER_DATA when configured properly.
See these release notes: https://community.rti.com/static/documentation/connext-dds/6.1.0/doc/manuals/connext_dds_professional/services/recording_service/release_notes.html#segmentation-fault-after-discovering-application-that-used-userdata-qos-policy
You will have to update to Connext 6.1.0 (or later...suggest at least the latest version of Connext 6.1.2, which is an LTS release).
2) I saw in your Recording Service configuration file that you are enabling <administration> and <monitoring>. If you do so, and those features are configured to use the same domain, in your config domain 0, as the Recording Service, then those features will also need to be configured to allow them to deal with USER_DATA > 256 bytes...since those features create their own DomainParticipants, one for Admin/one for Monitoring, then they will participate in the discovery in the domain of the Recording Service...and thus receive Discovery data for DataWriters and DataReaders in the same domain.
You will also need to configure the <participant_qos><resource_limits> for those features (admin/monitoring) independently (directly within the <administration> and <monitoring> tags) to adjust the allowable size of USER_DATA.
If you don't, then you will see error messages such as:
C:\Users\howard\Downloads\recording_service_test\Recording_Service_Test>c:\rti\rti_connext_dds-6.1.0\bin\rtirecordingservice.bat -cfgFile RTI_RECORDING_SERVICE_Test.xml -cfgName ABC_SERVICE [0x01014939,0x741EB6EF,0x0808192C:0x000004C7{E=DR,I=21}|RECEIVE FROM 0x01012E8E,0xAE9F1147,0x860F9284:0x000004C2] DISCBuiltin_deserializeUserDataQosPolicy:unmatched max length in sequence: 256 [0x01014939,0x741EB6EF,0x0808192C:0x000004C7{E=DR,I=21}|RECEIVE FROM 0x01012E8E,0xAE9F1147,0x860F9284:0x000004C2] PRESCstReaderCollator_storeSampleData:deserialize sample error in topic 'DISCSubscription' with type 'DISCSubscriptionParameter' [0x01014939,0x741EB6EF,0x0808192C:0x000004C7{E=DR,I=21}|RECEIVE FROM 0x01012E8E,0xAE9F1147,0x860F9284:0x000004C2] PRESCstReaderCollator_newData:!get entries RTI Recording Service (Recorder) 6.1.0 starting... RTI Recording Service startedI'd like to point out a few unrelated issues as well:
1) I see that you're trying to configure a reliable connection using RELIABLE Reliability and KEEP_ALL History QoS settings. Best practice to do so is to derive your QoS from the builting QoS Profile "BuiltinQosLib::Generic.StrictReliable". This not only configures the Reliablity and History Qos settings for you but also makes adjustments to the parameters of the reliability protocol from their default values to ones that are more performant generally.
Please see more info in these links:
https://community.rti.com/examples/built-qos-profiles
https://community.rti.com/kb/configuring-qos-built-profiles
https://community.rti.com/best-practices/configure-your-qos-through-profiles
Note: The name "BuiltinQosLibExp" has changed to "BuiltinQosLib".
2) I see that you are setting the DomainParticipant ResourceLimits parameters
<writer_data_tag_list_max_length>256</writer_data_tag_list_max_length>
<writer_data_tag_string_max_length>4096</writer_data_tag_string_max_length>
<reader_data_tag_list_max_length>256</reader_data_tag_list_max_length>
<reader_data_tag_string_max_length>4096</reader_data_tag_string_max_length>
These are only needed if you are using the DATA_TAG QoS policy for DataWriters/DataReaders. These don't affect the USER_DATA QoS policy.
Thanks a lot Mr. Howard.
Your Points are so helpfulI.
I wish you the best.