[
https://issues.apache.org/jira/browse/KUDU-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372449#comment-16372449
]
Todd Lipcon commented on KUDU-2322:
-----------------------------------
The specific log message is:
{code}
I0221 21:43:07.479466 21218 consensus_peers.cc:230] T
4ffc930e9f2148c38e441f19aa230872 P 335d132897de4bdb9b87443f2c487a42 -> Peer
d8009e07d82b4e66a7ab50f85e60bc30 (ve0136.halxg.cloudera.com:7050): Could not
obtain request from queue for peer: d8009e07d82b4e66a7ab50f85e60bc30. Status:
Not found: Failed to read ops 121718..137279: Segment 521 which contained index
121718 has been GCed
{code}
> Leader spews logs when follower falls behind log GC
> ---------------------------------------------------
>
> Key: KUDU-2322
> URL: https://issues.apache.org/jira/browse/KUDU-2322
> Project: Kudu
> Issue Type: Bug
> Components: consensus
> Affects Versions: 1.7.0
> Reporter: Todd Lipcon
> Priority: Critical
>
> I'm running a YCSB-based write stress test and found that one of the
> followers fell behind enough that its logs got GCed by the leader. At this
> point, the leader started logging about 100 messages per second indicating
> that it could not obtain a request for this peer.
> I believe this is a regression since 1.6, since before 3-4-3 replication we
> would have evicted the replica as soon as it fell behind GC.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
