issue with QoS using insight's built-in ishapes

[hansvanthag]

While testing (for the first time) the new 'built-in ishapes' feature of insight, I ran into a (small) bug:

I first created a writer/reader pair for 'squares' that worked just fine.

The only (minor) thing was that (having used the OSPL/cyclone ishapes-demo before), upon publishing, nothing was displayed (unlike our existing ishapes-demo's that show any published shape with an 'white' centre-dot and a subscribed shape with a 'black' center-dot .. maybe an idea but not a real problem

The issue I'm referring to manifested when I tried to create another/new square-reader but this time with a modified QoS i.e. a history of 10 samples.

That reader was not created an instead the log shows _"Error creating endpoint Square: [DDS_RETCODE_INCONSISTENT_POLICY] A policy with inconsistent values was used. Occurred upon initialisation of a cyclonedds.topic.Topic".

The suspicion is that the topic-creation is somehow tied to the publisher/subscribe creation which can cause these issues when you start manipulating the requested QoS that apparently is also used for (in this case multiple) creations of the same topic.

In a 'true data-centric world', there would be data-model designers that think about QoS (at least the ones with global impact) rather than each individual application-developer and that's why we introduced this notion of topic-level QoS policies that are 'inherited' when creating readers/writers for such a topic.
So a suggestion would be to have an option to define the topic-level QoS (including the DURABILITY_SERVICE QoS policies that will become relevant soon when we introduce a true durability-service for Cyclone) for each shape which then can be used/shown as the default QoS's when explicitly creating readers/writers for those topics and of course would allow to adjust/overrule QoS-policies such as (in this case) the history-depth QoS for a reader (similar to the current QoS-selection window that pops up once you opt to publish/subscribe to a shape).

Additionally noting (not sure its an issue) that 'history-depth' that's not part of the DURABILITY_SERVICE QoS i.e. that applies to a writer or reader is a pure local QoS-setting (also non-RxO) and should therefore be allowed to be adjusted separately for writers and readers, although most commonly its only exploited for the reading-side .. but that's another story...
For completeness, in cyclone, the DURABILITY_SERVICE history-QoS (kind and depth) is also used to 'dimension' the transient-local writer-side 'history' (so that its possible to have a different kind/depth for 'live-data' and 'historical-data', a usecase that you've encountered before I believe ;) .

Finally I haven't managed to select a >1 history-depth that was actually shown for a subscribed shape like a 'trail' (i.e. a reader with history-depth 10 shows the full history when periodically reading all arrived data i.e. the latest 10 samples, resulting in a 'trail' being shown. This is also the behavior of our ishape-demo apps. This comes in handy for non-volatile readers (transient-local/transient/persistent) that are late-joiners where it can be easily verified that all historical samples are delivered (assume they fit in the history). To show that for transient-local writers we also added the feature to 'suspend/resume' writing of shapes by clicking on the canvas. This wouldn't be needed for 'true' durable data i.e. transient/persistent as for testing that you could actually remove the writer before adding a late-joining reader that would depend on a 'durability-service' still running somewhere in your system.

Hope this makes sense, thanks for all the good work !!

[hansvanthag]

I think I also encountered a related issue when I tried to use the good-old 'ishapes' demo of OpenSplice with insight:
I created a single publisher of 'circle' shapes (default QoS) and then started insight, which immediately reported a QoS-conflict.
I think that the reader was created by insight using a QoS derived from the topic-QoS (where Cyclone maps 'persistent' on 'transient' as I seem to recall) whereas the OSPL-writer uses BestEffort 'as instructed'
Here's a screendump:

[hansvanthag]

Thanks for implementing the history and black/white center-dots for distinguishing between published and subscribed shapes!

Still, I'm having these more-or-less fundamental issues w.r.t. not being able to set the topic-level QoS when experimenting with non-volatile (i.e. transient-local or transient) data (basically the same issues as initially reported above)

• the topic's DURABILITY QoS-policy must be (able to be) defined as a non-volatile topic (TRANSIENT_LOCAL or TRANSIENT), noting that when trying-out our new durability-service, it reported that the shapes-type(s) where not defined as TRANSIENT so would ignore them
• the topic-level DurabilityService QoS-policy must be (able to be) defined w.r.t. history kind/depth, noting that these history-settings are both used by Cyclone for the dimensioning of the TRANSIENT_LOCAL store as well as the TRANSIENT store of our new durability-service when the topic is TRANSIENT

So as suggested above, I still think it would be great if the topic-level QoS's for each shape-type could be (pre-)defined by a dedicated menu and then re-used/inherited by the menu's to set the actual writer/reader QoS's for the publishers/subscribers.

And finally a few minor remarks:

• I'm typically using domain-33 and its a little annoying that I can't just type '33' when creating a iShapes publisher/writer but have to press the up/down button 33 times to get to domain 33
• Although there's now the (requested) 'pause' behavior when clicking on the canvas, I noticed that it only suspends the displaying but not the actual producing of shape-data which sort of nullifies its intended use to actually pauze the production of produced data so that when then starting a late-joining reader-with-history it could be verified that the history-trail is equal to that of a already-existing reader-with-history (similar to the existing cyclone/OSPL ishapes demo's)

Anyhow, thanks again for all the good work and effort going into this very useful extension of 'insight'

[trittsv]

Hi @hansvanthag, i am now back from vacation, thank you very much for the suggestions, i will implement them :)