[
https://issues.apache.org/jira/browse/KUDU-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15352275#comment-15352275
]
Todd Lipcon commented on KUDU-1078:
-----------------------------------
I continue to think it's harmless, though the log spew doesn't look good. Maybe
we could improve this by changing the order so that we don't append to the
consensus queue until after we've appended to the log? might be non-trivial to
do that change, though.
> Under heavy load, log cache reads return "Op in future"
> -------------------------------------------------------
>
> Key: KUDU-1078
> URL: https://issues.apache.org/jira/browse/KUDU-1078
> Project: Kudu
> Issue Type: Improvement
> Components: consensus
> Affects Versions: Private Beta
> Reporter: Todd Lipcon
> Assignee: Mike Percy
>
> JD accidentally configured botl80 so that all nodes were writing to a single
> tablet (talk about a stress test!) I see the following warning occasionally
> in the leader logs:
> W0827 11:34:04.051275 55950 consensus_queue.cc:272] T
> d6ff74fb04454712873abd0d2328e59b P 668314723deb4a818cc9a43eba51073c [LEADER]:
> The logs necessary to catch up peer 600e62435ca24425b29c00d9726b78be have
> been garbage collected. The follower will never be able to catch up (Not
> found: op in future). Instructing remote peer to remotely bootstrap.
> Calling this a blocker because, if we couple this with the "automatically
> re-bootstrap nodes if they fall behind", we'll be accidentally deleting
> tablets when this happens (no good!)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
