Thanks for the extra time to investigate. Unfortunately no progress on finding the root cause for this issue, just successful bootstraps in our attempts to reproduce. I think highlighting the ticket in the release notes is sufficient and resolving this issue should not hold up the release.
I agree with Jeff that the multiple concurrent bootstraps are unlikely to be the issue - I only mentioned in the ticket in case I am wrong. Abe or I will update the ticket if we find anything new. On Sun, Dec 11, 2022 at 12:33 PM Jeff Jirsa <jji...@gmail.com> wrote: > 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 <m...@apache.org> wrote: > > > > > On Sat, 10 Dec 2022 at 23:09, Abe Ratnofsky <a...@aber.io> 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. > > >
