[
https://issues.apache.org/jira/browse/KUDU-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15724212#comment-15724212
]
Todd Lipcon commented on KUDU-1346:
-----------------------------------
FWIW I've realized there's an issue with the prescribed workaround. The 'max
batch size' gflag is also the 'target' batch size. So, if you set it high (eg
50MB), and a server is lagging, then all requests are going to start being 50MB
requests. With the default 1-second consensus RPC timeout, it's often not
enough time to _transmit_ 50MB much less process the request, and thus every
request will just time out.
> Consensus queue crashes creating message for peer due to batch size
> -------------------------------------------------------------------
>
> Key: KUDU-1346
> URL: https://issues.apache.org/jira/browse/KUDU-1346
> Project: Kudu
> Issue Type: Bug
> Components: consensus
> Affects Versions: 0.7.0
> Reporter: David Alves
>
> bruce_song zhang hit the following error:
> {code}
> F0222 11:30:16.552686 23428 consensus_queue.cc:370] Check failed:
> request->ByteSize() <= FLAGS_consensus_max_batch_size_bytes (3042252 vs.
> 1048576)
> F0222 11:30:16.552693 23416 consensus_queue.cc:370] Check failed:
> request->ByteSize() <= FLAGS_consensus_max_batch_size_bytes (3042252 vs.
> 1048576)
> {code}
> It seems plausible that we might allow a write that is bigger than the max
> consensus batch size, and since there is a path in log cache that always
> sends at least one message, we might fail this check and crash.
> The workaround is to set a bigger value than the default for
> --consensus_max_batch_size_bytes
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
