Issue 6737: Detection_of_dynamic_qos_failure Issue (data-distribution-ftf) Source: (, ) Nature: Enhancement Severity: Significant Summary: Issue# 2080 Detection_of_dynamic_qos_failure Issue [Boeing SOSCOE] ? DDS does not provide the complete means for a user of the DDS API to detect “dynamic” failure of QoS and other “configuration” changes that may be important. For example: • LATENCY_BUDGET (on the receiver side). • Messages dropped due to lack of resources (on the receiver side) • Messages lost when QoS is RELIABLE KEEP_ALL (related to Issue# 2070) • Changes on the ownership of data-instances. • Addition of a remote DataReader that matches a local DataWriter. Removal of a remote DataReader that matches a local DataWriter. • Addition of a remote DataWriter to a local DataReader; removal of a remote DataWriter to a local DataReader. • Changes in “liveliness” of a remote DataReader of a local DataWriter. The symmetric situation, that is changes in liveliness of a remote DataWriter to a local DataReader does have a listener in the DataReader. Proposal [Boeing SOSCOE] ? Add the missing operations to the proper listeners Resolution: Revised Text: Actions taken: December 18, 2003: received issue Discussion: Some of the above requirements were addressed on the resolution of 6730. In particular the changes in the associations ("match") of local DataWriters with remote DataReaders and similarly the associations of local DataReaders with remote DataWriters. In addtion a change introduced as part of the resolution of 6736 (move the on_sample_lost operation from SubscriberListener to DataReaderListener) partially addresses the need to provide more detailed information when samples are lost. The FTF recognizes that it would be useful to provide more information to the application regarding changes stated in this issue. However, the FTF did not have enough time to assess how offering these additional facilities would impact the implementation and therefore resolved to defer the issue for a future F/RTF or revision. End of Annotations:===== m: webmaster@omg.org Date: 18 Dec 2003 20:37:02 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Matt Liu Company: Boeing mailFrom: matthew.k.liu@boeing.com Notification: Yes Specification: Data Distribution Service for Real-Time Systems Section: 4.1 FormalNumber: Unknown Version: 1.0 RevisionDate: 3/23/03 Page: 8 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description Issue# 2080 Detection_of_dynamic_qos_failure Issue [Boeing SOSCOE] ? DDS does not provide the complete means for a user of the DDS API to detect “dynamic” failure of QoS and other “configuration” changes that may be important. For example: • LATENCY_BUDGET (on the receiver side). • Messages dropped due to lack of resources (on the receiver side) • Messages lost when QoS is RELIABLE KEEP_ALL (related to Issue# 2070) • Changes on the ownership of data-instances. • Addition of a remote DataReader that matches a local DataWriter. Removal of a remote DataReader that matches a local DataWriter. • Addition of a remote DataWriter to a local DataReader; removal of a remote DataWriter to a local DataReader. • Changes in “liveliness” of a remote DataReader of a local DataWriter. The symmetric situation, that is changes in liveliness of a remote DataWriter to a local DataReader does have a listener in the DataReader. Proposal [Boeing SOSCOE] ? Add the missing operations to the proper listeners [OMG ISSUE# 6737, DDS# 67] Detection_of_dynamic_qos_failure Issue [Boeing SOSCOE] Ref# 2080 Detection_of_dynamic_qos_failure DDS does not provide the complete means for a user of the DDS API to detect .dynamic. failure of QoS and other .configuration. changes that may be important. For example: LATENCY_BUDGET (on the receiver side). Messages dropped due to lack of resources (on the receiver side) Messages lost when QoS is RELIABLE KEEP_ALL (related to Issue# 2070) Changes on the ownership of data-instances. Addition of a remote DataReader that matches a local DataWriter. Removal of a remote DataReader that matches a local DataWriter. Addition of a remote DataWriter to a local DataReader; Removal of a remote DataWriter to a local DataReader. Changes in .liveliness. of a remote DataReader of a local DataWriter. The symmetric situation, that is changes in liveliness of a remote DataWriter to a local DataReader does have a listener in the DataReader. Proposal [Boeing SOSCOE] Add the missing operations to the proper listeners 3-march teleconference Minimum profile! Latency-budget on receiver side OK; do not inform writer. Message dropped because of lack of RESOURCE_LIMIT OK on the receiver side. Only reader is notified OK Messages lost with reliable keep-all (also keep last?) but say that depending on implementation some cases may not be detected. So if detected this is the notification mechanisms but no guarantees. Ownership change. Reader OK; writer NO. Matching local/remote: Yes on the reader side. Not on the writer side. OK on the writer side but it is not mandatory. Will require adding statuses. Liveliness of remote readers. No this would require more traffic. FTF comments: Some of this information may not be available to the implementation. It could constrain the implementation to propagate more than it needs. We recommend deferring the addition of these listeners to the RTF or a later revision so that the impact of these additions is better understood.