Skip to content

Commit c46163c

Browse files
authored
Tweaks to automatic flush (#1613)
There was previously an edge case where we'd submit automatic flushes 500ms after the last Upstairs event, _even if_ we had IO pending. We normally don't see this in practice, because events are constantly happening (and therefore resetting the flush timer). However, @jmpesp saw it while testing in the Canada region; we're not yet sure why! This PR makes two changes: (1) do not send flushes if jobs are pending, even if the timeout has expired, and (2) log a specific warning message about this unusual situation.
1 parent f047a5a commit c46163c

File tree

1 file changed

+20
-7
lines changed

1 file changed

+20
-7
lines changed

upstairs/src/upstairs.rs

+20-7
Original file line numberDiff line numberDiff line change
@@ -567,13 +567,26 @@ impl Upstairs {
567567
self.on_client_message(m);
568568
}
569569
UpstairsAction::FlushCheck => {
570-
self.counters.action_flush_check += 1;
571-
cdt::up__action_flush_check!(|| (self
572-
.counters
573-
.action_flush_check));
574-
if self.need_flush {
575-
let io_guard = self.try_acquire_io(0);
576-
self.submit_flush(None, None, io_guard);
570+
if !has_jobs {
571+
self.counters.action_flush_check += 1;
572+
cdt::up__action_flush_check!(|| (self
573+
.counters
574+
.action_flush_check));
575+
if self.need_flush {
576+
let io_guard = self.try_acquire_io(0);
577+
self.submit_flush(None, None, io_guard);
578+
}
579+
} else {
580+
// The flush timer is reset after every event, so getting
581+
// here indicates that we didn't see _any_ events for 500 ms
582+
// despite jobs being pending.
583+
//
584+
// This is surprising, and may indicate network issues or
585+
// other problems.
586+
warn!(
587+
self.log,
588+
"flush check fired despite having jobs; resetting it"
589+
);
577590
}
578591
self.flush_deadline = Instant::now() + self.flush_interval;
579592
}

0 commit comments

Comments
 (0)