[jira] [Assigned] (CASSANDRA-18465) Add support for multiple condition branches and results in Accord transaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski reassigned CASSANDRA-18465:
-
Assignee: Jacek Lewandowski
> Add support for multiple condition branches and results in Accord transaction
> -
>
> Key: CASSANDRA-18465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18465
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> I'd like to propose adding support for multiple branches and result sets for
> Accord transactions. It could look like this:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> The existing syntax would remain valid, when a single SELECT is defined in
> which case the conditional SELECTs would not be valid.
> SELECTs would be validated to return columns of the same type. They would be
> able to return literals as well.
> This would be make the result of the transaction more intuitive as the client
> would know explicitly if the updates where applied or not.
> The following syntax would be considered as invalid:
> 1. select defined both on the top level and in branches
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> SELECT ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> 2. select defined after update - select must be before the update to make it
> clear we select data before modification
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> UPDATE ...
> SELECT 'one', a.value
> ELSE IF condition2 THEN
> UPDATE ...
> SELECT 'two', b.value
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> 3. missing select - if select is defined in a single branch, it has to be
> defined in all branches:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> UPDATE ...
> END IF
> COMMIT TRANSACTION
> {code}
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> END IF
> COMMIT TRANSACTION
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18190) ECJ upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-18190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720414#comment-17720414 ] Jacek Lewandowski commented on CASSANDRA-18190: --- Thanks [~e.dimitrova], that was a lot of work! Regarding Error-Prone licensing, I'm not sure if is a problem. Those libraries would be used only during the build and would not be part of the distribution. [~mck] ? > ECJ upgrade > --- > > Key: CASSANDRA-18190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18190 > Project: Cassandra > Issue Type: Task > Components: Feature/UDF >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > During testing it was identified that we will need to update ECJ for the Java > UDF functions in order to bring Java 17 in. > It seems the compiler artifacts are moved from > [here|https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj ] > to [here|https://mvnrepository.com/artifact/org.eclipse.jdt/ecj] and there is > change of license from EPL1.0 to EPL2.0 too. But if I read correctly > [here|https://www.apache.org/legal/resolved.html#weak-copyleft-licenses] that > should not affect us > Further testing and review of all changes between artifacts to be done. > ECJ is used for the eclipse-warnings and Java UDFs -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720407#comment-17720407 ] Jacek Lewandowski commented on CASSANDRA-17797: --- I've already approved on PR, +1, You want me to commit or you can do it on your own? > All system properties and environment variables should be accessed via the > new CassandraRelevantProperties and CassandraRelevantEnv classes > --- > > Key: CASSANDRA-17797 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17797 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Low > Fix For: 5.x > > Time Spent: 33h 10m > Remaining Estimate: 0h > > Follow up ticket for CASSANDRA-15876 - > "Always access system properties and environment variables via the new > CassandraRelevantProperties and CassandraRelevantEnv classes" > As part of that ticket we moved to the two new classes only > properties/variables that were currently listed in System Properties Virtual > Table. > We have to move to those classes the rest of the properties around the code > and start using those classes to access all of them. > +Additional information for newcomers:+ > You might want to start by getting acquainted with > CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might > want to check what changes were done and how the first batch was transferred > to this new framework as part of > [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > We are interested into the properties accessed currently through > getProperties around the code. > As part of CASSANDRA-15876 relevant unit tests were added > (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure > that all tests Cassandra pass and also to think about potential update of the > mentioned test class. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18441: -- Status: Ready to Commit (was: Changes Suggested) > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16555) Add out-of-the-box snitch for Ec2 IMDSv2
[ https://issues.apache.org/jira/browse/CASSANDRA-16555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720403#comment-17720403 ] Jacek Lewandowski commented on CASSANDRA-16555: --- [~brandon.williams] if you agree with my feedback on the PR, I can take over it, you can review, then we can merge - wdyt? > Add out-of-the-box snitch for Ec2 IMDSv2 > > > Key: CASSANDRA-16555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16555 > Project: Cassandra > Issue Type: New Feature > Components: Consistency/Coordination >Reporter: Paul Rütter (BlueConic) >Assignee: fulco taen >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > In order to patch a vulnerability, Amazon came up with a new version of their > metadata service. > It's no longer unrestricted but now requires a token (in a header), in order > to access the metadata service. > See > [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html] > for more information. > Cassandra currently doesn't offer an out-of-the-box snitch class to support > this. > See > [https://cassandra.apache.org/doc/latest/operating/snitch.html#snitch-classes] > This issue asks to add support for this as a separate snitch class. > We'll probably do a PR for this, as we are in the process of developing one. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720161#comment-17720161 ] Jacek Lewandowski commented on CASSANDRA-18441: --- I'd leave the decision to [~blambov] https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/690/workflows/e72b8202-55f8-4602-9734-c69462fbeedc > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719726#comment-17719726
]
Jacek Lewandowski commented on CASSANDRA-18399:
---
Ok, so since it does not change anything and does not force anyone to use it,
can we merge it into cassandra-builds [~mck]?
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit cassandra-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a --amend --no-edit # Remove all changes in .circleci
> directory if you need to
> git diff --name-only origin/cassandra-3.11..HEAD # print a list of all
> changes files
> # jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
> #
>
> git switch cassandra-4.0
> git reset --hard origin/cassandra-4.0
> git merge -s ours --log --no-edit cassandra-3.11
> git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n a71d4e3408 && git commit -a --amend --no-edit # a71d4e3408
> DO NOT MERGE - CircleCI config
> git cherry-pick -n 6dc53f4e97 && git commit -a --amend --no-edit # 6dc53f4e97
> fixes
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-4.1 -> cassandra-4.1
> #
>
> git switch cassandra-4.1
> git reset --hard origin/cassandra-4.1
> git merge -s ours --log --no-edit
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719410#comment-17719410 ] Jacek Lewandowski commented on CASSANDRA-18441: --- I've applied the remaining changes > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717012#comment-17717012
]
Jacek Lewandowski edited comment on CASSANDRA-18441 at 4/27/23 7:32 AM:
I'm sorry for going through it again, but I'd put the selected write format on
a parent level, that is, if translated into properties, it could look like this:
{noformat}
sstable.selected_format=big
sstable.format.big.max_version=nc
sstable.format.big.opt1=value1
{noformat}
The reason I don't want to do this:
{noformat}
sstable.format.default=big
sstable.format.big.max_version=nc
sstable.format.big.opt1=value1
{noformat}
is that, I'd have to actually use {{Map}} on the
{{sstable.format}} level (at least I don't know how to do that differently)
And, since we want to have some consistency around properties, this
{{sstable.format..=}} speaks to me more than
{{sstable.format.options..=}}
In summary, selected format is not a property of any format, IMO it better fits
to sstable level.
Regarding target version and format - I agree it will be probably modified with
the downgradability ticket, thus those fields will be completely optional. I
like the idea of having Cassandra version --> format/version mapping. I've
changed the name of the write version to "max_version" so that it expresses
more adequately what that parameter means.
was (Author: jlewandowski):
I'm sorry for going through it again, but I'd put the selected write format on
a parent level, that is, if translated into properties, it could look like this:
{noformat}
sstable.selected_format=big
sstable.format.big.max_version=nc
sstable.format.big.opt1=value1
{noformat}
The reason I don't want to do this:
{noformat}
sstable.format.default=big
sstable.format.big.write_version_limit=nc
sstable.format.big.opt1=value1
{noformat}
is that, I'd have to actually use {{Map}} on the
{{sstable.format}} level (at least I don't know how to do that differently)
And, since we want to have some consistency around properties, this
{{sstable.format..=}} speaks to me more than
{{sstable.format.options..=}}
In summary, selected format is not a property of any format, IMO it better fits
to sstable level.
Regarding target version and format - I agree it will be probably modified with
the downgradability ticket, thus those fields will be completely optional. I
like the idea of having Cassandra version --> format/version mapping. I've
changed the name of the write version to "max_version" so that it expresses
more adequately what that parameter means.
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717012#comment-17717012
]
Jacek Lewandowski edited comment on CASSANDRA-18441 at 4/27/23 7:31 AM:
I'm sorry for going through it again, but I'd put the selected write format on
a parent level, that is, if translated into properties, it could look like this:
{noformat}
sstable.selected_format=big
sstable.format.big.max_version=nc
sstable.format.big.opt1=value1
{noformat}
The reason I don't want to do this:
{noformat}
sstable.format.default=big
sstable.format.big.write_version_limit=nc
sstable.format.big.opt1=value1
{noformat}
is that, I'd have to actually use {{Map}} on the
{{sstable.format}} level (at least I don't know how to do that differently)
And, since we want to have some consistency around properties, this
{{sstable.format..=}} speaks to me more than
{{sstable.format.options..=}}
In summary, selected format is not a property of any format, IMO it better fits
to sstable level.
Regarding target version and format - I agree it will be probably modified with
the downgradability ticket, thus those fields will be completely optional. I
like the idea of having Cassandra version --> format/version mapping. I've
changed the name of the write version to "max_version" so that it expresses
more adequately what that parameter means.
was (Author: jlewandowski):
I'm sorry for going through it again, but I'd put the selected write format on
a parent level, that is, if translated into properties, it could look like this:
{noformat}
sstable.selected_format=big
sstable.format.big.write_version_limit=nc
sstable.format.big.opt1=value1
{noformat}
The reason I don't want to do this:
{noformat}
sstable.format.default=big
sstable.format.big.write_version_limit=nc
sstable.format.big.opt1=value1
{noformat}
is that, I'd have to actually use {{Map}} on the
{{sstable.format}} level (at least I don't know how to do that differently)
And, since we want to have some consistency around properties, this
{{sstable.format..=}} speaks to me more than
{{sstable.format.options..=}}
In summary, selected format is not a property of any format, IMO it better fits
to sstable level.
Regarding target version and format - I agree it will be probably modified with
the downgradability ticket, thus those fields will be completely optional. I
like the idea of having Cassandra version --> format/version mapping. I've
changed the name of the write version to "write_version_limit" so that it
expresses more adequately what that parameter means.
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717012#comment-17717012
]
Jacek Lewandowski edited comment on CASSANDRA-18441 at 4/27/23 7:19 AM:
I'm sorry for going through it again, but I'd put the selected write format on
a parent level, that is, if translated into properties, it could look like this:
{noformat}
sstable.selected_format=big
sstable.format.big.write_version_limit=nc
sstable.format.big.opt1=value1
{noformat}
The reason I don't want to do this:
{noformat}
sstable.format.default=big
sstable.format.big.write_version_limit=nc
sstable.format.big.opt1=value1
{noformat}
is that, I'd have to actually use {{Map}} on the
{{sstable.format}} level (at least I don't know how to do that differently)
And, since we want to have some consistency around properties, this
{{sstable.format..=}} speaks to me more than
{{sstable.format.options..=}}
In summary, selected format is not a property of any format, IMO it better fits
to sstable level.
Regarding target version and format - I agree it will be probably modified with
the downgradability ticket, thus those fields will be completely optional. I
like the idea of having Cassandra version --> format/version mapping. I've
changed the name of the write version to "write_version_limit" so that it
expresses more adequately what that parameter means.
was (Author: jlewandowski):
I'm sorry for going through it again, but I'd put the selected write format on
a parent level, that is, if translated into properties, it could look like this:
{noformat}
sstable.write_format=big
sstable.format.big.write_version=nc
sstable.format.big.opt1=value1
{noformat}
The reason I don't want to do this:
{noformat}
sstable.format.default=big
sstable.format.big.write_version=nc
sstable.format.big.opt1=value1
{noformat}
is that, I'd have to actually use {{Map}} on the
{{sstable.format}} level (at least I don't know how to do that differently)
And, since we want to have some consistency around properties, this
{{sstable.format..=}} speaks to me more than
{{sstable.format.options..=}}
In summary, selected format is not a property of any format, IMO it better fits
to sstable level.
Regarding target version and format - I agree it will be probably modified with
the downgradability ticket, thus those fields will be completely optional. I
like the idea of having Cassandra version --> format/version mapping.
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717012#comment-17717012
]
Jacek Lewandowski commented on CASSANDRA-18441:
---
I'm sorry for going through it again, but I'd put the selected write format on
a parent level, that is, if translated into properties, it could look like this:
{noformat}
sstable.write_format=big
sstable.format.big.write_version=nc
sstable.format.big.opt1=value1
{noformat}
The reason I don't want to do this:
{noformat}
sstable.format.default=big
sstable.format.big.write_version=nc
sstable.format.big.opt1=value1
{noformat}
is that, I'd have to actually use {{Map}} on the
{{sstable.format}} level (at least I don't know how to do that differently)
And, since we want to have some consistency around properties, this
{{sstable.format..=}} speaks to me more than
{{sstable.format.options..=}}
In summary, selected format is not a property of any format, IMO it better fits
to sstable level.
Regarding target version and format - I agree it will be probably modified with
the downgradability ticket, thus those fields will be completely optional. I
like the idea of having Cassandra version --> format/version mapping.
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716664#comment-17716664
]
Jacek Lewandowski commented on CASSANDRA-18441:
---
{noformat}
sstable_formats:
selected_format: big
options:
big:
write_version: nc
read_opt1: value
write_opt: value
bti:
write_version: da
read_opt1: value
write_opt1: value
{noformat}
?
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716603#comment-17716603
]
Jacek Lewandowski commented on CASSANDRA-18441:
---
I currently have this:
{noformat}
sstable_formats:
selected_format: big
selected_version: nc
options:
big:
read_opt1: value
write_opt: value
bti:
read_opt1: value
write_opt1: value
{noformat}
and wondering if we need to have "sstable" and "format" on separate levels?
Justifying the configuration of multiple formats, it is not read or write
configuration, but just a configuration passed to the constructor of the format.
Question about nesting - [~maedhroz] did you mean using just an untyped Map in
the config so that whatever is under the certain format type options we just
pass to that format constructor or just stick with some structure, like assume
we always have just a flat map of properties (Map)?
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18441: -- Test and Documentation Plan: regression tests Status: Patch Available (was: In Progress) https://github.com/apache/cassandra/pull/2295 https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/679/workflows/cb9987e4-cb8d-449b-aef8-1ea7829c19ea Something which I've done additionally was more refactoring of autosaving cache - instead of just moving format ids to metadata, I moved all dictionaries to the metadata. It made the cache smaller and loading faster, especially for tables with no clustering keys. Here are the results from some benchmark saving 2M rows in across 2 tables and 200 sstables. || UUID || saving-trunk || saving-18441 || size-trunk || size-18441 || loading-trunk || loading-18441 || | true | 952 ms | 800 ms | 72 MB | 30 MB | 5737 ms |860 ms | | false | 852 ms | 822 ms | 106 MB | 30 MB | 1058 ms |800 ms | SSTableFormat.Type is marked as deprecated as there is pretty little sense for it to exist. > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714107#comment-17714107 ] Jacek Lewandowski commented on CASSANDRA-18441: --- Ah, you refer to the yaml - right, I meant that I'll use "nesting" > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714106#comment-17714106
]
Jacek Lewandowski commented on CASSANDRA-18441:
---
{quote}To keep changes limited, I would prefer to not implement any per-table
configuration at this point, and thus only expose and configure the single
write format to use.{quote}
Indeed, I don't want to provide per sstable configuration in this ticket.
> Improvements to SSTable format configuration
>
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714054#comment-17714054 ] Jacek Lewandowski edited comment on CASSANDRA-18441 at 4/19/23 11:22 AM: - So summarizing things to be done there: 1. sstable format should have hardcoded its string identifier 2. numeric identifier should be removed and we should include a mapping in key cache 3. sstable formats should be discovered via service loader 4. format configuration should look differently - let's use the last proposal from [~maedhroz] with nesting 5. let configure sstable properties via yaml/system properties was (Author: jlewandowski): So summarizing things to be done there: 1. sstable format should have hardcoded its string identifier 2. numeric identifier should be removed and we should include a mapping in row cache 3. sstable formats should be discovered via service loader 4. format configuration should look differently - let's use the last proposal from [~maedhroz] with nesting 5. let configure sstable properties via yaml/system properties > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714054#comment-17714054 ] Jacek Lewandowski commented on CASSANDRA-18441: --- So summarizing things to be done there: 1. sstable format should have hardcoded its string identifier 2. numeric identifier should be removed and we should include a mapping in row cache 3. sstable formats should be discovered via service loader 4. format configuration should look differently - let's use the last proposal from [~maedhroz] with nesting 5. let configure sstable properties via yaml/system properties > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18465) Add support for multiple condition branches and results in Accord transaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18465:
--
Description:
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single SELECT is defined in
which case the conditional SELECTs would not be valid.
SELECTs would be validated to return columns of the same type. They would be
able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
The following syntax would be considered as invalid:
1. select defined both on the top level and in branches
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
SELECT ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
2. select defined after update - select must be before the update to make it
clear we select data before modification
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
UPDATE ...
SELECT 'one', a.value
ELSE IF condition2 THEN
UPDATE ...
SELECT 'two', b.value
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
3. missing select - if select is defined in a single branch, it has to be
defined in all branches:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
UPDATE ...
END IF
COMMIT TRANSACTION
{code}
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
END IF
COMMIT TRANSACTION
{code}
was:
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single SELECT is defined in
which case the conditional SELECTs would not be valid.
SELECTs would be validated to return columns of the same type. They would be
able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
> Add support for multiple condition branches and results in Accord transaction
> -
>
> Key: CASSANDRA-18465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18465
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> I'd like to propose adding support for multiple branches and result sets for
> Accord transactions. It could look like this:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> The existing syntax would remain valid, when a single SELECT is defined in
> which case the conditional SELECTs would not be valid.
> SELECTs would be validated to return columns of the same type. They would be
> able to return literals as well.
> This would be make the result of the transaction more intuitive as the client
> would know explicitly if the updates where applied or not.
> The following syntax would be considered as invalid:
> 1. select defined both on the top level and in branches
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> SELECT ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> 2. select defined after update - select must be before the update to make it
> clear we select data before modification
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> UPDATE ...
> SELECT 'one', a.value
> ELSE IF condition2 THEN
> UPDATE ...
>
[jira] [Created] (CASSANDRA-18465) Add support for multiple condition branches and results in Accord transaction
Jacek Lewandowski created CASSANDRA-18465:
-
Summary: Add support for multiple condition branches and results
in Accord transaction
Key: CASSANDRA-18465
URL: https://issues.apache.org/jira/browse/CASSANDRA-18465
Project: Cassandra
Issue Type: New Feature
Components: Accord, CQL/Syntax
Reporter: Jacek Lewandowski
I'd like to propose adding support for multiple branches and result sets for
Accord transactions. It could look like this:
{code:sql}
BEGIN TRANSACTION
LET a = ...
LET b = ...
IF condition THEN
SELECT 'one', a.value
UPDATE ...
ELSE IF condition2 THEN
SELECT 'two', b.value
UPDATE ...
ELSE
SELECT 'three', NULL
END IF
COMMIT TRANSACTION
{code}
The existing syntax would remain valid, when a single SELECT is defined in
which case the conditional SELECTs would not be valid.
SELECTs would be validated to return columns of the same type. They would be
able to return literals as well.
This would be make the result of the transaction more intuitive as the client
would know explicitly if the updates where applied or not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18239) Replace eclipse warnings based static code analysis with something better (Sonar)
[
https://issues.apache.org/jira/browse/CASSANDRA-18239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713011#comment-17713011
]
Jacek Lewandowski commented on CASSANDRA-18239:
---
ErrorProne works nice.
Since it is a compiler plugin, the verification cannot be separated from the
build itself. Overall it might be faster than others, perhaps it takes into
account incremental compilation.
Apart from reporting bugs resulting from static analysis, it is picky about
some JavaDocs structures, like having comment in {{@return}} but missing a
summary.
> Replace eclipse warnings based static code analysis with something better
> (Sonar)
> -
>
> Key: CASSANDRA-18239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18239
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> Eclipse warnings is used for static code analysis. However, it does not fit
> well into Cassandra code and practically we end up explicitly adding
> suppressions in many places just to satisfy that tool rather than fix the
> real issues.
> This is an incomplete list of reasons to remove it:
> - not closed resources are detected incorrectly
> - does not recognize custom utility methods used to close the resources,
> which use use heavily in the code, like {{Throwables.close}},
> {{FileUtils.close}}, {{closeQuietly}}...
> - because of the above, we cannot make important things like {{Ref}} to
> implement {{Closeable}} as it would make the tool to explode with tons of
> warnings
> - it complains about correct generics - something like "method X is not
> applicable for ..." when the code compiles successfully is not acceptable
> - it is old and not maintained
> There are better tools like IntelliJ inspections for example, which can also
> be run in headless mode
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18450) Do not include checkstyle or other checks in "jar" target, have separate target for them
[ https://issues.apache.org/jira/browse/CASSANDRA-18450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18450: -- Summary: Do not include checkstyle or other checks in "jar" target, have separate target for them (was: Do not include checkstyle or other check in "jar" target, have separate target for them) > Do not include checkstyle or other checks in "jar" target, have separate > target for them > > > Key: CASSANDRA-18450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18450 > Project: Cassandra > Issue Type: Task >Reporter: Jacek Lewandowski >Priority: Normal > > I'd like to propose that we reduce "jar" target in the build to absolute > minimum so that it is fast when you do everyday development and you build > frequently. > Checkstyle, and other checks, like Eclipse-Warnings could be a part of a > separate target, like "check" that would run all of them. > That "check" target would be also a part of "artifacts" target. > I know that we can always add a property to disable checkstyle but I find it > a pain to remember the property name. Also, we only run some of the checks > with "jar" which is confusing. > cc [~mck] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18450) Do not include checkstyle or other check in "jar" target, have separate target for them
Jacek Lewandowski created CASSANDRA-18450: - Summary: Do not include checkstyle or other check in "jar" target, have separate target for them Key: CASSANDRA-18450 URL: https://issues.apache.org/jira/browse/CASSANDRA-18450 Project: Cassandra Issue Type: Task Reporter: Jacek Lewandowski I'd like to propose that we reduce "jar" target in the build to absolute minimum so that it is fast when you do everyday development and you build frequently. Checkstyle, and other checks, like Eclipse-Warnings could be a part of a separate target, like "check" that would run all of them. That "check" target would be also a part of "artifacts" target. I know that we can always add a property to disable checkstyle but I find it a pain to remember the property name. Also, we only run some of the checks with "jar" which is confusing. cc [~mck] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711582#comment-17711582 ] Jacek Lewandowski commented on CASSANDRA-18441: --- Regarding a numeric ID - since we bumped the cache version I think we can add an explicit mapping to the header of the cache file, something like format name -> id, and use that id, whichever it is. This way the scope of numeric ID will be limited to the cache only. > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18441: -- Change Category: Semantic Complexity: Normal Status: Open (was: Triage Needed) > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711283#comment-17711283 ] Jacek Lewandowski commented on CASSANDRA-18441: --- TCM could share the identifiers of the sstable format that are available on the node classpath. By that, we could validate whether an update of the output format is valid or not for a table. Can we agree on hardcoding the name and numeric ID in the format itself? I like this idea, I implemented it in CASSANDRA-17056 in a bad way because I wanted everything to be configurable, and it turned out it was too much. My reasoning against the idea of fixed IDs was that if there are two external formats with the same ID, and the user is not the author of any of them, the user has no way to switch between one and the other. Though, it was probably too contrived. Can we agree on the service loader being used to discover the supported formats or do we want them to be enumerated in the config? I'm slightly leaning toward the service loader approach, but not insisting on that. For the selected format, even if we want that to be configured in table metadata, we still need some default configuration probably. I prefer the example from [Branimir Lambov|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=blambov] with a small change suggested by [David Capwell|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dcapwell] - use the identifier rather than the full class name, assuming we already discovered all formats before. What is worrying me in the example provided by [David Capwell|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dcapwell] is that it seems to suggest that we can define multiple write formats, while we really don't want to do that. > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18239) Replace eclipse warnings based static code analysis with something better (Sonar)
[
https://issues.apache.org/jira/browse/CASSANDRA-18239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711264#comment-17711264
]
Jacek Lewandowski commented on CASSANDRA-18239:
---
[~e.dimitrova] SpotBugs has something with limited functionality
[here|https://spotbugs.readthedocs.io/en/stable/detectors.html#findopenstream]
- it applies to unclosed IO streams but is not generic enough to detect all
auto-closeable.
My biggest problem with Eclipse-Warnings was a large number of false positives
(inconvenience) and failure to compile the correct code with more extensive use
of generics (blocker) - it couldn't have been suppressed because scanning
wasn't even started.
Sonar is something probably extensive, though a bit difficult to integrate. I
noticed a Docker image for the Sonar server in DockerHub - perhaps it is
possible to script starting it and running analysis as a part of verification
in Ant?
Also, I'd really like to try [ErrorProne|https://errorprone.info], as it has a
bug pattern we are primarily interested in
[here|https://errorprone.info/bugpattern/MustBeClosedChecker].
Concluding, I know you need to move forward with JDK17. If upgrading ECJ is the
easiest way to do that, please do it. If we manage to change Eclipse-Warnings
to something else later, that will be ok and won't be a blocker for you.
If you like, we can make a deal - we can try to verify SpotBugs, ErrorProne,
and Sonar by the end of the week on minimal code examples. If we fail to do
that due to the lack of time, go on with Eclipse-Warnings, WDYT? (maybe
[~mmuzaf] can help there as well). I have ErrorProne configured already on some
other project hence confirming it works or not should not be super hard.
> Replace eclipse warnings based static code analysis with something better
> (Sonar)
> -
>
> Key: CASSANDRA-18239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18239
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> Eclipse warnings is used for static code analysis. However, it does not fit
> well into Cassandra code and practically we end up explicitly adding
> suppressions in many places just to satisfy that tool rather than fix the
> real issues.
> This is an incomplete list of reasons to remove it:
> - not closed resources are detected incorrectly
> - does not recognize custom utility methods used to close the resources,
> which use use heavily in the code, like {{Throwables.close}},
> {{FileUtils.close}}, {{closeQuietly}}...
> - because of the above, we cannot make important things like {{Ref}} to
> implement {{Closeable}} as it would make the tool to explode with tons of
> warnings
> - it complains about correct generics - something like "method X is not
> applicable for ..." when the code compiles successfully is not acceptable
> - it is old and not maintained
> There are better tools like IntelliJ inspections for example, which can also
> be run in headless mode
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18441) Improvements to SSTable format configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski reassigned CASSANDRA-18441: - Assignee: Jacek Lewandowski > Improvements to SSTable format configuration > > > Key: CASSANDRA-18441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18441 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format > implementations and defined a method of plugging in specific configurations. > This method is brittle and asks users to specify format identifiers whose > configuration does not provide value but can be the source of conflicts and > problems. On the other hand it makes important choices non-obvious, as the > selection of format to write is given by the order of configured interfaces. > An improved specification mechanism needs to be put in place before Cassandra > 5 is released. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710435#comment-17710435
]
Jacek Lewandowski edited comment on CASSANDRA-18399 at 4/11/23 7:16 AM:
I think, I have finished.
There is one main entry script {{prepare_merge_commands.py}}. Just run in the
cassandra repo dir (making sure the worktree is clean, the script will fail
otherwise):
{noformat}
python3 ~/path-to-cassandra-builds/dev/scripts/prepare_merge_commands.py
../merge.script
{noformat}
The only argument is the script file to generate (use ../ so that the script is
not generated in the repo directory as it would make it dirty, appropriate
checks are included).
The script will guide you through all the steps, for example:
{noformat}
jlewandowski@deauville:~/dev/apache/cassandra$ python3
~/dev/cassandra-builds/CASSANDRA-18399/dev/scripts/prepare_merge_commands.py
Remote repositories:
JeetKunDoug
apache
jacek-lewandowski
jtgrabowski
origin
Enter the name of the remote repository that points to the upstream Apache
Cassandra [default: origin]:
g...@github.com:apache/cassandra.git
Enter the name of the remote repository that points to the upstream feature
branch [default: origin]: jacek-lewandowski
g...@github.com:jacek-lewandowski/cassandra.git
Enter the ticket number: 9
Fetching from origin
Fetching from jacek-lewandowski
Found the following release branches:
1.0: cassandra-1.0
1.1: cassandra-1.1
1.2: cassandra-1.2
2.0: cassandra-2.0
2.1: cassandra-2.1
2.2: cassandra-2.2
3.0: cassandra-3.0
3.11: cassandra-3.11
4.0: cassandra-4.0
4.1: cassandra-4.1
trunk: trunk
.*refs/heads/(CASSANDRA\-9((\d+)\.(\d+))?.*)$
Found the following feature branches:
4.0: CASSANDRA-9-4.0
4.1: CASSANDRA-9-4.1
trunk: CASSANDRA-9
Enter the oldest release version to merge into [default: 4.0]:
Enter the name of the feature branch to merge into cassandra-4.0 or type 'none'
if there is no feature branch for this release [default: CASSANDRA-9-4.0]:
Enter the name of the feature branch to merge into cassandra-4.1 or type 'none'
if there is no feature branch for this release [default: CASSANDRA-9-4.1]:
Enter the name of the feature branch to merge into trunk or type 'none' if
there is no feature branch for this release [default: CASSANDRA-9]:
Commits:
1: Commit(sha='bde2c79b82', author='Jacek Lewandowski', title='Updated
README.asc in a stupid way')
2: Commit(sha='045c27f4e8', author='Jacek Lewandowski', title='DO NOT MERGE')
Enter the number of the commit whose message should be used as a title in
CHANGES.txt or leave empty to enter a custom title: 1
Enter the filename to save the script to [default: merge_CASSANDRA-9.sh]:
{noformat}
As you can see, when the branches are named properly, it will autosuggest the
right names, but you are still free to choose any branches.
It generates a script like the following one:
{noformat}
#!/bin/bash
set -xe
[[ -z $(git status --porcelain) ]] # worktree must be clean
# Commands for merging CASSANDRA-9-4.0 -> cassandra-4.0
git switch cassandra-4.0
git reset --hard origin/cassandra-4.0
git cherry-pick bde2c79b82 # Jacek Lewandowski - Updated README.asc in a stupid
way
git cherry-pick -n 045c27f4e8 # Jacek Lewandowski - DO NOT MERGE
python3
/home/jlewandowski/dev/cassandra-builds/CASSANDRA-18399/dev/scripts/update_changes.py
'CASSANDRA-9' '4.0' '' 'Updated README.asc in a stupid way'
git add CHANGES.txt
git commit --amend --no-edit
[[ -n "$(git diff origin/cassandra-4.0..HEAD -- .circleci/)" ]] && (git diff
origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) && git commit
-a --amend --no-edit # Remove all changes in .circleci directory if you need to
git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
files
# Commands for merging CASSANDRA-9-4.1 -> cassandra-4.1
git switch cassandra-4.1
git reset --hard origin/cassandra-4.1
git merge -s ours --log --no-edit cassandra-4.0
git cherry-pick -n 339f66a75e # Jacek Lewandowski - Updated README.asc in a
stupid way
git cherry-pick -n eb400940b6 # Jacek Lewandowski - DO NOT MERGE
python3
/home/jlewandowski/dev/cassandra-builds/CASSANDRA-18399/dev/scripts/update_changes.py
'CASSANDRA-9' '4.1' '4.0' 'Updated README.asc in a stupid way'
git add CHANGES.txt
git commit --amend --no-edit
[[ -n "$(git diff origin/cassandra-4.1..HEAD -- .circleci/)" ]] && (git diff
origin/cassandra-4.1..HEAD -- .circleci/ | git apply -R --index) && git commit
-a --amend --no-edit # Remove all changes in .circleci directory if you need to
git diff --name-only origin/cassandra-4.1..HEAD # print a list of all changes
files
# Commands for merging CASSANDRA-9 -> trunk
[jira] [Commented] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710435#comment-17710435
]
Jacek Lewandowski commented on CASSANDRA-18399:
---
I think, I have finished.
There is one main entry script {{prepare_merge_commands.py}}. Just run in the
cassandra repo dir (making sure the worktree is clean, the script will fail
otherwise):
{noformat}
python3 ~/path-to-cassandra-builds/dev/scripts/prepare_merge_commands.py
../merge.script
{noformat}
The only argument is the script file to generate (use ../ so that the script is
not generated in the repo directory as it would make it dirty, appropriate
checks are included).
The script will guide you through all the steps, for example:
{noformat}
jlewandowski@deauville:~/dev/apache/cassandra$ python3
~/dev/cassandra-builds/CASSANDRA-18399/dev/scripts/prepare_merge_commands.py
Remote repositories:
JeetKunDoug
apache
jacek-lewandowski
jtgrabowski
origin
Enter the name of the remote repository that points to the upstream Apache
Cassandra [default: origin]:
g...@github.com:apache/cassandra.git
Enter the name of the remote repository that points to the upstream feature
branch [default: origin]: jacek-lewandowski
g...@github.com:jacek-lewandowski/cassandra.git
Enter the ticket number: 9
Fetching from origin
Fetching from jacek-lewandowski
Found the following release branches:
1.0: cassandra-1.0
1.1: cassandra-1.1
1.2: cassandra-1.2
2.0: cassandra-2.0
2.1: cassandra-2.1
2.2: cassandra-2.2
3.0: cassandra-3.0
3.11: cassandra-3.11
4.0: cassandra-4.0
4.1: cassandra-4.1
trunk: trunk
.*refs/heads/(CASSANDRA\-9((\d+)\.(\d+))?.*)$
Found the following feature branches:
4.0: CASSANDRA-9-4.0
4.1: CASSANDRA-9-4.1
trunk: CASSANDRA-9
Enter the oldest release version to merge into [default: 4.0]:
Enter the name of the feature branch to merge into cassandra-4.0 or type 'none'
if there is no feature branch for this release [default: CASSANDRA-9-4.0]:
Enter the name of the feature branch to merge into cassandra-4.1 or type 'none'
if there is no feature branch for this release [default: CASSANDRA-9-4.1]:
Enter the name of the feature branch to merge into trunk or type 'none' if
there is no feature branch for this release [default: CASSANDRA-9]:
Commits:
1: Commit(sha='bde2c79b82', author='Jacek Lewandowski', title='Updated
README.asc in a stupid way')
2: Commit(sha='045c27f4e8', author='Jacek Lewandowski', title='DO NOT MERGE')
Enter the number of the commit whose message should be used as a title in
CHANGES.txt or leave empty to enter a custom title: 1
Enter the filename to save the script to [default: merge_CASSANDRA-9.sh]:
{noformat}
As you can see, when the branches are named properly, it will autosuggest the
right names, but you are still free to choose any branches.
It generates a script like the following one:
{noformat}
#!/bin/bash
set -xe
[[ -z $(git status --porcelain) ]] # worktree must be clean
# Commands for merging CASSANDRA-9-4.0 -> cassandra-4.0
git switch cassandra-4.0
git reset --hard origin/cassandra-4.0
git cherry-pick bde2c79b82 # Jacek Lewandowski - Updated README.asc in a stupid
way
git cherry-pick -n 045c27f4e8 # Jacek Lewandowski - DO NOT MERGE
python3
/home/jlewandowski/dev/cassandra-builds/CASSANDRA-18399/dev/scripts/update_changes.py
'CASSANDRA-9' '4.0' '' 'Updated README.asc in a stupid way'
git add CHANGES.txt
git commit --amend --no-edit
[[ -n "$(git diff origin/cassandra-4.0..HEAD -- .circleci/)" ]] && (git diff
origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) && git commit
-a --amend --no-edit # Remove all changes in .circleci directory if you need to
git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
files
# Commands for merging CASSANDRA-9-4.1 -> cassandra-4.1
git switch cassandra-4.1
git reset --hard origin/cassandra-4.1
git merge -s ours --log --no-edit cassandra-4.0
git cherry-pick -n 339f66a75e # Jacek Lewandowski - Updated README.asc in a
stupid way
git cherry-pick -n eb400940b6 # Jacek Lewandowski - DO NOT MERGE
python3
/home/jlewandowski/dev/cassandra-builds/CASSANDRA-18399/dev/scripts/update_changes.py
'CASSANDRA-9' '4.1' '4.0' 'Updated README.asc in a stupid way'
git add CHANGES.txt
git commit --amend --no-edit
[[ -n "$(git diff origin/cassandra-4.1..HEAD -- .circleci/)" ]] && (git diff
origin/cassandra-4.1..HEAD -- .circleci/ | git apply -R --index) && git commit
-a --amend --no-edit # Remove all changes in .circleci directory if you need to
git diff --name-only origin/cassandra-4.1..HEAD # print a list of all changes
files
# Commands for merging CASSANDRA-9 -> trunk
[jira] [Commented] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709875#comment-17709875
]
Jacek Lewandowski commented on CASSANDRA-18399:
---
The last case is interesting because the information about the patch being
applied to trunk will be lost, right?
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit cassandra-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a --amend --no-edit # Remove all changes in .circleci
> directory if you need to
> git diff --name-only origin/cassandra-3.11..HEAD # print a list of all
> changes files
> # jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
> #
>
> git switch cassandra-4.0
> git reset --hard origin/cassandra-4.0
> git merge -s ours --log --no-edit cassandra-3.11
> git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n a71d4e3408 && git commit -a --amend --no-edit # a71d4e3408
> DO NOT MERGE - CircleCI config
> git cherry-pick -n 6dc53f4e97 && git commit -a --amend --no-edit # 6dc53f4e97
> fixes
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-4.1 -> cassandra-4.1
> #
>
> git switch cassandra-4.1
> git reset --hard origin/cassandra-4.1
> git merge -s ours --log --no-edit cassandra-4.0
> git
[jira] [Commented] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709869#comment-17709869
]
Jacek Lewandowski commented on CASSANDRA-18399:
---
Thank you Mick
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit cassandra-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a --amend --no-edit # Remove all changes in .circleci
> directory if you need to
> git diff --name-only origin/cassandra-3.11..HEAD # print a list of all
> changes files
> # jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
> #
>
> git switch cassandra-4.0
> git reset --hard origin/cassandra-4.0
> git merge -s ours --log --no-edit cassandra-3.11
> git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n a71d4e3408 && git commit -a --amend --no-edit # a71d4e3408
> DO NOT MERGE - CircleCI config
> git cherry-pick -n 6dc53f4e97 && git commit -a --amend --no-edit # 6dc53f4e97
> fixes
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-4.1 -> cassandra-4.1
> #
>
> git switch cassandra-4.1
> git reset --hard origin/cassandra-4.1
> git merge -s ours --log --no-edit cassandra-4.0
> git cherry-pick -n 3584d17b36 && git commit -a --amend --no-edit # 3584d17b36
> Save host id to
[jira] [Commented] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709838#comment-17709838
]
Jacek Lewandowski commented on CASSANDRA-18399:
---
Thanks, for checking, I expected there will be problems, that's why decided to
rewrite in Python to avoid discrepancies.
Anyway, for editing {{CHANGES.txt}} I'd like to find an algorithm which rules
how to do that correctly (I've noticed I don't know exactly):
say, trunk represents 5.0 (current situation)
1. If the change is only for *trunk*, then we add the entry in the *5.0*
section (top section).
2. If the change is for *4.1* and *trunk*, then:
- in *4.1*, we add the entry in the *4.1* section (top section)
- in *trunk*, we add the entry in the *4.1* section (first encountered *4.1*
section)
3. If the change is for *4.0*, *4.1* and *trunk*, then:
- in *4.0*, we add the entry in the *4.0* section (top section)
- in *4.1*, we add then entry in the *4.1* section (top section), under
*Merged from 4.0* subsection
- in *trunk*, we add the entry in the *4.1* section (first encountered *4.1*
section), under *Merged from 4.0* subsection
4. If the change is for *4.0* and not for *4.1* or *trunk*, then:
- in *4.0*, we add the entry in the *4.0* section (top section)
- in *4.1*, {color:#DE350B}*???*{color}
- in *trunk*, {color:#DE350B}*???*{color}
5. If the change is for *3.11* and *4.1* and not for *4.0* or *trunk*, then:
- in *3.11*, we add the entry in the *3.11* section (top section)
- in *4.0*, {color:#DE350B}*???*{color}
- in *4.1*, {color:#DE350B}*???*{color}
- in *trunk*, {color:#DE350B}*???*{color}
6. If the change is for *4.0* and *trunk*, and not for *4.1*, then:
- in *4.0*, we add the entry in the *4.0* section (top section)
- in *4.1*, {color:#DE350B}*???*{color}
- in *trunk*, {color:#DE350B}*???*{color}
I need to clarify what to do in the highlighted cases.
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit cassandra-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a
[jira] [Commented] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709291#comment-17709291
]
Jacek Lewandowski commented on CASSANDRA-18399:
---
{{JAVA__HOME}} would be a custom env anyway. Just need some consistent
way we can switch Java version and those envs could just point to certain
version. Alternatively, we could assume there is SDKMan installed and we can
use it to switch Java version
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit cassandra-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a --amend --no-edit # Remove all changes in .circleci
> directory if you need to
> git diff --name-only origin/cassandra-3.11..HEAD # print a list of all
> changes files
> # jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
> #
>
> git switch cassandra-4.0
> git reset --hard origin/cassandra-4.0
> git merge -s ours --log --no-edit cassandra-3.11
> git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n a71d4e3408 && git commit -a --amend --no-edit # a71d4e3408
> DO NOT MERGE - CircleCI config
> git cherry-pick -n 6dc53f4e97 && git commit -a --amend --no-edit # 6dc53f4e97
> fixes
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-4.1 -> cassandra-4.1
> #
>
[jira] [Comment Edited] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709227#comment-17709227
]
Jacek Lewandowski edited comment on CASSANDRA-18399 at 4/6/23 6:50 AM:
---
Thanks for trying [~e.dimitrova]
Answering your questions:
1) because such commits may have different titles, also because sometimes
changes to circle ci config can be part of some other commit - this approach
simply handles all the cases. Also, this is a script generator so you can
comment out / remove that line from the output
2) if you mean, git push --atomic -n, then it is added, and in new version it
does the verification whether:
- the newer branch contains all the commits from the previous branch + one new
merge commit with correct versions
- the first branch contains only one commit, which is not a merge commit
Additionally, the script generates git diff --name-only, and git show commands
for each branch reported by git push -n
3) this is a good idea, but I'd rather do ant artifacts; though - I don't know
where to get the supported java versions from, also, I don't know what is the
common way to switch the java version
EDIT: I can see a property java.supported got added in 5.0, so we can use that,
and hardcode for previous versions. We can assume JAVA__HOME env
properties to be present so that the script can consistently switch
4) because this must be branch/version agnostic stuff
The error you reported is valid if your commit does not cherry-pick cleanly -
was that the case?
was (Author: jlewandowski):
Thanks for trying [~e.dimitrova]
Answering your questions:
1) because such commits may have different titles, also because sometimes
changes to circle ci config can be part of some other commit - this approach
simply handles all the cases. Also, this is a script generator so you can
comment out / remove that line from the output
2) if you mean, git push --atomic -n, then it is added, and in new version it
does the verification whether:
- the newer branch contains all the commits from the previous branch + one new
merge commit with correct versions
- the first branch contains only one commit, which is not a merge commit
Additionally, the script generates git diff --name-only, and git show commands
for each branch reported by git push -n
3) this is a good idea, but I'd rather do ant artifacts; though - I don't know
where to get the supported java versions from, also, I don't know what is the
common way to switch the java version
4) because this must be branch/version agnostic stuff
The error you reported is valid if your commit does not cherry-pick cleanly -
was that the case?
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours
[jira] [Commented] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709227#comment-17709227
]
Jacek Lewandowski commented on CASSANDRA-18399:
---
Thanks for trying [~e.dimitrova]
Answering your questions:
1) because such commits may have different titles, also because sometimes
changes to circle ci config can be part of some other commit - this approach
simply handles all the cases. Also, this is a script generator so you can
comment out / remove that line from the output
2) if you mean, git push --atomic -n, then it is added, and in new version it
does the verification whether:
- the newer branch contains all the commits from the previous branch + one new
merge commit with correct versions
- the first branch contains only one commit, which is not a merge commit
Additionally, the script generates git diff --name-only, and git show commands
for each branch reported by git push -n
3) this is a good idea, but I'd rather do ant artifacts; though - I don't know
where to get the supported java versions from, also, I don't know what is the
common way to switch the java version
4) because this must be branch/version agnostic stuff
The error you reported is valid if your commit does not cherry-pick cleanly -
was that the case?
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit cassandra-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a --amend --no-edit # Remove all changes in .circleci
> directory if you need to
> git diff --name-only origin/cassandra-3.11..HEAD # print a list of all
> changes files
> # jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
> #
>
> git switch cassandra-4.0
> git reset --hard origin/cassandra-4.0
> git merge -s ours --log --no-edit cassandra-3.11
> git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n a71d4e3408 && git
[jira] [Updated] (CASSANDRA-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-17797: -- Status: Changes Suggested (was: Review In Progress) > All system properties and environment variables should be accessed via the > new CassandraRelevantProperties and CassandraRelevantEnv classes > --- > > Key: CASSANDRA-17797 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17797 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Low > Fix For: 5.x > > Time Spent: 19h > Remaining Estimate: 0h > > Follow up ticket for CASSANDRA-15876 - > "Always access system properties and environment variables via the new > CassandraRelevantProperties and CassandraRelevantEnv classes" > As part of that ticket we moved to the two new classes only > properties/variables that were currently listed in System Properties Virtual > Table. > We have to move to those classes the rest of the properties around the code > and start using those classes to access all of them. > +Additional information for newcomers:+ > You might want to start by getting acquainted with > CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might > want to check what changes were done and how the first batch was transferred > to this new framework as part of > [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > We are interested into the properties accessed currently through > getProperties around the code. > As part of CASSANDRA-15876 relevant unit tests were added > (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure > that all tests Cassandra pass and also to think about potential update of the > mentioned test class. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-17797: -- Status: Review In Progress (was: Needs Committer) > All system properties and environment variables should be accessed via the > new CassandraRelevantProperties and CassandraRelevantEnv classes > --- > > Key: CASSANDRA-17797 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17797 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Low > Fix For: 5.x > > Time Spent: 19h > Remaining Estimate: 0h > > Follow up ticket for CASSANDRA-15876 - > "Always access system properties and environment variables via the new > CassandraRelevantProperties and CassandraRelevantEnv classes" > As part of that ticket we moved to the two new classes only > properties/variables that were currently listed in System Properties Virtual > Table. > We have to move to those classes the rest of the properties around the code > and start using those classes to access all of them. > +Additional information for newcomers:+ > You might want to start by getting acquainted with > CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might > want to check what changes were done and how the first batch was transferred > to this new framework as part of > [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > We are interested into the properties accessed currently through > getProperties around the code. > As part of CASSANDRA-15876 relevant unit tests were added > (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure > that all tests Cassandra pass and also to think about potential update of the > mentioned test class. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17708446#comment-17708446 ] Jacek Lewandowski commented on CASSANDRA-17797: --- tests looks good, I'll do my best to review this week > All system properties and environment variables should be accessed via the > new CassandraRelevantProperties and CassandraRelevantEnv classes > --- > > Key: CASSANDRA-17797 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17797 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Low > Fix For: 5.x > > Time Spent: 18h 50m > Remaining Estimate: 0h > > Follow up ticket for CASSANDRA-15876 - > "Always access system properties and environment variables via the new > CassandraRelevantProperties and CassandraRelevantEnv classes" > As part of that ticket we moved to the two new classes only > properties/variables that were currently listed in System Properties Virtual > Table. > We have to move to those classes the rest of the properties around the code > and start using those classes to access all of them. > +Additional information for newcomers:+ > You might want to start by getting acquainted with > CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might > want to check what changes were done and how the first batch was transferred > to this new framework as part of > [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > We are interested into the properties accessed currently through > getProperties around the code. > As part of CASSANDRA-15876 relevant unit tests were added > (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure > that all tests Cassandra pass and also to think about potential update of the > mentioned test class. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-17797: -- Reviewers: Jacek Lewandowski, Stefan Miklosovic (was: Stefan Miklosovic) > All system properties and environment variables should be accessed via the > new CassandraRelevantProperties and CassandraRelevantEnv classes > --- > > Key: CASSANDRA-17797 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17797 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Low > Fix For: 5.x > > Time Spent: 18h 50m > Remaining Estimate: 0h > > Follow up ticket for CASSANDRA-15876 - > "Always access system properties and environment variables via the new > CassandraRelevantProperties and CassandraRelevantEnv classes" > As part of that ticket we moved to the two new classes only > properties/variables that were currently listed in System Properties Virtual > Table. > We have to move to those classes the rest of the properties around the code > and start using those classes to access all of them. > +Additional information for newcomers:+ > You might want to start by getting acquainted with > CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might > want to check what changes were done and how the first batch was transferred > to this new framework as part of > [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > We are interested into the properties accessed currently through > getProperties around the code. > As part of CASSANDRA-15876 relevant unit tests were added > (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure > that all tests Cassandra pass and also to think about potential update of the > mentioned test class. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18153:
--
Fix Version/s: 3.0.29
3.11.15
4.0.9
5.0
4.1.2
Since Version: 3.0.25
Source Control Link:
https://github.com/apache/cassandra/commit/f96659c5306e62666e21c371c2ded646dd51672b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.9, 5.0, 4.1.2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18153:
--
Status: Ready to Commit (was: Review In Progress)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 2h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18399:
--
Description:
This is just a simple additional script which committers can use to help them
merge commits, especially if the change applies to multiple Cassandra versions.
For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates the
following commands, which then can be run manually:
{noformat}
git fetch origin
git fetch jacek-lewandowski
# jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
#
git switch cassandra-3.0
git reset --hard origin/cassandra-3.0
git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and flush
immediately after startup
git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
fixes
git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
DO NOT MERGE - CircleCI config
grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\ *
Save host id to system.local and flush immediately after startup
(CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
git diff CHANGES.txt
git add CHANGES.txt
git commit --amend --no-edit
(git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
git commit -a --amend --no-edit # Remove all changes in .circleci directory if
you need to
git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
files
# jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
#
git switch cassandra-3.11
git reset --hard origin/cassandra-3.11
git merge -s ours --log --no-edit cassandra-3.0
git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
Save host id to system.local and flush immediately after startup
git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
fixes
git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
DO NOT MERGE - CircleCI config
grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\ *
Save host id to system.local and flush immediately after startup
(CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
git diff CHANGES.txt
git add CHANGES.txt
git commit --amend --no-edit
(git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index) &&
git commit -a --amend --no-edit # Remove all changes in .circleci directory if
you need to
git diff --name-only origin/cassandra-3.11..HEAD # print a list of all changes
files
# jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
#
git switch cassandra-4.0
git reset --hard origin/cassandra-4.0
git merge -s ours --log --no-edit cassandra-3.11
git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
Save host id to system.local and flush immediately after startup
git cherry-pick -n a71d4e3408 && git commit -a --amend --no-edit # a71d4e3408
DO NOT MERGE - CircleCI config
git cherry-pick -n 6dc53f4e97 && git commit -a --amend --no-edit # 6dc53f4e97
fixes
grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\ *
Save host id to system.local and flush immediately after startup
(CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
git diff CHANGES.txt
git add CHANGES.txt
git commit --amend --no-edit
(git diff origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) &&
git commit -a --amend --no-edit # Remove all changes in .circleci directory if
you need to
git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
files
# jacek-lewandowski/CASSANDRA-18153-4.1 -> cassandra-4.1
#
git switch cassandra-4.1
git reset --hard origin/cassandra-4.1
git merge -s ours --log --no-edit cassandra-4.0
git cherry-pick -n 3584d17b36 && git commit -a --amend --no-edit # 3584d17b36
Save host id to system.local and flush immediately after startup
git cherry-pick -n e7b2ca37e6 && git commit -a --amend --no-edit # e7b2ca37e6
DO NOT MERGE - CircleCI config
git cherry-pick -n 85f3049e90 && git commit -a --amend --no-edit # 85f3049e90
fixes
grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\ *
Save host id to system.local and flush immediately after startup
(CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
git diff CHANGES.txt
git add CHANGES.txt
git commit --amend --no-edit
(git diff origin/cassandra-4.1..HEAD -- .circleci/ | git apply -R --index) &&
git commit -a --amend --no-edit # Remove all changes in .circleci directory if
you need to
git diff --name-only origin/cassandra-4.1..HEAD
[jira] [Updated] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18399:
--
Test and Documentation Plan: user tests
Status: Patch Available (was: In Progress)
https://github.com/apache/cassandra-builds/pull/89
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit CASSANDRA-18153-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a --amend --no-edit # Remove all changes in .circleci
> directory if you need to
> git diff --name-only origin/cassandra-3.11..HEAD # print a list of all
> changes files
> # jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
> #
>
> git switch cassandra-4.0
> git reset --hard origin/cassandra-4.0
> git merge -s ours --log --no-edit CASSANDRA-18153-3.11
> git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n a71d4e3408 && git commit -a --amend --no-edit # a71d4e3408
> DO NOT MERGE - CircleCI config
> git cherry-pick -n 6dc53f4e97 && git commit -a --amend --no-edit # 6dc53f4e97
> fixes
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-4.1 -> cassandra-4.1
> #
>
> git switch cassandra-4.1
> git reset --hard origin/cassandra-4.1
> git merge -s ours --log --no-edit CASSANDRA-18153-4.0
> git cherry-pick -n 3584d17b36 &&
[jira] [Updated] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18399:
--
Description:
This is just a simple additional script which committers can use to help them
merge commits, especially if the change applies to multiple Cassandra versions.
For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates the
following commands, which then can be run manually:
{noformat}
git fetch origin
git fetch jacek-lewandowski
# jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
#
git switch cassandra-3.0
git reset --hard origin/cassandra-3.0
git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and flush
immediately after startup
git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
fixes
git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
DO NOT MERGE - CircleCI config
grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\ *
Save host id to system.local and flush immediately after startup
(CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
git diff CHANGES.txt
git add CHANGES.txt
git commit --amend --no-edit
(git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
git commit -a --amend --no-edit # Remove all changes in .circleci directory if
you need to
git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
files
# jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
#
git switch cassandra-3.11
git reset --hard origin/cassandra-3.11
git merge -s ours --log --no-edit CASSANDRA-18153-3.0
git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
Save host id to system.local and flush immediately after startup
git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
fixes
git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
DO NOT MERGE - CircleCI config
grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\ *
Save host id to system.local and flush immediately after startup
(CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
git diff CHANGES.txt
git add CHANGES.txt
git commit --amend --no-edit
(git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index) &&
git commit -a --amend --no-edit # Remove all changes in .circleci directory if
you need to
git diff --name-only origin/cassandra-3.11..HEAD # print a list of all changes
files
# jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
#
git switch cassandra-4.0
git reset --hard origin/cassandra-4.0
git merge -s ours --log --no-edit CASSANDRA-18153-3.11
git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
Save host id to system.local and flush immediately after startup
git cherry-pick -n a71d4e3408 && git commit -a --amend --no-edit # a71d4e3408
DO NOT MERGE - CircleCI config
git cherry-pick -n 6dc53f4e97 && git commit -a --amend --no-edit # 6dc53f4e97
fixes
grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\ *
Save host id to system.local and flush immediately after startup
(CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
git diff CHANGES.txt
git add CHANGES.txt
git commit --amend --no-edit
(git diff origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) &&
git commit -a --amend --no-edit # Remove all changes in .circleci directory if
you need to
git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
files
# jacek-lewandowski/CASSANDRA-18153-4.1 -> cassandra-4.1
#
git switch cassandra-4.1
git reset --hard origin/cassandra-4.1
git merge -s ours --log --no-edit CASSANDRA-18153-4.0
git cherry-pick -n 3584d17b36 && git commit -a --amend --no-edit # 3584d17b36
Save host id to system.local and flush immediately after startup
git cherry-pick -n e7b2ca37e6 && git commit -a --amend --no-edit # e7b2ca37e6
DO NOT MERGE - CircleCI config
git cherry-pick -n 85f3049e90 && git commit -a --amend --no-edit # 85f3049e90
fixes
grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\ *
Save host id to system.local and flush immediately after startup
(CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
git diff CHANGES.txt
git add CHANGES.txt
git commit --amend --no-edit
(git diff origin/cassandra-4.1..HEAD -- .circleci/ | git apply -R --index) &&
git commit -a --amend --no-edit # Remove all changes in .circleci directory if
you need to
git diff --name-only
[jira] [Updated] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[ https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18399: -- Change Category: Code Clarity Complexity: Low Hanging Fruit Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Add simple helper script for commiting a change to multiple branches > > > Key: CASSANDRA-18399 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18399 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Low > > This is just a simple additional script which committers can use to help them > merge commits, especially if the change applies to multiple Cassandra > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
Jacek Lewandowski created CASSANDRA-18399: - Summary: Add simple helper script for commiting a change to multiple branches Key: CASSANDRA-18399 URL: https://issues.apache.org/jira/browse/CASSANDRA-18399 Project: Cassandra Issue Type: Task Components: Build Reporter: Jacek Lewandowski Assignee: Jacek Lewandowski This is just a simple additional script which committers can use to help them merge commits, especially if the change applies to multiple Cassandra versions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705418#comment-17705418
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
[~samt] I'm basically ready to merge it, if you have any objections please let
me know. I know it is going to be largely overwritten by TCM, but we have to
have something for now.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 2h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705406#comment-17705406
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/27/23 3:33 PM:
the latest rerun of jvm dtests:
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/663/workflows/1c1c11a0-e202-4824-8a1b-995bb0d32a6a
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/664/workflows/0aced992-fb32-468c-85fb-183a8f5e240e
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/660/workflows/5daa9ea1-5c62-40bf-a3e9-80d8420c6f4c
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/660/workflows/56cf5ddc-5bfe-4c4d-809c-0eed7b88a13b
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/659/workflows/6f4cb147-11b1-40b7-a5b2-4f4ef3666ce3
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/659/workflows/aeb7abc6-b97d-4faf-9c43-d80419d23c08
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/661/workflows/8dce1230-b9ab-4b10-a87e-dec6548c1ce7
the only failing tests are those recognized as flakies
was (Author: jlewandowski):
the latest rerun of jvm dtests:
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/663/workflows/1c1c11a0-e202-4824-8a1b-995bb0d32a6a
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/664/workflows/0aced992-fb32-468c-85fb-183a8f5e240e
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/660/workflows/5daa9ea1-5c62-40bf-a3e9-80d8420c6f4c
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/660/workflows/56cf5ddc-5bfe-4c4d-809c-0eed7b88a13b
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/659/workflows/6f4cb147-11b1-40b7-a5b2-4f4ef3666ce3
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/659/workflows/aeb7abc6-b97d-4faf-9c43-d80419d23c08
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/661/workflows/8dce1230-b9ab-4b10-a87e-dec6548c1ce7
the only failing tests are those recognized as flakies
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 2h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705406#comment-17705406
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
the latest rerun of jvm dtests:
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/663/workflows/1c1c11a0-e202-4824-8a1b-995bb0d32a6a
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/664/workflows/0aced992-fb32-468c-85fb-183a8f5e240e
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/660/workflows/5daa9ea1-5c62-40bf-a3e9-80d8420c6f4c
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/660/workflows/56cf5ddc-5bfe-4c4d-809c-0eed7b88a13b
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/659/workflows/6f4cb147-11b1-40b7-a5b2-4f4ef3666ce3
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/659/workflows/aeb7abc6-b97d-4faf-9c43-d80419d23c08
11:20
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/661/workflows/8dce1230-b9ab-4b10-a87e-dec6548c1ce7
the only failing tests are those recognized as flakies
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 2h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18047) fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18047:
--
Fix Version/s: 4.1.x
5.0
> fix flaky
> o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
> -
>
> Key: CASSANDRA-18047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18047
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0
>
>
> This test was introduced by CASSANDRA-18029
>
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Repair
> session 864c53d0-61fe-11ed-935f-5103a8e332f7 for range
> [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error UNKNOWN failure
> response from /127.0.0.3:7012, Repair command #1 finished with error] at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> different error:
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Endpoint
> not alive: /127.0.0.3:7012, Repair command #1 finished with error]
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18047) fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18047:
--
Since Version: 4.1.x
> fix flaky
> o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
> -
>
> Key: CASSANDRA-18047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18047
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> This test was introduced by CASSANDRA-18029
>
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Repair
> session 864c53d0-61fe-11ed-935f-5103a8e332f7 for range
> [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error UNKNOWN failure
> response from /127.0.0.3:7012, Repair command #1 finished with error] at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> different error:
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Endpoint
> not alive: /127.0.0.3:7012, Repair command #1 finished with error]
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18047) fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18047:
--
Resolution: (was: Fixed)
Status: Open (was: Resolved)
> fix flaky
> o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
> -
>
> Key: CASSANDRA-18047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18047
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> This test was introduced by CASSANDRA-18029
>
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Repair
> session 864c53d0-61fe-11ed-935f-5103a8e332f7 for range
> [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error UNKNOWN failure
> response from /127.0.0.3:7012, Repair command #1 finished with error] at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> different error:
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Endpoint
> not alive: /127.0.0.3:7012, Repair command #1 finished with error]
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18047) fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705405#comment-17705405
]
Jacek Lewandowski commented on CASSANDRA-18047:
---
Here is a fresh rerun on the current {{cassandra-4.1}} branch -
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/665/workflows/54c999f3-5cef-4182-bd1b-e580072aaee4/jobs/7908/parallel-runs/8?filterBy=ALL
> fix flaky
> o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
> -
>
> Key: CASSANDRA-18047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18047
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> This test was introduced by CASSANDRA-18029
>
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Repair
> session 864c53d0-61fe-11ed-935f-5103a8e332f7 for range
> [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error UNKNOWN failure
> response from /127.0.0.3:7012, Repair command #1 finished with error] at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> different error:
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Endpoint
> not alive: /127.0.0.3:7012, Repair command #1 finished with error]
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18047) fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705356#comment-17705356
]
Jacek Lewandowski edited comment on CASSANDRA-18047 at 3/27/23 1:47 PM:
[~dcapwell] the test run you attached for CASSANDRA-18292 does not seem to
prove it resolved this issue -
https://app.circleci.com/pipelines/github/dcapwell/cassandra/1905/workflows/84ab75da-8b79-4236-bed6-7ec252d666cf/jobs/17205/tests
could you take a look once again? I noticed it failed on unrelated 4.1-based
feature branch
was (Author: jlewandowski):
[~dcapwell] the test run you attached does not seem to prove CASSANDRA-18292
was resolved with this fix -
https://app.circleci.com/pipelines/github/dcapwell/cassandra/1905/workflows/84ab75da-8b79-4236-bed6-7ec252d666cf/jobs/17205/tests
could you take a look once again? I noticed it failed on unrelated 4.1-based
feature branch
> fix flaky
> o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
> -
>
> Key: CASSANDRA-18047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18047
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> This test was introduced by CASSANDRA-18029
>
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Repair
> session 864c53d0-61fe-11ed-935f-5103a8e332f7 for range
> [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error UNKNOWN failure
> response from /127.0.0.3:7012, Repair command #1 finished with error] at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> different error:
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Endpoint
> not alive: /127.0.0.3:7012, Repair command #1 finished with error]
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18047) fix flaky o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705356#comment-17705356
]
Jacek Lewandowski commented on CASSANDRA-18047:
---
[~dcapwell] the test run you attached does not seem to prove CASSANDRA-18292
was resolved with this fix -
https://app.circleci.com/pipelines/github/dcapwell/cassandra/1905/workflows/84ab75da-8b79-4236-bed6-7ec252d666cf/jobs/17205/tests
could you take a look once again? I noticed it failed on unrelated 4.1-based
feature branch
> fix flaky
> o.a.c.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair
> -
>
> Key: CASSANDRA-18047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18047
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> This test was introduced by CASSANDRA-18029
>
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Repair
> session 864c53d0-61fe-11ed-935f-5103a8e332f7 for range
> [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error UNKNOWN failure
> response from /127.0.0.3:7012, Repair command #1 finished with error] at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> different error:
> {code:java}
> junit.framework.AssertionFailedError: Repair failed with errors: [Endpoint
> not alive: /127.0.0.3:7012, Repair command #1 finished with error]
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$repair$54f7d7c2$1(PaxosRepair2Test.java:186)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704480#comment-17704480 ] Jacek Lewandowski commented on CASSANDRA-18301: --- There is separate ticket https://issues.apache.org/jira/browse/CASSANDRA-8110 which I think is aiming to address that problem. That is, it will not allow to use the sstable format version higher than the lowest supported in the cluster. That would work for upgrades where we have mixed clusters. For the compatibility mode, which should be kept even after upgrade, so that the user retains its ability to downgrade - it is up to the user to setup Cassandra properly - it the user fails to setup compatibility mode on all the nodes - it is a misconfiguration. Though, we may do something to confirm that all the nodes use the same configuration. I suppose that TCM can help there. > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704297#comment-17704297 ] Jacek Lewandowski commented on CASSANDRA-18301: --- There is no way we will support writing at some version while not supporting reading in that version, so no worries in that regards. Mixed tables versions is allowed as a temporary state, just because of the performance considerations. Compaction, scrubbing, etc. - all of those tasks can read sstable at any supported version and they will produce an sstable in the write version. > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18301) Let the user select the sstable version to write
[
https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704151#comment-17704151
]
Jacek Lewandowski commented on CASSANDRA-18301:
---
You are right assuming we use the same configuration in yaml.
{quote}So, in general when a "compatibility mode" property is set we should
validate a startup that the rest of the config and its feature flags are
compatible with that choice. Does it makes sense?{quote}
yeah, that make sense to me
Let me summarize what I think:
We should have a separate option to control the sstables write format / version
(whether it is Cassandra version, exact version, some special value)
Do we all agree on that?
> Let the user select the sstable version to write
>
>
> Key: CASSANDRA-18301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18301
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Config, Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704003#comment-17704003
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
thanks [~samt] - the test takes that into account rather than rely on that. I
was initially confused that I needed to expect one more sstable that I thought.
Now the number of expected sstables match the number of flushes which is good I
think.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702463#comment-17702463
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/23/23 9:09 AM:
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
(/)
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
(/)
4.0 - [PR|https://github.com/apache/cassandra/pull/2231],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2373/]
(!),
fixed just two unit tests, so rerunning the unit tests only:
[regular|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test/1775/]
(/),
[cdc|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-cdc/1755/]
(!),
[compression|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-compression/1761/]
(/)
since some other unrelated unit test failed for CDC, I did repeatable runs in
[CircleCI|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/644/workflows/42afa702-4500-46f3-96d6-b2e14f5e1b75](/)
4.1 - [PR|https://github.com/apache/cassandra/pull/2232],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2378/]
(!)
there are failures in one jvm-dtest, the test was fixed and rerun in CircleCI,
[1|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/648/workflows/0ff558cc-e975-4646-90ee-762d374c/jobs/6437](/),
[2|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/648/workflows/0ff558cc-e975-4646-90ee-762d374c/jobs/6438]
(/),
[3|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/648/workflows/1aa7cde3-7845-4672-9a46-f177797e9f59/jobs/6441],
[4|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/648/workflows/1aa7cde3-7845-4672-9a46-f177797e9f59/jobs/6440]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2384/]
(?)
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
was (Author: jlewandowski):
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
(/)
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
(/)
4.0 - [PR|https://github.com/apache/cassandra/pull/2231],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2373/]
(!),
fixed just two unit tests, so rerunning the unit tests only:
[regular|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test/1775/]
(/),
[cdc|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-cdc/1755/]
(!),
[compression|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-compression/1761/]
(/)
since some other unrelated unit test failed for CDC, I did repeatable runs in
[CircleCI|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/644/workflows/42afa702-4500-46f3-96d6-b2e14f5e1b75](/)
4.1 - [PR|https://github.com/apache/cassandra/pull/2232],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2378/]
(?)
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
>
[jira] [Commented] (CASSANDRA-18301) Let the user select the sstable version to write
[
https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703982#comment-17703982
]
Jacek Lewandowski commented on CASSANDRA-18301:
---
CEP-17 made the formats configurable. In particular, when we have a situation
where someone upgrades 5.0 to 6.0, 5.0 supports both big and bti formats - it
is not only about version, but also the type of the format. Saying that we want
to be compatible in 6.0 with 5.0 does not tell us much about which format to
choose. That's why I think that we should be explicit.
Though, the format could be selected as say "compatible" which could mean that
we select the format and version (note that, not only the version) by
examining the existing sstables, in particular - selecting the format and
version of the newest sstable found in the storage. That should also make the
system fail to start if that format/version is not supported for writing.
I'm just saying that I'm rather -1 on configuring the storage so that sstables
should be compatible with exact Cassandra version. If we don't want to be that
explicit, I'm still thinking that we should rather say something like
{{compatible}}, {{oldest_supported}}, {{newest_supported}}.
> Let the user select the sstable version to write
>
>
> Key: CASSANDRA-18301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18301
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Config, Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703757#comment-17703757 ] Jacek Lewandowski commented on CASSANDRA-18301: --- [~bereng] what behaviour do you mean in particular? I'm not sure I'm in favour of making it work like that - specify the Cassandra version instead the exact sstable format version. I have my reasons: - we still don't know which format implementation was used in the previous version of Cassandra - the user may want to enable other features while keep the old sstables format version - after enabling other features but not bumping sstable format version, the user is still able to go back. Without enabling other new features, the user will not be able to evaluate a new version > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702463#comment-17702463
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/22/23 11:05 AM:
-
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
(/)
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
(/)
4.0 - [PR|https://github.com/apache/cassandra/pull/2231],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2373/]
(!),
fixed just two unit tests, so rerunning the unit tests only:
[regular|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test/1775/]
(/),
[cdc|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-cdc/1755/]
(!),
[compression|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-compression/1761/]
(/)
since some other unrelated unit test failed for CDC, I did repeatable runs in
[CircleCI|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/644/workflows/42afa702-4500-46f3-96d6-b2e14f5e1b75](/)
4.1 - [PR|https://github.com/apache/cassandra/pull/2232],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2378/]
(?)
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
was (Author: jlewandowski):
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
(/)
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
(/)
4.0 - [PR|https://github.com/apache/cassandra/pull/2231],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2373/]
(!),
fixed just two unit tests, so rerunning the unit tests only:
[regular|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test/1775/]
(/),
[cdc|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-cdc/1755/]
(!),
[compression|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-compression/1761/]
(/)
since some other unrelated unit test failed for CDC, I did repeatable runs in
[CircleCI|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/644/workflows/42afa702-4500-46f3-96d6-b2e14f5e1b75](/)
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702463#comment-17702463
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/22/23 10:43 AM:
-
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
(/)
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
(/)
4.0 - [PR|https://github.com/apache/cassandra/pull/2231],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2373/]
(!),
fixed just two unit tests, so rerunning the unit tests only:
[regular|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test/1775/]
(/),
[cdc|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-cdc/1755/]
(!),
[compression|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-compression/1761/]
(/)
since some other unrelated unit test failed for CDC, I did repeatable runs in
[CircleCI|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/644/workflows/42afa702-4500-46f3-96d6-b2e14f5e1b75](/)
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
was (Author: jlewandowski):
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
(/)
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
(/)
4.0 - [PR|https://github.com/apache/cassandra/pull/2231],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2373/]
(!), fixed just two unit tests, so rerunning the unit tests only:
[regular|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test/1775/]
(?),
[cdc|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-cdc/1755/]
(?),
[compression|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-compression/1761/]
(?)
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702463#comment-17702463
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/22/23 9:14 AM:
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
(/)
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
(/)
4.0 - [PR|https://github.com/apache/cassandra/pull/2231],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2373/]
(!), fixed just two unit tests, so rerunning the unit tests only:
[regular|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test/1775/]
(?),
[cdc|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-cdc/1755/]
(?),
[compression|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test-compression/1761/]
(?)
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
was (Author: jlewandowski):
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
(/)
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
(/)
4.0 - [PR|https://github.com/apache/cassandra/pull/2231],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2373/]
(?)
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702463#comment-17702463
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/21/23 9:42 AM:
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
(/)
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
(/)
4.0 - [PR|https://github.com/apache/cassandra/pull/2231],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2373/]
(?)
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
was (Author: jlewandowski):
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-17701:
--
Fix Version/s: 3.0.29
3.11.15
(was: 3.0.x)
(was: 3.11.x)
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/f6a04ca81f2d0d8973fb7a99569c118122c500a2
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.29, 3.11.15
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702754#comment-17702754
]
Jacek Lewandowski commented on CASSANDRA-17701:
---
thanks [~brandon.williams]
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702672#comment-17702672
]
Jacek Lewandowski commented on CASSANDRA-17701:
---
hmmm... you talking about this:
https://issues.apache.org/jira/browse/CASSANDRA-18156 ?
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702673#comment-17702673
]
Jacek Lewandowski commented on CASSANDRA-17701:
---
it seems like it is failing for some time already
https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-3.0/cassandra-3.0
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702463#comment-17702463
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/20/23 10:35 AM:
-
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
was (Author: jlewandowski):
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702463#comment-17702463
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/20/23 6:57 AM:
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
was (Author: jlewandowski):
3.0 - [PR|https://github.com/apache/cassandra/pull/2234]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702463#comment-17702463
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/20/23 6:55 AM:
3.0 - [PR|https://github.com/apache/cassandra/pull/2234]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
was (Author: jlewandowski):
3.0 - [PR|https://github.com/apache/cassandra/pull/2234]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702463#comment-17702463
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
3.0 - [PR|https://github.com/apache/cassandra/pull/2234]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702079#comment-17702079
]
Jacek Lewandowski commented on CASSANDRA-17701:
---
It seems like it is just a logging problem. In addition to the message that the
repair job had failed (which was expected), it logged separately a cancellation
exception.
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-17701:
--
Test and Documentation Plan: regression tests
Status: Patch Available (was: Open)
3.0 - https://github.com/apache/cassandra/pull/2229 -
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2355/
3.11 - https://github.com/apache/cassandra/pull/2230 -
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2356/
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski reassigned CASSANDRA-17701:
-
Assignee: Jacek Lewandowski
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701997#comment-17701997
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/628/workflows/93a1362e-f205-4d60-a46f-64fb375b695e
(3.0)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701986#comment-17701986
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
Tests show something interesting - {{CQLSSTableWriter}} - it is a client
application so it should not try to read data from sstables, in particular,
from {{system.local}}. It stored {{null}} as a host ID and I will leave it as
it is - that is, in order to fix the test, {{getLocalHostId}} will not go to
{{system.local}} if the system is running in client mode.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18153:
--
Reviewers: Sam Tunnicliffe, Stefan Miklosovic (was: Stefan Miklosovic)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18153:
--
Authors: Adriano Bonacin, Jacek Lewandowski (was: Adriano Bonacin)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701725#comment-17701725
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
Please have a look at these tests:
https://github.com/apache/cassandra-dtest/pull/216
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701598#comment-17701598
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
Unfortunately it will have to be a Python DTest, JVM dtests have its startup
code very different to what is really used when you start Cassandra.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701551#comment-17701551
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
Thank you for feedback. I'll try to add a dtest and address the missing host id
in metadata output.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18302: -- Source Control Link: https://github.com/apache/cassandra/commit/ef87a5ae224b12350a248e469bc3b42471490540 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18302: -- Status: Ready to Commit (was: Review In Progress) > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18193) Provide design and API documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18193:
--
Change Category: Code Clarity
Complexity: Challenging
Component/s: Documentation/Javadoc
Status: Open (was: Triage Needed)
> Provide design and API documentation
>
>
> Key: CASSANDRA-18193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18193
> Project: Cassandra
> Issue Type: Task
> Components: Accord, Documentation/Javadoc
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> Would be great if we have at minimum:
> - white paper in a form of an AsciiDoc or Markdown somewhere in the project
> tree
> - all interfaces and all methods in {{acccord.api}} have API docs explaining
> the requirements for the implementations
> - enums and their values across the project are documented
> - interfaces, abstract classes, or classes that do not inherit from anything
> in the project have at least some class level explanation
> Eventually, it would really awesome if concepts from the whitepaper are
> somehow referenced in the code (or vice-versa). It would make it much easier
> to understand the implementation and I believe it would improve reuse of this
> project for external applications
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18193) Provide design and API documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski reassigned CASSANDRA-18193:
-
Assignee: Jacek Lewandowski
> Provide design and API documentation
>
>
> Key: CASSANDRA-18193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18193
> Project: Cassandra
> Issue Type: Task
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> Would be great if we have at minimum:
> - white paper in a form of an AsciiDoc or Markdown somewhere in the project
> tree
> - all interfaces and all methods in {{acccord.api}} have API docs explaining
> the requirements for the implementations
> - enums and their values across the project are documented
> - interfaces, abstract classes, or classes that do not inherit from anything
> in the project have at least some class level explanation
> Eventually, it would really awesome if concepts from the whitepaper are
> somehow referenced in the code (or vice-versa). It would make it much easier
> to understand the implementation and I believe it would improve reuse of this
> project for external applications
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701019#comment-17701019 ] Jacek Lewandowski commented on CASSANDRA-18302: --- https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/623/workflows/d00ac385-5cad-4350-975d-39722fd7dd7f > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700856#comment-17700856
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
thanks [~samt], frankly the PR has only few locs :)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700855#comment-17700855 ] Jacek Lewandowski commented on CASSANDRA-18302: --- ok, done, please take a look > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700807#comment-17700807
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
[~samt] can I consider it as your review +1 on that?
[~smiklosovic] - are you ok with the fix?
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700806#comment-17700806 ] Jacek Lewandowski commented on CASSANDRA-18302: --- Ok guys, let me finish that - can I just remove storing the raw string (with the current version it will be trivial, just don't create the source text) and avoid printing strings entirely, letting the user to rely on line/position in line? > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700709#comment-17700709
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
I think it can be reviewed at this point.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18153:
--
Status: Patch Available (was: In Progress)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18043) remove deprecated DateTieredCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700697#comment-17700697 ] Jacek Lewandowski commented on CASSANDRA-18043: --- looks good to me +1 > remove deprecated DateTieredCompactionStrategy > -- > > Key: CASSANDRA-18043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18043 > Project: Cassandra > Issue Type: Task > Components: Local/Compaction/DTCS >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > DTCS was marked as deprecated in CASSANDRA-9666 which was released in 3.0.8 > and 3.8. If I get our deprecation policies right, we wait one major release > (4.0) and we can remove it in the next one (5.0). Having 4.1 about to be > released soon and 4.2 will be 5.0, I think nothing blocks us from removing > this strategy in trunk. > This also makes CASSANDRA-18042 easier as it would most probably have to > cover this strategy as well. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18043) remove deprecated DateTieredCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18043: -- Reviewers: Jacek Lewandowski > remove deprecated DateTieredCompactionStrategy > -- > > Key: CASSANDRA-18043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18043 > Project: Cassandra > Issue Type: Task > Components: Local/Compaction/DTCS >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > DTCS was marked as deprecated in CASSANDRA-9666 which was released in 3.0.8 > and 3.8. If I get our deprecation policies right, we wait one major release > (4.0) and we can remove it in the next one (5.0). Having 4.1 about to be > released soon and 4.2 will be 5.0, I think nothing blocks us from removing > this strategy in trunk. > This also makes CASSANDRA-18042 easier as it would most probably have to > cover this strategy as well. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700693#comment-17700693 ] Jacek Lewandowski commented on CASSANDRA-18302: --- I get you don't want to make it complex. I managed to simplify it significantly while keeping its benefits. In particular, I've managed to find a way to get a query source directly in the parser and pass it to the prepared statement. Therefore, all that stuff with setting the raw text and then extracting a relevant part of it is now gone. > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
