journal: suppress notifications if client still in try_pop_front loop

One such example is popping the last entry from an object.  The next
object will be automatically prefetched.  When that object is received,
we do not want to alert the user that entries are available since
try_pop_front already indicated more records were available.

Fixes: http://tracker.ceph.com/issues/15755
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
(cherry picked from commit 3b8d21ac13865791d8fc4c519f47c1f7d6096e76)

diff --git a/src/journal/JournalPlayer.cc b/src/journal/JournalPlayer.cc
index aee87165d86abed70ad4866ff132cf513a5f7a9c..c9dc66b4959a3453e153a49d091c199036d179fc 100644 (file)
--- a/src/journal/JournalPlayer.cc
+++ b/src/journal/JournalPlayer.cc
@@ -154,12 +154,13 @@ bool JournalPlayer::try_pop_front(Entry *entry, uint64_t *commit_tid) {
   ldout(m_cct, 20) << __func__ << dendl;
   Mutex::Locker locker(m_lock);
 
-  m_handler_notified = false;
   if (m_state != STATE_PLAYBACK) {
+    m_handler_notified = false;
     return false;
   }
 
   if (!is_object_set_ready()) {
+    m_handler_notified = false;
     return false;
   }
 
@@ -167,6 +168,7 @@ bool JournalPlayer::try_pop_front(Entry *entry, uint64_t *commit_tid) {
     if (!m_watch_enabled) {
       notify_complete(0);
     } else if (!m_watch_scheduled) {
+      m_handler_notified = false;
       schedule_watch();
     }
     return false;
@@ -396,7 +398,6 @@ bool JournalPlayer::verify_playback_ready() {
   // set of data before advancing to a new tag
   if (m_watch_enabled && m_watch_required) {
     m_watch_required = false;
-    schedule_watch();
     return false;
   }