mirror of https://github.com/sipwise/rtpengine.git
Ref #2211 When json_restore_call() fails, it sends "DEL <call-id>" twice: on the write connection, in its own DB, and on the notification connection, in whatever DB the last keyspace notification selected. For a foreign call (a keyspace notification, or the restore of a subscribed keyspace at startup) that key belongs to the instance that owns the call, which keeps writing it: a standby that fails to restore one record deletes the owner's copy, and the call cannot be taken over any more. For an own call, the DEL on the notification connection can hit a peer's DB. Only delete an unrestorable record when the call is our own, and only on the write connection, in our own DB. A foreign record that can never be restored now stays until its owner rewrites or deletes it, or until it expires (--redis-expires). Seen in a lab with Redis Sentinel, where a subscriber's DEL was refused only because its node had just become a replica. Tests, in auto-daemon-tests-redis-subscribe.pl: a keyspace notification for a foreign call whose record cannot be parsed is followed by no command on either connection, and an own record that cannot be parsed at startup is deleted once, on the write connection only. Without this change both get a DEL on both connections. Change-Id: I5d8a53f3515596cf3fc2c58ea97847476385b876 (cherry picked from commitmr26.0.16b3bf8299b) (cherry picked from commitfef185612e)
parent
177a8c02f5
commit
7a103c13fd
Loading…
Reference in new issue