Fix #4205
closedlibrados: Improve Watch-notify semantics
0%
Description
In the new implementation Sam set up, and apparently in the old code as well, a notify can succeed without getting a response from one of the watchers — and the watcher doesn't get told that it failed to respond in time, and it doesn't get disconnected, and the notifier doesn't get told that somebody timed out.
This means that watch-notify actually provides guarantees consisting of...pretty much nothing.
I suspect that notify needs to lose the ability to provide timeouts shorter than the watch timeout, and when a watch fails the client needs to get a disconnect or something. Or else allow notifies to provide an attack space, and to force-disconnect (or force-fail the Watch) on a client which doesn't ack a Notify as quickly as requested.
Updated by Sage Weil about 11 years ago
I think this is simply a matter of making the notify fail (return an error to teh notifier) if any of the watches failed to respond within their timeout. I thought it already did that.
Making a watch session get disconnected if the notify isn't acked within the watch timeout makes sense to me. I'm not sure if it makes sense to enforce that the watch and notify timeouts align, though. It might be perfectly reasonable for a notifier to say the are only willing to wait so long.
I don't know if it is practical (or necessarily worthwhile) to make the watcher aware that the notify it acked didn't result in a successful notify reply to the notifier..
Updated by Ian Colle about 11 years ago
- Subject changed from Watch-notify doesn't provide the semantics anybody expects to Improve Watch-notify semantics
Updated by Sage Weil over 10 years ago
- Tracker changed from Bug to Fix
- Subject changed from Improve Watch-notify semantics to librados: Improve Watch-notify semantics
- Assignee set to Sage Weil
- Target version set to v0.71
sam, figure out what this means.