Strict reliable large data connection lost after aprox. 20 messages

2 posts / 0 new
Last post
xty250hp's picture
Offline
Last seen: 3 years 5 months ago
Joined: 03/09/2015
Posts: 21
Strict reliable large data connection lost after aprox. 20 messages

Hi everyone, 

I have runned into a problem and i do not seem to wrap my head around it. let me explain what is my setup and how things should work.

I am using connext 5.2 

first I have a base participand qos defined  as :   

<qos_profile name="Default.Participant.QoS" is_default_participant_factory_profile="true">
<participant_qos>
<receiver_pool>
<buffer_size>65530</buffer_size>
</receiver_pool>
<discovery_config>
<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>
<transport_builtin>
<mask>UDPv4</mask>
</transport_builtin>
<property>
<value>
<element>
<name>dds.transport.UDPv4.builtin.recv_socket_buffer_size</name>
<value>1048576</value>
</element>
<element>
<name>dds.transport.UDPv4.builtin.parent.message_size_max</name>
<value>65530</value>
</element>
<element>
<name>dds.transport.UDPv4.builtin.send_socket_buffer_size</name>
<value>65530</value>
</element>
</value>
</property>
<resource_limits>
<type_code_max_serialized_length>0</type_code_max_serialized_length>
<type_object_max_serialized_length>1048576</type_object_max_serialized_length>
<participant_property_string_max_length>1048576</participant_property_string_max_length>
<participant_property_list_max_length>10000</participant_property_list_max_length>
</resource_limits>
</participant_qos>
</qos_profile>

 

For each topic I have a base QOS in which I define the base behaviour for that particular entity as : 

1. Machine order topic
*****************************************************************************************-->
<qos_profile name="MachineOrderBase" base_name="User.Generic.StrictReliable.LargeData" >
<datawriter_qos>
<property>
<value>
<element>
<name>
dds.data_writer.history.memory_manager.fast_pool.pool_buffer_max_size
</name>
<value>1048576</value>
</element>
</value>
</property>
</datawriter_qos>
<datareader_qos>
<property>
<value>
<element>
<name>
dds.data_reader.history.memory_manager.fast_pool.pool_buffer_max_size
</name>
<value>1048576</value>
</element>
</value>
</property>
</datareader_qos>
</qos_profile>

I have a persistant topic where the history with a depth of 1 is stored for all late joiners and two event topics for the system to react when sothong is happening as CHANGE and CHANGENOTIFICATION. The change is received by a storage plugin which reacts acordingly and sends a change notification to all endpoints interested in that notification. 

The persistant QOS is as follows : 

<qos_profile name="MachineOrder" base_name="Custom.Transient.Local" >
<datawriter_qos>
<publish_mode>
<kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>
<priority>0</priority>
</publish_mode>
<property>
<value>
<element>
<name>
dds.data_writer.history.memory_manager.fast_pool.pool_buffer_max_size
</name>
<value>1048576</value>
</element>
</value>
</property>
</datawriter_qos>
<datareader_qos>
<property>
<value>
<element>
<name>
dds.data_reader.history.memory_manager.fast_pool.pool_buffer_max_size
</name>
<value>1048576</value>
</element>
</value>
</property>
</datareader_qos>
</qos_profile>

The typeCode of the entity is not available to the Admin console so I am loading the type from the xml. The problem I have is that after a number of messages the topic is dead and not recoverebel until I restart the app. Is there a way to detect if a topic is dead for some reason and try to restart the subscription from a higher point that the reader. As I see it the publisher does not publish anything. 

Thank you and plaese let me know if you need more details and loggs

 

 

Gerardo Pardo's picture
Offline
Last seen: 2 days 5 hours ago
Joined: 06/02/2010
Posts: 588

Hello,

Can you expand on what you mean by "the Topic is dead"? Do you mean  that the sending application is writing the topic but the receiving application does not receive the data anymore?

In terms of reproducing and troubleshooting the problem one thing that would be very helpful would be to have a description of your whole system using the XML-Application Creation file format.  In principle if this was a problem in the Qos configuration you should be able to reproduce it just using that XML file and the rtiddsprototyper utility to "inpersonate" each DomainParticipant. If you get that to occur and send us the XML file we can easily reproduce it determine what is going on...

Regards,

Gerardo