You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2017/11/16 21:28:00 UTC

[jira] [Commented] (KUDU-2217) Clarify on report about decreasing index of committed Raft config

    [ https://issues.apache.org/jira/browse/KUDU-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255995#comment-16255995 ] 

Todd Lipcon commented on KUDU-2217:
-----------------------------------

That's interesting. This implies that we have a config change op 1.3 which has its "new_config.index" set to 2 instead of 3. It seems, though, that whenever a pending op is added in AddPendingOperationUnlocked, we are forcing the new_config().index() to match the op index. Maybe we can add a DCHECK into the code that checks the above invariant when committing a change config and try looping this test?

> Clarify on report about decreasing index of committed Raft config
> -----------------------------------------------------------------
>
>                 Key: KUDU-2217
>                 URL: https://issues.apache.org/jira/browse/KUDU-2217
>             Project: Kudu
>          Issue Type: Task
>          Components: consensus, test
>            Reporter: Alexey Serbin
>            Assignee: Alexey Serbin
>
> Prior bf1fcb0df5f2fbb6d1557b6b932bc67045fff531 changelist, the RaftConsensusNonVoterITest.PromoteAndDemote scenario exhibited flakiness when running the binary built in DEBUG configuration.  In addition to being flaky, the test output some interesting error messages, e.g. it was something like
> {noformat}
> I1030 22:33:14.041613 12284 raft_consensus.cc:2456] T 2abeb033beb040499f686713f41ba96c P 9e14a0231da149b2926039f26070025d [term 1 FOLLOWER]: Committing config change with OpId 1.3: config changed from index 3 to 2, ...
> {noformat}
> Unfortunately, I could not find the log from that run, but I remember how [~mpercy] and I were looking at the message, wondering why committed index went down from 3 to 2.
> It would be nice to reproduce that and understand what is the reason behind.  It might be a regression. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)