New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mon/OSDMonitor: no_reply on MOSDFailure messages #22259
Conversation
If we are ignoring the message, tell the forwarding mon to discard it's state. Fixes: http://tracker.ceph.com/issues/24322 Signed-off-by: Sage Weil <sage@redhat.com>
src/mon/OSDMonitor.cc
Outdated
@@ -559,6 +559,7 @@ void OSDMonitor::on_active() | |||
op->mark_osdmon_event(__func__); | |||
dispatch(op); | |||
ls.pop_front(); | |||
// no need to mon->no_reply since this is a new quorum |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think the reason we don't need to mon->no_reply()
here is that the op
is not handled yet. they will be taken care of by PaxosService::dispatch()
. we will send no_reply()
when actually processing them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh right, i didn't see the dispatch() call there. removing this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aside from the nit on comment, lgtm.
Failure ops get attached to the failure report. Once we finally process them, mark them no_reply so that the forwarding mon will know about it. The other paths through prepare_failure() do no_reply on the messages that don't get logged in the failure_info_t::reporters. Fixes: http://tracker.ceph.com/issues/24322 Signed-off-by: Sage Weil <sage@redhat.com>
http://tracker.ceph.com/issues/24322