[jira] [Updated] (CASSANDRA-19751) IllegalStateException when query on table having static columns during the Cassandra cluster upgrade from 3.11.4 to 4.0.11
[
https://issues.apache.org/jira/browse/CASSANDRA-19751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alaykumar Barochia updated CASSANDRA-19751:
---
Description:
We are upgrading Cassandra cluster from 3.11.4 to 4.0.11. This cluster has SSL
enabled.
While performing upgrade on 1st DC, we observed below WARN/ERROR messages on C*
3 and C* 4 nodes.
+C*3 nodes:+
{noformat}
WARN [ReadStage-1] 2024-06-11 08:04:09,088
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
WARN [ReadStage-1] 2024-06-19 05:10:31,226
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [default_price_json, last_metadata_updt_ts,
price_metadata] is not a subset of [price_metadata]
{noformat}
+C*4 nodes:+
{noformat}
ERROR [ReadStage-1] 2024-06-19 05:48:47,388
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[ReadStage-1,5,main]
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
{noformat}
Table definition for which above columns are associated is as below:
{noformat}
CREATE TABLE omni_price_ks_v2.location_price_mstr (
tcin text,
location_id bigint,
price_change_id text,
default_price_json text static,
end_ts bigint,
last_metadata_updt_ts bigint static,
last_update_ts bigint,
price_json text,
price_metadata text static,
price_type text,
start_ts bigint,
status text,
version text,
PRIMARY KEY (tcin, location_id, price_change_id)
) WITH CLUSTERING ORDER BY (location_id ASC, price_change_id ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': '100'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{noformat}
App team also observed below error in their application logs when try to read
from this table.
{noformat}
{ "code": "ERR_GETPRICE_0034", "message": "Cassandra failure during read query
at consistency LOCAL_QUORUM (2 responses were required but only 1 replica
responded, 1 failed)" }
{noformat}
Because of this error, the application is getting impacted during the upgrade.
Once the upgrade on all DCs is completed, this error stops.
I found below bug which matches our case.
https://issues.apache.org/jira/browse/CASSANDRA-17601
It seems like we are hitting some bug and hence raising this Jira.
Can you please have a look if this is still a bug and what would be the fix?
Let me know if you need any more details.
was:
We are upgrading Cassandra cluster from 3.11.4 to 4.0.11.
While performing upgrade on 1st DC, we observed below WARN/ERROR messages on C*
3 and C* 4 nodes.
+C*3 nodes:+
{noformat}
WARN [ReadStage-1] 2024-06-11 08:04:09,088
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
WARN [ReadStage-1] 2024-06-19 05:10:31,226
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [default_price_json, last_metadata_updt_ts,
price_metadata] is not a subset of [price_metadata]
{noformat}
+C*4 nodes:+
{noformat}
ERROR [ReadStage-1] 2024-06-19 05:48:47,388
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[ReadStage-1,5,main]
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
{noformat}
Table definition for which above columns are associated is as below:
{noformat}
CREATE TABLE omni_price_ks_v2.location_price_mstr (
tcin text,
location_id bigint,
price_change_id text,
default_price_json text static,
end_ts bigint,
last_metadata_updt_ts bigint static,
last_update_ts bigint,
price_json text,
price_metadata text static,
price_type text,
start_ts bigint,
status text,
version text,
PRIMARY KEY (tcin, location_id, price_change_id)
) WITH CLUSTERING ORDER BY (location_id ASC, price_change_id ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'row
[jira] [Updated] (CASSANDRA-19751) IllegalStateException when query on table having static columns during the Cassandra cluster upgrade from 3.11.4 to 4.0.11
[
https://issues.apache.org/jira/browse/CASSANDRA-19751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alaykumar Barochia updated CASSANDRA-19751:
---
Description:
We are upgrading Cassandra cluster from 3.11.4 to 4.0.11.
While performing upgrade on 1st DC, we observed below WARN/ERROR messages on C*
3 and C* 4 nodes.
+C*3 nodes:+
{noformat}
WARN [ReadStage-1] 2024-06-11 08:04:09,088
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
WARN [ReadStage-1] 2024-06-19 05:10:31,226
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [default_price_json, last_metadata_updt_ts,
price_metadata] is not a subset of [price_metadata]
{noformat}
+C*4 nodes:+
{noformat}
ERROR [ReadStage-1] 2024-06-19 05:48:47,388
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[ReadStage-1,5,main]
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
{noformat}
Table definition for which above columns are associated is as below:
{noformat}
CREATE TABLE omni_price_ks_v2.location_price_mstr (
tcin text,
location_id bigint,
price_change_id text,
default_price_json text static,
end_ts bigint,
last_metadata_updt_ts bigint static,
last_update_ts bigint,
price_json text,
price_metadata text static,
price_type text,
start_ts bigint,
status text,
version text,
PRIMARY KEY (tcin, location_id, price_change_id)
) WITH CLUSTERING ORDER BY (location_id ASC, price_change_id ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': '100'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{noformat}
App team also observed below error in their application logs when try to read
from this table.
{noformat}
{ "code": "ERR_GETPRICE_0034", "message": "Cassandra failure during read query
at consistency LOCAL_QUORUM (2 responses were required but only 1 replica
responded, 1 failed)" }
{noformat}
Because of this error, the application is getting impacted during the upgrade.
Once the upgrade on all DCs is completed, this error stops.
I found below bug which matches our case.
https://issues.apache.org/jira/browse/CASSANDRA-17601
It seems like we are hitting some bug and hence raising this Jira.
Can you please have a look if this is still a bug and what would be the fix?
Let me know if you need any more details.
was:
We are upgrading Cassandra cluster from 3.11.4 to 4.0.11.
While performing upgrade on 1st DC, we observed below WARN/ERROR messages on C*
3 and C* 4 nodes.
*C*3 nodes:*
{noformat}
WARN [ReadStage-1] 2024-06-11 08:04:09,088
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
WARN [ReadStage-1] 2024-06-19 05:10:31,226
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [default_price_json, last_metadata_updt_ts,
price_metadata] is not a subset of [price_metadata]
{noformat}
*C*4 nodes:*
{noformat}
ERROR [ReadStage-1] 2024-06-19 05:48:47,388
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[ReadStage-1,5,main]
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
{noformat}
Table definition for which above columns are associated is as below:
{noformat}
CREATE TABLE omni_price_ks_v2.location_price_mstr (
tcin text,
location_id bigint,
price_change_id text,
default_price_json text static,
end_ts bigint,
last_metadata_updt_ts bigint static,
last_update_ts bigint,
price_json text,
price_metadata text static,
price_type text,
start_ts bigint,
status text,
version text,
PRIMARY KEY (tcin, location_id, price_change_id)
) WITH CLUSTERING ORDER BY (location_id ASC, price_change_id ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': '100'}
AND c
[jira] [Created] (CASSANDRA-19751) IllegalStateException when query on table having static columns during the Cassandra cluster upgrade from 3.11.4 to 4.0.11
Alaykumar Barochia created CASSANDRA-19751:
--
Summary: IllegalStateException when query on table having static
columns during the Cassandra cluster upgrade from 3.11.4 to 4.0.11
Key: CASSANDRA-19751
URL: https://issues.apache.org/jira/browse/CASSANDRA-19751
Project: Cassandra
Issue Type: Bug
Reporter: Alaykumar Barochia
We are upgrading Cassandra cluster from 3.11.4 to 4.0.11.
While performing upgrade on 1st DC, we observed below WARN/ERROR messages on C*
3 and C* 4 nodes.
*C*3 nodes:*
{noformat}
WARN [ReadStage-1] 2024-06-11 08:04:09,088
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
WARN [ReadStage-1] 2024-06-19 05:10:31,226
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.IllegalStateException: [default_price_json, last_metadata_updt_ts,
price_metadata] is not a subset of [price_metadata]
{noformat}
*C*4 nodes:*
{noformat}
ERROR [ReadStage-1] 2024-06-19 05:48:47,388
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[ReadStage-1,5,main]
java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is not
a subset of [price_metadata]
{noformat}
Table definition for which above columns are associated is as below:
{noformat}
CREATE TABLE omni_price_ks_v2.location_price_mstr (
tcin text,
location_id bigint,
price_change_id text,
default_price_json text static,
end_ts bigint,
last_metadata_updt_ts bigint static,
last_update_ts bigint,
price_json text,
price_metadata text static,
price_type text,
start_ts bigint,
status text,
version text,
PRIMARY KEY (tcin, location_id, price_change_id)
) WITH CLUSTERING ORDER BY (location_id ASC, price_change_id ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': '100'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{noformat}
App team also observed below error in their application logs when try to read
from this table.
{noformat}
{ "code": "ERR_GETPRICE_0034", "message": "Cassandra failure during read query
at consistency LOCAL_QUORUM (2 responses were required but only 1 replica
responded, 1 failed)" }
{noformat}
Because of this error, the application is getting impacted during the upgrade.
Once the upgrade on all DCs is completed, this error stops.
I found below bug which matches our case.
https://issues.apache.org/jira/browse/CASSANDRA-17601
It seems like we are hitting some bug and hence raising this Jira.
Can you please have a look if this is still a bug and what would be the fix?
Let me know if you need any more details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17457) CEP-24 - Password validation/generation
[ https://issues.apache.org/jira/browse/CASSANDRA-17457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863100#comment-17863100 ] Stefan Miklosovic edited comment on CASSANDRA-17457 at 7/5/24 12:03 AM: [~djoshi] , thanks, also, for the reference, as discussed in LEGAL-677, upon actual release, we need to carry forward the copyright NOTICE of passay into the NOTICE of the tarball distribution. For the source release, we do not need to do anything. was (Author: smiklosovic): [~djoshi] , thanks, also, for the reference, as discussed in LEGAL-677, upon actual release, we need to carry forward the copyright NOTICE of passay into the NOTICE of a tarball distribution. > CEP-24 - Password validation/generation > --- > > Key: CASSANDRA-17457 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17457 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Berenguer Blasi >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > Implement CEP-24 as per > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17457) CEP-24 - Password validation/generation
[ https://issues.apache.org/jira/browse/CASSANDRA-17457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863100#comment-17863100 ] Stefan Miklosovic commented on CASSANDRA-17457: --- [~djoshi] , thanks, also, for the reference, as discussed in LEGAL-677, upon actual release, we need to carry forward the copyright NOTICE of passay into the NOTICE of a tarball distribution. > CEP-24 - Password validation/generation > --- > > Key: CASSANDRA-17457 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17457 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Berenguer Blasi >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > Implement CEP-24 as per > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17457) CEP-24 - Password validation/generation
[ https://issues.apache.org/jira/browse/CASSANDRA-17457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17457: - Status: Ready to Commit (was: Review In Progress) > CEP-24 - Password validation/generation > --- > > Key: CASSANDRA-17457 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17457 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Berenguer Blasi >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > Implement CEP-24 as per > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17457) CEP-24 - Password validation/generation
[ https://issues.apache.org/jira/browse/CASSANDRA-17457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863084#comment-17863084 ] Dinesh Joshi commented on CASSANDRA-17457: -- +1, thanks for the patch. [~smiklosovic] if there are any notice we need to add pertaining to licensing, we should handle them in a separate follow on ticket. Given the response from Justin on the legal jira, we don't need to be doing anything special. > CEP-24 - Password validation/generation > --- > > Key: CASSANDRA-17457 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17457 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Berenguer Blasi >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > Implement CEP-24 as per > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863044#comment-17863044
]
Stefan Miklosovic edited comment on CASSANDRA-19747 at 7/4/24 6:21 PM:
---
[CASSANDRA-19747-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19747-trunk]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 48s
✓ j17_cqlsh_dtests_py3117m 2s
✓ j17_cqlsh_dtests_py311_vnode 7m 15s
✓ j17_cqlsh_dtests_py387m 18s
✓ j17_cqlsh_dtests_py38_vnode 7m 14s
✓ j17_cqlshlib_cython_tests9m 39s
✓ j17_cqlshlib_tests7m 4s
✓ j17_dtests 36m 45s
✓ j17_dtests_latest 36m 11s
✓ j17_unit_tests 14m 39s
✓ j17_unit_tests_repeat 4m 2s
✓ j17_utests_latest 17m 18s
✓ j17_utests_latest_repeat 3m 57s
✓ j17_utests_oa_repeat 4m 51s
✕ j17_dtests_vnode49m 31s
bootstrap_test.TestBootstrap
test_consistent_range_movement_false_with_replica_down_should_succeed
bootstrap_test.TestBootstrap test_shutdown_wiped_node_cannot_join
✕ j17_jvm_dtests 23m 43s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testOptionalMtlsModeDoNotAllowNonSSLConnections
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
✕ j17_jvm_dtests_latest_vnode 22m 13s
org.apache.cassandra.distributed.test.tcm.CMSPlacementAfterMoveTest
testMoveToCMS
org.apache.cassandra.distributed.test.tcm.SplitBrainTest
testSplitBrainStartup
✕ j17_utests_oa 14m 12s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4465/workflows/79911554-8523-485d-9fae-2a2bd8f0c70]
was (Author: smiklosovic):
[CASSANDRA-19747-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19747-trunk]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 48s
✓ j17_cqlsh_dtests_py3117m 2s
✓ j17_cqlsh_dtests_py311_vnode 7m 15s
✓ j17_cqlsh_dtests_py387m 18s
✓ j17_cqlsh_dtests_py38_vnode 7m 14s
✓ j17_cqlshlib_cython_tests9m 39s
✓ j17_cqlshlib_tests7m 4s
✓ j17_dtests 36m 45s
✓ j17_dtests_latest 36m 11s
✓ j17_unit_tests 14m 39s
✓ j17_unit_tests_repeat 4m 2s
✓ j17_utests_latest 17m 18s
✓ j17_utests_latest_repeat 3m 57s
✓ j17_utests_oa_repeat 4m 51s
✕ j17_dtests_vnode49m 31s
bootstrap_test.TestBootstrap
test_consistent_range_movement_false_with_replica_down_should_succeed
bootstrap_test.TestBootstrap test_shutdown_wiped_node_cannot_join
✕ j17_jvm_dtests 23m 43s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testOptionalMtlsModeDoNotAllowNonSSLConnections
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
✕ j17_jvm_dtests_latest_vnode 22m 13s
org.apache.cassandra.distributed.test.tcm.CMSPlacementAfterMoveTest
testMoveToCMS
org.apache.cassandra.distributed.test.tcm.SplitBrainTest
testSplitBrainStartup
✕ j17_utests_oa 14m 12s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4465/workflows/79911554-8523-485d-9fae-2a2bd8f0c70
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Assignee: Stefan Miklosovic
>Priority: Normal
>
[jira] [Updated] (CASSANDRA-13890) Expose current compaction throughput
[
https://issues.apache.org/jira/browse/CASSANDRA-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-13890:
--
Status: Ready to Commit (was: Review In Progress)
> Expose current compaction throughput
>
>
> Key: CASSANDRA-13890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13890
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Jon Haddad
>Assignee: Ling Mao
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Getting and setting the current compaction throughput limit is supported, but
> there's no means of knowing if the setting is actually making a difference.
> Let's expose the current throughput being utilized by Cassandra that's in the
> {{compactionRateLimiter}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13890) Expose current compaction throughput
[
https://issues.apache.org/jira/browse/CASSANDRA-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-13890:
--
Reviewers: Jon Haddad, Stefan Miklosovic
Status: Review In Progress (was: Needs Committer)
> Expose current compaction throughput
>
>
> Key: CASSANDRA-13890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13890
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Jon Haddad
>Assignee: Ling Mao
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Getting and setting the current compaction throughput limit is supported, but
> there's no means of knowing if the setting is actually making a difference.
> Let's expose the current throughput being utilized by Cassandra that's in the
> {{compactionRateLimiter}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13890) Expose current compaction throughput
[
https://issues.apache.org/jira/browse/CASSANDRA-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863081#comment-17863081
]
Stefan Miklosovic commented on CASSANDRA-13890:
---
Seems just fine. For the record, one minor cosmetic change I did is that there
is not "limit: " added in nodetool's output which was not there before. We
would be changing the ouput of the nodetool and that is highly sensitive for
anybody who is integrating with this in their scripts etc. We may discuss this
addition in another ticket if people insist on that.
I am going to ship the bellow branch.
[CASSANDRA-13890|https://github.com/instaclustr/cassandra/tree/CASSANDRA-13890]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 51s
✓ j17_cqlsh_dtests_py311_vnode 7m 35s
✓ j17_cqlsh_dtests_py38 7m 0s
✓ j17_cqlsh_dtests_py38_vnode 7m 9s
✓ j17_cqlshlib_cython_tests7m 28s
✓ j17_cqlshlib_tests 6m 39s
✓ j17_dtests 36m 52s
✓ j17_dtests_latest 39m 17s
✓ j17_dtests_vnode34m 48s
✓ j17_unit_tests_repeat 15m 42s
✓ j17_utests_latest 13m 28s
✓ j17_utests_latest_repeat15m 43s
✓ j17_utests_oa 15m 15s
✓ j17_utests_oa_repeat15m 14s
✕ j17_cqlsh_dtests_py311 7m 23s
cqlsh_tests.test_cqlsh_copy.TestCqlshCopy
test_bulk_round_trip_with_timeouts
✕ j17_jvm_dtests 24m 7s
✕ j17_jvm_dtests_latest_vnode 22m 33s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
org.apache.cassandra.distributed.test.tcm.CMSPlacementAfterMoveTest
testMoveToCMS
✕ j17_unit_tests 13m 18s
org.apache.cassandra.db.commitlog.CommitlogShutdownTest
testShutdownWithPendingTasks
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4466/workflows/60f9652a-dd46-4a5f-9491-ac6261104815]
> Expose current compaction throughput
>
>
> Key: CASSANDRA-13890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13890
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Jon Haddad
>Assignee: Ling Mao
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Getting and setting the current compaction throughput limit is supported, but
> there's no means of knowing if the setting is actually making a difference.
> Let's expose the current throughput being utilized by Cassandra that's in the
> {{compactionRateLimiter}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863060#comment-17863060
]
Stefan Miklosovic commented on CASSANDRA-19130:
---
Even better, not allowing truncations in mixed version cluster is fine to me.
Also, the suggestion made in CASSANDRA-19556 about forbidding schema
modifications by adding a system property / flag for that might be indeed
extended to forbidding truncations as well.
> Implement transactional table truncation
>
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TRUNCATE table should leverage cluster metadata to ensure consistent
> truncation timestamps across all replicas. The current implementation depends
> on all nodes being available, but this could be reimplemented as a
> {{Transformation}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863056#comment-17863056
]
Sam Tunnicliffe commented on CASSANDRA-19130:
-
To be honest, I would simply not permit truncations in a mixed version cluster.
We already don't allow schema or topology changes in this scenario, to the
extent that if the request is received by an upgraded node, it will reject it
if all other nodes are not yet in a compatible state. The caveat is that if the
coordinator is still running the previous version, there is no means to reject
in the same way - hence discussion{^}[1][2]{^} about adding an operator control
to do this manually in a 5.0.x and advising that upgrades go through that
version.
[1]
[https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata#CEP21:TransactionalClusterMetadata-MigrationPlan]
[2]
https://issues.apache.org/jira/browse/CASSANDRA-19556?focusedCommentId=17848544=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17848544
> Implement transactional table truncation
>
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TRUNCATE table should leverage cluster metadata to ensure consistent
> truncation timestamps across all replicas. The current implementation depends
> on all nodes being available, but this could be reimplemented as a
> {{Transformation}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19750) /etc/cassandra/cassandra-jaas.config does not exist in Packages install
[ https://issues.apache.org/jira/browse/CASSANDRA-19750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19750: - Bug Category: Parent values: Packaging(13660) Complexity: Normal Component/s: Packaging Discovered By: User Report Fix Version/s: 3.11.x 4.0.x 4.1.x 5.0.x 5.x Severity: Normal Status: Open (was: Triage Needed) > /etc/cassandra/cassandra-jaas.config does not exist in Packages install > --- > > Key: CASSANDRA-19750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19750 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Johnny Miller >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > When installing cassandra 4.1.5 wth the debian packaged installer the file > cassandra-jaas.config does not exist. > When enabling JMX authentication in the cassandra-env.sh you uncomment the > line JVM_OPTS="$JVM_OPTS > -Djava.security.auth.login.config=$CASSANDRA_CONF/cassandra-jaas.config" > It is expecting this file to be in this location (which maps to > /etc/cassandra/) and it is not. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19750) /etc/cassandra/cassandra-jaas.config does not exist in Packages install
[ https://issues.apache.org/jira/browse/CASSANDRA-19750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863047#comment-17863047 ] Brandon Williams commented on CASSANDRA-19750: -- This isn't in the redhat packaging either. > /etc/cassandra/cassandra-jaas.config does not exist in Packages install > --- > > Key: CASSANDRA-19750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19750 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Johnny Miller >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > When installing cassandra 4.1.5 wth the debian packaged installer the file > cassandra-jaas.config does not exist. > When enabling JMX authentication in the cassandra-env.sh you uncomment the > line JVM_OPTS="$JVM_OPTS > -Djava.security.auth.login.config=$CASSANDRA_CONF/cassandra-jaas.config" > It is expecting this file to be in this location (which maps to > /etc/cassandra/) and it is not. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19750) /etc/cassandra/cassandra-jaas.config does not exist in Packages install
[ https://issues.apache.org/jira/browse/CASSANDRA-19750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19750: - Summary: /etc/cassandra/cassandra-jaas.config does not exist in Packages install (was: /etc/cassandra/cassandra-jaas.config does not exist in debian/ubuntu Packages install for 4.1.5) > /etc/cassandra/cassandra-jaas.config does not exist in Packages install > --- > > Key: CASSANDRA-19750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19750 > Project: Cassandra > Issue Type: Bug >Reporter: Johnny Miller >Priority: Normal > > When installing cassandra 4.1.5 wth the debian packaged installer the file > cassandra-jaas.config does not exist. > When enabling JMX authentication in the cassandra-env.sh you uncomment the > line JVM_OPTS="$JVM_OPTS > -Djava.security.auth.login.config=$CASSANDRA_CONF/cassandra-jaas.config" > It is expecting this file to be in this location (which maps to > /etc/cassandra/) and it is not. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863044#comment-17863044
]
Stefan Miklosovic commented on CASSANDRA-19747:
---
[CASSANDRA-19747-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19747-trunk]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 48s
✓ j17_cqlsh_dtests_py3117m 2s
✓ j17_cqlsh_dtests_py311_vnode 7m 15s
✓ j17_cqlsh_dtests_py387m 18s
✓ j17_cqlsh_dtests_py38_vnode 7m 14s
✓ j17_cqlshlib_cython_tests9m 39s
✓ j17_cqlshlib_tests7m 4s
✓ j17_dtests 36m 45s
✓ j17_dtests_latest 36m 11s
✓ j17_unit_tests 14m 39s
✓ j17_unit_tests_repeat 4m 2s
✓ j17_utests_latest 17m 18s
✓ j17_utests_latest_repeat 3m 57s
✓ j17_utests_oa_repeat 4m 51s
✕ j17_dtests_vnode49m 31s
bootstrap_test.TestBootstrap
test_consistent_range_movement_false_with_replica_down_should_succeed
bootstrap_test.TestBootstrap test_shutdown_wiped_node_cannot_join
✕ j17_jvm_dtests 23m 43s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testOptionalMtlsModeDoNotAllowNonSSLConnections
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
✕ j17_jvm_dtests_latest_vnode 22m 13s
org.apache.cassandra.distributed.test.tcm.CMSPlacementAfterMoveTest
testMoveToCMS
org.apache.cassandra.distributed.test.tcm.SplitBrainTest
testSplitBrainStartup
✕ j17_utests_oa 14m 12s
org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4465/workflows/79911554-8523-485d-9fae-2a2bd8f0c70
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After dropping at least 2 fields the schema.cql produced by _nodetool
> snapshot_ is invalid (it is missing a comma)
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID ...{code}
> expected outcome
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text,
> field3 text
> ) WITH ID ...{code}
> reproducing the isue is simple by running the following commands
> {code:sh}
> docker run -d --name cassandra cassandra:4.1.5
> echo "Wait for the container to start"
> until docker exec -ti cassandra nodetool status | grep UN;do sleep
> 1;done;sleep 10
> echo "Create keyspace and table for test"
> docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
> TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2
> text,field3 text);"
> echo "Drop 2 fields"
> docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
> field3);"
> echo "Create snapshot and view schema.cql"
> docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
> docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql
> -exec cat {} + {code}
> the full output of the sql generated by the reproduce is below
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.Si
[jira] [Created] (CASSANDRA-19750) /etc/cassandra/cassandra-jaas.config does not exist in debian/ubuntu Packages install for 4.1.5
Johnny Miller created CASSANDRA-19750: - Summary: /etc/cassandra/cassandra-jaas.config does not exist in debian/ubuntu Packages install for 4.1.5 Key: CASSANDRA-19750 URL: https://issues.apache.org/jira/browse/CASSANDRA-19750 Project: Cassandra Issue Type: Bug Reporter: Johnny Miller When installing cassandra 4.1.5 wth the debian packaged installer the file cassandra-jaas.config does not exist. When enabling JMX authentication in the cassandra-env.sh you uncomment the line JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config=$CASSANDRA_CONF/cassandra-jaas.config" It is expecting this file to be in this location (which maps to /etc/cassandra/) and it is not. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863020#comment-17863020
]
Stefan Miklosovic edited comment on CASSANDRA-16916 at 7/4/24 12:32 PM:
[~bereng] [~blerer]
I think this feature was broken on delivery. I think we did a pretty poor job
while testing it as CASSANDRA-19749 shows.
this code:
[https://github.com/apache/cassandra/commit/e137c7c34cc10d4f8c9124c6f9af17a44061ab1f#diff-9c7fbde9c5b432f9ce35424491d70e572567712cdfe08f048d5278bb9460223d]
IF you notice, it just tests the syntax when it comes to roles / users. It is
actually never testing the functionality itself which CASSANDRA-19749
discovered.
{code:java}
cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER =
true ;
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
+---+--+---+--
this_role_is_not_there | null | True | null |
null
cassandra | True | True | null |
$2a$10$.3sia/S1SL6Y7MTHN3DdUu79QnKdvcARLiIMCHgQLVOVaDZA1VnPW
{code}
was (Author: smiklosovic):
[~bereng] [~blerer]
I think this feature was broken on delivery. I think we did a pretty poor job
while testing it as CASSANDRA-19749 shows.
this code:
[https://github.com/apache/cassandra/commit/e137c7c34cc10d4f8c9124c6f9af17a44061ab1f#diff-9c7fbde9c5b432f9ce35424491d70e572567712cdfe08f048d5278bb9460223d]
IF you notice, it just tests the syntax when it comes to roles / users. It is
actually never testing the functionality itself which CASSANDRA-19749
discovered.
{code:java}
cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER =
true ;
cassandra@cqlsh> select * from system_auth.roles; role |
can_login | is_superuser | member_of | salted_hash
+---+--+---+--
this_role_is_not_there | null | True | null |
null
cassandra | True | True | null |
$2a$10$.3sia/S1SL6Y7MTHN3DdUu79QnKdvcARLiIMCHgQLVOVaDZA1VnPW
{code}
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
> Fix For: 4.1-alpha1, 4.1
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863020#comment-17863020
]
Stefan Miklosovic edited comment on CASSANDRA-16916 at 7/4/24 12:32 PM:
[~bereng] [~blerer]
I think this feature was broken on delivery. I think we did a pretty poor job
while testing it as CASSANDRA-19749 shows.
this code:
[https://github.com/apache/cassandra/commit/e137c7c34cc10d4f8c9124c6f9af17a44061ab1f#diff-9c7fbde9c5b432f9ce35424491d70e572567712cdfe08f048d5278bb9460223d]
IF you notice, it just tests the syntax when it comes to roles / users. It is
actually never testing the functionality itself which CASSANDRA-19749
discovered.
{code:java}
cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER =
true ;
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
+---+--+---+--
this_role_is_not_there | null | True | null |
null
cassandra | True | True | null |
$2a$10$.3sia/S1SL6Y7MTHN3DdUu79QnKdvcARLiIMCHgQLVOVaDZA1VnPW
{code}
was (Author: smiklosovic):
[~bereng] [~blerer]
I think this feature was broken on delivery. I think we did a pretty poor job
while testing it as CASSANDRA-19749 shows.
this code:
[https://github.com/apache/cassandra/commit/e137c7c34cc10d4f8c9124c6f9af17a44061ab1f#diff-9c7fbde9c5b432f9ce35424491d70e572567712cdfe08f048d5278bb9460223d]
IF you notice, it just tests the syntax when it comes to roles / users. It is
actually never testing the functionality itself which CASSANDRA-19749
discovered.
{code:java}
cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER =
true ;
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
+---+--+---+--
this_role_is_not_there | null | True | null |
null
cassandra | True | True | null |
$2a$10$.3sia/S1SL6Y7MTHN3DdUu79QnKdvcARLiIMCHgQLVOVaDZA1VnPW
{code}
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
> Fix For: 4.1-alpha1, 4.1
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19749) ALTER USER | ROLE IF EXISTS creates a user / role if it does not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-19749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19749:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Implementation(12988)
Complexity: Normal
Component/s: Legacy/CQL
Discovered By: Adhoc Test
Fix Version/s: 4.1.x
5.0.x
5.x
Severity: Normal
Assignee: Stefan Miklosovic
Status: Open (was: Triage Needed)
> ALTER USER | ROLE IF EXISTS creates a user / role if it does not exist
> --
>
> Key: CASSANDRA-19749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19749
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Let's have:
> {code}
> authenticator:
> class_name : org.apache.cassandra.auth.PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> {code}
> and do this:
> {code}
> cassandra@cqlsh> select * from system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
> {code}
> Then
> {code}
> cassandra@cqlsh> ALTER USER IF EXISTS this_does_not_exist SUPERUSER ;
> cassandra@cqlsh> select * from system_auth.roles where role =
> 'this_does_not_exist';
> role| can_login | is_superuser | member_of | salted_hash
> -+---+--+---+-
> this_does_not_exist | null | True | null |null
> {code}
> It seems to be same behaviour for ALTER ROLE too.
> {code}
> cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER =
> true ;
> cassandra@cqlsh> select * from system_auth.roles where role =
> 'this_role_is_not_there';
> role | can_login | is_superuser | member_of | salted_hash
> +---+--+---+-
> this_role_is_not_there | null | True | null |null
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863020#comment-17863020
]
Stefan Miklosovic edited comment on CASSANDRA-16916 at 7/4/24 12:21 PM:
[~bereng] [~blerer]
I think this feature was broken on delivery. I think we did a pretty poor job
while testing it as CASSANDRA-19749 shows.
this code:
[https://github.com/apache/cassandra/commit/e137c7c34cc10d4f8c9124c6f9af17a44061ab1f#diff-9c7fbde9c5b432f9ce35424491d70e572567712cdfe08f048d5278bb9460223d]
IF you notice, it just tests the syntax when it comes to roles / users. It is
actually never testing the functionality itself which CASSANDRA-19749
discovered.
{code:java}
cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER =
true ;
cassandra@cqlsh> select * from system_auth.roles; role |
can_login | is_superuser | member_of | salted_hash
+---+--+---+--
this_role_is_not_there | null | True | null |
null
cassandra | True | True | null |
$2a$10$.3sia/S1SL6Y7MTHN3DdUu79QnKdvcARLiIMCHgQLVOVaDZA1VnPW
{code}
was (Author: smiklosovic):
[~bereng] [~blerer]
I think this feature was broken on delivery. I think we did a pretty poor job
while testing it as CASSANDRA-19749 shows.
this code:
[https://github.com/apache/cassandra/commit/e137c7c34cc10d4f8c9124c6f9af17a44061ab1f#diff-9c7fbde9c5b432f9ce35424491d70e572567712cdfe08f048d5278bb9460223d]
IF you notice, it just tests the syntax when it comes to roles / users. It is
actually never testing the functionality itself which CASSANDRA-19749
discovered.
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
> Fix For: 4.1-alpha1, 4.1
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863020#comment-17863020
]
Stefan Miklosovic edited comment on CASSANDRA-16916 at 7/4/24 12:20 PM:
[~bereng] [~blerer]
I think this feature was broken on delivery. I think we did a pretty poor job
while testing it as CASSANDRA-19749 shows.
this code:
[https://github.com/apache/cassandra/commit/e137c7c34cc10d4f8c9124c6f9af17a44061ab1f#diff-9c7fbde9c5b432f9ce35424491d70e572567712cdfe08f048d5278bb9460223d]
IF you notice, it just tests the syntax when it comes to roles / users. It is
actually never testing the functionality itself which CASSANDRA-19749
discovered.
was (Author: smiklosovic):
[~bereng] [~blerer]
I think this feature was broken on delivery. I think we did a pretty poor job
while testing it as CASSANDRA-19749 shows.
this code:
[https://github.com/apache/cassandra/commit/e137c7c34cc10d4f8c9124c6f9af17a44061ab1f#diff-9c7fbde9c5b432f9ce35424491d70e572567712cdfe08f048d5278bb9460223d]
IF you notice, it just tests the syntax when it comes to roles / users. It is
actually never testing the functionality itself which CASSANDRA_19749
discovered.
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
> Fix For: 4.1-alpha1, 4.1
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863020#comment-17863020
]
Stefan Miklosovic commented on CASSANDRA-16916:
---
[~bereng] [~blerer]
I think this feature was broken on delivery. I think we did a pretty poor job
while testing it as CASSANDRA-19749 shows.
this code:
[https://github.com/apache/cassandra/commit/e137c7c34cc10d4f8c9124c6f9af17a44061ab1f#diff-9c7fbde9c5b432f9ce35424491d70e572567712cdfe08f048d5278bb9460223d]
IF you notice, it just tests the syntax when it comes to roles / users. It is
actually never testing the functionality itself which CASSANDRA_19749
discovered.
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
> Fix For: 4.1-alpha1, 4.1
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19749) ALTER USER | ROLE IF EXISTS creates a user / role if it does not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-19749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19749:
--
Summary: ALTER USER | ROLE IF EXISTS creates a user / role if it does not
exist (was: ALTER USER IF EXISTS creates a user if it does not exist)
> ALTER USER | ROLE IF EXISTS creates a user / role if it does not exist
> --
>
> Key: CASSANDRA-19749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19749
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Let's have:
> {code}
> authenticator:
> class_name : org.apache.cassandra.auth.PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> {code}
> and do this:
> {code}
> cassandra@cqlsh> select * from system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
> {code}
> Then
> {code}
> cassandra@cqlsh> ALTER USER IF EXISTS this_does_not_exist SUPERUSER ;
> cassandra@cqlsh> select * from system_auth.roles where role =
> 'this_does_not_exist';
> role| can_login | is_superuser | member_of | salted_hash
> -+---+--+---+-
> this_does_not_exist | null | True | null |null
> {code}
> It seems to be same behaviour for ALTER ROLE too.
> {code}
> cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER =
> true ;
> cassandra@cqlsh> select * from system_auth.roles where role =
> 'this_role_is_not_there';
> role | can_login | is_superuser | member_of | salted_hash
> +---+--+---+-----
> this_role_is_not_there | null | True | null |null
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19749) ALTER USER IF EXISTS creates a user if it does not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-19749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19749:
--
Description:
Let's have:
{code}
authenticator:
class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}
and do this:
{code}
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
---+---+--+---+--
cassandra | True | True | null |
$2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
{code}
Then
{code}
cassandra@cqlsh> ALTER USER IF EXISTS this_does_not_exist SUPERUSER ;
cassandra@cqlsh> select * from system_auth.roles where role =
'this_does_not_exist';
role| can_login | is_superuser | member_of | salted_hash
-+---+--+---+-
this_does_not_exist | null | True | null |null
{code}
It seems to be same behaviour for ALTER ROLE too.
{code}
cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER =
true ;
cassandra@cqlsh> select * from system_auth.roles where role =
'this_role_is_not_there';
role | can_login | is_superuser | member_of | salted_hash
+---+--+---+-
this_role_is_not_there | null | True | null |null
{code}
was:
Let's have:
{code}
authenticator:
class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}
and do this:
{code}
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
---+---+--+---+--
cassandra | True | True | null |
$2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
{code}
Then
{code}
cassandra@cqlsh> ALTER USER IF EXISTS this_does_not_exist SUPERUSER ;
cassandra@cqlsh> select * from system_auth.roles where role =
'this_does_not_exist';
role| can_login | is_superuser | member_of | salted_hash
-+---+--+---+-
this_does_not_exist | null | True | null |null
{code}
> ALTER USER IF EXISTS creates a user if it does not exist
>
>
> Key: CASSANDRA-19749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19749
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Let's have:
> {code}
> authenticator:
> class_name : org.apache.cassandra.auth.PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> {code}
> and do this:
> {code}
> cassandra@cqlsh> select * from system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
> {code}
> Then
> {code}
> cassandra@cqlsh> ALTER USER IF EXISTS this_does_not_exist SUPERUSER ;
> cassandra@cqlsh> select * from system_auth.roles where role =
> 'this_does_not_exist';
> role| can_login | is_superuser | member_of | salted_hash
> -+---+--+---+-
> this_does_not_exist | null | True | null |null
> {code}
> It seems to be same behaviour for ALTER ROLE too.
> {code}
> cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER =
> true ;
> cassandra@cqlsh> select * from system_auth.roles where role =
> 'this_role_is_not_there';
> role | can_login | is_superuser | member_of | salted_hash
> +---+--+---+-
> this_role_is_not_there | null | True | null |null
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19749) ALTER USER IF EXISTS creates a user if it does not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-19749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19749:
--
Description:
Let's have:
{code}
authenticator:
class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}
and do this:
{code}
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
---+---+--+---+--
cassandra | True | True | null |
$2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
{code}
Then
{code}
cassandra@cqlsh> ALTER USER IF EXISTS this_does_not_exist SUPERUSER ;
cassandra@cqlsh> select * from system_auth.roles where role =
'this_does_not_exist';
role| can_login | is_superuser | member_of | salted_hash
-+---+--+---+-
this_does_not_exist | null | True | null |null
{code}
was:
Let's have:
{code}
authenticator:
class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}
and do this:
{code}
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
---+---+--+---+--
cassandra | True | True | null |
$2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
{code}
Then
{code}
cassandra@cqlsh> ALTER USER IF EXISTS this_role_does_not_exist SUPERUSER ;
cassandra@cqlsh> select * from system_auth.roles where role =
'this_does_not_exist';
role| can_login | is_superuser | member_of | salted_hash
-+---+--+---+-
this_does_not_exist | null | True | null |null
{code}
> ALTER USER IF EXISTS creates a user if it does not exist
>
>
> Key: CASSANDRA-19749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19749
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Let's have:
> {code}
> authenticator:
> class_name : org.apache.cassandra.auth.PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> {code}
> and do this:
> {code}
> cassandra@cqlsh> select * from system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
> {code}
> Then
> {code}
> cassandra@cqlsh> ALTER USER IF EXISTS this_does_not_exist SUPERUSER ;
> cassandra@cqlsh> select * from system_auth.roles where role =
> 'this_does_not_exist';
> role| can_login | is_superuser | member_of | salted_hash
> -+---+--+---+-
> this_does_not_exist | null | True | null |null
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19749) ALTER USER IF EXISTS creates a user if it does not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-19749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19749:
--
Description:
Let's have:
{code}
authenticator:
class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}
and do this:
{code}
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
---+---+--+---+--
cassandra | True | True | null |
$2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
{code}
Then
{code}
cassandra@cqlsh> ALTER USER IF EXISTS this_role_does_not_exist SUPERUSER ;
cassandra@cqlsh> select * from system_auth.roles where role =
'this_does_not_exist';
role| can_login | is_superuser | member_of | salted_hash
-+---+--+---+-
this_does_not_exist | null | True | null |null
{code}
was:
Let's have:
{code}
authenticator:
class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}
and do this:
{code}
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
---+---+--+---+--
cassandra | True | True | null |
$2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
{code}
Then
{code}
cassandra@cqlsh> select * from system_auth.roles where role =
'this_does_not_exist';
role| can_login | is_superuser | member_of | salted_hash
-+---+--+---+-
this_does_not_exist | null | True | null |null
{code}
> ALTER USER IF EXISTS creates a user if it does not exist
>
>
> Key: CASSANDRA-19749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19749
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Let's have:
> {code}
> authenticator:
> class_name : org.apache.cassandra.auth.PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> {code}
> and do this:
> {code}
> cassandra@cqlsh> select * from system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
> {code}
> Then
> {code}
> cassandra@cqlsh> ALTER USER IF EXISTS this_role_does_not_exist SUPERUSER ;
> cassandra@cqlsh> select * from system_auth.roles where role =
> 'this_does_not_exist';
> role| can_login | is_superuser | member_of | salted_hash
> -+---+--+---+-
> this_does_not_exist | null | True | null |null
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19749) ALTER USER IF EXISTS creates a user if it does not exist
Stefan Miklosovic created CASSANDRA-19749:
-
Summary: ALTER USER IF EXISTS creates a user if it does not exist
Key: CASSANDRA-19749
URL: https://issues.apache.org/jira/browse/CASSANDRA-19749
Project: Cassandra
Issue Type: Bug
Reporter: Stefan Miklosovic
Let's have:
{code}
authenticator:
class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}
and do this:
{code}
cassandra@cqlsh> select * from system_auth.roles where role = 'cassandra';
role | can_login | is_superuser | member_of | salted_hash
---+---+--+---+--
cassandra | True | True | null |
$2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
{code}
Then
{code}
cassandra@cqlsh> select * from system_auth.roles where role =
'this_does_not_exist';
role| can_login | is_superuser | member_of | salted_hash
-+---+--+---+-
this_does_not_exist | null | True | null |null
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19749) ALTER USER IF EXISTS creates a user if it does not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-19749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19749:
--
Description:
Let's have:
{code}
authenticator:
class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}
and do this:
{code}
cassandra@cqlsh> select * from system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
---+---+--+---+--
cassandra | True | True | null |
$2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
{code}
Then
{code}
cassandra@cqlsh> select * from system_auth.roles where role =
'this_does_not_exist';
role| can_login | is_superuser | member_of | salted_hash
-+---+--+---+-
this_does_not_exist | null | True | null |null
{code}
was:
Let's have:
{code}
authenticator:
class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}
and do this:
{code}
cassandra@cqlsh> select * from system_auth.roles where role = 'cassandra';
role | can_login | is_superuser | member_of | salted_hash
---+---+--+---+--
cassandra | True | True | null |
$2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
{code}
Then
{code}
cassandra@cqlsh> select * from system_auth.roles where role =
'this_does_not_exist';
role| can_login | is_superuser | member_of | salted_hash
-+---+--+---+-
this_does_not_exist | null | True | null |null
{code}
> ALTER USER IF EXISTS creates a user if it does not exist
>
>
> Key: CASSANDRA-19749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19749
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Let's have:
> {code}
> authenticator:
> class_name : org.apache.cassandra.auth.PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> {code}
> and do this:
> {code}
> cassandra@cqlsh> select * from system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S
> {code}
> Then
> {code}
> cassandra@cqlsh> select * from system_auth.roles where role =
> 'this_does_not_exist';
> role| can_login | is_superuser | member_of | salted_hash
> -+---+--+---+-
> this_does_not_exist | null | True | null |null
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862993#comment-17862993
]
Stefan Miklosovic commented on CASSANDRA-19747:
---
[CASSANDRA-19747-4.1|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19747-4.1]
{noformat}
java11_pre-commit_tests
✓ j11_build1m 38s
✓ j11_cqlsh_dtests_py3 5m 52s
✓ j11_cqlsh_dtests_py311 5m 44s
✓ j11_cqlsh_dtests_py311_vnode 5m 48s
✓ j11_cqlsh_dtests_py385m 48s
✓ j11_cqlsh_dtests_py38_vnode 5m 54s
✓ j11_cqlsh_dtests_py3_vnode 5m 30s
✓ j11_cqlshlib_cython_tests7m 18s
✓ j11_cqlshlib_tests 6m 38s
✓ j11_jvm_dtests_vnode15m 40s
✓ j11_unit_tests_repeat2m 47s
✕ j11_dtests 35m 53s
largecolumn_test.TestLargeColumn test_cleanup
✕ j11_dtests_vnode 36m 2s
largecolumn_test.TestLargeColumn test_cleanup
✕ j11_jvm_dtests 16m 23s
org.apache.cassandra.distributed.test.ReadRepairTest
readRepairRTRangeMovementTest
✕ j11_unit_tests 9m 17s
org.apache.cassandra.cql3.MemtableSizeTest testSize[skiplist]
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4464/workflows/70021489-ed7b-4f06-af3e-5060b0b13d43]
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After dropping at least 2 fields the schema.cql produced by _nodetool
> snapshot_ is invalid (it is missing a comma)
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID ...{code}
> expected outcome
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text,
> field3 text
> ) WITH ID ...{code}
> reproducing the isue is simple by running the following commands
> {code:sh}
> docker run -d --name cassandra cassandra:4.1.5
> echo "Wait for the container to start"
> until docker exec -ti cassandra nodetool status | grep UN;do sleep
> 1;done;sleep 10
> echo "Create keyspace and table for test"
> docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
> TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2
> text,field3 text);"
> echo "Drop 2 fields"
> docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
> field3);"
> echo "Create snapshot and view schema.cql"
> docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
> docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql
> -exec cat {} + {code}
> the full output of the sql generated by the reproduce is below
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> ALTER TABLE te
[jira] [Commented] (CASSANDRA-19665) Add download link for Java drivers from download page
[ https://issues.apache.org/jira/browse/CASSANDRA-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862969#comment-17862969 ] Michael Semb Wever commented on CASSANDRA-19665: bq. I replaced my original branch with a new one, and the PR-277 has the same changes as 276. LGTM, +1 > Add download link for Java drivers from download page > - > > Key: CASSANDRA-19665 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19665 > Project: Cassandra > Issue Type: Task > Components: Client/java-driver, Documentation/Website >Reporter: Bret McGuire >Assignee: Brad Schoening >Priority: Normal > Labels: pull-request-available > > Seems like we should have a link to download Java drivers from the [download > page|https://cassandra.apache.org/_/download.html] on the Website -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18508:
---
Component/s: Local/Config
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Anthony Grasso
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-13428:
---
Component/s: Feature/Encryption
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19748) [Analytics] Refactor Analytics to move standalone code into common module with minimal dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-19748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Berragan updated CASSANDRA-19748: --- Change Category: Code Clarity Complexity: Low Hanging Fruit Fix Version/s: NA Reviewers: Yuriy Semchyshyn Priority: Low (was: Normal) Status: Open (was: Triage Needed) > [Analytics] Refactor Analytics to move standalone code into common module > with minimal dependencies > --- > > Key: CASSANDRA-19748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19748 > Project: Cassandra > Issue Type: Improvement > Components: Analytics Library >Reporter: James Berragan >Priority: Low > Fix For: NA > > > The Analytics codebase is heavily tied to Spark. In an effort to re-use code > across projects (like CDC) we should move standalone Pojos and util classes > into an cassandra-analytics-common module that exists standalone without > dependencies to Cassandra or Spark and with minimal standard dependencies > (Kryo, Guava, Jackson, Apache Commons Lang etc). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19748) [Analytics] Refactor Analytics to move standalone code into common module with minimal dependencies
James Berragan created CASSANDRA-19748: -- Summary: [Analytics] Refactor Analytics to move standalone code into common module with minimal dependencies Key: CASSANDRA-19748 URL: https://issues.apache.org/jira/browse/CASSANDRA-19748 Project: Cassandra Issue Type: Improvement Components: Analytics Library Reporter: James Berragan The Analytics codebase is heavily tied to Spark. In an effort to re-use code across projects (like CDC) we should move standalone Pojos and util classes into an cassandra-analytics-common module that exists standalone without dependencies to Cassandra or Spark and with minimal standard dependencies (Kryo, Guava, Jackson, Apache Commons Lang etc). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19747:
--
Status: Needs Committer (was: Patch Available)
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After dropping at least 2 fields the schema.cql produced by _nodetool
> snapshot_ is invalid (it is missing a comma)
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID ...{code}
> expected outcome
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text,
> field3 text
> ) WITH ID ...{code}
> reproducing the isue is simple by running the following commands
> {code:sh}
> docker run -d --name cassandra cassandra:4.1.5
> echo "Wait for the container to start"
> until docker exec -ti cassandra nodetool status | grep UN;do sleep
> 1;done;sleep 10
> echo "Create keyspace and table for test"
> docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
> TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2
> text,field3 text);"
> echo "Drop 2 fields"
> docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
> field3);"
> echo "Create snapshot and view schema.cql"
> docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
> docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql
> -exec cat {} + {code}
> the full output of the sql generated by the reproduce is below
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> ALTER TABLE test.testtable DROP field2 USING TIMESTAMP 171102807000;
> ALTER TABLE test.testtable DROP field3 USING TIMESTAMP 171102807001;
> {code}
> Found this bug while trying to restore the schema from a backup created by
> copying a snapshot from a running node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862875#comment-17862875
]
Stefan Miklosovic commented on CASSANDRA-19747:
---
[CASSANDRA-19747-4.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19747-4.0]
{noformat}
java11_pre-commit_tests
✓ j11_build1m 29s
✓ j11_cqlsh-dtests-py2-no-vnodes 5m 34s
✓ j11_cqlsh-dtests-py2-with-vnodes 5m 33s
✓ j11_cqlsh_dtests_py3 5m 24s
✓ j11_cqlsh_dtests_py311 5m 41s
✓ j11_cqlsh_dtests_py311_vnode 5m 35s
✓ j11_cqlsh_dtests_py385m 50s
✓ j11_cqlsh_dtests_py38_vnode 5m 50s
✓ j11_cqlsh_dtests_py3_vnode 5m 51s
✓ j11_cqlshlib_tests 7m 35s
✓ j11_dtests 33m 46s
✓ j11_dtests_vnode 35m 5s
✓ j11_jvm_dtests 9m 26s
✓ j11_unit_tests_repeat3m 15s
✕ j11_unit_tests8m 9s
org.apache.cassandra.cql3.MemtableSizeTest testTruncationReleasesLogSpace
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4463/workflows/e22e6a6b-cb68-4995-bd0f-9239997f0931]
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After dropping at least 2 fields the schema.cql produced by _nodetool
> snapshot_ is invalid (it is missing a comma)
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID ...{code}
> expected outcome
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text,
> field3 text
> ) WITH ID ...{code}
> reproducing the isue is simple by running the following commands
> {code:sh}
> docker run -d --name cassandra cassandra:4.1.5
> echo "Wait for the container to start"
> until docker exec -ti cassandra nodetool status | grep UN;do sleep
> 1;done;sleep 10
> echo "Create keyspace and table for test"
> docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
> TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2
> text,field3 text);"
> echo "Drop 2 fields"
> docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
> field3);"
> echo "Create snapshot and view schema.cql"
> docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
> docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql
> -exec cat {} + {code}
> the full output of the sql generated by the reproduce is below
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> ALTER TABLE test.testtable DROP field2 USING TIMESTAMP 171102807000;
> ALTER TABLE test.testtable DROP field3 USING TIMESTAMP 171102807001;
> {code}
[jira] [Comment Edited] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[ https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862873#comment-17862873 ] Josh McKenzie edited comment on CASSANDRA-18831 at 7/3/24 7:25 PM: --- Pushed another [commit|https://github.com/jmckenzie-dev/cassandra/commit/d6424ad6e01295f691ea5ebe31e1350ad89b9dda] that takes JDK21 support to passing unit and in-jvm dtests. The branch should be in a state where we can start doing prelim perf testing and fuzz testing against it. Specifying no UseCompressedOops to work around jamm having incorrect default if not specified for JDK21; annotated to change that in lockstep w/ZGC in the .options file. Plan to get python dtests into a good place and do some testing with genZGC; will update as more comes online. was (Author: jmckenzie): Pushed another commit that takes JDK21 support to passing unit and in-jvm dtests. The branch should be in a state where we can start doing prelim perf testing and fuzz testing against it. Specifying no UseCompressedOops to work around jamm having incorrect default if not specified for JDK21; annotated to change that in lockstep w/ZGC in the .options file. Plan to get python dtests into a good place and do some testing with genZGC; will update as more comes online. > Enable Cassandra to build and run under JDK21 > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Assignee: Josh McKenzie >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18831) JDK21 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-18831: -- Summary: JDK21 support (was: Enable Cassandra to build and run under JDK21) > JDK21 support > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Assignee: Josh McKenzie >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[ https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862873#comment-17862873 ] Josh McKenzie commented on CASSANDRA-18831: --- Pushed another commit that takes JDK21 support to passing unit and in-jvm dtests. The branch should be in a state where we can start doing prelim perf testing and fuzz testing against it. Specifying no UseCompressedOops to work around jamm having incorrect default if not specified for JDK21; annotated to change that in lockstep w/ZGC in the .options file. Plan to get python dtests into a good place and do some testing with genZGC; will update as more comes online. > Enable Cassandra to build and run under JDK21 > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Assignee: Josh McKenzie >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19665) Add download link for Java drivers from download page
[ https://issues.apache.org/jira/browse/CASSANDRA-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862871#comment-17862871 ] Brad Schoening commented on CASSANDRA-19665: [~mck] [~absurdfarce] I replaced my original branch with a new one, and the PR-277 has the same changes as 276. If you could just give that a thumbs up pls. > Add download link for Java drivers from download page > - > > Key: CASSANDRA-19665 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19665 > Project: Cassandra > Issue Type: Task > Components: Client/java-driver, Documentation/Website >Reporter: Bret McGuire >Assignee: Brad Schoening >Priority: Normal > Labels: pull-request-available > > Seems like we should have a link to download Java drivers from the [download > page|https://cassandra.apache.org/_/download.html] on the Website -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19747:
--
Fix Version/s: 4.0.x
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After dropping at least 2 fields the schema.cql produced by _nodetool
> snapshot_ is invalid (it is missing a comma)
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID ...{code}
> expected outcome
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text,
> field3 text
> ) WITH ID ...{code}
> reproducing the isue is simple by running the following commands
> {code:sh}
> docker run -d --name cassandra cassandra:4.1.5
> echo "Wait for the container to start"
> until docker exec -ti cassandra nodetool status | grep UN;do sleep
> 1;done;sleep 10
> echo "Create keyspace and table for test"
> docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
> TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2
> text,field3 text);"
> echo "Drop 2 fields"
> docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
> field3);"
> echo "Create snapshot and view schema.cql"
> docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
> docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql
> -exec cat {} + {code}
> the full output of the sql generated by the reproduce is below
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> ALTER TABLE test.testtable DROP field2 USING TIMESTAMP 171102807000;
> ALTER TABLE test.testtable DROP field3 USING TIMESTAMP 171102807001;
> {code}
> Found this bug while trying to restore the schema from a backup created by
> copying a snapshot from a running node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862850#comment-17862850
]
Stefan Miklosovic commented on CASSANDRA-19747:
---
[CASSANDRA-19747-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19747-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build3m 33s
✓ j17_cqlsh_dtests_py3116m 3s
✓ j17_cqlsh_dtests_py311_vnode 6m 14s
✓ j17_cqlsh_dtests_py38 6m 5s
✓ j17_cqlsh_dtests_py38_vnode 6m 14s
✓ j17_cqlshlib_cython_tests7m 16s
✓ j17_cqlshlib_tests 8m 41s
✓ j17_dtests 34m 11s
✓ j17_dtests_latest 33m 40s
✓ j17_dtests_vnode34m 25s
✓ j17_jvm_dtests 23m 54s
✓ j17_jvm_dtests_latest_vnode 15m 17s
✓ j17_unit_tests 15m 1s
✓ j17_unit_tests_repeat3m 12s
✓ j17_utests_latest 12m 55s
✓ j17_utests_latest_repeat 3m 6s
✓ j17_utests_oa_repeat 3m 49s
✕ j17_utests_oa 13m 47s
org.apache.cassandra.net.ConnectionTest testTimeout
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4462/workflows/0ece8db5-d6c5-433d-9978-50a5bd05c0ab]
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After dropping at least 2 fields the schema.cql produced by _nodetool
> snapshot_ is invalid (it is missing a comma)
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID ...{code}
> expected outcome
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text,
> field3 text
> ) WITH ID ...{code}
> reproducing the isue is simple by running the following commands
> {code:sh}
> docker run -d --name cassandra cassandra:4.1.5
> echo "Wait for the container to start"
> until docker exec -ti cassandra nodetool status | grep UN;do sleep
> 1;done;sleep 10
> echo "Create keyspace and table for test"
> docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
> TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2
> text,field3 text);"
> echo "Drop 2 fields"
> docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
> field3);"
> echo "Create snapshot and view schema.cql"
> docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
> docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql
> -exec cat {} + {code}
> the full output of the sql generated by the reproduce is below
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> ALTER TABLE test.testtable DROP field2 USING TIME
[jira] [Commented] (CASSANDRA-19708) Remove sid from bullseye docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-19708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862819#comment-17862819 ] Brandon Williams commented on CASSANDRA-19708: -- +1 > Remove sid from bullseye docker images > -- > > Key: CASSANDRA-19708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x > > Attachments: CASSANDRA-19708_50_105_ci_summary.html, > CASSANDRA-19708_50_105_results_details.tar.xz > > > sid is flakey, often broken and takes days for correct packages to be > uploaded. > ref: > https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/jdk=jdk_1.8_latest,label=cassandra/611/ > > sid is only used for jdk8 > looks like replacing it with temurin might be a safer/stable choice. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19708) Remove sid from bullseye docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-19708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855727#comment-17855727 ] Michael Semb Wever edited comment on CASSANDRA-19708 at 7/3/24 2:51 PM: in-tree patch. also contains debug (requested by [~edimitrova], and timeouts around script execution of the test splits (which has been witnessed to hang indefinitely). (it remains unclear if this is enough, whether timeout is also beneficial around the node call for when the node is unresponsive and the inner timeout wouldn't trigger. an outer timeout would need a much higher value, e.g. 1 day.) Patch: https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/jenkinsfile-extra-debug/5.0 CI: [^CASSANDRA-19708_50_105_ci_summary.html] and [^CASSANDRA-19708_50_105_results_details.tar.xz] was (Author: michaelsembwever): in-tree patch. also contains debug (requested by [~edimitrova], and timeouts around script execution of the test splits (which has been witnessed to hang indefinitely). (it remains unclear if this is enough, whether timeout is also beneficial around the node call for when the node is unresponsive and the inner timeout wouldn't trigger. an outer timeout would need a much higher value, e.g. 1 day.) PR: https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/jenkinsfile-extra-debug/5.0 CI: [^CASSANDRA-19708_50_105_ci_summary.html] and [^CASSANDRA-19708_50_105_results_details.tar.xz] > Remove sid from bullseye docker images > -- > > Key: CASSANDRA-19708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x > > Attachments: CASSANDRA-19708_50_105_ci_summary.html, > CASSANDRA-19708_50_105_results_details.tar.xz > > > sid is flakey, often broken and takes days for correct packages to be > uploaded. > ref: > https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/jdk=jdk_1.8_latest,label=cassandra/611/ > > sid is only used for jdk8 > looks like replacing it with temurin might be a safer/stable choice. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19747:
--
Test and Documentation Plan: CI
Status: Patch Available (was: In Progress)
This should do it for trunk. Let's see what Circle thinks.
(1) https://github.com/apache/cassandra/pull/3401
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After dropping at least 2 fields the schema.cql produced by _nodetool
> snapshot_ is invalid (it is missing a comma)
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID ...{code}
> expected outcome
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text,
> field3 text
> ) WITH ID ...{code}
> reproducing the isue is simple by running the following commands
> {code:sh}
> docker run -d --name cassandra cassandra:4.1.5
> echo "Wait for the container to start"
> until docker exec -ti cassandra nodetool status | grep UN;do sleep
> 1;done;sleep 10
> echo "Create keyspace and table for test"
> docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
> TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2
> text,field3 text);"
> echo "Drop 2 fields"
> docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
> field3);"
> echo "Create snapshot and view schema.cql"
> docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
> docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql
> -exec cat {} + {code}
> the full output of the sql generated by the reproduce is below
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> ALTER TABLE test.testtable DROP field2 USING TIMESTAMP 171102807000;
> ALTER TABLE test.testtable DROP field3 USING TIMESTAMP 171102807001;
> {code}
> Found this bug while trying to restore the schema from a backup created by
> copying a snapshot from a running node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19665) Add download link for Java drivers from download page
[ https://issues.apache.org/jira/browse/CASSANDRA-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19665: --- Reviewers: Michael Semb Wever Status: Review In Progress (was: Patch Available) +1 (one small optionally comment/question about the maven repo url we want to use) > Add download link for Java drivers from download page > - > > Key: CASSANDRA-19665 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19665 > Project: Cassandra > Issue Type: Task > Components: Client/java-driver, Documentation/Website >Reporter: Bret McGuire >Assignee: Brad Schoening >Priority: Normal > Labels: pull-request-available > > Seems like we should have a link to download Java drivers from the [download > page|https://cassandra.apache.org/_/download.html] on the Website -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-19747:
-
Assignee: Stefan Miklosovic
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> After dropping at least 2 fields the schema.cql produced by _nodetool
> snapshot_ is invalid (it is missing a comma)
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID ...{code}
> expected outcome
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text,
> field3 text
> ) WITH ID ...{code}
> reproducing the isue is simple by running the following commands
> {code:sh}
> docker run -d --name cassandra cassandra:4.1.5
> echo "Wait for the container to start"
> until docker exec -ti cassandra nodetool status | grep UN;do sleep
> 1;done;sleep 10
> echo "Create keyspace and table for test"
> docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
> TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2
> text,field3 text);"
> echo "Drop 2 fields"
> docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
> field3);"
> echo "Create snapshot and view schema.cql"
> docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
> docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql
> -exec cat {} + {code}
> the full output of the sql generated by the reproduce is below
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> ALTER TABLE test.testtable DROP field2 USING TIMESTAMP 171102807000;
> ALTER TABLE test.testtable DROP field3 USING TIMESTAMP 171102807001;
> {code}
> Found this bug while trying to restore the schema from a backup created by
> copying a snapshot from a running node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19739: --- Component/s: Dependencies (was: Build) > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta2, 5.0, 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19739: --- Fix Version/s: 5.0 > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta2, 5.0, 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19739: --- Fix Version/s: 5.1 (was: 5.1-alpha1) > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta2, 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19747:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable
Corruption / Loss(12986)
Complexity: Normal
Component/s: Local/Snapshots
Discovered By: User Report
Fix Version/s: 4.1.x
5.0.x
5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Invalid schema.cql created by snapshot after dropping more than one field
> -
>
> Key: CASSANDRA-19747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Frank vissing
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> After dropping at least 2 fields the schema.cql produced by _nodetool
> snapshot_ is invalid (it is missing a comma)
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID ...{code}
> expected outcome
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text,
> field3 text
> ) WITH ID ...{code}
> reproducing the isue is simple by running the following commands
> {code:sh}
> docker run -d --name cassandra cassandra:4.1.5
> echo "Wait for the container to start"
> until docker exec -ti cassandra nodetool status | grep UN;do sleep
> 1;done;sleep 10
> echo "Create keyspace and table for test"
> docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
> TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2
> text,field3 text);"
> echo "Drop 2 fields"
> docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
> field3);"
> echo "Create snapshot and view schema.cql"
> docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
> docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql
> -exec cat {} + {code}
> the full output of the sql generated by the reproduce is below
> {code:sql}
> CREATE TABLE IF NOT EXISTS test.testtable (
> field1 text PRIMARY KEY,
> field2 text
> field3 text
> ) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> ALTER TABLE test.testtable DROP field2 USING TIMESTAMP 171102807000;
> ALTER TABLE test.testtable DROP field3 USING TIMESTAMP 171102807001;
> {code}
> Found this bug while trying to restore the schema from a backup created by
> copying a snapshot from a running node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank vissing updated CASSANDRA-19747:
--
Description:
After dropping at least 2 fields the schema.cql produced by _nodetool snapshot_
is invalid (it is missing a comma)
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID ...{code}
expected outcome
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text,
field3 text
) WITH ID ...{code}
reproducing the isue is simple by running the following commands
{code:sh}
docker run -d --name cassandra cassandra:4.1.5
echo "Wait for the container to start"
until docker exec -ti cassandra nodetool status | grep UN;do sleep 1;done;sleep
10
echo "Create keyspace and table for test"
docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2 text,field3
text);"
echo "Drop 2 fields"
docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
field3);"
echo "Create snapshot and view schema.cql"
docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql -exec
cat {} + {code}
the full output of the sql generated by the reproduce is below
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
AND additional_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '16', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND memtable = 'default'
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
ALTER TABLE test.testtable DROP field2 USING TIMESTAMP 171102807000;
ALTER TABLE test.testtable DROP field3 USING TIMESTAMP 171102807001;
{code}
Found this bug while trying to restore the schema from a backup created by
copying a snapshot from a running node.
was:
After dropping at least 2 fields the schema.cql produced by _nodetool snapshot_
is invalid (it is missing a comma)
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID ...{code}
expected outcome
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text,
field3 text
) WITH ID ...{code}
reproducing the isue is simple by running the following commands
{code:sh}
docker run -d --name cassandra cassandra:4.1.5
echo "Wait for the container to start"
until docker exec -ti cassandra nodetool status | grep UN;do sleep 1;done;sleep
10
echo "Create keyspace and table for test"
docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2 text,field3
text);"
echo "Drop 2 fields"
docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
field3);"
echo "Create snapshot and view schema.cql"
docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql -exec
cat {} + {code}
the full output of the sql generated by the reproduce is below
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
AND additional_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '16', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND memtable = 'default'
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_
[jira] [Commented] (CASSANDRA-13890) Expose current compaction throughput
[
https://issues.apache.org/jira/browse/CASSANDRA-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862711#comment-17862711
]
Jon Haddad commented on CASSANDRA-13890:
LGTM +1. Please fix the new line on line 61 in the imports in
src/java/org/apache/cassandra/db/compaction/CompactionManager.java on commit.
> Expose current compaction throughput
>
>
> Key: CASSANDRA-13890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13890
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Jon Haddad
>Assignee: Ling Mao
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Getting and setting the current compaction throughput limit is supported, but
> there's no means of knowing if the setting is actually making a difference.
> Let's expose the current throughput being utilized by Cassandra that's in the
> {{compactionRateLimiter}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
[
https://issues.apache.org/jira/browse/CASSANDRA-19747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank vissing updated CASSANDRA-19747:
--
Description:
After dropping at least 2 fields the schema.cql produced by _nodetool snapshot_
is invalid (it is missing a comma)
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID ...{code}
expected outcome
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text,
field3 text
) WITH ID ...{code}
reproducing the isue is simple by running the following commands
{code:sh}
docker run -d --name cassandra cassandra:4.1.5
echo "Wait for the container to start"
until docker exec -ti cassandra nodetool status | grep UN;do sleep 1;done;sleep
10
echo "Create keyspace and table for test"
docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2 text,field3
text);"
echo "Drop 2 fields"
docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
field3);"
echo "Create snapshot and view schema.cql"
docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql -exec
cat {} + {code}
the full output of the sql generated by the reproduce is below
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
AND additional_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '16', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND memtable = 'default'
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
{code}
Found this bug while trying to restore the schema from a backup created by
copying a snapshot from a running node.
was:
After dropping at least 2 fields the schema.cql produced by _nodetool snapshot_
is invalid (it is missing a comma)
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID ...{code}
expected outcome
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text,
field3 text
) WITH ID ...{code}
reproducing the isue is simple by running the following commands
{code:sh}
docker run -d --name cassandra cassandra:4.1.5
echo Wait for the container to start
until docker exec -ti cassandra nodetool status | grep UN;do sleep 1;done;sleep
10
echo create keyspace and table for test
docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2 text,field3
text);"
echo Drop 2 fields
docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
field3);"
echo create snapshot and view schema.cql
docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql -exec
cat {} + {code}
the full output of the sql generated by the reproduce is below
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
AND additional_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '16', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND memtable = 'default'
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
{code}
Found this bug while trying to
[jira] [Created] (CASSANDRA-19747) Invalid schema.cql created by snapshot after dropping more than one field
Frank vissing created CASSANDRA-19747:
-
Summary: Invalid schema.cql created by snapshot after dropping
more than one field
Key: CASSANDRA-19747
URL: https://issues.apache.org/jira/browse/CASSANDRA-19747
Project: Cassandra
Issue Type: Bug
Reporter: Frank vissing
After dropping at least 2 fields the schema.cql produced by _nodetool snapshot_
is invalid (it is missing a comma)
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID ...{code}
expected outcome
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text,
field3 text
) WITH ID ...{code}
reproducing the isue is simple by running the following commands
{code:sh}
docker run -d --name cassandra cassandra:4.1.5
echo Wait for the container to start
until docker exec -ti cassandra nodetool status | grep UN;do sleep 1;done;sleep
10
echo create keyspace and table for test
docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH
replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE
TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2 text,field3
text);"
echo Drop 2 fields
docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2,
field3);"
echo create snapshot and view schema.cql
docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql -exec
cat {} + {code}
the full output of the sql generated by the reproduce is below
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
field1 text PRIMARY KEY,
field2 text
field3 text
) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
AND additional_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '16', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND memtable = 'default'
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
{code}
Found this bug while trying to restore the schema from a backup created by
copying a snapshot from a running node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862692#comment-17862692
]
Stefan Miklosovic commented on CASSANDRA-19130:
---
I feel like I would be able to move this forward if I knew how to act in a
mixed cluster (some nodes on TCM, some not). [~aratnofsky]'s suggestion to
treat truncation as it is now until all nodes are on TCM makes sense to me. We
would check the topology before deciding what to do. Does that make sense to
people? cc [~samt]
> Implement transactional table truncation
>
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TRUNCATE table should leverage cluster metadata to ensure consistent
> truncation timestamps across all replicas. The current implementation depends
> on all nodes being available, but this could be reimplemented as a
> {{Transformation}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19739: -- Status: Ready to Commit (was: Review In Progress) > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta2, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19739: -- Reviewers: Brandon Williams Status: Review In Progress (was: Needs Committer) > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta2, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19739: -- Fix Version/s: 5.1-alpha1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/a9d6900d445ee44470f80d45c647fd015dba57ba Resolution: Fixed Status: Resolved (was: Ready to Commit) > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha1 > > Time Spent: 20m > Remaining Estimate: 0h > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19733) Add feature to filter streaming source when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-19733:
---
Test and Documentation Plan: Unit test attched
Status: Patch Available (was: Open)
> Add feature to filter streaming source when bootstrapping
> -
>
> Key: CASSANDRA-19733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h2. Proposed improvement
> Right now, the stream sources for the bootstrap are chosen from the closest
> nodes of the bootstrapping node.
> Add the following system properties so that when bootstrap happens, the node
> can choose where to stream data from.
> * {{cassandra.bootstrap.include_dcs}}
> * {{cassandra.bootstrap.exclude_dcs}}
> * {{cassandra.bootstrap.include_sources}}
> {{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
> take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to
> specify DC/Racks.}}
> {{cassandra.bootstrap.include_sources is used to specify ip address/port of
> the specific nodes to stream from.}}
> h2. Motivation
> Currently, when the node failure happens in the middle of the major cluster
> upgrade, general advice given to the user is to complete the upgrade of the
> cluster until all nodes are in the same version, and replace/remove the
> failed node. This is because the streaming breaks when there is unsupported
> SSTable version streamed from newer to the older.
> This approach can create availability issue when two nodes (the failed node
> from different rack and the node currently stopped for the upgrade) are down.
> With this improvement, the user can replace the failed node using, for
> example, specific rack in the same DC or another DC, to eliminate the
> availability issue described above.
> h2. Note
> The user also needs to set "-Dcassandra.skip_schema_check=true" when
> replacing the node during the major upgrade to complete the replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19733) Add feature to filter streaming source when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-19733:
---
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Add feature to filter streaming source when bootstrapping
> -
>
> Key: CASSANDRA-19733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h2. Proposed improvement
> Right now, the stream sources for the bootstrap are chosen from the closest
> nodes of the bootstrapping node.
> Add the following system properties so that when bootstrap happens, the node
> can choose where to stream data from.
> * {{cassandra.bootstrap.include_dcs}}
> * {{cassandra.bootstrap.exclude_dcs}}
> * {{cassandra.bootstrap.include_sources}}
> {{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
> take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to
> specify DC/Racks.}}
> {{cassandra.bootstrap.include_sources is used to specify ip address/port of
> the specific nodes to stream from.}}
> h2. Motivation
> Currently, when the node failure happens in the middle of the major cluster
> upgrade, general advice given to the user is to complete the upgrade of the
> cluster until all nodes are in the same version, and replace/remove the
> failed node. This is because the streaming breaks when there is unsupported
> SSTable version streamed from newer to the older.
> This approach can create availability issue when two nodes (the failed node
> from different rack and the node currently stopped for the upgrade) are down.
> With this improvement, the user can replace the failed node using, for
> example, specific rack in the same DC or another DC, to eliminate the
> availability issue described above.
> h2. Note
> The user also needs to set "-Dcassandra.skip_schema_check=true" when
> replacing the node during the major upgrade to complete the replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19746) Update CQLSH documentation to remove Python 2.7 reference
[ https://issues.apache.org/jira/browse/CASSANDRA-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19746: --- Change Category: Code Clarity Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Update CQLSH documentation to remove Python 2.7 reference > - > > Key: CASSANDRA-19746 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19746 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Low > > The CQLSH > [Compatibility|https://cassandra.apache.org/doc/stable/cassandra/tools/cqlsh.html#compatibility] > section mentions Python 2.7 but this should be Python 3.x now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19746) Update CQLSH website documentation to remove Python 2.7 reference
[ https://issues.apache.org/jira/browse/CASSANDRA-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19746: --- Summary: Update CQLSH website documentation to remove Python 2.7 reference (was: Update CQLSH documentation to remove Python 2.7 reference) > Update CQLSH website documentation to remove Python 2.7 reference > - > > Key: CASSANDRA-19746 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19746 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Low > > The CQLSH > [Compatibility|https://cassandra.apache.org/doc/stable/cassandra/tools/cqlsh.html#compatibility] > section mentions Python 2.7 but this should be Python 3.x now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19746) Update CQLSH documentation to remove Python 2.7 reference
[ https://issues.apache.org/jira/browse/CASSANDRA-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening reassigned CASSANDRA-19746: -- Assignee: Brad Schoening > Update CQLSH documentation to remove Python 2.7 reference > - > > Key: CASSANDRA-19746 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19746 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Low > > The CQLSH > [Compatibility|https://cassandra.apache.org/doc/stable/cassandra/tools/cqlsh.html#compatibility] > section mentions Python 2.7 but this should be Python 3.x now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19746) Update CQLSH documentation to remove Python 2.7 reference
[ https://issues.apache.org/jira/browse/CASSANDRA-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19746: --- Priority: Low (was: Normal) > Update CQLSH documentation to remove Python 2.7 reference > - > > Key: CASSANDRA-19746 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19746 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Brad Schoening >Priority: Low > > The CQLSH > [Compatibility|https://cassandra.apache.org/doc/stable/cassandra/tools/cqlsh.html#compatibility] > section mentions Python 2.7 but this should be Python 3.x now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19746) Update CQLSH documentation to remove Python 2.7 reference
[ https://issues.apache.org/jira/browse/CASSANDRA-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19746: --- Impacts: Docs (was: None) > Update CQLSH documentation to remove Python 2.7 reference > - > > Key: CASSANDRA-19746 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19746 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Brad Schoening >Priority: Low > > The CQLSH > [Compatibility|https://cassandra.apache.org/doc/stable/cassandra/tools/cqlsh.html#compatibility] > section mentions Python 2.7 but this should be Python 3.x now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19746) Update CQLSH documentation to remove Python 2.7 reference
Brad Schoening created CASSANDRA-19746: -- Summary: Update CQLSH documentation to remove Python 2.7 reference Key: CASSANDRA-19746 URL: https://issues.apache.org/jira/browse/CASSANDRA-19746 Project: Cassandra Issue Type: Task Components: Documentation Reporter: Brad Schoening The CQLSH [Compatibility|https://cassandra.apache.org/doc/stable/cassandra/tools/cqlsh.html#compatibility] section mentions Python 2.7 but this should be Python 3.x now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19665) Add download link for Java drivers from download page
[ https://issues.apache.org/jira/browse/CASSANDRA-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-19665: --- Labels: pull-request-available (was: ) > Add download link for Java drivers from download page > - > > Key: CASSANDRA-19665 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19665 > Project: Cassandra > Issue Type: Task > Components: Client/java-driver, Documentation/Website >Reporter: Bret McGuire >Assignee: Brad Schoening >Priority: Normal > Labels: pull-request-available > > Seems like we should have a link to download Java drivers from the [download > page|https://cassandra.apache.org/_/download.html] on the Website -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19665) Add download link for Java drivers from download page
[ https://issues.apache.org/jira/browse/CASSANDRA-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19665: --- Test and Documentation Plan: Text only change, ran 'website build' (was: Doc only change, ran 'website build') > Add download link for Java drivers from download page > - > > Key: CASSANDRA-19665 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19665 > Project: Cassandra > Issue Type: Task > Components: Client/java-driver, Documentation/Website >Reporter: Bret McGuire >Assignee: Brad Schoening >Priority: Normal > > Seems like we should have a link to download Java drivers from the [download > page|https://cassandra.apache.org/_/download.html] on the Website -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17445) Library airlift/airline has been deprecated
[ https://issues.apache.org/jira/browse/CASSANDRA-17445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17445: Reviewers: Caleb Rackliffe > Library airlift/airline has been deprecated > --- > > Key: CASSANDRA-17445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17445 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Tibor Repasi >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > The [airlift/airline|https://github.com/airlift/airline] library has been > deprecated and is not maintained since [8 Jun > 2021|https://github.com/airlift/airline/commit/ae3d7e103bdc140969bde944d4ba09345d663a61]. > It is used in many tools and some tests of Cassandra which should be > reviewed. > Tools using that library: > * org.apache.cassandra.tools.JMXTool > * org.apache.cassandra.tools.NodeTool > * org.apache.cassandra.stress.Compaction > * org.apache.cassandra.fqltool.FullQueryLogTool > Tests using it: > * org.apache.cassandra.simulator.SimulationRunner > Alternatives (as suggested in the depreciation notice): > * [Airline 2|https://rvesse.github.io/airline/] > * [picocli|https://picocli.info] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862600#comment-17862600
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/2/24 9:31 PM:
-
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
However by 'unified' I don't mean a 'single class'. Just a single interface and
a mechanism and have ability to write providers if needed. We must also provide
implementation to address the tickets in the concern as well.
was (Author: maulin.vasavada):
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
However by 'unified' I don't mean a 'single class'. Just a single interface and
a mechanism and have ability to write providers if needed.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862600#comment-17862600
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/2/24 9:30 PM:
-
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
However by 'unified' I don't mean a 'single class'. Just a single interface and
a mechanism and have ability to write providers if needed.
was (Author: maulin.vasavada):
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862602#comment-17862602
]
Maulin Vasavada commented on CASSANDRA-13428:
-
cc: [~smiklosovic] [~brandon.williams]
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862601#comment-17862601
]
Maulin Vasavada commented on CASSANDRA-13428:
-
It has been a while I touched this code :( (bumps ahead :) ) but I can try to
work out a solution in next few weeks/months.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862601#comment-17862601
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/2/24 9:27 PM:
-
It has been a while since I touched this code :( (bumps ahead :) ) but I can
try to work out a solution in next few weeks/months.
was (Author: maulin.vasavada):
It has been a while I touched this code :( (bumps ahead :) ) but I can try to
work out a solution in next few weeks/months.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862600#comment-17862600
]
Maulin Vasavada commented on CASSANDRA-13428:
-
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862594#comment-17862594 ] Brandon Williams commented on CASSANDRA-19739: -- +1 > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19739: -- Fix Version/s: 5.0-beta2 > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta2, 5.x > > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[
https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862593#comment-17862593
]
Stefan Miklosovic commented on CASSANDRA-19739:
---
[CASSANDRA-19739-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19739-5.0]
{noformat}
java11_pre-commit_tests
✓ j11_build8m 25s
✓ j11_cqlsh_dtests_py311 9m 58s
✓ j11_cqlsh_dtests_py311_vnode 8m 2s
✓ j11_cqlsh_dtests_py388m 47s
✓ j11_cqlsh_dtests_py38_vnode 10m 50s
✓ j11_cqlshlib_cython_tests11m 1s
✓ j11_cqlshlib_tests 9m 56s
✓ j11_dtests 38m 43s
✓ j11_dtests_latest 37m 44s
✓ j11_dtests_vnode37m 50s
✓ j11_jvm_dtests 29m 29s
✓ j11_jvm_dtests_latest_vnode 20m 4s
✓ j11_simulator_dtests 7m 2s
✓ j11_unit_tests 15m 26s
✓ j11_utests_latest 16m 50s
✓ j11_utests_oa 18m 36s
✓ j11_utests_system_keyspace_directory17m 32s
✓ j17_cqlsh_dtests_py311 6m 39s
✓ j17_cqlsh_dtests_py311_vnode 6m 32s
✓ j17_cqlsh_dtests_py386m 22s
✓ j17_cqlsh_dtests_py38_vnode 6m 14s
✓ j17_cqlshlib_cython_tests 7m 5s
✓ j17_cqlshlib_tests 8m 43s
✓ j17_dtests 33m 11s
✓ j17_dtests_latest 34m 20s
✓ j17_dtests_vnode32m 27s
✓ j17_jvm_dtests 25m 58s
✓ j17_jvm_dtests_latest_vnode 15m 4s
✓ j17_unit_tests 14m 19s
✓ j17_utests_latest 13m 34s
✓ j17_utests_oa 14m 40s
java11_separate_tests
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4445/workflows/2964649a-e712-4684-84b5-8d8cd20cd945]
> Move bcprov-jdk18on-1.76.jar to build deps
> --
>
> Key: CASSANDRA-19739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19739
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> This came up after I bumped dependency-check version to 10.0.0 as suggested
> in CASSANDRA-19738.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19739: -- Status: Needs Committer (was: Patch Available) > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19704:
Fix Version/s: 4.0.14
4.1.6
5.0
5.1
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Since Version: 4.0
Source Control Link:
https://github.com/apache/cassandra/commit/d54646e40957ffc18f651753941fac3068b79f8e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
https://github.com/apache/cassandra/commit/d54646e40957ffc18f651753941fac3068b79f8e
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.14, 4.1.6, 5.0, 5.1
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary-3.html,
> ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19745) Schema change failed in Cassandra Dtest after node restart and upgrade but success in setup
ConfX created CASSANDRA-19745:
-
Summary: Schema change failed in Cassandra Dtest after node
restart and upgrade but success in setup
Key: CASSANDRA-19745
URL: https://issues.apache.org/jira/browse/CASSANDRA-19745
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/java
Reporter: ConfX
h2. What happened
Cassandra dtest {{schemaChange}} behaves differently in {{setup}} and
{{{}runAfterNodeUpgrade{}}}.
h2. How to reproduce:
Put the following test under
{{{}cassandra/test/distributed/org/apache/cassandra/distributed/upgrade/{}}},
and build dtest jars.
{code:java}
package org.apache.cassandra.distributed.upgrade;
public class demoUpgradeTest extends UpgradeTestBase {
@Test
public void firstDemoTest() throws Throwable {
new TestCase()
.nodes(2)
.nodesToUpgrade(1)
.withConfig((cfg) -> cfg.with(Feature.NETWORK, Feature.GOSSIP))
.upgradesToCurrentFrom(v3X)
.setup((cluster) -> {
cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int, ck
int, v1 int, PRIMARY KEY (pk, ck))"));
})
.runAfterNodeUpgrade((cluster, node) -> {
// let's do nothing here.
}).run();
}
@Test
public void secondDemoTest() throws Throwable {
new TestCase()
.nodes(2)
.nodesToUpgrade(1)
.withConfig((cfg) -> cfg.with(Feature.NETWORK, Feature.GOSSIP))
.upgradesToCurrentFrom(v3X)
.setup((cluster) -> {
// let's do nothing here.
})
.runAfterNodeUpgrade((cluster, node) -> {
cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int, ck
int, v1 int, PRIMARY KEY (pk, ck))"));
}).run();
}
} {code}
Run the test with:
{code:java}
$ ant test-jvm-dtest-some-Duse.jdk11=true
-Dtest.name=org.apache.cassandra.distributed.upgrade.demoUpgradeTest {code}
firstDemoTest passes, but secondDemoTest fails with the following output:
{code:java}
java.lang.AssertionError: Error in test '5.0-beta2 -> [5.1]' while upgrading to
'5.1'; successful upgrades []
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:396)
at
org.apache.cassandra.distributed.upgrade.demoUpgradeTest.secondDemoTest(demoUpgradeTest.java:56)
Caused by: java.lang.IllegalStateException: Can't commit transformations when
running in gossip mode. Enable the ClusterMetadataService with `nodetool
addtocms`.
at
org.apache.cassandra.tcm.migration.GossipProcessor.commit(GossipProcessor.java:34)
at
org.apache.cassandra.tcm.ClusterMetadataService$SwitchableProcessor.commit(ClusterMetadataService.java:836)
at org.apache.cassandra.tcm.Processor.commit(Processor.java:45)
at
org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:511)
at org.apache.cassandra.schema.Schema.submit(Schema.java:292) {code}
As a previous issue suggested, {{schemaChange}} would fail to execute when
gossip mode is disabled. However, even with gossip mode enabled,
{{schemaChange}} behaves differently in {{setup}} and
{{{}runAfterNodeUpgrade{}}}. Executing {{schemaChange}} in
{{runAfterNodeUpgrade}} would call the {{commit}} function in
[{{org.apache.cassandra.tcm.migration.GossipProcessor.java}}|https://github.com/apache/cassandra/blob/cbe07fd57e3d94a1f2512fced3f38e69ad4b3eb2/src/java/org/apache/cassandra/tcm/migration/GossipProcessor.java#L32]:
{code:java}
public Commit.Result commit(Entry.Id entryId, Transformation transform, Epoch
lastKnown, Retry.Deadline retryPolicy)
{
throw new IllegalStateException("Can't commit transformations when running
in gossip mode. Enable the ClusterMetadataService with `nodetool addtocms`.");
} {code}
which directly throws an exception.
The expected behavior should be that {{schemaChange}} consistently in {{setup}}
and {{{}runAfterNodeUpgrade{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19545) Null pointer when running Upgrade Tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862570#comment-17862570
]
ConfX commented on CASSANDRA-19545:
---
[~mck] There is a logic to find all the local "build/dtest-*.jar" and set those
jars as target versions. Should we just include all the existing versions
(through the local jars) instead of also having non-existing versions?
> Null pointer when running Upgrade Tests
> ---
>
> Key: CASSANDRA-19545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19545
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: ConfX
>Priority: Normal
>
> h2. What happened
> The `UpgradeTestBase.java` may throw null pointer exception when creating the
> version upgrade pairs in `upgradesTo()` method.
> The problem happens in the for loop shown below. The `upgradesTo()` calls
> `versions.getLatest(Semver version)` method to create the `Version` class.
> {code:java}
> for (Semver start : vertices.subSet(lowerBound, true, to, false))
> {
> // only include pairs that are allowed, and start or end on CURRENT
> if (SUPPORTED_UPGRADE_PATHS.hasEdge(start, to) &&
> edgeTouchesTarget(start, to, CURRENT))
> upgrade.add(new TestVersions(versions.getLatest(start),
> Collections.singletonList(versions.getLatest(to;
> } {code}
> However, in the `Version.java`, `getLatest()` function never checks whether
> the `first(version)` is in the `versions` map or not. When the version is not
> there, a null pointer exception will be thrown and crash all the upgrade
> tests.
> {code:java}
> public Version getLatest(Semver version)
> {
> return versions.get(first(version)) // <--- Here might cause NPE
> .stream()
> .findFirst()
> .orElseThrow(() -> new RuntimeException("No " +
> version + " versions found"));
> }
> {code}
> h2. How to reproduce
> To reproduce this bug, I'm running Cassandra with commit SHA
> `310d790ce4734727f943225eb951ab0d889c0a5b`; and dtest API with
> `dtest-api-0.0.16.jar`.
> The versions I put under `build/` directory are:
> dtest-4.0.9.jar, dtest-4.0.13.jar, dtest-4.1.4.jar, and dtest-5.1.jar.
> The command I'm running is:
> {code:java}
> $ ant test-jvm-dtest-some -Duse.jdk11=true
> -Dtest.name=org.apache.cassandra.distributed.upgrade.UpgradeTest {code}
> The error message I got was:
> {code:java}
> [junit-timeout] INFO [main] 2024-04-08 17:34:23,936 Versions.java:136
> - Looking for dtest jars in /Users/xxx/Documents/xxx/cassandra/build
> [junit-timeout] Found 4.0.13, 4.0.9
> [junit-timeout] Found 4.1.4
> [junit-timeout] Found 5.1
> [junit-timeout] - ---
> [junit-timeout] Testcase:
> simpleUpgradeWithNetworkAndGossipTest(org.apache.cassandra.distributed.upgrade.UpgradeTest)-_jdk11:
> Caused an ERROR
> [junit-timeout] null
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.distributed.shared.Versions.getLatest(Versions.java:127)
> [junit-timeout] at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.upgradesTo(UpgradeTestBase.java:218)
> [junit-timeout] at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.upgradesToCurrentFrom(UpgradeTestBase.java:203)
> [junit-timeout] at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.simpleUpgradeWithNetworkAndGossipTest(UpgradeTest.java:37)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.upgrade.UpgradeTest
> FAILED
> {code}
> With some debugging, the version causing the null pointer is `5.0-alpha1`,
> but this version is not shown in `build/` directory and should not be tested
> if I understand correctly.
> h2. How to fix.
> There are two ways to fix this problem. One is to add a null pointer checker
> in `UpgradeTestBase#upgradesTo()`, and the other approach is to add the null
> pointer in `Versions#getLatest()`.
> I would love to provide a PR to fix this issue if you can tell me which fix
> looks better to you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19735) Cannot correctly create keyspace statement with replication during schemaChange
[
https://issues.apache.org/jira/browse/CASSANDRA-19735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862555#comment-17862555
]
ConfX edited comment on CASSANDRA-19735 at 7/2/24 6:29 PM:
---
Thank you for the clarification [~samt]
was (Author: JIRAUSER296392):
Thank you for the clarification [~samt]
> Cannot correctly create keyspace statement with replication during
> schemaChange
> ---
>
> Key: CASSANDRA-19735
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19735
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: ConfX
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> h3. What happened
> A specific schema change for creating keyspace with replications failed
> during Cassandra upgrade testing, but can pass under Cassandra distributed
> testing (non-upgrade).
> h3. How to reproduce:
> Put the following test under
> {{{}cassandra/test/distributed/org/apache/cassandra/distributed/upgrade/{}}},
> and build dtest jars for any versions within [4.1.3, 5.0-alpha2].
> {code:java}
> package org.apache.cassandra.distributed.upgrade;
> public class demoUpgradeTest extends UpgradeTestBase
> @Test
> public void demoTest() throws Throwable {
> new TestCase()
> .nodes(1)
> .nodesToUpgrade(1)
> .withConfig(config -> config.with(NETWORK, GOSSIP,
> NATIVE_PROTOCOL))
> .upgradesToCurrentFrom(v41)
> .setup((cluster) -> {
> cluster.schemaChange(withKeyspace("CREATE KEYSPACE %s
> WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 2}"));
> }).runAfterNodeUpgrade((cluster, node) -> {
> // let's do nothing here.
> }).run();
> }
> } {code}
> Run the test with
> {code:java}
> $ ant test-jvm-dtest-some-Duse.jdk11=true
> -Dtest.name=org.apache.cassandra.distributed.upgrade.demoUpgradeTest {code}
> You will see the following failure:
> {code:java}
> [junit-timeout] Testcase:
> demoTest(org.apache.cassandra.distributed.upgrade.demoUpgradeTest)-_jdk11:
> Caused an ERROR
> [junit-timeout] Cannot add existing keyspace "distributed_test_keyspace"
> [junit-timeout] org.apache.cassandra.exceptions.AlreadyExistsException:
> Cannot add existing keyspace "distributed_test_keyspace"
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.CreateKeyspaceStatement.apply(CreateKeyspaceStatement.java:78)
> [junit-timeout] at
> org.apache.cassandra.schema.DefaultSchemaUpdateHandler.apply(DefaultSchemaUpdateHandler.java:230)
> [junit-timeout] at
> org.apache.cassandra.schema.Schema.transform(Schema.java:597)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:114)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:60)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> [junit-timeout] at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [junit-timeout] at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [junit-timeout] at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [junit-timeout] at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829) {code}
> I have tested version pairs 4.1.3_4.1.4, 4.1.4_4.1.5, 4.1.5_5.0-alpha1, and
> 5.0-alpha1_5.0-alpha2. All of them have the same issue.
> I wrote a very similar test with Cassandra distributed test framework
> (non-upgrade test) as below:
> {code:java}
> package org.apache.cassandra.distributed.test.streaming;public class
> LCSStreamingKeepLevelTest extends TestBaseImpl
> {
> @Test
> public void demoTest() throws IOException
> {
> tr
[jira] [Commented] (CASSANDRA-19735) Cannot correctly create keyspace statement with replication during schemaChange
[
https://issues.apache.org/jira/browse/CASSANDRA-19735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862555#comment-17862555
]
ConfX commented on CASSANDRA-19735:
---
Thank you for the clarification [~samt]
> Cannot correctly create keyspace statement with replication during
> schemaChange
> ---
>
> Key: CASSANDRA-19735
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19735
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: ConfX
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> h3. What happened
> A specific schema change for creating keyspace with replications failed
> during Cassandra upgrade testing, but can pass under Cassandra distributed
> testing (non-upgrade).
> h3. How to reproduce:
> Put the following test under
> {{{}cassandra/test/distributed/org/apache/cassandra/distributed/upgrade/{}}},
> and build dtest jars for any versions within [4.1.3, 5.0-alpha2].
> {code:java}
> package org.apache.cassandra.distributed.upgrade;
> public class demoUpgradeTest extends UpgradeTestBase
> @Test
> public void demoTest() throws Throwable {
> new TestCase()
> .nodes(1)
> .nodesToUpgrade(1)
> .withConfig(config -> config.with(NETWORK, GOSSIP,
> NATIVE_PROTOCOL))
> .upgradesToCurrentFrom(v41)
> .setup((cluster) -> {
> cluster.schemaChange(withKeyspace("CREATE KEYSPACE %s
> WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 2}"));
> }).runAfterNodeUpgrade((cluster, node) -> {
> // let's do nothing here.
> }).run();
> }
> } {code}
> Run the test with
> {code:java}
> $ ant test-jvm-dtest-some-Duse.jdk11=true
> -Dtest.name=org.apache.cassandra.distributed.upgrade.demoUpgradeTest {code}
> You will see the following failure:
> {code:java}
> [junit-timeout] Testcase:
> demoTest(org.apache.cassandra.distributed.upgrade.demoUpgradeTest)-_jdk11:
> Caused an ERROR
> [junit-timeout] Cannot add existing keyspace "distributed_test_keyspace"
> [junit-timeout] org.apache.cassandra.exceptions.AlreadyExistsException:
> Cannot add existing keyspace "distributed_test_keyspace"
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.CreateKeyspaceStatement.apply(CreateKeyspaceStatement.java:78)
> [junit-timeout] at
> org.apache.cassandra.schema.DefaultSchemaUpdateHandler.apply(DefaultSchemaUpdateHandler.java:230)
> [junit-timeout] at
> org.apache.cassandra.schema.Schema.transform(Schema.java:597)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:114)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:60)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> [junit-timeout] at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [junit-timeout] at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [junit-timeout] at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [junit-timeout] at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829) {code}
> I have tested version pairs 4.1.3_4.1.4, 4.1.4_4.1.5, 4.1.5_5.0-alpha1, and
> 5.0-alpha1_5.0-alpha2. All of them have the same issue.
> I wrote a very similar test with Cassandra distributed test framework
> (non-upgrade test) as below:
> {code:java}
> package org.apache.cassandra.distributed.test.streaming;public class
> LCSStreamingKeepLevelTest extends TestBaseImpl
> {
> @Test
> public void demoTest() throws IOException
> {
> try (Cluster cluster = builder().withNodes(1)
> .withConfig(config -> config.with(NETWORK, GOSSIP,
> NATIVE_PROTOCO
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19739: -- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19744) Accord migration and interop correctness
[ https://issues.apache.org/jira/browse/CASSANDRA-19744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-19744: --- Labels: pull-request-available (was: ) > Accord migration and interop correctness > > > Key: CASSANDRA-19744 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19744 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Labels: pull-request-available > > There are several issues around splitting and retrying mutations, using the > original timestamp for batchlog/hints, batchlog/hint support in general, > running Accord barriers only against the ranges actually owned by Accord. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[
https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862532#comment-17862532
]
Stefan Miklosovic commented on CASSANDRA-19739:
---
[CASSANDRA-19739-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19739-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build 4m 5s
✓ j17_cqlsh_dtests_py311 6m 26s
✓ j17_cqlsh_dtests_py311_vnode 6m 11s
✓ j17_cqlsh_dtests_py385m 57s
✓ j17_cqlsh_dtests_py38_vnode 6m 15s
✓ j17_cqlshlib_cython_tests9m 36s
✓ j17_cqlshlib_tests 6m 38s
✓ j17_dtests 34m 56s
✓ j17_dtests_latest 32m 43s
✓ j17_dtests_vnode32m 54s
✓ j17_jvm_dtests 26m 18s
✓ j17_jvm_dtests_latest_vnode 15m 30s
✓ j17_unit_tests 14m 19s
✓ j17_utests_latest 14m 55s
✓ j17_utests_oa 14m 13s
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4445/workflows/59b77b46-5da0-40e7-bd81-5ec23c853a6d]
> Move bcprov-jdk18on-1.76.jar to build deps
> --
>
> Key: CASSANDRA-19739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19739
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> This came up after I bumped dependency-check version to 10.0.0 as suggested
> in CASSANDRA-19738.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19739) Move bcprov-jdk18on-1.76.jar to build deps
[ https://issues.apache.org/jira/browse/CASSANDRA-19739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19739: -- Summary: Move bcprov-jdk18on-1.76.jar to build deps (was: Investigate bcprov-jdk18on-1.76.jar: CVE-2024-30172, CVE-2024-30171, CVE-2024-29857, CVE-2024-34447) > Move bcprov-jdk18on-1.76.jar to build deps > -- > > Key: CASSANDRA-19739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19739 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > This came up after I bumped dependency-check version to 10.0.0 as suggested > in CASSANDRA-19738. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862516#comment-17862516
]
Caleb Rackliffe commented on CASSANDRA-19400:
-
[~arkn98] Hi there! Just checking in on this. Let me know if you need any
further help or to reassign...
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-137) Bump AWS SDK v2 version to the latest
[ https://issues.apache.org/jira/browse/CASSANDRASC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-137: --- Labels: pull-request-available (was: ) > Bump AWS SDK v2 version to the latest > - > > Key: CASSANDRASC-137 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-137 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > Fix For: 1.0 > > > The latest AWS SDK v2 version is now 2.26.10, whereas the version used in > sidecar is 2.20.43. There are many improvement and bug fixes between the > version. See changes log > https://github.com/aws/aws-sdk-java-v2/tree/master/changelogs -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19704:
Status: Ready to Commit (was: Review In Progress)
[~jasonstack] Partly because I'm going to be out until next Monday, I'm going
to just move forward to commit the {{level == 0}} version of the fix. We may
miss an opportunity to compact some expired SSTables, but that can be improved
later.
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary-3.html,
> ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19704) UnsupportedOperationException is thrown when no space for LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-19704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19704:
Reviewers: Marcus Eriksson, Zhao Yang (was: Zhao Yang)
> UnsupportedOperationException is thrown when no space for LCS
> -
>
> Key: CASSANDRA-19704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19704
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary-3.html,
> ci_summary.html
>
>
> In {{CompactionTask#buildCompactionCandidatesForAvailableDiskSpace}} with
> LCS, if node has limited disk space and can't remove any sstable from L0 or
> L1 in {{{}LeveledCompactionTask#reduceScopeForLimitedSpace{}}},
> {{LeveledCompactionTask#partialCompactionsAcceptable}} will throw
> {{UnsupportedOperationException}}.
> We should handle {{LeveledCompactionTask#partialCompactionsAcceptable}} more
> gracefully with {{return level <= 1}} or simply {{true}} since
> {{reduceScopeForLimitedSpace}} only removes sstable from L0 or L1.
> Related https://issues.apache.org/jira/browse/CASSANDRA-17272
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19668) SIGSEGV originating in Paxos V2 Scheduled Task
[
https://issues.apache.org/jira/browse/CASSANDRA-19668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862494#comment-17862494
]
Jeremiah Jordan commented on CASSANDRA-19668:
-
Thanks for finding and fixing this. Should we add an in tree test to ensure
this can’t regress?
> SIGSEGV originating in Paxos V2 Scheduled Task
> --
>
> Key: CASSANDRA-19668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19668
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Urgent
> Fix For: 4.1.6, 5.0-beta2, 5.0, 5.1
>
> Attachments: ci_summar-5.0.html, ci_summary-4.1.html,
> ci_summary-trunk.html
>
>
> I haven't gotten to the root cause of this yet. Several 4.1 nodes have
> crashed in in production. I'm not sure if this is related to Paxos v2 or
> not, but it is enabled. offheap_objects also enabled.
> I'm not sure if this affects 5.0, yet.
> Most of the crashes don't have a stacktrace - they only reference this
> {noformat}
> Stack: [0x7fabf4c34000,0x7fabf4d34000], sp=0x7fabf4d31f00, free
> space=1015k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> v ~StubRoutines::jint_disjoint_arraycopy
> {noformat}
> They all are in the {{ScheduledTasks}} thread.
> However, one node does have this in the crash log:
> {noformat}
> --- T H R E A D ---
> Current thread (0x78b375eac800): JavaThread "ScheduledTasks:1" daemon
> [_thread_in_Java, id=151791, stack(0x78b34b78,0x78b34b88)]
> Stack: [0x78b34b78,0x78b34b88], sp=0x78b34b87c350, free
> space=1008k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> J 29467 c2
> org.apache.cassandra.db.rows.AbstractCell.clone(Lorg/apache/cassandra/utils/memory/ByteBufferCloner;)Lorg/apache/cassandra/db/rows/Cell;
> (50 bytes) @ 0x78b3dd40a42f [0x78b3dd409de0+0x064f]
> J 17669 c2
> org.apache.cassandra.db.rows.Cell.clone(Lorg/apache/cassandra/utils/memory/Cloner;)Lorg/apache/cassandra/db/rows/ColumnData;
> (6 bytes) @ 0x78b3dc54edc0 [0x78b3dc54ed40+0x0080]
> J 17816 c2
> org.apache.cassandra.db.rows.BTreeRow$$Lambda$845.apply(Ljava/lang/Object;)Ljava/lang/Object;
> (12 bytes) @ 0x78b3dbed01a4 [0x78b3dbed0120+0x0084]
> J 17828 c2
> org.apache.cassandra.utils.btree.BTree.transform([Ljava/lang/Object;Ljava/util/function/Function;)[Ljava/lang/Object;
> (194 bytes) @ 0x78b3dc5f35f0 [0x78b3dc5f34a0+0x0150]
> J 35096 c2
> org.apache.cassandra.db.rows.BTreeRow.clone(Lorg/apache/cassandra/utils/memory/Cloner;)Lorg/apache/cassandra/db/rows/Row;
> (37 bytes) @ 0x78b3dda9111c [0x78b3dda90fe0+0x013c]
> J 30500 c2
> org.apache.cassandra.utils.memory.EnsureOnHeap$CloneToHeap.applyToRow(Lorg/apache/cassandra/db/rows/Row;)Lorg/apache/cassandra/db/rows/Row;
> (16 bytes) @ 0x78b3dd59b91c [0x78b3dd59b8c0+0x005c]
> J 26498 c2 org.apache.cassandra.db.transform.BaseRows.hasNext()Z (215 bytes)
> @ 0x78b3dcf1c454 [0x78b3dcf1c180+0x02d4]
> J 30775 c2
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext()Ljava/lang/Object;
> (49 bytes) @ 0x78b3dc789020 [0x78b3dc788fc0+0x0060]
> J 9082 c2 org.apache.cassandra.utils.AbstractIterator.hasNext()Z (80 bytes) @
> 0x78b3dbb3c544 [0x78b3dbb3c440+0x0104]
> J 35593 c2
> org.apache.cassandra.service.paxos.uncommitted.PaxosRows$PaxosMemtableToKeyStateIterator.computeNext()Lorg/apache/cassandra/service/paxos/uncommitted/PaxosKeyState;
> (126 bytes) @ 0x78b3dc7ceeec [0x78b3dc7cee20+0x00cc]
> J 35591 c2
> org.apache.cassandra.service.paxos.uncommitted.PaxosRows$PaxosMemtableToKeyStateIterator.computeNext()Ljava/lang/Object;
> (5 bytes) @ 0x78b3dc7d09e4 [0x78b3dc7d09a0+0x0044]
> J 9082 c2 org.apache.cassandra.utils.AbstractIterator.hasNext()Z (80 bytes) @
> 0x78b3dbb3c544 [0x78b3dbb3c440+0x0104]
> J 34146 c2
> com.google.common.collect.Iterators.addAll(Ljava/util/Collection;Ljava/util/Iterator;)Z
> (41 bytes) @ 0x78b3dd9197e8 [0x78b3dd919680+0x0168]
> J 38256 c1
> org.apache.cassandra.service.paxos.uncommitted.PaxosRows.toIterator(Lorg/apache/cassandra/db/partitions/UnfilteredPartitionIterator;Lorg/apache/cassandra/sc
[jira] [Updated] (CASSANDRA-19419) Non-transactional schema updates can interfere with Accord transaction execution
[ https://issues.apache.org/jira/browse/CASSANDRA-19419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19419: --- Summary: Non-transactional schema updates can interfere with Accord transaction execution (was: Non-transactional schema updates can interfere with Accord transaction execuion) > Non-transactional schema updates can interfere with Accord transaction > execution > > > Key: CASSANDRA-19419 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19419 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Priority: Normal > > While Accord can handle topology changes correctly it can’t handle > non-transaction schema updates because those execute outside of Accord. When > Accord tries to execute a transaction against the schema in the epoch the > transaction is supposed to execute in then it is possible for different nodes > to see different schemas when reading or writing data as part of a > transaction. > Dropping a needed a column or table is the most likely issue as we don't > support altering column types. > Because commit is async it is possible for a table or to be dropped before > the writes can be propagated after it was acknowledged instead of signaling > an error. While the table was dropped it's possible the client needed the > error to know that the request was processed improperly or that it needed to > take some other action client side. > Or add table where the original coordinator can't read the table, but the > recovery coordinator can and might apply different results to different > replicas. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19744) Accord migration and interop correctness
Ariel Weisberg created CASSANDRA-19744: -- Summary: Accord migration and interop correctness Key: CASSANDRA-19744 URL: https://issues.apache.org/jira/browse/CASSANDRA-19744 Project: Cassandra Issue Type: Bug Components: Accord Reporter: Ariel Weisberg Assignee: Ariel Weisberg There are several issues around splitting and retrying mutations, using the original timestamp for batchlog/hints, batchlog/hint support in general, running Accord barriers only against the ranges actually owned by Accord. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19743) add keyspace name to exception message in StorageService#getEffectiveOwnership for better debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ling Mao updated CASSANDRA-19743:
-
Description:
{code:java}
➜ bin ./nodetool status
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 127.0.0.2 235.8 KiB 16 ? f581f6fa-7192-40ab-8665-8ff270fa3fd3 rack2
UN 127.0.0.1 198.32 KiB 16 ? 00b387d8-f269-4780-878d-17648be2f218 rack1
UN 127.0.0.3 198.59 KiB 16 ? a2398380-951a-464c-a8bb-6418831715ad rack3
Datacenter: datacenter2
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 127.0.0.11 148.47 KiB 16 ? 661da11a-08e4-4082-81e0-c33328669e8d rack1
UN 127.0.0.12 187.26 KiB 16 ? a12fe27b-fc98-4a23-9d8c-843f58562b8b rack1
Note: Non-system keyspaces don't have the same replication settings, effective
ownership information is meaningless
{code}
I have 5 nodes and over 20 keyspaces. It's difficult for me to identify which
one has different replication settings without going through each one
individually, as stated in the warning note.
was:getEffectiveOwnership
> add keyspace name to exception message in
> StorageService#getEffectiveOwnership for better debugging
> ---
>
> Key: CASSANDRA-19743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19743
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.1
>
>
>
>
> {code:java}
> ➜ bin ./nodetool status
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID Rack
> UN 127.0.0.2 235.8 KiB 16 ? f581f6fa-7192-40ab-8665-8ff270fa3fd3 rack2
> UN 127.0.0.1 198.32 KiB 16 ? 00b387d8-f269-4780-878d-17648be2f218 rack1
> UN 127.0.0.3 198.59 KiB 16 ? a2398380-951a-464c-a8bb-6418831715ad rack3
>
> Datacenter: datacenter2
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID Rack
> UN 127.0.0.11 148.47 KiB 16 ? 661da11a-08e4-4082-81e0-c33328669e8d rack1
> UN 127.0.0.12 187.26 KiB 16 ? a12fe27b-fc98-4a23-9d8c-843f58562b8b rack1
>
> Note: Non-system keyspaces don't have the same replication settings,
> effective ownership information is meaningless
> {code}
> I have 5 nodes and over 20 keyspaces. It's difficult for me to identify which
> one has different replication settings without going through each one
> individually, as stated in the warning note.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19743) add keyspace name to exception message in StorageService#getEffectiveOwnership for better debugging
[ https://issues.apache.org/jira/browse/CASSANDRA-19743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ling Mao updated CASSANDRA-19743: - Fix Version/s: 5.1 > add keyspace name to exception message in > StorageService#getEffectiveOwnership for better debugging > --- > > Key: CASSANDRA-19743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19743 > Project: Cassandra > Issue Type: Improvement >Reporter: Ling Mao >Priority: Normal > Fix For: 5.1 > > > getEffectiveOwnership -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
