[jira] [Comment Edited] (CASSANDRA-15876) Accessors for SystemProperties
[
https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180169#comment-17180169
]
Ekaterina Dimitrova edited comment on CASSANDRA-15876 at 8/18/20, 11:41 PM:
Great, thank you for the fast response [~dcapwell] , as we talked on Slack I
will remove the functions (left just because of the initial request but I also
don't like them) and do a cleanup now when we agreed on the format.
Also, I will open a new ticket for the other
{code:java}
name.startsWith(Config.PROPERTY_PREFIX){code}
properties and complete this work as per the initial request. Thus, as you
also pointed this work will be more incremental and less prone to errors, also
someone else might want to take over on the additional patch when he/she has
free cycles.
was (Author: e.dimitrova):
Great, thank you for the fast response [~dcapwell] , as we talked on Slack I
will remove the functions (left just because of the initial request but I also
don't like them) and do a cleanup now when we agreed on the format.
Also, I will open a new ticket for the other
name.startsWith(Config.PROPERTY_PREFIX)
properties and complete this work as per the initial request. Thus, as you also
pointed this work will be more incremental and less prone to errors, also
someone else might want to take over on the additional patch when he/she has
free cycles.
> Accessors for SystemProperties
> --
>
> Key: CASSANDRA-15876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15876
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> As part of CASSANDRA-15234, it was suggested a class of accessors for System
> properties to be created for better clarity and maintainability.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180169#comment-17180169 ] Ekaterina Dimitrova commented on CASSANDRA-15876: - Great, thank you for the fast response [~dcapwell] , as we talked on Slack I will remove the functions (left just because of the initial request but I also don't like them) and do a cleanup now when we agreed on the format. Also, I will open a new ticket for the other name.startsWith(Config.PROPERTY_PREFIX) properties and complete this work as per the initial request. Thus, as you also pointed this work will be more incremental and less prone to errors, also someone else might want to take over on the additional patch when he/she has free cycles. > Accessors for SystemProperties > -- > > Key: CASSANDRA-15876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15876 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0, 4.0-beta > > > As part of CASSANDRA-15234, it was suggested a class of accessors for System > properties to be created for better clarity and maintainability. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180164#comment-17180164 ] David Capwell commented on CASSANDRA-15876: --- * Since you are using getter, should make the field private: https://github.com/ekaterinadimitrova2/cassandra/commit/a269216be895995de36de765e22cc0fd53b20115#diff-67567e4c45fc05832fecc525f2a08be0R42 * Same, should use private https://github.com/ekaterinadimitrova2/cassandra/commit/a269216be895995de36de765e22cc0fd53b20115#diff-aa726f08e6baa983bcd860797e60d8a2R88 * nit: rather than convert default before calling method, why not do it If-and-only-if default is accessed? It unifies the conversation logic (int has 2 different logics to convert). https://github.com/ekaterinadimitrova2/cassandra/commit/a269216be895995de36de765e22cc0fd53b20115#diff-aa726f08e6baa983bcd860797e60d8a2R122 * Make all the converters private, the interface is but the field isn't: https://github.com/ekaterinadimitrova2/cassandra/commit/a269216be895995de36de765e22cc0fd53b20115#diff-aa726f08e6baa983bcd860797e60d8a2R136 * This is my personal preference, so not a blocker. I feel that we should remove the functions in favor of just hitting the enum. I feel that over time people won't add the functions, it will cause confusion "which one should I use", and makes the code more verbose. https://github.com/ekaterinadimitrova2/cassandra/commit/a269216be895995de36de765e22cc0fd53b20115#diff-aa726f08e6baa983bcd860797e60d8a2R151 Getting pulled away, ill look at the other changes in a bit > Accessors for SystemProperties > -- > > Key: CASSANDRA-15876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15876 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0, 4.0-beta > > > As part of CASSANDRA-15234, it was suggested a class of accessors for System > properties to be created for better clarity and maintainability. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15876) Accessors for SystemProperties
[
https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180152#comment-17180152
]
Ekaterina Dimitrova edited comment on CASSANDRA-15876 at 8/18/20, 11:03 PM:
I implemented the requested suggestions [here
|https://github.com/ekaterinadimitrova2/cassandra/commit/a269216be895995de36de765e22cc0fd53b20115]
(only I have to get rid of the sets in a new commit plus a couple of nits(like
code format and correct
{code:java}
getBoolean() {code}
method to consider also user provided default values)) but on a further
discussion with [~mck] today, we thought that it would be good to add also all
options which
{code:java}
name.startsWith(Config.PROPERTY_PREFIX)
{code}
to
{code:java}
CassandraRelevantProperties
{code}
. Then when the virtual table is listed we can log a warning if there are
options which
{code:java}
name.startsWith(Config.PROPERTY_PREFIX)
{code}
if they are not found in
{code:java}
CassandraRelevantProperties{code}
. Also, I think to add maybe a unit test which checks for options which are not
in the enum and breaks if we find options,
{code:java}
name.startsWith(Config.PROPERTY_PREFIX){code}
which are not included in SystemPropertiesTable. [~dcapwell], WDYT? If you
agree with that I will proceed adding the rest of the properties, warning and
tests mentioned.
I think that will be a good way to enforce the C* developers to use this
framework so we have everything at one place, easier to maintain.
was (Author: e.dimitrova):
I implemented the requested suggestions [here
|https://github.com/ekaterinadimitrova2/cassandra/commit/a269216be895995de36de765e22cc0fd53b20115]
(only I have to get rid of the sets in a new commit plus a couple of nits) but
on a further discussion with [~mck] today, we thought that it would be good to
add also all options which
{code:java}
name.startsWith(Config.PROPERTY_PREFIX)
{code}
to
{code:java}
CassandraRelevantProperties
{code}
. Then when the virtual table is listed we can log a warning if there are
options which
{code:java}
name.startsWith(Config.PROPERTY_PREFIX)
{code}
if they are not found in
{code:java}
CassandraRelevantProperties{code}
. Also, I think to add maybe a unit test which checks for options which are not
in the enum and breaks if we find options,
{code:java}
name.startsWith(Config.PROPERTY_PREFIX){code}
which are not included in SystemPropertiesTable. [~dcapwell], WDYT? If you
agree with that I will proceed adding the rest of the properties, warning and
tests mentioned.
I think that will be a good way to enforce the C* developers to use this
framework so we have everything at one place, easier to maintain.
> Accessors for SystemProperties
> --
>
> Key: CASSANDRA-15876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15876
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> As part of CASSANDRA-15234, it was suggested a class of accessors for System
> properties to be created for better clarity and maintainability.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15876) Accessors for SystemProperties
[
https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180152#comment-17180152
]
Ekaterina Dimitrova commented on CASSANDRA-15876:
-
I implemented the requested suggestions [here
|https://github.com/ekaterinadimitrova2/cassandra/commit/a269216be895995de36de765e22cc0fd53b20115]
(only I have to get rid of the sets in a new commit plus a couple of nits) but
on a further discussion with [~mck] today, we thought that it would be good to
add also all options which
{code:java}
name.startsWith(Config.PROPERTY_PREFIX)
{code}
to
{code:java}
CassandraRelevantProperties
{code}
. Then when the virtual table is listed we can log a warning if there are
options which
{code:java}
name.startsWith(Config.PROPERTY_PREFIX)
{code}
if they are not found in
{code:java}
CassandraRelevantProperties{code}
. Also, I think to add maybe a unit test which checks for options which are not
in the enum and breaks if we find options,
{code:java}
name.startsWith(Config.PROPERTY_PREFIX){code}
which are not included in SystemPropertiesTable. [~dcapwell], WDYT? If you
agree with that I will proceed adding the rest of the properties, warning and
tests mentioned.
I think that will be a good way to enforce the C* developers to use this
framework so we have everything at one place, easier to maintain.
> Accessors for SystemProperties
> --
>
> Key: CASSANDRA-15876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15876
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> As part of CASSANDRA-15234, it was suggested a class of accessors for System
> properties to be created for better clarity and maintainability.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[ https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-16054: Source Control Link: https://github.com/apache/cassandra/commit/1575649888ec2632e02e5199bd57fb7de274d561 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed to 3.0 and merged up to 3.11 and trunk (which is a no-op because the test has been removed in trunk). Commit: https://github.com/apache/cassandra/commit/1575649888ec2632e02e5199bd57fb7de274d561 > Regression Test for Compact Storage Upgrades When Table Has Clustering and > Value Column > > > Key: CASSANDRA-16054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16054 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Add a regression test that shows that dropping compact storage on tables that > have clustering columns and a value column defined are safe after upgrading > sstables in 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[ https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-16054: Status: Ready to Commit (was: Review In Progress) Tests passed. The only failing test was a known SASI flaky unit test. > Regression Test for Compact Storage Upgrades When Table Has Clustering and > Value Column > > > Key: CASSANDRA-16054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16054 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Add a regression test that shows that dropping compact storage on tables that > have clustering columns and a value column defined are safe after upgrading > sstables in 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (e2ecdf2 -> 1575649)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e2ecdf2 Remove broken "defragment-on-read" optimization add 1575649 Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column No new revisions were added by this update. Summary of changes: .../upgrade/CompactStorage2to3UpgradeTest.java | 257 - 1 file changed, 256 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (14d1e3e -> d8432f1)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 14d1e3e Fix communication between versions 3 and 4 in upgrade JVM DTests add 1575649 Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column add 7d2d250 Merge branch 'cassandra-3.0' into cassandra-3.11 new d8432f1 Merge branch 'cassandra-3.11' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (ecd23f1 -> 7d2d250)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ecd23f1 Merge commit 'e2ecdf268a82fa3ac0f4c9fe77ab35bca33cc72a' into cassandra-3.11 add 1575649 Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column add 7d2d250 Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: .../upgrade/CompactStorage2to3UpgradeTest.java | 260 - 1 file changed, 257 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. jwest pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d8432f1ad64ee456be34d1e26928e678c0b56906 Merge: 14d1e3e 7d2d250 Author: Jordan West AuthorDate: Tue Aug 18 15:06:52 2020 -0700 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16055) StorageService exposes ensureTraceKeyspace that is used by jvm-dtest, but it should be removed and use MigrationManager.evolveSystemKeyspace instead
[ https://issues.apache.org/jira/browse/CASSANDRA-16055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180124#comment-17180124 ] David Capwell commented on CASSANDRA-16055: --- removing myself as I don't have the time. > StorageService exposes ensureTraceKeyspace that is used by jvm-dtest, but it > should be removed and use MigrationManager.evolveSystemKeyspace instead > > > Key: CASSANDRA-16055 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16055 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Priority: Normal > > Jvm dtest uses StorageService.ensureTraceKeyspace to register the tracing > keyspace, but doesn’t register the other distributed key spaces. This method > should not be used by dtest and instead should use > MigrationManager.evolveSystemKeyspace as it registers all keyspaces -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16055) StorageService exposes ensureTraceKeyspace that is used by jvm-dtest, but it should be removed and use MigrationManager.evolveSystemKeyspace instead
[ https://issues.apache.org/jira/browse/CASSANDRA-16055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-16055: - Assignee: (was: David Capwell) > StorageService exposes ensureTraceKeyspace that is used by jvm-dtest, but it > should be removed and use MigrationManager.evolveSystemKeyspace instead > > > Key: CASSANDRA-16055 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16055 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Priority: Normal > > Jvm dtest uses StorageService.ensureTraceKeyspace to register the tracing > keyspace, but doesn’t register the other distributed key spaces. This method > should not be used by dtest and instead should use > MigrationManager.evolveSystemKeyspace as it registers all keyspaces -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15406) Show the progress of data streaming and index build
[ https://issues.apache.org/jira/browse/CASSANDRA-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180122#comment-17180122 ] David Capwell commented on CASSANDRA-15406: --- [~blerer] still planning to review? I am almost ready to +1 this so would be good to get a second review. Speaking to [~stefan.miklosovic] in Slack he was planning to adding bootstrap into the test, this would get a good addition (make sure to put into its own class file to avoid CI test timeout) > Show the progress of data streaming and index build > > > Key: CASSANDRA-15406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15406 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming, Legacy/Streaming and Messaging, > Tool/nodetool >Reporter: maxwellguo >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0, 4.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > I found that we should supply a command to show the progress of streaming > when we do the operation of bootstrap/move/decommission/removenode. For when > do data streaming , noboday knows which steps there program are in , so I > think a command to show the joing/leaving node's is needed . > > PR [https://github.com/apache/cassandra/pull/558] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15406) Show the progress of data streaming and index build
[ https://issues.apache.org/jira/browse/CASSANDRA-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180121#comment-17180121 ] David Capwell commented on CASSANDRA-15406: --- Ok finally did a full pass and overall LGTM. I left a few small comments in GitHub and ran the logic with lower resources in a loop to show it was stable. bq. I am getting this exception randomly and test fail. Seems to be interal error of Cassandra during streaming / repair. The logs given don't show the test failing (at least I couldn't find it), all the errors thrown were during shutdown which makes sense (if the instance is shutting down there will be many different subsystems throwing since our shutdown isn't that clean). I suspect that the issue was that you run repair in the background and block waiting on streaming. If repair takes more than 1m to complete the stream then the test would get a timeout and fail (though don't see the logs showing this). In GH I recommended using nodetool repair and that will block the test, so you don't wait on streaming as much; with this change I couldn't get the test to fail running in a loop with lower resources. > Show the progress of data streaming and index build > > > Key: CASSANDRA-15406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15406 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming, Legacy/Streaming and Messaging, > Tool/nodetool >Reporter: maxwellguo >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0, 4.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > I found that we should supply a command to show the progress of streaming > when we do the operation of bootstrap/move/decommission/removenode. For when > do data streaming , noboday knows which steps there program are in , so I > think a command to show the joing/leaving node's is needed . > > PR [https://github.com/apache/cassandra/pull/558] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16059) Add Documentation on Running In-JVM DTest Upgrade Tests
Jordan West created CASSANDRA-16059: --- Summary: Add Documentation on Running In-JVM DTest Upgrade Tests Key: CASSANDRA-16059 URL: https://issues.apache.org/jira/browse/CASSANDRA-16059 Project: Cassandra Issue Type: Improvement Reporter: Jordan West Assignee: Jordan West Its helpful to have some documentation on how to easily set up and run in-jvm dtest upgrade tests locally -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16058) Include ant dtest-jar target in IntelliJ Testing Builds/Runs
Jordan West created CASSANDRA-16058: --- Summary: Include ant dtest-jar target in IntelliJ Testing Builds/Runs Key: CASSANDRA-16058 URL: https://issues.apache.org/jira/browse/CASSANDRA-16058 Project: Cassandra Issue Type: Improvement Reporter: Jordan West Assignee: Jordan West When running in-jvm dtest upgrade tests from inside IntelliJ, if the developer makes changes and does not re-run “ant dtest-jar” the changes will not be visible to the test. This can be fixed by manually running the command or manually adding the ant target to the IntelliJ pre-launch configuration for the test. We can do this automatically as well by modifying the `ide/idea` settings. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15802) Commented-out lines that end in a semicolon cause an error.
[ https://issues.apache.org/jira/browse/CASSANDRA-15802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15802: --- Status: Ready to Commit (was: Review In Progress) > Commented-out lines that end in a semicolon cause an error. > --- > > Key: CASSANDRA-15802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15802 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter, CQL/Syntax >Reporter: null >Assignee: Rens Groothuijsen >Priority: Normal > Attachments: cqlsh.png > > Time Spent: 40m > Remaining Estimate: 0h > > Commented-out lines that end in a semicolon cause an error. > For example: > /* > describe keyspaces; > */ > > This produces an error: > SyntaxException: line 2:22 no viable alternative at input ' (...* > describe keyspaces;...) > > It works as expected if you use syntax: > -- describe keyspaces; > > Environment: > python:3.7.7-slim-stretch (docker image) > > I found that this was first seen here, and was patched, but the bug appears > to have resurfaced: > https://issues.apache.org/jira/browse/CASSANDRA-2488 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15802) Commented-out lines that end in a semicolon cause an error.
[ https://issues.apache.org/jira/browse/CASSANDRA-15802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15802: --- Fix Version/s: 4.0-beta > Commented-out lines that end in a semicolon cause an error. > --- > > Key: CASSANDRA-15802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15802 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter, CQL/Syntax >Reporter: null >Assignee: Rens Groothuijsen >Priority: Normal > Fix For: 4.0-beta > > Attachments: cqlsh.png > > Time Spent: 40m > Remaining Estimate: 0h > > Commented-out lines that end in a semicolon cause an error. > For example: > /* > describe keyspaces; > */ > > This produces an error: > SyntaxException: line 2:22 no viable alternative at input ' (...* > describe keyspaces;...) > > It works as expected if you use syntax: > -- describe keyspaces; > > Environment: > python:3.7.7-slim-stretch (docker image) > > I found that this was first seen here, and was patched, but the bug appears > to have resurfaced: > https://issues.apache.org/jira/browse/CASSANDRA-2488 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15802) Commented-out lines that end in a semicolon cause an error.
[ https://issues.apache.org/jira/browse/CASSANDRA-15802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15802: --- Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Michael Semb Wever, Michael Semb Wever Status: Review In Progress (was: Patch Available) > Commented-out lines that end in a semicolon cause an error. > --- > > Key: CASSANDRA-15802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15802 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter, CQL/Syntax >Reporter: null >Assignee: Rens Groothuijsen >Priority: Normal > Attachments: cqlsh.png > > Time Spent: 40m > Remaining Estimate: 0h > > Commented-out lines that end in a semicolon cause an error. > For example: > /* > describe keyspaces; > */ > > This produces an error: > SyntaxException: line 2:22 no viable alternative at input ' (...* > describe keyspaces;...) > > It works as expected if you use syntax: > -- describe keyspaces; > > Environment: > python:3.7.7-slim-stretch (docker image) > > I found that this was first seen here, and was patched, but the bug appears > to have resurfaced: > https://issues.apache.org/jira/browse/CASSANDRA-2488 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[ https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180100#comment-17180100 ] Jordan West commented on CASSANDRA-16054: - [3.11 branch | https://github.com/jrwest/cassandra/tree/jwest/16054-3.11] > Regression Test for Compact Storage Upgrades When Table Has Clustering and > Value Column > > > Key: CASSANDRA-16054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16054 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Add a regression test that shows that dropping compact storage on tables that > have clustering columns and a value column defined are safe after upgrading > sstables in 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[ https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180100#comment-17180100 ] Jordan West edited comment on CASSANDRA-16054 at 8/18/20, 9:01 PM: --- [3.11 branch | https://github.com/jrwest/cassandra/tree/jwest/16054-3.11] [tests | https://app.circleci.com/pipelines/github/jrwest/cassandra?branch=jwest%2F16054-3.11] was (Author: jrwest): [3.11 branch | https://github.com/jrwest/cassandra/tree/jwest/16054-3.11] > Regression Test for Compact Storage Upgrades When Table Has Clustering and > Value Column > > > Key: CASSANDRA-16054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16054 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Add a regression test that shows that dropping compact storage on tables that > have clustering columns and a value column defined are safe after upgrading > sstables in 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16057) Should update in-jvm dtest to expose stdout and stderr for nodetool
David Capwell created CASSANDRA-16057: - Summary: Should update in-jvm dtest to expose stdout and stderr for nodetool Key: CASSANDRA-16057 URL: https://issues.apache.org/jira/browse/CASSANDRA-16057 Project: Cassandra Issue Type: Improvement Components: Test/dtest Reporter: David Capwell Many nodetool commands output to stdout or stderr so running nodetool using in-jvm dtest should expose that to tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[ https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16054: Status: Review In Progress (was: Changes Suggested) > Regression Test for Compact Storage Upgrades When Table Has Clustering and > Value Column > > > Key: CASSANDRA-16054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16054 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Add a regression test that shows that dropping compact storage on tables that > have clustering columns and a value column defined are safe after upgrading > sstables in 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[ https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180094#comment-17180094 ] Caleb Rackliffe commented on CASSANDRA-16054: - +1 > Regression Test for Compact Storage Upgrades When Table Has Clustering and > Value Column > > > Key: CASSANDRA-16054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16054 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Add a regression test that shows that dropping compact storage on tables that > have clustering columns and a value column defined are safe after upgrading > sstables in 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15406) Show the progress of data streaming and index build
[ https://issues.apache.org/jira/browse/CASSANDRA-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180074#comment-17180074 ] David Capwell commented on CASSANDRA-15406: --- bq. We have done it without the need to release dtest api Yep, the work around lets us not have to worry about this, but long term we should move this logic into the api > Show the progress of data streaming and index build > > > Key: CASSANDRA-15406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15406 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming, Legacy/Streaming and Messaging, > Tool/nodetool >Reporter: maxwellguo >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0, 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I found that we should supply a command to show the progress of streaming > when we do the operation of bootstrap/move/decommission/removenode. For when > do data streaming , noboday knows which steps there program are in , so I > think a command to show the joing/leaving node's is needed . > > PR [https://github.com/apache/cassandra/pull/558] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[
https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180072#comment-17180072
]
Jordan West commented on CASSANDRA-16054:
-
Thanks [~maedhroz]! Pushed a new commit (will squash) with some updates based
on your review. Some comments below:
* I wanted to use a cluster because of the schema agreement reason you noticed
as well as wanting to test the entire stack for how it behaved in this state,
not just the local engine. The upgradesstables call is there because the test
is only meant to show these guarantees hold after its been run.
* I've made the suggested changes to
{{testDropCompactWithClusteringAndValueColumn,}}
{{testDropCompactWithClusteringAndValueColumnWithDeletesAndWrites}}, along with
some of your other suggestions.
* The visibility changes in {{AbstractCluster}} and
{{DelegatingInvokableInstance}} were from another test. I've removed them.
Since I'm not modifying the files anymore I didn't remove the import of
{{org.apache.cassandra.distributed.shared.NetworkTopology}} in
{{DelegatingInvokableInstance}}
{quote}Both tests issue coordinator queries at CL=ONE rather than using
executeInternal(). Are we guaranteed that the former can't hit the wrong node?
{quote}
That is my understanding.
> Regression Test for Compact Storage Upgrades When Table Has Clustering and
> Value Column
>
>
> Key: CASSANDRA-16054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16054
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> Add a regression test that shows that dropping compact storage on tables that
> have clustering columns and a value column defined are safe after upgrading
> sstables in 3.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15406) Show the progress of data streaming and index build
[ https://issues.apache.org/jira/browse/CASSANDRA-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180061#comment-17180061 ] Stefan Miklosovic commented on CASSANDRA-15406: --- We have done it without the need to release dtest api I am getting this exception randomly and test fail. Seems to be interal error of Cassandra during streaming / repair. [https://gist.githubusercontent.com/smiklosovic/1ad5d7d356e880611d47b37edce9b933/raw/1992ab56415d25d629a09393ef4392da66fa7825/NetstatsTest.java] > Show the progress of data streaming and index build > > > Key: CASSANDRA-15406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15406 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming, Legacy/Streaming and Messaging, > Tool/nodetool >Reporter: maxwellguo >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0, 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I found that we should supply a command to show the progress of streaming > when we do the operation of bootstrap/move/decommission/removenode. For when > do data streaming , noboday knows which steps there program are in , so I > think a command to show the joing/leaving node's is needed . > > PR [https://github.com/apache/cassandra/pull/558] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16039) FQL replay should have options to ignore DDL statements
[ https://issues.apache.org/jira/browse/CASSANDRA-16039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180058#comment-17180058 ] David Capwell commented on CASSANDRA-16039: --- LGTM +1 > FQL replay should have options to ignore DDL statements > --- > > Key: CASSANDRA-16039 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16039 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: David Capwell >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 0.5h > Remaining Estimate: 0h > > FQL logs will contain DDL statements made on the host, and the replay tool > will attempt to replay them; this can be unsafe in general so should have an > option to filter them out. > Thinking about it, since DDL replay isn’t obvious, we should most likely > default to false and have a flag to allow DDL replay as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16039) FQL replay should have options to ignore DDL statements
[ https://issues.apache.org/jira/browse/CASSANDRA-16039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180057#comment-17180057 ] David Capwell commented on CASSANDRA-16039: --- bq. I have not done anything with return codes, this type of change is not trivial and I do not know how to go about it Thats fine, just was not expected; would prefer a different ticket handles that and not this. bq. In theory I agree that if all queries fail, return code should not be 0, but in order to implement these changes we would need to change a lot of internals and this ticket is not about that issue No worries, I am 100% fine with a different ticket answer this question, this ticket should only have to focus on that single flag. > FQL replay should have options to ignore DDL statements > --- > > Key: CASSANDRA-16039 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16039 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: David Capwell >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 0.5h > Remaining Estimate: 0h > > FQL logs will contain DDL statements made on the host, and the replay tool > will attempt to replay them; this can be unsafe in general so should have an > option to filter them out. > Thinking about it, since DDL replay isn’t obvious, we should most likely > default to false and have a flag to allow DDL replay as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[ https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16054: Fix Version/s: 3.11.x 3.0.x > Regression Test for Compact Storage Upgrades When Table Has Clustering and > Value Column > > > Key: CASSANDRA-16054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16054 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Add a regression test that shows that dropping compact storage on tables that > have clustering columns and a value column defined are safe after upgrading > sstables in 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15802) Commented-out lines that end in a semicolon cause an error.
[ https://issues.apache.org/jira/browse/CASSANDRA-15802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180039#comment-17180039 ] Michael Semb Wever commented on CASSANDRA-15802: Oh, ok. No worries, have aborted that one, new run [here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/250/pipeline]. > Commented-out lines that end in a semicolon cause an error. > --- > > Key: CASSANDRA-15802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15802 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter, CQL/Syntax >Reporter: null >Assignee: Rens Groothuijsen >Priority: Normal > Attachments: cqlsh.png > > Time Spent: 40m > Remaining Estimate: 0h > > Commented-out lines that end in a semicolon cause an error. > For example: > /* > describe keyspaces; > */ > > This produces an error: > SyntaxException: line 2:22 no viable alternative at input ' (...* > describe keyspaces;...) > > It works as expected if you use syntax: > -- describe keyspaces; > > Environment: > python:3.7.7-slim-stretch (docker image) > > I found that this was first seen here, and was patched, but the bug appears > to have resurfaced: > https://issues.apache.org/jira/browse/CASSANDRA-2488 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[
https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180028#comment-17180028
]
Caleb Rackliffe commented on CASSANDRA-16054:
-
[~jwest] Made a first pass at review...
*General Impressions*
* Dropping COMPACT STORAGE seems like mostly a concern for the local storage
engine, so my initial reaction to having even a 2-node cluster was that it
might not be strictly necessary. Reading further, I see that we're looking at
operational scenarios like schema not being in agreement, so I suppose a
cluster makes sense if we're worried about that somehow confusing the
coordinator. (I'm also not sure if we strictly need to query both coordinators
post-drop, but perhaps that would only be a real problem if we were executing
many more queries.)
* In {{testDropCompactWithClusteringAndValueColumn}}, it might be interesting
to test a range query on the last clustering key and include a query or two
that return no results by design.
* In {{testDropCompactWithClusteringAndValueColumnWithDeletesAndWrites}}, was
the intent to write new partitions, or just overwrite some of the partitions
from the first set of 10? Testing a range delete might be interesting, but we
might need to add a second clustering key?
*Minor Things *
* {{import org.apache.cassandra.distributed.shared.NetworkTopology}} looks
unused in {{DelegatingInvokableInstance}}
* Were the field visibility changes in {{AbstractCluster}} and
{{DelegatingInvokableInstance}} necessary?
* {{preUpgradeResults}} can be final in {{DropCompactTestHelper}}
* {{DropCompactTestHelper}} could be named something like {{ResultRecorder}}
(class) / {{recorder}} (local). (My guess is that this construct might end up
being used more and more as we add upgrade tests?) It might even make sense to
move things like {{validateResults()}} into it, and you'd have the beginnings
of a "differ" / "validator" that you can populate however you want and then
throw other clusters at.
* Both tests issue coordinator queries at CL=ONE rather than using
{{executeInternal()}}. Are we guaranteed that the former can't hit the wrong
node?
* We might be able to factor out the {{upgradesstables}} call from the two new
tests.
> Regression Test for Compact Storage Upgrades When Table Has Clustering and
> Value Column
>
>
> Key: CASSANDRA-16054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16054
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
>
> Add a regression test that shows that dropping compact storage on tables that
> have clustering columns and a value column defined are safe after upgrading
> sstables in 3.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[ https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16054: Status: Changes Suggested (was: Review In Progress) > Regression Test for Compact Storage Upgrades When Table Has Clustering and > Value Column > > > Key: CASSANDRA-16054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16054 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > Add a regression test that shows that dropping compact storage on tables that > have clustering columns and a value column defined are safe after upgrading > sstables in 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[
https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180028#comment-17180028
]
Caleb Rackliffe edited comment on CASSANDRA-16054 at 8/18/20, 7:29 PM:
---
[~jwest] Made a first pass at review...
*General Impressions*
* Dropping COMPACT STORAGE seems like mostly a concern for the local storage
engine, so my initial reaction to having even a 2-node cluster was that it
might not be strictly necessary. Reading further, I see that we're looking at
operational scenarios like schema not being in agreement, so I suppose a
cluster makes sense if we're worried about that somehow confusing the
coordinator. (I'm also not sure if we strictly need to query both coordinators
post-drop, but perhaps that would only be a real problem if we were executing
many more queries.) If this were a unit test, I might try to isolate something
like the behavior w/ a schema mismatch in its own test, but I know our
threshold for that kind of thing is higher when spinning up a new cluster (even
in-JVM) isn't free :)
* In {{testDropCompactWithClusteringAndValueColumn}}, it might be interesting
to test a range query on the last clustering key and include a query or two
that return no results by design.
* In {{testDropCompactWithClusteringAndValueColumnWithDeletesAndWrites}}, was
the intent to write new partitions, or just overwrite some of the partitions
from the first set of 10? Testing a range delete might be interesting, but we
might need to add a second clustering key?
*Minor Things *
* {{import org.apache.cassandra.distributed.shared.NetworkTopology}} looks
unused in {{DelegatingInvokableInstance}}
* Were the field visibility changes in {{AbstractCluster}} and
{{DelegatingInvokableInstance}} necessary?
* {{preUpgradeResults}} can be final in {{DropCompactTestHelper}}
* {{DropCompactTestHelper}} could be named something like {{ResultRecorder}}
(class) / {{recorder}} (local). (My guess is that this construct might end up
being used more and more as we add upgrade tests?) It might even make sense to
move things like {{validateResults()}} into it, and you'd have the beginnings
of a "differ" / "validator" that you can populate however you want and then
throw other clusters at.
* Both tests issue coordinator queries at CL=ONE rather than using
{{executeInternal()}}. Are we guaranteed that the former can't hit the wrong
node?
* We might be able to factor out the {{upgradesstables}} call from the two new
tests.
was (Author: maedhroz):
[~jwest] Made a first pass at review...
*General Impressions*
* Dropping COMPACT STORAGE seems like mostly a concern for the local storage
engine, so my initial reaction to having even a 2-node cluster was that it
might not be strictly necessary. Reading further, I see that we're looking at
operational scenarios like schema not being in agreement, so I suppose a
cluster makes sense if we're worried about that somehow confusing the
coordinator. (I'm also not sure if we strictly need to query both coordinators
post-drop, but perhaps that would only be a real problem if we were executing
many more queries.)
* In {{testDropCompactWithClusteringAndValueColumn}}, it might be interesting
to test a range query on the last clustering key and include a query or two
that return no results by design.
* In {{testDropCompactWithClusteringAndValueColumnWithDeletesAndWrites}}, was
the intent to write new partitions, or just overwrite some of the partitions
from the first set of 10? Testing a range delete might be interesting, but we
might need to add a second clustering key?
*Minor Things *
* {{import org.apache.cassandra.distributed.shared.NetworkTopology}} looks
unused in {{DelegatingInvokableInstance}}
* Were the field visibility changes in {{AbstractCluster}} and
{{DelegatingInvokableInstance}} necessary?
* {{preUpgradeResults}} can be final in {{DropCompactTestHelper}}
* {{DropCompactTestHelper}} could be named something like {{ResultRecorder}}
(class) / {{recorder}} (local). (My guess is that this construct might end up
being used more and more as we add upgrade tests?) It might even make sense to
move things like {{validateResults()}} into it, and you'd have the beginnings
of a "differ" / "validator" that you can populate however you want and then
throw other clusters at.
* Both tests issue coordinator queries at CL=ONE rather than using
{{executeInternal()}}. Are we guaranteed that the former can't hit the wrong
node?
* We might be able to factor out the {{upgradesstables}} call from the two new
tests.
> Regression Test for Compact Storage Upgrades When Table Has Clustering and
> Value Column
>
>
> Key: CASSANDRA-16054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16054
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180022#comment-17180022
]
Jordan West commented on CASSANDRA-16048:
-
Thanks for the input [~slebresne]. I was hoping you would chime in.
I'm currently working on a plan for migrating a rather large fleet off of
{{COMPACT STORAGE}} and found this approach to reduce the burden significantly
(my findings are that the "shape" of COMPACT STORAGE table addressed by this
patch is very common). Each additional out of band process that needs to be
performed before the upgrade adds to the burden of moving to 4.0 and having a
safe way that operators don't have to think about is helpful. However, I do
agree its unfortunate we can't do this for all COMPACT STORAGE tables so that
we have a unified story and I am +1 on the documentation reading something like
to "you should drop COMPACT STORAGE manually by yourself before upgrading to
4.0 -- see CASSANDRA-16048 for potential alternatives".
Regarding the DENSE flag, this is the same as if "DROP COMPACT STORAGE" was
run, and the behavior prior to this patch is that the database would fail to
start, so I'm not sure there will be much surprise to the user or that its of
much concern. I did consider putting the patch behind a flag that defaulted to
off but the semantics of flipping that flag sometime after the upgrade are even
more confusing imo.
As an aside, I am also concerned about the current behavior that we halt the
database from starting when we detect compact storage tables but I need to
investigate more what escape hatches exist before filing anything.
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15802) Commented-out lines that end in a semicolon cause an error.
[ https://issues.apache.org/jira/browse/CASSANDRA-15802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180008#comment-17180008 ] Rens Groothuijsen commented on CASSANDRA-15802: --- Thanks, I probably should've pushed before I mentioned that though. Looking at the timestamps, I think this one's gonna replay the old one. > Commented-out lines that end in a semicolon cause an error. > --- > > Key: CASSANDRA-15802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15802 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter, CQL/Syntax >Reporter: null >Assignee: Rens Groothuijsen >Priority: Normal > Attachments: cqlsh.png > > Time Spent: 40m > Remaining Estimate: 0h > > Commented-out lines that end in a semicolon cause an error. > For example: > /* > describe keyspaces; > */ > > This produces an error: > SyntaxException: line 2:22 no viable alternative at input ' (...* > describe keyspaces;...) > > It works as expected if you use syntax: > -- describe keyspaces; > > Environment: > python:3.7.7-slim-stretch (docker image) > > I found that this was first seen here, and was patched, but the bug appears > to have resurfaced: > https://issues.apache.org/jira/browse/CASSANDRA-2488 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15802) Commented-out lines that end in a semicolon cause an error.
[ https://issues.apache.org/jira/browse/CASSANDRA-15802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180002#comment-17180002 ] Michael Semb Wever commented on CASSANDRA-15802: Ok, new run [here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/249/pipeline]. > Commented-out lines that end in a semicolon cause an error. > --- > > Key: CASSANDRA-15802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15802 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter, CQL/Syntax >Reporter: null >Assignee: Rens Groothuijsen >Priority: Normal > Attachments: cqlsh.png > > Time Spent: 40m > Remaining Estimate: 0h > > Commented-out lines that end in a semicolon cause an error. > For example: > /* > describe keyspaces; > */ > > This produces an error: > SyntaxException: line 2:22 no viable alternative at input ' (...* > describe keyspaces;...) > > It works as expected if you use syntax: > -- describe keyspaces; > > Environment: > python:3.7.7-slim-stretch (docker image) > > I found that this was first seen here, and was patched, but the bug appears > to have resurfaced: > https://issues.apache.org/jira/browse/CASSANDRA-2488 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15802) Commented-out lines that end in a semicolon cause an error.
[ https://issues.apache.org/jira/browse/CASSANDRA-15802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179987#comment-17179987 ] Rens Groothuijsen commented on CASSANDRA-15802: --- Might be because this branch uses an outdated trunk, when I merged trunk into my branch that particular test passed. > Commented-out lines that end in a semicolon cause an error. > --- > > Key: CASSANDRA-15802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15802 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter, CQL/Syntax >Reporter: null >Assignee: Rens Groothuijsen >Priority: Normal > Attachments: cqlsh.png > > Time Spent: 40m > Remaining Estimate: 0h > > Commented-out lines that end in a semicolon cause an error. > For example: > /* > describe keyspaces; > */ > > This produces an error: > SyntaxException: line 2:22 no viable alternative at input ' (...* > describe keyspaces;...) > > It works as expected if you use syntax: > -- describe keyspaces; > > Environment: > python:3.7.7-slim-stretch (docker image) > > I found that this was first seen here, and was patched, but the bug appears > to have resurfaced: > https://issues.apache.org/jira/browse/CASSANDRA-2488 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15946) NPE when sending REQUEST_RSP from 3.0 to 4.0 in in-jvm dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-15946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-15946:
Fix Version/s: 4.0-beta2
Since Version: 4.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/14d1e3eb91189e1684583918305116061eba6413
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Tests passed. Committed to trunk as
https://github.com/apache/cassandra/commit/14d1e3eb91189e1684583918305116061eba6413
> NPE when sending REQUEST_RSP from 3.0 to 4.0 in in-jvm dtests
> -
>
> Key: CASSANDRA-15946
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15946
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0-beta2
>
>
> There is a communication problem when testing upgrades using in-JVM dtest
> between Cassandra 3 and 4.
> In a method {{registerInboundFilter}} of {{Instance}}, we get a message which
> was just received and we prepare it for filtering as part of which, we
> serialize the payload again. This is fine when dealing with incoming
> Cassandra 4 message, because we can serialize it. However when we get the
> Cassandra 3 message, which uses a different protocol, and we get something
> like {{REQUEST_RSP}}, we can surely deserialize it through some special
> deserialization path, but we cannot serialize the payload for it as there is
> no serializer defined for {{REQUEST_RSP}} - no wonder, why would Cassandra
> 4.0 need to be able to serialize Cassandra 3.0 payloads?
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.net.Message$Serializer.serializePost40(Message.java:760)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:618)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:267)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerInboundFilter$4(Instance.java:234)
> at
> org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:62)
> at
> org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:49)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:93)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:305)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> 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.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15946) NPE when sending REQUEST_RSP from 3.0 to 4.0 in in-jvm dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-15946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-15946:
Status: Ready to Commit (was: Review In Progress)
> NPE when sending REQUEST_RSP from 3.0 to 4.0 in in-jvm dtests
> -
>
> Key: CASSANDRA-15946
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15946
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> There is a communication problem when testing upgrades using in-JVM dtest
> between Cassandra 3 and 4.
> In a method {{registerInboundFilter}} of {{Instance}}, we get a message which
> was just received and we prepare it for filtering as part of which, we
> serialize the payload again. This is fine when dealing with incoming
> Cassandra 4 message, because we can serialize it. However when we get the
> Cassandra 3 message, which uses a different protocol, and we get something
> like {{REQUEST_RSP}}, we can surely deserialize it through some special
> deserialization path, but we cannot serialize the payload for it as there is
> no serializer defined for {{REQUEST_RSP}} - no wonder, why would Cassandra
> 4.0 need to be able to serialize Cassandra 3.0 payloads?
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.net.Message$Serializer.serializePost40(Message.java:760)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:618)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:267)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerInboundFilter$4(Instance.java:234)
> at
> org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:62)
> at
> org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:49)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:93)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:305)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> 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.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix communication between versions 3 and 4 in upgrade JVM DTests
This is an automated email from the ASF dual-hosted git repository.
jwest pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 14d1e3e Fix communication between versions 3 and 4 in upgrade JVM
DTests
14d1e3e is described below
commit 14d1e3eb91189e1684583918305116061eba6413
Author: jacek-lewandowski
AuthorDate: Tue Jul 28 13:30:21 2020 +0200
Fix communication between versions 3 and 4 in upgrade JVM DTests
patch by Jacek Lewandowski; reviewed by Jordan West for CASSANDRA-15946
---
src/java/org/apache/cassandra/net/Verb.java | 2 +-
test/distributed/org/apache/cassandra/distributed/impl/Instance.java | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/java/org/apache/cassandra/net/Verb.java
b/src/java/org/apache/cassandra/net/Verb.java
index 6ba9ab8..2ef981d 100644
--- a/src/java/org/apache/cassandra/net/Verb.java
+++ b/src/java/org/apache/cassandra/net/Verb.java
@@ -329,7 +329,7 @@ public enum Verb
}
@VisibleForTesting
-Supplier>
unsafeSetSerializer(Supplier>
serializer) throws NoSuchFieldException, IllegalAccessException
+public Supplier>
unsafeSetSerializer(Supplier>
serializer) throws NoSuchFieldException, IllegalAccessException
{
Supplier> original =
this.serializer;
Field field = Verb.class.getDeclaredField("serializer");
diff --git
a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
index 44cef6f..2941668 100644
--- a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
+++ b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
@@ -55,6 +55,7 @@ import org.apache.cassandra.cql3.QueryProcessor;
import org.apache.cassandra.db.ColumnFamilyStore;
import org.apache.cassandra.db.Keyspace;
import org.apache.cassandra.db.Memtable;
+import org.apache.cassandra.db.ReadResponse;
import org.apache.cassandra.db.SystemKeyspace;
import org.apache.cassandra.db.SystemKeyspaceMigrator40;
import org.apache.cassandra.db.commitlog.CommitLog;
@@ -84,6 +85,7 @@ import org.apache.cassandra.io.util.FileUtils;
import org.apache.cassandra.locator.InetAddressAndPort;
import org.apache.cassandra.net.Message;
import org.apache.cassandra.net.MessagingService;
+import org.apache.cassandra.net.Verb;
import org.apache.cassandra.schema.Schema;
import org.apache.cassandra.schema.SchemaConstants;
import org.apache.cassandra.service.ActiveRepairService;
@@ -383,6 +385,8 @@ public class Instance extends IsolatedExecutor implements
IInvokableInstance
throw new RuntimeException(e);
}
+Verb.REQUEST_RSP.unsafeSetSerializer(() ->
ReadResponse.serializer);
+
if (config.has(NETWORK))
{
MessagingService.instance().listen();
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15946) NPE when sending REQUEST_RSP from 3.0 to 4.0 in in-jvm dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-15946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179732#comment-17179732
]
Jordan West commented on CASSANDRA-15946:
-
Kicked off a test run [here |
https://app.circleci.com/pipelines/github/jrwest/cassandra?branch=CASSANDRA-15946]
so that we can get this merged -- this is blocking a few people / tests and
the patch that exists solves the initially reported problem. [~dcapwell] will
follow up on the other issues he found separately.
> NPE when sending REQUEST_RSP from 3.0 to 4.0 in in-jvm dtests
> -
>
> Key: CASSANDRA-15946
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15946
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> There is a communication problem when testing upgrades using in-JVM dtest
> between Cassandra 3 and 4.
> In a method {{registerInboundFilter}} of {{Instance}}, we get a message which
> was just received and we prepare it for filtering as part of which, we
> serialize the payload again. This is fine when dealing with incoming
> Cassandra 4 message, because we can serialize it. However when we get the
> Cassandra 3 message, which uses a different protocol, and we get something
> like {{REQUEST_RSP}}, we can surely deserialize it through some special
> deserialization path, but we cannot serialize the payload for it as there is
> no serializer defined for {{REQUEST_RSP}} - no wonder, why would Cassandra
> 4.0 need to be able to serialize Cassandra 3.0 payloads?
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.net.Message$Serializer.serializePost40(Message.java:760)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:618)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:267)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerInboundFilter$4(Instance.java:234)
> at
> org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:62)
> at
> org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:49)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:93)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:305)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> 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.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13701) Lower default num_tokens
[ https://issues.apache.org/jira/browse/CASSANDRA-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179700#comment-17179700 ] Alexander Dejanovski commented on CASSANDRA-13701: -- New CI run with some additional adjustements in timings [here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/248/tests]. The last failing test is fixed in trunk by [this commit|https://github.com/apache/cassandra/commit/c94ececec0fcd87459858370396d6cd586853787]. It's unrelated to this ticket. I've squashed the commits in [my cassandra-dtests branch|https://github.com/adejanovski/cassandra-dtest/tree/CASSANDRA-13701], but I still need to drop the commit that points to [the patched version of ccm|https://github.com/adejanovski/ccm/tree/CASSANDRA-13701]. Let's wait for the conversation to settle in the ASF Slack before moving on here. Maybe we should re-run CI again to see if we have some flaky tests that would be related to this ticket? > Lower default num_tokens > > > Key: CASSANDRA-13701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13701 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Chris Lohfink >Assignee: Alexander Dejanovski >Priority: Low > Fix For: 4.0-alpha > > > For reasons highlighted in CASSANDRA-7032, the high number of vnodes is not > necessary. It is very expensive for operations processes and scanning. Its > come up a lot and its pretty standard and known now to always reduce the > num_tokens within the community. We should just lower the defaults. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16054) Regression Test for Compact Storage Upgrades When Table Has Clustering and Value Column
[ https://issues.apache.org/jira/browse/CASSANDRA-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16054: Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Caleb Rackliffe, Caleb Rackliffe Status: Review In Progress (was: Patch Available) > Regression Test for Compact Storage Upgrades When Table Has Clustering and > Value Column > > > Key: CASSANDRA-16054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16054 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > Add a regression test that shows that dropping compact storage on tables that > have clustering columns and a value column defined are safe after upgrading > sstables in 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179691#comment-17179691
]
Sylvain Lebresne commented on CASSANDRA-16048:
--
Not to reject this upfront completely, but wanted to note that a part of me
wonders if this is a good idea.
First, I feel this murky the waters a bit around the upgrade path to 4.0. "You
have to run {{DROP COMPACT STORAGE}} on all compact table before upgrading" is
a simple rule. Simple is good, and I feel adding special cases is adding
confusion. And the upside here is pretty minor.
Of course, we could leave this undocumented, and keep only the simple rule in
all documentation. But if we don't document this, I think this create a risk of
surprising users, which is my other point.
Because it's not 100% true that "there is no visible change to the user facing
schema after dropping compact storage". The schema of those tables loses the
{{WITH COMPACT STORAGE}} (and the {{system_schema}} table will lose the
{{DENSE}} flag, which is also technically visible). Which may sound trivial,
but it's a bit hard to ensure that there no user tool/code out there that rely
on it. And in general, users may simply be confused that their table appears to
lose a property silently, or wonder why the schema dump of that table done on
3.x does not replay properly on 4.0 anymore.
Tbc, I get how for "us", devs of C* that understand the internals, it sounds
annoying to have to run a command when we know it could be done automatically
and we're not gonna be confused by it. Just not sure this is a good place to
optimize for "us".
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15406) Show the progress of data streaming and index build
[ https://issues.apache.org/jira/browse/CASSANDRA-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179575#comment-17179575 ] Stefan Miklosovic commented on CASSANDRA-15406: --- I have implemented your suggestions however I think we need to release new dtest api. Looking forward to have further feedback. > Show the progress of data streaming and index build > > > Key: CASSANDRA-15406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15406 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming, Legacy/Streaming and Messaging, > Tool/nodetool >Reporter: maxwellguo >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0, 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > I found that we should supply a command to show the progress of streaming > when we do the operation of bootstrap/move/decommission/removenode. For when > do data streaming , noboday knows which steps there program are in , so I > think a command to show the joing/leaving node's is needed . > > PR [https://github.com/apache/cassandra/pull/558] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15828) Remove jackson-mapper-asl-1.9.13 to address CVE
[ https://issues.apache.org/jira/browse/CASSANDRA-15828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Eveker updated CASSANDRA-15828: - Resolution: Fixed Status: Resolved (was: Triage Needed) > Remove jackson-mapper-asl-1.9.13 to address CVE > --- > > Key: CASSANDRA-15828 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15828 > Project: Cassandra > Issue Type: Improvement >Reporter: Kevin Eveker >Priority: Normal > > Recent scan results identified the following CVE that require this upgrade to > address > [https://nvd.nist.gov/vuln/detail/CVE-2019-10172] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13701) Lower default num_tokens
[ https://issues.apache.org/jira/browse/CASSANDRA-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179534#comment-17179534 ] Michael Semb Wever edited comment on CASSANDRA-13701 at 8/18/20, 10:38 AM: --- CI run [here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/247/pipeline/258/]. [~adejanovski], could you check if any of [these failures|https://ci-cassandra.apache.org/job/Cassandra-devbranch/247/testReport/] are related? Based on just the one run (though there was no pipelines running in ci-cassandra.a.o at the time), the total runtime for devbranch tests (trunk based) has gone from ~16hrs to ~27hrs. But, due to parallelisation, the pipeline run times have only increased from ~2hrs to ~2:20 hours. This is not ideal but I think it's worth pushing fixing/further-improving dtest performance to out-of-scope and a separate ticket. was (Author: michaelsembwever): CI run [here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/247/pipeline/258/]. [~adejanovski], could you check if any of [these failures|https://ci-cassandra.apache.org/job/Cassandra-devbranch/247/testReport/] are related? Based on just the one run (though there was no pipelines running in ci-cassandra.a.o at the time), the total runtime for devbranch tests (trunk based) has gone from ~16hrs to ~27hrs. But, due to parallelisation, the pipeline run times have only increased from ~2hrs to ~2:20 hours. This is not ideal but I think it's worth pushing fixing/further-improving dtest performance to out-of-scope and a separate ticket. > Lower default num_tokens > > > Key: CASSANDRA-13701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13701 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Chris Lohfink >Assignee: Alexander Dejanovski >Priority: Low > Fix For: 4.0-alpha > > > For reasons highlighted in CASSANDRA-7032, the high number of vnodes is not > necessary. It is very expensive for operations processes and scanning. Its > come up a lot and its pretty standard and known now to always reduce the > num_tokens within the community. We should just lower the defaults. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13701) Lower default num_tokens
[ https://issues.apache.org/jira/browse/CASSANDRA-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179534#comment-17179534 ] Michael Semb Wever commented on CASSANDRA-13701: CI run [here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/247/pipeline/258/]. [~adejanovski], could you check if any of [these failures|https://ci-cassandra.apache.org/job/Cassandra-devbranch/247/testReport/] are related? Based on just the one run (though there was no pipelines running in ci-cassandra.a.o at the time), the total runtime for devbranch tests (trunk based) has gone from ~16hrs to ~27hrs. But, due to parallelisation, the pipeline run times have only increased from ~2hrs to ~2:20 hours. This is not ideal but I think it's worth pushing fixing/further-improving dtest performance to out-of-scope and a separate ticket. > Lower default num_tokens > > > Key: CASSANDRA-13701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13701 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Chris Lohfink >Assignee: Alexander Dejanovski >Priority: Low > Fix For: 4.0-alpha > > > For reasons highlighted in CASSANDRA-7032, the high number of vnodes is not > necessary. It is very expensive for operations processes and scanning. Its > come up a lot and its pretty standard and known now to always reduce the > num_tokens within the community. We should just lower the defaults. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16056) Remove jackson-mapper-asl-1.9.13 to mitigate CVE-2019-10172
[
https://issues.apache.org/jira/browse/CASSANDRA-16056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Denihan updated CASSANDRA-16056:
-
Component/s: Dependencies
> Remove jackson-mapper-asl-1.9.13 to mitigate CVE-2019-10172
> ---
>
> Key: CASSANDRA-16056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16056
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Mark Denihan
>Priority: Normal
> Fix For: 2.2.x
>
>
> As a Cassandra consumer
> I want the jackson-mapper-asl removed
> So that I do not suffer risks that are published in that dependency
> Swapping the codehause libraries over to jackson-databind resulted in
> CVE-2019-10172 being mitigated in 3.11. See CASSANDRA-15867;
> {code:java}
> Author: Stefan Miklosovic 2020-06-13
> 16:09:00
> Committer: Brandon Williams 2020-06-17 17:21:35
> Parent: e49853914bd407827093cebf5151db0ebe2eba9e (Merge branch
> 'cassandra-3.0' into cassandra-3.11)
> Child: ac289270f2bb3bb7251319f7f71d6c66a4272db4 (Merge branch
> 'cassandra-3.0' into cassandra-3.11)
> Branches: 3.11.7, cassandra-3.11, remotes/origin/cassandra-3.11,
> remotes/origin/trunk, trunk
> Follows: cassandra-3.11.6
> Precedes: cassandra-3.11.7
> update Jackson to 2.9.10
>
> Patch by Stefan Miklosovic, reviewed by brandonwilliams for
> CASSANDRA-15867
> -- build.xml
> --
> index 0724dbb29c..25a47335b9 100644
> @@ -406,8 +406,9 @@
> version="1.7.7" />
> version="1.1.3"/>
> version="1.1.3"/>
> - artifactId="jackson-core-asl" version="1.9.2"/>
> - artifactId="jackson-mapper-asl" version="1.9.2"/>
> + artifactId="jackson-core" version="2.9.10"/>
> + artifactId="jackson-databind" version="2.9.10.4"/>
> + artifactId="jackson-annotations" version="2.9.10"/>
> artifactId="json-simple" version="1.1"/>
> version="1.0.6"/>
> version="0.3.0"/>
> @@ -627,8 +628,9 @@
>
>
>
> - artifactId="jackson-core-asl"/>
> - artifactId="jackson-mapper-asl"/>
> + artifactId="jackson-core"/>
> + artifactId="jackson-databind"/>
> + artifactId="jackson-annotations"/>
> artifactId="json-simple"/>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16056) Remove jackson-mapper-asl-1.9.13 to mitigate CVE-2019-10172
[
https://issues.apache.org/jira/browse/CASSANDRA-16056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Denihan updated CASSANDRA-16056:
-
Fix Version/s: 2.2.x
> Remove jackson-mapper-asl-1.9.13 to mitigate CVE-2019-10172
> ---
>
> Key: CASSANDRA-16056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16056
> Project: Cassandra
> Issue Type: Bug
>Reporter: Mark Denihan
>Priority: Normal
> Fix For: 2.2.x
>
>
> As a Cassandra consumer
> I want the jackson-mapper-asl removed
> So that I do not suffer risks that are published in that dependency
> Swapping the codehause libraries over to jackson-databind resulted in
> CVE-2019-10172 being mitigated in 3.11. See CASSANDRA-15867;
> {code:java}
> Author: Stefan Miklosovic 2020-06-13
> 16:09:00
> Committer: Brandon Williams 2020-06-17 17:21:35
> Parent: e49853914bd407827093cebf5151db0ebe2eba9e (Merge branch
> 'cassandra-3.0' into cassandra-3.11)
> Child: ac289270f2bb3bb7251319f7f71d6c66a4272db4 (Merge branch
> 'cassandra-3.0' into cassandra-3.11)
> Branches: 3.11.7, cassandra-3.11, remotes/origin/cassandra-3.11,
> remotes/origin/trunk, trunk
> Follows: cassandra-3.11.6
> Precedes: cassandra-3.11.7
> update Jackson to 2.9.10
>
> Patch by Stefan Miklosovic, reviewed by brandonwilliams for
> CASSANDRA-15867
> -- build.xml
> --
> index 0724dbb29c..25a47335b9 100644
> @@ -406,8 +406,9 @@
> version="1.7.7" />
> version="1.1.3"/>
> version="1.1.3"/>
> - artifactId="jackson-core-asl" version="1.9.2"/>
> - artifactId="jackson-mapper-asl" version="1.9.2"/>
> + artifactId="jackson-core" version="2.9.10"/>
> + artifactId="jackson-databind" version="2.9.10.4"/>
> + artifactId="jackson-annotations" version="2.9.10"/>
> artifactId="json-simple" version="1.1"/>
> version="1.0.6"/>
> version="0.3.0"/>
> @@ -627,8 +628,9 @@
>
>
>
> - artifactId="jackson-core-asl"/>
> - artifactId="jackson-mapper-asl"/>
> + artifactId="jackson-core"/>
> + artifactId="jackson-databind"/>
> + artifactId="jackson-annotations"/>
> artifactId="json-simple"/>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16056) Remove jackson-mapper-asl-1.9.13 to mitigate CVE-2019-10172
[
https://issues.apache.org/jira/browse/CASSANDRA-16056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Denihan updated CASSANDRA-16056:
-
Impacts: Security (was: None)
> Remove jackson-mapper-asl-1.9.13 to mitigate CVE-2019-10172
> ---
>
> Key: CASSANDRA-16056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16056
> Project: Cassandra
> Issue Type: Bug
>Reporter: Mark Denihan
>Priority: Normal
> Fix For: 2.2.x
>
>
> As a Cassandra consumer
> I want the jackson-mapper-asl removed
> So that I do not suffer risks that are published in that dependency
> Swapping the codehause libraries over to jackson-databind resulted in
> CVE-2019-10172 being mitigated in 3.11. See CASSANDRA-15867;
> {code:java}
> Author: Stefan Miklosovic 2020-06-13
> 16:09:00
> Committer: Brandon Williams 2020-06-17 17:21:35
> Parent: e49853914bd407827093cebf5151db0ebe2eba9e (Merge branch
> 'cassandra-3.0' into cassandra-3.11)
> Child: ac289270f2bb3bb7251319f7f71d6c66a4272db4 (Merge branch
> 'cassandra-3.0' into cassandra-3.11)
> Branches: 3.11.7, cassandra-3.11, remotes/origin/cassandra-3.11,
> remotes/origin/trunk, trunk
> Follows: cassandra-3.11.6
> Precedes: cassandra-3.11.7
> update Jackson to 2.9.10
>
> Patch by Stefan Miklosovic, reviewed by brandonwilliams for
> CASSANDRA-15867
> -- build.xml
> --
> index 0724dbb29c..25a47335b9 100644
> @@ -406,8 +406,9 @@
> version="1.7.7" />
> version="1.1.3"/>
> version="1.1.3"/>
> - artifactId="jackson-core-asl" version="1.9.2"/>
> - artifactId="jackson-mapper-asl" version="1.9.2"/>
> + artifactId="jackson-core" version="2.9.10"/>
> + artifactId="jackson-databind" version="2.9.10.4"/>
> + artifactId="jackson-annotations" version="2.9.10"/>
> artifactId="json-simple" version="1.1"/>
> version="1.0.6"/>
> version="0.3.0"/>
> @@ -627,8 +628,9 @@
>
>
>
> - artifactId="jackson-core-asl"/>
> - artifactId="jackson-mapper-asl"/>
> + artifactId="jackson-core"/>
> + artifactId="jackson-databind"/>
> + artifactId="jackson-annotations"/>
> artifactId="json-simple"/>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16056) Remove jackson-mapper-asl-1.9.13 to mitigate CVE-2019-10172
Mark Denihan created CASSANDRA-16056:
Summary: Remove jackson-mapper-asl-1.9.13 to mitigate
CVE-2019-10172
Key: CASSANDRA-16056
URL: https://issues.apache.org/jira/browse/CASSANDRA-16056
Project: Cassandra
Issue Type: Bug
Reporter: Mark Denihan
As a Cassandra consumer
I want the jackson-mapper-asl removed
So that I do not suffer risks that are published in that dependency
Swapping the codehause libraries over to jackson-databind resulted in
CVE-2019-10172 being mitigated in 3.11. See CASSANDRA-15867;
{code:java}
Author: Stefan Miklosovic 2020-06-13
16:09:00
Committer: Brandon Williams 2020-06-17 17:21:35
Parent: e49853914bd407827093cebf5151db0ebe2eba9e (Merge branch 'cassandra-3.0'
into cassandra-3.11)
Child: ac289270f2bb3bb7251319f7f71d6c66a4272db4 (Merge branch 'cassandra-3.0'
into cassandra-3.11)
Branches: 3.11.7, cassandra-3.11, remotes/origin/cassandra-3.11,
remotes/origin/trunk, trunk
Follows: cassandra-3.11.6
Precedes: cassandra-3.11.7
update Jackson to 2.9.10
Patch by Stefan Miklosovic, reviewed by brandonwilliams for
CASSANDRA-15867
-- build.xml --
index 0724dbb29c..25a47335b9 100644
@@ -406,8 +406,9 @@
-
-
+
+
+
@@ -627,8 +628,9 @@
-
-
+
+
+
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15828) Remove jackson-mapper-asl-1.9.13 to address CVE
[ https://issues.apache.org/jira/browse/CASSANDRA-15828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179460#comment-17179460 ] Mark Denihan commented on CASSANDRA-15828: -- [~c3-keveker] I'm pretty sure you can if this ticket was targeted for 3.11 [~brandon.williams] Thanks for the suggestion. I'll create a ticket for 2.2 and see if swapping over the dependency is a straight forward fix and doesn't break anything > Remove jackson-mapper-asl-1.9.13 to address CVE > --- > > Key: CASSANDRA-15828 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15828 > Project: Cassandra > Issue Type: Improvement >Reporter: Kevin Eveker >Priority: Normal > > Recent scan results identified the following CVE that require this upgrade to > address > [https://nvd.nist.gov/vuln/detail/CVE-2019-10172] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16039) FQL replay should have options to ignore DDL statements
[ https://issues.apache.org/jira/browse/CASSANDRA-16039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179448#comment-17179448 ] Stefan Miklosovic commented on CASSANDRA-16039: --- I ve addressed the most of your feedback. I have not done anything with return codes, this type of change is not trivial and I do not know how to go about it. In theory I agree that if all queries fail, return code should not be 0, but in order to implement these changes we would need to change a lot of internals and this ticket is not about that issue. If you want to address it, it would be better to merge this stuff and treat it separately in a completely new ticket. > FQL replay should have options to ignore DDL statements > --- > > Key: CASSANDRA-16039 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16039 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: David Capwell >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 0.5h > Remaining Estimate: 0h > > FQL logs will contain DDL statements made on the host, and the replay tool > will attempt to replay them; this can be unsafe in general so should have an > option to filter them out. > Thinking about it, since DDL replay isn’t obvious, we should most likely > default to false and have a flag to allow DDL replay as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
