Replay service- Mismatch

5 posts / 0 new
Last post
Offline
Last seen: 6 months 3 weeks ago
Joined: 08/24/2018
Posts: 11
Replay service- Mismatch

I have an Intel NUC that I have setup to headlessly run the RTI Record and Replay services which we are calling the Blackbox. I have verified this system works using the shapes demo.

Now we have a single prototype unit here running RTI and serving data. I also have a logging software that subscribes to a topic from that prototype and logs. I have verified those work together.

We had a run recently where I recorded with the Blackbox and my logging software simultaneously. Everything appeared to work and record services created files on the Blackbox. I then took the Blackbox back to my desk and connected it. When I run it with my logging software, I suddenly get a mismatch.

I've tried this with and without the QOS profile loaded into the Blackbox (the same one running on the other two systems) and it doesn't seem to make a difference. So I'm little confused now. Also, how is infinite < 31,536,000 seconds?

Offline
Last seen: 4 months 3 weeks ago
Joined: 08/09/2017
Posts: 15

The message may seem backwards, but it is actually complaining that the offered value needs to be less than or equal to the requested value.  In other words, each participant must be willing to update its liveliness as least as often as other participants want it updated.

That being said, these are unusual values for lease duration.  Are you setting the values explicitly in the QoS, either during record or during replay?

Offline
Last seen: 6 months 3 weeks ago
Joined: 08/24/2018
Posts: 11

They are being set explicitly in the QOS I have on the prototype and the logger. Honestly I think that strange number is just a development number and not intended for the final state.

So does this mean that RTI is not getting the USER_QOS_PROFILES.xml correctly? I've done three different things to try to accomplish this while debugging.

  1. Placed USR_QOS_PROFILES in ~/rti_connext_dds-6.0.0/bin with the record/replay service executables
  2. Placed another copy of QOS in  /usr/bin/ (where the compiled thing that launches record replay is)
  3. Tried to set it in the systemd service file with "Environment=NDDS_QOS_PROFILES=path to the QOS" (This is the file that launches our program that handles launching record or replay when commanded, theoretically that line should set a env variable)
  4. I've tried to set the environmental variable with export pointing to the same profile

I'm pretty sure it's set by now, unless record/replay use a different method of loading QOS

Offline
Last seen: 4 months 3 weeks ago
Joined: 08/09/2017
Posts: 15

Looking at the screenshot a little closer, I see that this is actually a DataWriter entity and not a DomainParticipant.  Infinite is the default value for the DataWriter liveliness, but 31,536,000 is not the default for the DataReader.  If the writer is part of rtireplayservice, and you are setting the DataWriter QoS in the replay configuration file, then I'd say the QoS is not getting picked up.  Typically you would include the QoS in the replay service configuration file and specify it using the -cfgFile, but you can also use the locations and variables documented in section 4.2.1 at https://community.rti.com/static/documentation/connext-dds/6.0.0/doc/manuals/recording_service/replay/replay_configuration.html.

Offline
Last seen: 6 months 3 weeks ago
Joined: 08/24/2018
Posts: 11

Ok, I'm reading through the documentation with that in mind now. Thanks for the help. Mind if I clarify something before I start writing?

DDS Replay requires that you explicitly name each publisher and topic name and give a QOS for each in the Record Service's xml syntax? There is no way to point to existing structure in a USER_QOS_PROFILES.xml that defines topic/publishers/qos and have the replay service match using that existing structure?

Basically I want is record service to record everything, and replay service to match what it saw (no need to change QOS).