We have been testing the release at various scales and workloads and for the most part everything has been working really well (great performance, zero copy streaming is amazing, compaction is fast, etc ...). However, upon testing incremental repair (currently the default in 4.0) we hit a potential issue [1]. If confirmed, the bug would indicate that after an incremental repair run via "nodetool repair" that performed anticompaction, nodes may be unable to make any forward progress on compaction.
Is it possible to extend the vote by 24 hours for us to triage the issue and confirm if it is user error or a legitimate bug? My concern is that a release candidate may plausibly be put in production and if nodes might stop compacting that seems to be a potentially serious stability issue. [1] https://issues.apache.org/jira/browse/CASSANDRA-16552 -Joey On Tue, Mar 30, 2021 at 8:54 PM Ben Bromhead <b...@instaclustr.com> wrote: > > https://issues.apache.org/jira/browse/CASSANDRA-16550 :) > > On Wed, Mar 31, 2021 at 10:08 AM Mick Semb Wever <m...@apache.org> wrote: > > > > > > > If we could tidy up the others quickly (I'm happy to submit a PR for > > > anything that is outstanding) I'm ready to jump on board the train! > > > > > > > > > The LICENSE and NOTICE issues remain unassigned, if you are keen! > > > > > -- > > Ben Bromhead > > Instaclustr | www.instaclustr.com | @instaclustr > <http://twitter.com/instaclustr> | +64 27 383 8975 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
