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>
Currently contexts C_Probe/C_PurgeRange are executed while holding
OSDSession::completion_lock. C_Probe and C_PurgeRange may call
Objecter::stat() and Objecter::remove() respectively, which acquire
Objecter::rwlock. This can cause deadlock because there is intermediate
dependency between Objecter::rwlock and OSDSession::completion_lock:
Objecter::rwlock -> OSDSession::lock -> OSDSession::completion_lock
The fix is exexcute C_Probe/C_PurgeRange in finisher thread.
Fixes: #10229
Signed-off-by: Yan, Zheng <zyan@redhat.com>
The google/ headers location has been deprecated as of gperftools 2.0.
As of gperftools 2.2rc, the google/ headers will now give deprecation
warnings, and they will probably disappear in a future gperftools
update.
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
This was missing from 17b5fc9a but we didn't notice
because the test wasn't being run by the gitbuilders.
Signed-off-by: John Spray <john.spray@redhat.com>
The func of command perfcounters_dump and 'perf dump' are the same .
But from the print 'ceph --admin-daemon help', it only print 'perf
dump'. So replace.
In order to keep consistent, still keep perfcounters_dump in code for
old user.
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
