[jira] [Commented] (CASSANDRA-13975) Add a workaround for overly large read repair mutations
[ https://issues.apache.org/jira/browse/CASSANDRA-13975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348795#comment-17348795 ] Paulo Motta commented on CASSANDRA-13975: - Is there a plan for making this the default behavior? I don't see why it shouldn't in a major version. > Add a workaround for overly large read repair mutations > --- > > Key: CASSANDRA-13975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13975 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 3.0.16, 3.11.2 > > > It's currently possible for {{DataResolver}} to accumulate more changes to > read repair that would fit in a single serialized mutation. If that happens, > the node receiving the mutation would fail, and the read would time out, and > won't be able to proceed until the operator runs repair or manually drops the > affected partitions. > Ideally we should either read repair iteratively, or at least split the > resulting mutation into smaller chunks in the end. In the meantime, for > 3.0.x, I suggest we add logging to catch this, and a -D flag to allow > proceeding with the requests as is when the mutation is too large, without > read repair. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13975) Add a workaround for overly large read repair mutations
[ https://issues.apache.org/jira/browse/CASSANDRA-13975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249540#comment-16249540 ] Aleksey Yeschenko commented on CASSANDRA-13975: --- Thanks, committed as [f1e850a492126572efc636a6838cff90333806b9|https://github.com/apache/cassandra/commit/f1e850a492126572efc636a6838cff90333806b9] to 3.0 and merged up with 3.11 and trunk. > Add a workaround for overly large read repair mutations > --- > > Key: CASSANDRA-13975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13975 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Fix For: 3.0.16, 3.11.2 > > > It's currently possible for {{DataResolver}} to accumulate more changes to > read repair that would fit in a single serialized mutation. If that happens, > the node receiving the mutation would fail, and the read would time out, and > won't be able to proceed until the operator runs repair or manually drops the > affected partitions. > Ideally we should either read repair iteratively, or at least split the > resulting mutation into smaller chunks in the end. In the meantime, for > 3.0.x, I suggest we add logging to catch this, and a -D flag to allow > proceeding with the requests as is when the mutation is too large, without > read repair. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13975) Add a workaround for overly large read repair mutations
[ https://issues.apache.org/jira/browse/CASSANDRA-13975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245526#comment-16245526 ] Sam Tunnicliffe commented on CASSANDRA-13975: - LGTM, modulo an exceeding minor nit about inconsistent whitespace at the top of {{sendRepairMutation}}, feel free to fix on commit. > Add a workaround for overly large read repair mutations > --- > > Key: CASSANDRA-13975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13975 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > It's currently possible for {{DataResolver}} to accumulate more changes to > read repair that would fit in a single serialized mutation. If that happens, > the node receiving the mutation would fail, and the read would time out, and > won't be able to proceed until the operator runs repair or manually drops the > affected partitions. > Ideally we should either read repair iteratively, or at least split the > resulting mutation into smaller chunks in the end. In the meantime, for > 3.0.x, I suggest we add logging to catch this, and a -D flag to allow > proceeding with the requests as is when the mutation is too large, without > read repair. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13975) Add a workaround for overly large read repair mutations
[ https://issues.apache.org/jira/browse/CASSANDRA-13975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16235982#comment-16235982 ] Aleksey Yeschenko commented on CASSANDRA-13975: --- A straight-forward change pushed [here|https://github.com/iamaleksey/cassandra/commits/13975-3.0]. Unit test run [here|https://circleci.com/gh/iamaleksey/cassandra/63], dtest run [here|https://builds.apache.org/job/Cassandra-devbranch-dtest/407/]. > Add a workaround for overly large read repair mutations > --- > > Key: CASSANDRA-13975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13975 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Major > Fix For: 3.0.x, 3.11.x > > > It's currently possible for {{DataResolver}} to accumulate more changes to > read repair that would fit in a single serialized mutation. If that happens, > the node receiving the mutation would fail, and the read would time out, and > won't be able to proceed until the operator runs repair or manually drops the > affected partitions. > Ideally we should either read repair iteratively, or at least split the > resulting mutation into smaller chunks in the end. In the meantime, for > 3.0.x, I suggest we add logging to catch this, and a -D flag to allow > proceeding with the requests as is when the mutation is too large, without > read repair. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org