Hi,
According the Spy's current configuration, I need to set up its QOS but I’m not able adjust its QOS to the QOS of the matched publication (excluding reliability and durability that are supported). Is there a roadmap for expanding this capability to be fully dynamic? Meaning Spy will create the most matching DR for the discovered DW (even if it mean I will have many DRs for a specific topic) according to the QOS discovered in the discovery phase (the same as it is already performed for Reliability QOS from my understanding).
Thank you,
GS
Hey Gal,
Unless you are using a qos property that requires an exact match between the reader and the writer (and have multiple writers setting different values for it), you can create a qos profile which will satisfy all writers.
Then you can use -qosFile and -qosProfile to use that profile.
You will lose the nifty durability / reliability / other capabilities this way but you'll be able to match all of the writers with one instance of dds spy.
Although I'm guessing you need something more complicated than that :)
Good luck,
Roy.
Hi GS,
As far as I know, Spy creates only a DataReader (DR) per topic with the most generic QoS settings that could satisfy all DataWriters (DWs). However, you may run in some combinations of QoS settings that are not supported by a generic DR (Ownership for redundancy, for instance). If you have two DWs with different strength level for the same instance, if the strongest one disappears, DDS Spy is not going to change to the less strong DW because the "generic" Deadline is inifinite (default value).
Take into accout that Spy will discover all the DWs and show their information, it is only Print Sample feature that is not going to be able to work unless you pass the correct deadline when launching DDS Spy (-deasline <seconds>).
DDS Spy was designed to do a first level of debugging, focusing on connectivity. Admin Console, on the other hand, creates a DR for each different DW QoS combination that is shared over Discovery. In general, those are the ones under PublicationBuiltin/SubscriptionBuiltin TopicData . So if you want to recover the print samples using all combinations of DRs, I would recommend to use Admin Console.
I hope this helps.
Thanks,
Sara
Hi,
First of all, thank you for your answers. I have few comments/questions:
1. I also assume that the SPY sets up a DR per topic so the same QOS rules apply to him. In that case, Deadline QOS is not the only QOS that determines the ownership change for a specific instance.The LivelinessQOS also takes part in that change. I managed to reproduce this behavior in SPY:
Turning on SPY with UDPv4_AND_SHARED_MEMORY QOS.
Turning on one publisher with OwnershipStrength of 1 ==> The Spy shows the samples from the publisher ==> OK.
Turning on one publisher with OwnershipStrength of 10 ==> The Spy doesn't show the samples from that publisher ==> OK.
Turning off gracefully (using delete_contained_entities() AND delete_participant()) the publisher with OwnershipStrength of 10 ==> The Spy shows the samples from the publisher with OwnershipStrength of 1 ==> Not according to your statement Sara.
Turning back on the publisher with OwnershipStrength of 10 ==> The Spy shows the samples from this publisher ==> OK.
2. As far as I understand, Spy's QOS inherits from the the Baseline.root that has OwnershipKind == SHARED. In that case, how the Spy manages to read the samples from writers with OwnershipKind == EXCLUSIVE? It supposed to be an IncompatiableQOS.
3. Back to my original question, first of all, I want to avoid using the Admin Console for now.I am specifically interested in the QOSs that have Request/Offered semantics: Deadline, DestinationOrder, Durability, LatencyBudget,Liveliness,Ownership,Presentation and Reliability. For now, according to the documentation Spy only supports RELIABILITY and DURABILITY on the first discovered publication of that topic.
Thank you,
GS
Hi GS,
Spy does indeed create a seperate data-reader for each topic it discovers and each having its own set of QoS. It is also true that each Spy datareader will inherit the offered OWNERSHIP QoS setting. This is the only QoS that is inherited by default because if they differ a mismatch will occur. It's also possible to request Spy inherit the offered QoS settings for Reliability and Durability using the "-useFirstPublicationQos" option.
Working through your example, assuming OWNERSHIP is EXCLUSIVE and both publishers are writing the same topic...
This is correct, Spy will start receiving DDS samples from this first writer.
Actually, since this second writer has a higher strength that the previous writer, Spy will stop receiving samples from the first writer and begin to receive them from this writer.
This is correct, because the second writer is gone, Spy will revert to receiving samples from the first writer. The LIVELINES and DEADLINE QoSes could also be used here to set the period before the Spy datareader determines the current datawriter is not available. These QoS settings address the case where the datawriter does not cleanly shutdown.
This is correct.
The Spy datareader always inherits the offered OWNERSHIP. There should never be the case where Spy's datareader OWNERSHIP is not equal to the datawriter's.
Examining the remaining RxO QoS settings...
I hope this information helps.
-John
Hi John,
Thank you for your comprehensive answer.
Best regards,
Gal