[
https://issues.apache.org/jira/browse/CASSANDRA-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970673#comment-13970673
]
Benedict commented on CASSANDRA-6487:
-------------------------------------
Basic approach looks good. I would:
# use Iterables.concat(Iterables.transform()) to create set of items to process
(this requires changing signature to accept an Iterable instead of Collection)
# Only construct the set of affected KS/CFs in the case that the size warn
limit is breached. You can just use an ArrayList as well, as uniqueness is
guaranteed (see getMutations(), which merges mutations for the same CF into one
IMutation. Feel free to add a comment to this method explaining this so the
next person to read this doesn't have to figure it out)
> Log WARN on large batch sizes
> -----------------------------
>
> Key: CASSANDRA-6487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6487
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Patrick McFadin
> Assignee: Lyuben Todorov
> Priority: Minor
> Fix For: 2.0.8
>
> Attachments: 6487-cassandra-2.0.patch
>
>
> Large batches on a coordinator can cause a lot of node stress. I propose
> adding a WARN log entry if batch sizes go beyond a configurable size. This
> will give more visibility to operators on something that can happen on the
> developer side.
> New yaml setting with 5k default.
> {{# Log WARN on any batch size exceeding this value. 5k by default.}}
> {{# Caution should be taken on increasing the size of this threshold as it
> can lead to node instability.}}
> {{batch_size_warn_threshold: 5k}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
