replaying issue

I've encountered a certain problem with the recording service while recording and replaying data.

I've set-up a DataWriter that sends samples of a certain unkeyed instance, with the recording service up. Later on, I close the DataWriter and try replaying from the recording to a DataReader. By doing match analysis in the Analyzer, I see that the sample sent from the DataWriter (the replay), arrived with key, while the DataReader expects to receive no key. I'm using a very basic replay configuration that doesn't define anything concerning keyed/unkeyed instances whatsoever. Also there is a zero chance of this instance being sent from other DataWriters.

Is there any chance the problem is in the recording/replaying service or their configuration?

This is a very odd situation. I do not see how recording/replay service can be doing this. Let me break this down into a set of questions/observations:

Are you defining the data-types to be recorded in the XML file you use to configure recording service? Or re you simply specifying the Topics to record and letting Recorder discover the data-types? If you defined the types in the recorder XML configuration then you could see if any attributes in the data-type were marked as key.

Independent of (1) above for recorder to record the Topic the data-type definition must match that of the DataWriter. So if the DataWriter had no keys, then recorder either uses an unkeyed data-reader to record the data, or else if if tried to use a keyed-data reader (e.g. because the type was defined as keyed in the XML or discovered from a different data-writer) it would then not match the unkeyed data-reader and not record its data.

Recorder saves the type associated with the DataReader it used to record and uses that to create the DataWriter. So if it did record data from an unkeyed DataWriter it had to use and unkeyed DataReader (see 2) and it would publish it also as unkeyed.

Given all this the only possible explanation I can think of is that you actually had both an unkeyed and a keyed DataWriter publishing to the same Topic in your system when you run Recorder. Somehow either because Recorder was configured via XML with a keyed type, or if not because it discovered the Keyed DataWriter first, Recorder ended up creating a Keyed DataReader to record the data and then played it back as keyed...

To clear things up and answer your questions: I don't denife the data-types in recorder config xml, I define only the topics to record.

Moreover, I've defined a new topic just to make sure I'm the only one sending and receiving data on that topic, and removed all other topics from recorder config xml. Also, while recording the data, I ran an Analyzer and saw that the DataWriter and the recorder's DataReader had a match with no key. Which makes it even more baffling that the replayer's DataWriter behaves differently from the recorder's DataReader... Is it possible that somehow the recorder DataReader received a keyed typecode from another topic that uses the same instance even though in Analyzer I saw an unkeyed match?

That is indeed a weird behaviour. However, we did fix an issue when getting the keyed status of the type-code in Replay and it will be available in the next general-access release.It has also been fixed in one of the patches available for Support customers.

I've ran into a bit of a problem installing the Recorder on linux. Running ./RecordingService-5.0.0.4-linux-installer.run doesn't seem to install it or produce any output. Is it supposed to be installed by other means?

RTI Community Portal Terms of Use

NOTICE: Any content you submit to the RTI Research Community Portal, including personal information, is not subject to the protections which may be afforded to information collected under other sections of RTI's Web site. You are entirely responsible for all content that you upload, post, e-mail, transmit or otherwise make available via RTI Community Portal. RTI does not control the content posted by visitors to RTI Community Portal and, does not guarantee the accuracy, integrity, or quality of such content. Under no circumstances will RTI be liable in any way for any content not authored by RTI, or any loss or damage of any kind incurred as a result of the use of any content posted, e-mailed, transmitted or otherwise made available via RTI Community Portal. Read the complete Terms prior to use.