Jump to content
OpenSplice DDS Forum

Hans van 't Hag

Moderators
  • Content count

    312
  • Joined

  • Last visited

About Hans van 't Hag

  • Rank
    Product Manager

Contact Methods

  • Website URL
    http://www.opensplice.org

Profile Information

  • Gender
    Male
  • Location
    Hengelo, The Netherlands
  • Company
    ADLINK Technology
  1. helloworld standalone example memory leak

    Yeah, I remember that the msgId is a 'key' in the topic so you're creating as many instances as you have key-values. You could try unregistering the instance after you've written it.
  2. helloworld standalone example memory leak

    Hi, It might help if you could share the modified code. What might have happened is that you're creating as many instances (i.e. key-values) as you're creating samples and then perhaps don't unregister() or take() the samples .. in which case the administration-overhead related to any 'instance' might explain your observation. Regards, Hans
  3. Mapping a partition to a channel

    Hi Guy, I think you're confusing 2 concepts: network-channels (that relate to a range of transport-priorities) and network-partitions (that relate to a set of logical DDS-partitions). In your case it seems like you're looking for 'network-partitions' rather than 'network-channels'. Currently both 'mapping' features (i.e. mapping of logical QoS's such as TRANSPORT_PRIORITY and/or PARTITION to physical constructs such as network-channels and network-partitions) are part of our 'extended' DDSI2E service thats currently not part of our community edition. Note however that these are purely non-functional optimizations so even without those, functionally you should be 'fine' when 'just' using logical DDS-partitions to 'group' your topics and their connectivity. The good news is that DDSI2E and its mapping features will become available soon when we are going to opensource our full product under the Eclipse foundation (working title: Eclipse Cyclone). In the mean-time you could try-out our commercially supported version to see if it suits your needs via our website (see opensplice download). Regards, Hans
  4. Multitopic in isocpp2

    Yes, our IDLParser(s) do support unions. What languages do you envision ? I'll start some discussions internally on the above and see what we could do to help in the short-term as proper multi-topic support isn't on the horizon yet.
  5. Multitopic in isocpp2

    Hi Emmanuel, You're right in that MultiTopics are indeed targeting that functionality and also in your observation that this functionality isn't supported yet (actually by none of the current DDS-vendors). The reason behind not having implemented this (yet) is that there are still gaps in the semantics in case of incomplete information in 2 situations: (1) when should you first get a joined-set (i.e. only when its complete w.r.t. availability of all the attributes from all topics that you're interested in (2) when should you last get updates on a joined-set (i.e. up to the point where at least one of the attributes has reached the end of its lifecycle e.g. is part of a disposed instance) That said, its not rocket-science to do such a joint on application-level (as we ARE following a relational model isn't it) .. and apply some basic semantics for the above .. We're still looking at some good (business-)cases that would justify investment in that piece of missing spec-coverage so perhaps you can contribute yours
  6. Communicate betwwen different subnets

    I suspect that there's an issue with multicasting being allowed between your subnets. You could perhaps try and set-up DDSI not to use multicast (AllowMulticast=false) and explicitly specify the peers under Discovery/Peers/Peer
  7. Vortex DDS on Raspberry pi

    Hi Jeremy, If you're looking for our community-edition, there are pre-built version for Raspberry pi (DDS Community Edition Version 6.7 for Raspberry Pi Host and Target, Debian Linux, gcc 4.9.2, ARM v6l) available here: http://www.prismtech.com/dds-community/software-downloads If you're looking for the latest commercially supported Vortex OpenSplice installer (6.8) for Raspberri PI, please contact us here: http://www.prismtech.com/contact-us You can move whichever version to the SD-card of the pi .. that shouldn't be a problem .. just make sure that the 'release.com' which you have to source before usage sets the right paths for the OSPL_HOME and OSPL_URI environment variables. Thanks, Hans
  8. TTopicImpl.hpp Line 175 Bus Error

    Could you share the code so we could reproduce ? Thanks, Hans
  9. Compilation fails with gcc/g++ 5.3.1 (ubuntu 16.04)

    You can also take a look here: http://forums.opensplice.org/index.php?/topic/2602-build-opensplicedds-v64-from-source-error-on-unbuntu-1504/ Which references the page: http://ros2.xyz/blog/2015/09/16/building-opensplicedds-v6-4-on-ubuntu15-04/ We will also update our website w.r.t. these instructions .. sorry for the inconvenience Regards, Hans
  10. 6.7 and apache license

    Hi Bud, Yes being (even) more permissive was the driver for our change towards Apache license 2.0 as especially the combination of LGPLv3 and Apache was troublesome for some of our community users. Regards, Hans
  11. Hi, DestinationOrder is a RxO QoS so you must assure that you've set the same policy both on the writer and the reader. If you've only set it for the reader, then there's a QoS-mismatch that indeed results in no communication happening (anymore). Apart from that, ordering by SourceTimestamp only orders samples for the same instance (key-value). I you require ordering of samples over multiple instances within a topic or even ordering of samples over a group of topics, then you need to use the 'PRESENTATION' QoS policies (w.r.t. both 'ordered-access' as well as access-scope 'TOPIC' or 'GROUP'). Please note that the current community-edition doesn't support anything beyond the default PRESENTATION QoS -settings (access_scope 'INSTANCE') yet our upcoming community-update in June DOES support full PRESENTATION QoS
  12. DDS Community download links are not working!

    Hi Sean, We should be up again now .. sorry for any caused inconvenience! Regards, Hans
  13. DDS Community download links are not working!

    Hi, We're in the middle of moving offices .. downloads will be back-up again shortly Thanks, Hans
  14. What if I want to forward topic sample to the cloud (MQTT)?

    Hi, OpenSplice indeed allows to specify (extensible) data-structures with Google Protobuf instead of IDL and that included the ability to extract the protobuf 'blob' (rather than individual attributes) at you reader-side whereafter you could send that blob to the cloud using any technology and then 'digest' using the appropriate protobuf definition (the same that was used at the writer where it was 'wrapped' into a DDS-topic for efficient sharing in the 'DDS-domain'). Note that besides Vortex OpenSplice we also have products (Vortex Fog and Vortex Cloud, see http://www.prismtech.com/vortex ) that allow to transparently (and securely) 'extend' the DDS 'backbone' from a LAN to any private/public cloud (realized by a combination of dynamic-discovery over the WAN and selective routing of data for which there is remote interest from the UDP/multicast-LAN to the typically TCP/SSL based WAN). Hope this helps, -Hans
  15. Ok, I think I understand the source of the confusion: QoS-policies defined on topic-level do not automatically get 'transferred' to the policies of readers/writers. They are there to serve as 'defaults' but they have to be explicitly copied (copy-from-topic-qos API's). The reason is that the guys that come-up with the data-model i.e. the topics are often also the domain-experts that can 'reason' about those QoS's that define global-behavior such as durability, reliability, urgency, importance. So if they define the proper topic-level QoS's then individual appliation-programmers that eventually write/read samples of those topics can 'inherit' that knowledge by re-using those policies as defined on the topic-level. In your case, although you have specified a KEEP_ALL history-policy on the topic-level, that wasn't 'effectuated' for your reader which is still using the default KEEP_LAST policy with a depth of 1. Since a reader-history is more about local-behavior than system-wide behavior, it usually isn't specified on topic-level, unless your topic is non-volatile i.e. TRANSIENT or PERSISTENT, in which case you MUST specify the DURABILITY_SERVICE QoS policies on the topic-level (i.e. history-kind, history-depth and resource-limits). So for your example there's 2 things to do: 1. specify the DURABILITY_SERVICE policies for you topic so that the middleware knows how to 'retain' those non-volatile samples 2. specify a (matching) history-policy for your reader so that sufficient historical samples are maintained in your reader's history-cache Typically I'd suggest a KEEP_LAST policy with a sufficient depth rather than using a KEEP_ALL policy as KEEP_ALL will cause end-to-end flow-control in case resource-limits are reached (or if you don't specify resource-limits, you can run out of memory if you're not careful with your instance-management and/or disposing stale data) Hope this helps.
×