Jump to content
OpenSplice DDS Forum


  • Content Count

  • Joined

  • Last visited

About niels.kortstee

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. Did you also update the //OpenSplice/Domain/Id in your XML configuration file to 8331 (the value of your OSPL_URI environment variable points you to your XML configuration)?
  2. Have you seen the Throughput example that comes as part of the OpenSplice distribution? That example seems to do exactly what you are trying to achieve.
  3. Please note that the jar attempts to load a JNI C-library that is in $OSPL__HOME/lib. Therefore you'll need to set java.library.path to $OSPL_HOME/lib.
  4. Hi Akhil, The message board application simply polls for data indeed. DDS provides so-called Waitset and Conditions in the API. You can for instance create a ReadCondition, attach it to the Waitset and block until the condition become true, similar to the select usage that you're used to. The Waitset example in the distribution may be a good place to start.
  5. Hi Akhil, Not sure what your question is... be aware that what you calculate here is how long it takes to write a sample. Since DDS is asynchronous, the write operation may return before the sample is delivered to the DataReader(s). Regards, Niels
  6. Hi Akhil, In DDS every sample you write gets timestamped when you write it (called source-timestamp). This timestamp is used to determine ordering in the history of samples with the same key-value (called instance in DDS) in DataReader caches. By default DDS attaches the timestamp given by operating system clock when writing the sample, but you can also provide your own timestamp using the write_w_timestamp function. Typically the latter approach is taken when the data that is written is coming from an external source that already provides a timestamp. The source timestamp is sent over the wire with the data you've written and delivered to your DataReader(s). When the sample is delivered there, DDS automatically requests the time again from the operating system at the receiving side and stores this timestamp (called reception timestamp) with your data as well. When your subscribing application then reads the sample, it also gets access to the so-called SampleInfo and that structure holds both source and reception timestamps. In principle you could use the difference between these two to calculate the latency, but be aware that source timestamp is determined on the writing node and the destination timestamp is determined on the receiving node. Given the fact that latencies are typically in the microseconds domain and time-alignment between nodes using NTP is in the milliseconds domain, this approach will not give you reliable numbers. The RoundTrip example that is shipped as part of the product prevents this issue by sending data from A to B and back and therefore calculating the difference on the same node. Also, it does not rely on the source and destination timestamps in the SampleInfo as the reception timestamp does not include the time it takes to trigger the application on the incoming data and have the application read the data. Well... that's quite a long story, but the conclusion is that the write_w_timestamp does not give you what you need and the RoundTrip example exactly seems to calculate what you are looking for. Regards, Niels
  7. Why not use the RoundTrip example that is part of the distribution already? This example consists of two applications. A ping application that writes a sample, which is received by the pong application and immediately written again to be received by the ping application again. The ping application calculates the time from just before writing and just after reading the sample received from the pong application and divides it by two (because sample goes over the wire twice in this scenario). The ping-pong approach is taken to ensure there is no need for time alignment between the node where ping runs and the potentially other node where pong runs.
  8. Hi Dennis, what is the value of your OSPL_URI environment variable? You might need to add an extra set of double quotes before and after.
  9. Hello Dennis, Judging by the log files you initially had some issues setting up your OSPL_URI environment variable in previous runs. Assuming this has been resolved, the error "Can not Create the database file (C:\Users\Dennis\AppData\Local\Temp\ospA42E.DBF), System Error Code: 80" tells me that the creation of the shared memory file fails due to the fact it exists already (error code 80). I think manually deleting C:\Users\Dennis\AppData\Local\Temp\osp* and restarting should do the trick. Cheers, Niels
  10. What's the actual type you're publishing? Assuming you're using struct X as you type and don't want to use keys, you could model your struct like this: struct X { string xstr; }; #pragma keylist X When you use this, you'll be able to use xstr='germany' as the condition string for a ContentFilteredTopic or QueryCondition.
  11. Hi Morly, do you have an ospl-info.log and/or ospl-error.log that can shed some light on this maybe?
  12. You are setting the listener after the historical data has arrived (as that data arrives during creation of datareader already) and this causes the listener not to trigger. The solution would be to set the listener at creation time of the entity by supplying listener plus mask as parameters of the create_datareader method.
  13. You need to use the DurabilityQosPolicy for that and switch from the default VOLATILE to TRANSIENT (or even PERSISTENT if you like data to outlive system downtime) on Topic, DataWriter and DataReader QoS-ses. You can find more information in section of the Java reference manual in $OSPL_HOME/docs/pdf/OpenSplice_refman_Java.pdf.
  14. Each DataReader has its own private 'cache'. This means that if a sample arrives in both your readers and you take it from one of them, it will still be available in the other one.
  15. That would be ANY_VIEW_STATE. Please also be aware that you will read your samples multiple times as you're using read (and not take) i.c.w. ANY_SAMPLE_STATE. This would result in reading all samples in your reader cache every time one sample arrives. You could consider using the take method instead of read or alternatively use the NOT_READ_SAMPLE_STATE instead of the ANY_SAMPLE_STATE.
  • Create New...