When nodes get reconnected after being disconnected, a request for alignment data is sent. Possible alignment mismatch when an asymmetrical disconnect occurs during alignment Solution: Processing instances with invalid samples contained a bug in an return code causing the implementation to stop iterating instances and return 'no-data' result to applications prematurely.
Note this applies to operations such as take_w_condition but also to conditions in waitsets. view, sample or instance states, which an instance with invalid sample(s) doesn't meet, no other instances are considered and a 'no-data' result is returned to the application.
In specific cases when a reader has both instances with invalid samples and others with valid samples, if samples are read using a condition on eg. Issue with invalid samples when using read condition causes readers to get stuck unable to read samples. You can read/take status of an entity and set the partition of a subscriber by Qos, for example via the XML QosProvider. Solution: You can now change the Qos policies of entities (but only those allowed by DDS). Ensured that setting the partition on creation of a subscriber does function and included a test for this. Solution: Both mechanisms are now fully commutative, and the resulting instance lifecycle state is now eventually consistent with the rest of the system.Īdd missing python API methods and ensure the subscriber partition setting is functional.Īdded methods to set Qos, read_status and take_status. Both mechanisms should have been commutative, but in certain scenarios they were not, and this could cause the instance to end up in the wrong life cycle state. However, this caused a race condition between the spliced trying to revert the instance back to its state prior to the disconnect, and durability/dlite, which are trying to update the instance to its latest state.
In the 6.11.0, a new mechanism was introduced that allowed the spliced to revive instances that lost liveliness due to a disconnect when their writer was re-discovered. Race condition in management of instance lifecycle states Solution: The protocol logic is fixed by excluding publishers from differential alignment calculations until they have published data. This could prevent the wait_for_historical_data from unblocking which can cause numerous application issues. The differential alignment protocol concluded wrongly that not all data was received from writers that didn't published any data yet. Incorrect inconsistency detection in the DLite differential alignment protocol. In the OpenSplice Python API, when having an IDL which has a module B inside module A and using something from module B (e.g., an enum) inside module A, it results in a circular dependency during the import of module A. Idlpp for Python API creates circular dependency in the generated file.
0 kommentar(er)
