Tunable to prevent PINGs. This will let us test paths the client gets
disconnected from the OSD (at least from the client's perspective).
Signed-off-by: Sage Weil <sage@redhat.com>
For a new watcher, we set the timeout event on connect, and reset it when
we get a ping.
For an old watcher, we continue to set the timeout on disconnect() and
rely on the msgr Connection reset.
Signed-off-by: Sage Weil <sage@redhat.com>
Use a new watch op code that is different from the legacy one so we can
tell when the client is doing all the new stuff (like sending pings).
Signed-off-by: Sage Weil <sage@redhat.com>
If we are a watcher and we fail to notify in a timely manner, or
circumstances otherwise conspire to prevent out ack from arriving in time,
initiate a callback.
Signed-off-by: Sage Weil <sage@redhat.com>
This is essentially watchers.size() at all times and obfuscates the code.
In particular this makes the maybe_complete_notify() logic much clearer.
Signed-off-by: Sage Weil <sage@redhat.com>
Send a full PING op to the object to ensure we are still connected. For
now just use the existing ping interval; we may want to change this in
the future.
Signed-off-by: Sage Weil <sage@redhat.com>
Use WATCH op for the initial registration. This is idempotent in that
it will succeed whether the watch information has been persisted or not.
It is used by the client if it does not know that it is registered.
The RECONNECT op is used for any subsequent session reconnect. It will
fail if the watch state isn't already persisted on the OSD.
Signed-off-by: Sage Weil <sage@redhat.com>
Use a reusable context in the WatchNotifyInfo to trigger an error
event, delivered via the existing Finisher thread. Re-lookup the cookie
in the thread to cope with races with unregister (just as we do with
notify events).
Signed-off-by: Sage Weil <sage@redhat.com>
This is the async notification of a watch error (failure to reconnect to
the object's OSD after a peering event or network disconnect).
Signed-off-by: Sage Weil <sage@redhat.com>
The ping will essentially assert that a watch is still valid.
A reconnect will reestablish session state *only* if the watch is
still persistent. If not, it will fail (and the client will know it
may have missed something).
Note that the only difference here is that a PING is a bit lighter
weight; it will not reestablish the session state (which should already
be established). We could use a single op here but the unique op
code makes the messages easier to understand and simplifies the code
path a bit for PING.
Signed-off-by: Sage Weil <sage@redhat.com>
- drop the useless add_watch() helper; do it explicitly
- drop the unused var arg everywhere
- make a separate notify member of the union that excludes
the other unused fields
Signed-off-by: Sage Weil <sage@redhat.com>
It is perfectly valid to register multiple watchers via the same
librados client. Make the notify_replies a multimap to capture all
of the acks.
Signed-off-by: Sage Weil <sage@redhat.com>
The notify replies include the identify of everyone who acked the
notify. For symmetry, inform the notified client who sent the notify.
Fixes: #9198
Signed-off-by: Sage Weil <sage@redhat.com>
Allow the notify2 callers to provide bufferlists or char ** pointers
so that we can pass the reply buffer back to them.
Signed-off-by: Sage Weil <sage@redhat.com>
If the notified send back reply payloads, pass them back to the notifier.
Note that we have changed the on-wire behavior of the watch completion
message a bit: instead of sending the original notify payload back to the
notifier, we send the map of notified to replies. Note that only users of
the new API will know what to do with the notify acknowledgement
information. At the same time, we stop sending the original payload.
However, the old API users never saw that data; we were uselessly sending
it over the wire.
Signed-off-by: Sage Weil <sage@redhat.com>
- new notify callback with the correct values:
- notify_id
- watch handle
- payload
- new notify_ack call
- not implicit when the callback returns (for new api only)
- optional payload
- new watch2 call
- that provides the new callback
- new notify2 call
- with the right arguments, and optional timeout
A couple refactors in here:
- IoCtx notify_ack is now called unlocked (Note: this will soon change
with pending Objecter locking changes)
- Objecter notify_ack takes a buffer
TODO:
- no timeout on the individual watch, yet...
Signed-off-by: Sage Weil <sage@redhat.com>