partition matching

[hansvanthag]

Hi,

This morning I understood from a colleague who tried out the latest insight version that when using the bundled roundtrip-example (that uses a ping and pong partition to separate the traffic from ping to pong and vice versa), the tool reports QoS mismatches due to that partition usage.

I would admit that its somewhat confusing that 'partitions' could (or even should) be treated as RxO QoS's (where a mismatch is likely by accident rather than on purpose) yet that's actually not how these are intended to be used (arguably those shouldn't even be QoS's in DDS but that's how it is unfortunately).

Partitions are meant to (as the name suggests) partition the global dataspace and with that impact the matching of writers and readers (that are either within the same partition or not). So observing that there's a partition-mismatch between endpoints is NOT an error-condition (i.e. worthy of reporting a QOS mismatch). When using wildcards in partitions that becomes even more obvious but let's not go into that detail here/now.

Have to admit, I didn't try it myself, but the info might be useful anyways.
Thanks for all the nice work that already went into 'insight' ;)

[trittsv]

@hansvanthag so you mean to not report a warning when there are different non-matching partitions on a topic?
(So the tool should not care about partitions at all?)

i tried to clone the qos mismatch logic from the C repo

cyclonedds-insight/src/dds_qos.py

Line 319 in 9fde641

def partitions_match_p(a, b):

.

[hansvanthag]

Indeed, I wouldn't expect warnings/reports on non-matching partitions. But of course having the tool to correctly handle/show partitions is very valuable (including the ability to observe or even inject data on specified partition(s) )

If you've ever seen the OpenSplice Tester-tool it would perhaps make more sense .. there 'partitions' are shown independent from QoS-policies (also as QoS-policies are typically meant to 'annotate' the data with how you'd like that data to be treated by the middleware, whereas 'partitions' are used to specify 'where data (of whatever QoS) lives' within the global-dataspace)

[trittsv]

@hansvanthag to observe specific partitions is already possible with the latest cyclone insight ;-)
To create writer to inject data is still in progress (only structs in arrays currently missing)

I never saw the OpenSplice tools, i just recently found out that there is also a "insight"-tool, its funny that i came up with the same name

So the qos matching for partitions can be removed from cyclone insight.

[hansvanthag]

I'd say yes! ..
Thanks a lot !

PS> yet if possible I'd very much would like to see the partition of a writer (and reader) to be shown independent from the QoS (as they serve such different purpose) .. so even if you're not interested in each-and-every-QoS of a writer/reader, showing the partition(s) that those writers/readers are 'connected too' (via their publishers/subscribers) is i.m.o. very useful

[hansvanthag]

just as an examle here's a screencopy of OpenSplice's tester-tool when running the pingpong example:

And only if you click on one of the endpoints it will show the matching of the partitions, here I clicked on the 'pong writer', which then shows that the ping-reader isn't matching (and when you hover over it it will highlight the incompatibility reason which in this case is a non-matching partition):

So I'm not asking to replicate this, just showing that showing partitions is useful (even if you're not interested that much in all the other QoS's) ..

[trittsv]

@hansvanthag thanks for the screenshots, currently i am implementing something like this:

So that partitions are shown directly in the endpoint and when clicking on it there is highlighting with all matching endpoints.