Jump to content
OpenSplice DDS Forum


  • Content count

  • Joined

  • Last visited

About armando.paz

  • Rank

Profile Information

  • Company
  1. armando.paz

    delivery delay

    Hi, actually there is no real error ... so no error code to show. There was one DataWriter producing samples, and three DataReaders consuming, all in different processes. When one of the readers was killed, could observe that the other readers paused their reception of samples. No sample was lost. Just wasn't expecting that other subscribers could be affected by the failure of one DataReader. But after your comment, and rereading the spec it seems that this is valid behavior ... and the blocking seems occurs at the writer. Well ... anyway will investigate a little further this scenario. Thanks, Armando.
  2. armando.paz

    delivery delay

    Hi All ! was experimenting with one publisher and some subscribers for a topic. The publisher just sends a periodic update for an instance. The rate of sending is one update per second. The QoS for the topic is configured to Reliable and History is defined to KeepAll. The point is that when I kill one of the subscriber processes, the other subscribers stop receiving updates stop getting the regular updates for a period (around 5 seconds) and then resume their receiving a burst of samples before returning to the regular rate of receiving one sample a second. No samples are lost. Thought that maybe there is some configuration item that can be touched so that the reception behaves differently, and that the other subscribers are not affected when one of them gets killed. Remember when working with TAO that there was some configuration that defined the use of one thread per connection ... anything related in Opensplice ? Or some timing parameter that controls this ? btw ... using the community edition V6.7. Regards. Armando.
  3. armando.paz

    segmentation fault listener

    a little update: - was working with a local build of the DDS tree, where I did configure to compile with C++11 support and defined the macro OSPL_USE_CXX11 in file setup/x86_64.linux-release/config.mak. Compilation went OK, but produced a result reported in previous message. - downloaded the binary of the Community Edition for the OS flavour I am using (Ubuntu 16.1), and after recompiling just the contents of directory custom_lib, to have the things in C++11 and compatible with my code base, the Listener example and my application did work. So there is some issue with my local compilation ... if I have time will check what may be the problem. And a final remark: - after transitioning from version 6.4 to 6.7 had to selected the events that where being notified to the Listener by setting the appropriate mask when associating the Listener to the DataReader.
  4. armando.paz

    segmentation fault listener

    Hi, was testing the last release of community edition (V6.7) against some code that used to work with the previous version (V6.4). When reading data with a Listener the program crashes when receiving data. Did repeat the test using the example provided in the Opensplice tree: ../examples/dcps/Listener The example with the C language worked ok, but both isocpp and isocpp2 crash in a similar fashion as my application. Any clues ? Saw inside the code (src/api/dcps/c++/common/code/Entity.cpp) a reference to issue OSPL-8179, that maybe is related to the crash. Below the fragment of file Entity.cpp: ------------------------------------------------------------------------ DDS::ReturnCode_t DDS::OpenSplice::Entity::reset_dataAvailable_status ( ) THROW_ORB_EXCEPTIONS { u_result uResult; /* TODO OSPL-8179: This is a bit tricky, the entity may already been deleted and in that case * this operation will perform a dirty memory read. * It may be better to wipe all pending events belonging to an entity when it is deleted or * if that is too intrusive find another way to safely detect/avoid deletion. * NOTE: This was copied from SAC. */ uResult = u_observableAction(u_observable(this->uEntity), Entity_resetDataAvailable, NULL); return this->uResultToReturnCode(uResult); }