Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

2022-12-11 Thread Jeff Jirsa
Concurrent shouldn’t matter (they’re non-overlapping in the repro). And I’d personally be a bit surprised if table count matters that much. It probably just requires high core count and enough data that the streams actually interact with the rate limiter On Dec 11, 2022, at 10:32 AM, Mick Semb Wever  wrote:On Sat, 10 Dec 2022 at 23:09, Abe Ratnofsky  wrote:Sorry - responded on the take1 thread:Could we defer the close of this vote til Monday, December 12th after 6pm Pacific Time?Jon Meredith and I have been working thru an issue blocking streaming on 4.1 for the last couple months, and are now testing a promising fix. We're currently working on a write-up, and we'd like to hold the release until the community is able to review our findings.Update on behalf of Jon and Abe.The issue raised is CASSANDRA-18110.Concurrent, or nodes with high cpu count and number of tables performing, host replacements can fail.It is still unclear if this is applicable to OSS C*, and if so to what extent users might ever be impacted.More importantly, there's a simple workaround for anyone that hits the problem.Without further information on the table, I'm inclined to continue with 4.1.0 GA (closing the vote in 32 hours), but add a clear message to the release announcement of the issue and workaround. Interested in hearing others' positions, don't be afraid to veto if that's where you're at.


Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

2022-12-11 Thread Mick Semb Wever
On Sat, 10 Dec 2022 at 23:09, Abe Ratnofsky  wrote:

> Sorry - responded on the take1 thread:
>
> Could we defer the close of this vote til Monday, December 12th after 6pm
> Pacific Time?
>
> Jon Meredith and I have been working thru an issue blocking streaming on
> 4.1 for the last couple months, and are now testing a promising fix. We're
> currently working on a write-up, and we'd like to hold the release until
> the community is able to review our findings.
>


Update on behalf of Jon and Abe.

The issue raised is CASSANDRA-18110.
Concurrent, or nodes with high cpu count and number of tables performing,
host replacements can fail.

It is still unclear if this is applicable to OSS C*, and if so to what
extent users might ever be impacted.
More importantly, there's a simple workaround for anyone that hits the
problem.

Without further information on the table, I'm inclined to continue with
4.1.0 GA (closing the vote in 32 hours), but add a clear message to the
release announcement of the issue and workaround. Interested in hearing
others' positions, don't be afraid to veto if that's where you're at.