Jump to content
OpenSplice DDS Forum

Hans van 't Hag

Moderators
  • Content Count

    401
  • Joined

  • Last visited

About Hans van 't Hag

  • Rank
    Product Manager

Contact Methods

  • Website URL
    http://ist.adlinktech.com/

Profile Information

  • Gender
    Male
  • Location
    Hengelo, The Netherlands
  • Company
    ADLINK Technology

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, It might be an issue with anonymous types (that are deprecated in IDL 3) .. could you share an example that exhibits the issue ?
  2. Hi Jan-Marc, Unfortunately not: you have to specify a list of peers, either by address (as you've done here) or by name. Note however that 'your own address/name' may be part of that list thus allowing the same config-file to be applied to every machine in the system.
  3. I'm not aware of a 'special editor', guess you could use any editor you like .. What we use ourselves are a bunch of 'best-practices' captured in such QoS-profiles that 'capture' different 'kinds' of data such as telemetry, state and/or events. Here's for instance our 'telemetry' profile (typically used to distribute periodic digital-samples of the analogue world): telemetry.xml
  4. I suspect you'd be happy with our 'qosProvider' API:
  5. editing output of idlpp is generally a bad-thing to do so I doubt that anybody else has experienced that same issue. I'm trying to understand what you'd like to achieve .. is it about modules in the IDL (and related 'fully-qualified-type-names that migh have ::) ? Otherwise, if its about topi-names, those can't have a '.' in them.
  6. if you do an 'ldd' on for istance $OSPL_HOME/lib/libspliced.so you'll get something like this: hansh@perf2:~/ADLINK/Vortex_v2/Device/VortexOpenSplice/6.9.181127OSS/HDE/x86_64.linux/lib$ ldd libspliced.so linux-vdso.so.1 => (0x00007ffd1c702000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00002ae91a668000) libddskernel.so => /work/hansh/ADLINK/Vortex_v2/Device/VortexOpenSplice/6.9.181127OSS/HDE/x86_64.linux/lib/libddskernel.so (0x00002ae91aa32000) /lib64/ld-linux-x86-64.so.2 (0x00002ae91a22f000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00002ae91ae09000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00002ae91b112000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00002ae91b316000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00002ae91b533000) would that be helpful ?
  7. Hi Jan-Marc, Thats 2 questions applications can exploit KEEP_ALL writer-history QoS setting which allows them to specify a timeout on the ability to 'get rid of their data' (i.e. to get notified of such a timeout when blocking on a high-watermark) the WHC settings can NOT be influenced by API-functions (as the whole point of DDS is to 'shield' applications from those underlying network intricacies) but you CAN choose to change the (default) settings (of a 100 kb watermark) like this (see 'Watermarks' section): <DDSI2Service name="ddsi2"> <General> <NetworkInterfaceAddress>AUTO</NetworkInterfaceAddress> <AllowMulticast>true</AllowMulticast> <EnableMulticastLoopback>true</EnableMulticastLoopback> <CoexistWithNativeNetworking>false</CoexistWithNativeNetworking> </General> <Compatibility> <!-- see the release notes and/or the OpenSplice configurator on DDSI interoperability --> <StandardsConformance>lax</StandardsConformance> <!-- the following one is necessary only for TwinOaks CoreDX DDS compatibility --> <!-- <ExplicitlyPublishQosSetToDefault>true</ExplicitlyPublishQosSetToDefault> --> </Compatibility> <Internal> <Watermarks> <WhcHigh>800 kB</WhcHigh> </Watermarks> </Internal> </DDSI2Service>
  8. My statement was about not being able to support TRANSIENT/PERSISTENT data in your system once you remove all durability-services. It indeed doesn't impact TRANSIENT_LOCAL data-distribution. So whereas using TRANSIENT_LOCAL data in your (current) applications is a 'local decision', not having any durability-services configured is more of a 'global decision' for the whole system. I've also checked with the durability-exports on the cause of that warning and that's typically related to high network-latencies (i.e. like in a WIFI) network that's not anticipated by the durability-service's internal protocols do decide who is the 'master' to provide late-joining applications with TRANSIENT/PERSISTENT historical data. We've introduced an alternative to that 'majority-voting' that can be easily enabled by adding the 'masterPriority="1"' attribute in the durability-configuration: <Policy alignee="Initial" aligner="true" durability="Durable" masterPriority="1" nameSpace="defaultNamespace"/> Here's a complete ospl_sp_ddsi.xml that includes that setting ospl_sp_ddsi.xml
  9. Theoretically you could completely remove it .. Personally I never do that, also as our tools (Tuner/Tester, that are part of the commercially-supported edition) are 'unhappy' without durability .. And of course, once removed, your late-joiners for TRANSIENT/PERSISTENT data won't get historical-data delivered to them without that being flagged as a (local) problem
  10. just ignore it, its a warning of the durability-service(s), which you're not using when using TransientLocal .. I'll have to check here about the situations where/when these warnings happen, but it shouldn't impact your applications (yet could be a sign of a bad network)..
  11. to be clear: after you make the change, does the warning come immediately when starting the 1st (modified) application ? And furthermore, I assume that you're not using the commercial-edition (that supports federations and where its a very common mistake to leave a federation-running after all applications are 'gone' which implies that the topic-definitions are still available in the system .. and like highlander .. there can be only 1 (topic-definition)
  12. don't understand either.. As asked before, do you get the 'unmatching' warning already when starting the first application or only when you start a second one ? I.m.o. the error can only arise when you run applications with different settings (or still have a durability-service running somewhere that has 'cached' the old topic-definition
  13. I'm sorry but I don't see any TRANSIENT_LOCAL settings in that example .. (and I thought you had the 'unmatching QoS-policiy' issues when using TRANSIENT_LOCAL)
  14. The only 2 things I can think of is that you still somewhere register the topic as TRANSIENT(eventhough your readers/writers might be generated as TRANSIENT_LOCAL) .. somewhere on your network, there's still an application (or federation) running that has 'remembered' that topic as being TRANSIENT Maybe its good to take a look at the bundled durability-example that shows how first the topic-level qos is created and how then that qos-set is used in creation of writers/readers .. (see <install_dir>\HDE\x86_64.win64\examples\dcps\Durability\isocpp2\implementation.cpp .. or comparable if you're not on windows) It would also help if you could share your actual code, but maybe thats impossible, or needs to get sanitized first .. or at least provide the info/error-logs of both applications with some information if the error is generated when starting the second app' or already when starting the first app ..
  15. Hmm .. such a detection means that somewhere in your system somebody is still exploiting/defining either topics and/or readers/writers for which the durability-settings are still TRANSIENT rather than TRANSIENT_LOCAL Also don't forget that w.r.t. configuring durability on topics, there's actually 2 settings involved, see this excerpt from the specification: I suspect that its the topic-level DURABILITY_SERVICE configuration that has been overlooked somewhere. Noting that these settings are their to 'configure' the behavior of the durability-service(s) of the system (and that can't be done via writers/readers as the lifecycle of those is basically decoupled from that of durability service(s), thats also a reason why we don't exploit the suggested option above to apply those settings on/for a dataWriter which is actually an oversight in the spec). Note that topic-level DURABILITY settings (as opposed to the DURABILITY_SERVICE settings above) serve merely as defaults for - to be created - writers/readers (where you use the copy_qos_from_topic_qos as a utility to exploit those defaults). You might find some clues by firing up your app's in specific order, as a conflict will only be reported once a conflicting definition is inserted in the system ..
×
×
  • Create New...