[RESULT][VOTE] Release Apache Cassandra 4.1.0 (take2)

[Mick Semb Wever]

Proposing the (second) test build of Cassandra 4.1.0 for release.
>
> sha1: f9e033f519c14596da4dc954875756a69aea4e78
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1282/org/apache/cassandra/cassandra-all/4.1.0/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.0/
>
> The vote will be open for 96 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>


Vote passes with ten +1s (six binding).

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

[Abe Ratnofsky]

I agree Benedict - I don't think we can provide a clear advisory to our users, 
so I would approve of not sharing anything in the release notes. But if someone 
posts an issue (likely to the user ML) related to streaming / bootstrapping on 
4.1.0, then we should engage with the knowledge that it might be related to 
18110.

> On Dec 12, 2022, at 5:06 PM, Benedict  wrote:
> 
> I’m unsure that without more information it is very helpful to highlight in 
> the release notes. We don’t even have a strong hypothesis tying this issue to 
> 4.1.0 specifically, and don’t have a general policy of highlighting 
> undiagnosed issues in release notes?
> 
> 
>> On 13 Dec 2022, at 00:48, Jon Meredith  wrote:
>> 
>> 
>> 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 > > 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 >> > 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)

[Benedict]

I’m unsure that without more information it is very helpful to highlight in 
the release notes. We don’t even have a strong hypothesis tying this issue to 
4.1.0 specifically, and don’t have a general policy of highlighting undiagnosed 
issues in release notes?


> On 13 Dec 2022, at 00:48, Jon Meredith  wrote:
> 
> 
> 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  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  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)

[Jon Meredith]

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  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  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: [DISCUSSION] New dependencies for SAI CEP-7

[David Capwell]

> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test 
> dependency

Can you talk more about why?  There are several ways to do random testing 
in-tree ATM, so wondering why we need another one


> On Dec 8, 2022, at 6:51 AM, Mike Adamson  wrote:
> 
> Hi,
> 
> I wanted to discuss the addition of the following dependencies for CEP-7. The 
> dependencies are:
> 
> org.apache.lucene.lucene-core 7.5.0
> org.apache.lucene.lucene-analyzers-common 7.5.0
> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test 
> dependency
> 
> Lucene is an apache project so is licensed APL2. Carrotsearch is not an 
> apache project but is licensed APL2
> 
> We are also removing the dependency on com.github.rholder.snowball-stemmer. 
> This library is used by SASI stemming filters but a later version of the same 
> library is available in the lucene libraries.
> 
> Does anyone have any concerns about these changes?
> 
> Mike Adamson

Re: [DISCUSSION] Cassandra's code style and source code analysis

[Maxim Muzafarov]

> Technically it can be two commits which would be merged / pushed at once.

I'll prepare a new pull request containing both of the changes. My
previous experience says me that it's really hard to find a reviewer
who will be able to go through huge pull requests, that's why
initially I've split this into AvoidStarImport and CustomImportOrder
rules. So, if you'll help with the review I'm happy to proceed the way
you suggested :-)

> One thing which needs extra care for ordering imports is that if you order it 
> in IDEA by right-clicking on a package and choosing organising imports, it 
> will remove special comments

You're right, but this is quite unusual behaviour for me and this
seems to be a bug, that hasn't been fixed for a long time [1]. I've
tested the same thing for Eclipse and NetBeans and `optimize imports`
working there as we expect (no comments removes), so the issue exists
only for the IntelliJ IDEA [1].
Despite all of that, we are still on the safe side here - if these
comments will be removed by the `optimized import` procedure the build
with checkstyle will fail.

> I think this is a great time to revisit this ordering.

I would say that the imports order is pretty good (probably, except
for the blank lines) and the imports order is not as important as it
is important that it be the same in all files and automation `optimize
imports`.
I suggest going through a "minimum change" strategy here. The IntelliJ
IDEA has the following configuration with the imports order that most
of the classes already fit:

import java
import javax
[blank line]
import com.google.common
import org.apache.log4j
import org.apache.commons
import org.cliffc.high_scale_lib
import org.junit
import org.slf4j
[blank line]
import all other imports
[blank line]
import static all other imports

We can update the documentation page [2] with this order and implement
the same for NetBeans and Eclipse IDE configuration files as well as
for the checkstyle config.


If everyone is OK with the plan above I'll prepare everything for it.

Suggested summary:
- use current IntelliJ IDEA imports order as defaults for other IDEs;
- update the documentation page;
- prepare a single pull request with AvoidStarImport and CustomImportOrder;



[1] 
https://youtrack.jetbrains.com/issue/IDEA-128133/Optimize-Imports-disregards-line-comments
[2] https://cassandra.apache.org/_/development/code_style.html

On Sun, 11 Dec 2022 at 00:03, Miklosovic, Stefan
 wrote:
>
> Should the source code obey the AvoidStarImport rule?
>
> yes
>
>  Should we implement AvoidStarImport and CustomImportOrder in a
> single pull request or do it one by one?
>
> Technically it can be two commits which would be merged / pushed at once.
>
> One thing which needs extra care for ordering imports is that if you order it 
> in IDEA by right-clicking on a package and choosing organising imports, it 
> will remove special comments which are put at the end of the import 
> statement. We need to be sure you put them back.  Look at changes in 
> CASSANDRA-17055. We need to preserve this.
>
> Also, we need to be sure that the importing style can be (roughly) set in 
> each major IDE. (eclipse / netbeans / idea) so if we require some import 
> style it can be set in IDE like that. I do not know if we have any strong 
> preference when it comes to this but it definitely does not hurt.
>
> Also, I see that the current import style is
>
> java
> [blank line]
> com.google.common
> org.apache.commons
> org.junit
> org.slf4j
> [blank line]
> everything else alphabetically
>
> I think this is a great time to revisit this ordering. I am not particularly 
> persuaded on this order and why it was choosen. Where has that decision come 
> from?
>
> 
> From: Maxim Muzafarov 
> Sent: Wednesday, December 7, 2022 18:29
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
>
> NetApp Security WARNING: This is an external email. Do not click links or 
> open attachments unless you recognize the sender and know the content is safe.
>
>
>
>
> Dear community,
>
>
> I have created the epic with code-style activities to track the progress:
> https://issues.apache.org/jira/browse/CASSANDRA-18090
>
> In my understanding, there is no need to format whole the code base at
> once according to the code style described on the page [1], and the
> best strategy here is to go forward with small evolutionary changes.
> Thus eventually we will come up with a set of rules convenient for all
> members of the community. In my mind, having one commit per an added
> code style rule should be easy to look at for a reviewer, the git
> commits history as well as rebasing/merging other pull requests that
> may be affected by the new rules.
>
>
> I want to raise one more question related to class imports and the
> classses import order for a wider discussion. The import order is well
> described on the code style page [1], but using