[jira] [Created] (CASSANDRA-15541) Add dch release version to debian packages
Michael Semb Wever created CASSANDRA-15541: -- Summary: Add dch release version to debian packages Key: CASSANDRA-15541 URL: https://issues.apache.org/jira/browse/CASSANDRA-15541 Project: Cassandra Issue Type: Task Components: Packaging Reporter: Michael Semb Wever Add to the prepare_release.sh script the `dch -r ` step that adds the version. Currently the script will generate an UNRELEASED version. Reference: https://lists.apache.org/thread.html/r7f8addef88553955b1057a61b29526cb974cc9037f20ce46fb26fb61%40%3Cdev.cassandra.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15540) Use the ASF process for packaging and uploading deb files
Michael Semb Wever created CASSANDRA-15540: -- Summary: Use the ASF process for packaging and uploading deb files Key: CASSANDRA-15540 URL: https://issues.apache.org/jira/browse/CASSANDRA-15540 Project: Cassandra Issue Type: Task Components: Packaging Reporter: Michael Semb Wever Use the ASF process for packaging and uploading deb files. https://cwiki.apache.org/confluence/display/INFRA/Packaging+a+deb+and+uploading+to+Bintray The current process is found in https://github.com/apache/cassandra-builds/tree/master/cassandra-release -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15034) cassandra-stress fails to retry user profile insert and query operations
[
https://issues.apache.org/jira/browse/CASSANDRA-15034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029596#comment-17029596
]
Dmitry Kropachev edited comment on CASSANDRA-15034 at 2/4/20 6:21 AM:
--
[~djoshi] , could you please look into it, this issue is really annoying.
was (Author: dkropachev):
Dinesh Joshi, could you please look into it, this issue is really annoying.
> cassandra-stress fails to retry user profile insert and query operations
> -
>
> Key: CASSANDRA-15034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15034
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Shlomi Livne
>Assignee: Shlomi Livne
>Priority: Normal
> Attachments: 0001-Fix-retry-of-userdefined-operations.patch,
> stress.yaml
>
>
> cassandra-stress that is run with a user profile against a cluster will fail
> to trey operations when a node is killed.
> To reproduce:
> # Create a 3 ndoe cluster with ccm
> {code:java}
> ccm create cas-3 --vnodes -n 1 --version=3.11.3``{code}
> # start the cluster
> {code:java}
> ccm start{code}
> # run
> {code:java}
> tools/bin/cassandra-stress user profile=stress.yaml n=10 ops(insert=1)
> no-warmup cl=QUORUM -node 127.0.0.2 -rate threads=10{code}
> or run
> {code:java}
> tools/bin/cassandra-stress user profile=stress.yaml n=10 ops(simple=1)
> no-warmup cl=QUORUM -node 127.0.0.2 -rate threads=10{code}
> # while the stress is progressing kill a node
> {code:java}
> ccm node1 stop --not-gently{code}
> # wait for cassandra-stress to end
> for the insert case check
> {code:java}
> ccm node2 cqlsh -e " select count(*) FROM stresscql.tb ;"{code}
> we are missing rows
> for the query case (simple) the following errors will be reported
> {code:java}
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.io.IOException: Operation x10 on key(s) [49a26f35297303469236]: Error
> executing: (NoSuchElementException)
> at
> org.apache.cassandra.stress.Operation.error(Operation.java:127)java.util.NoSuchElementException
> at
> org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105)com.datastax.driver.core.exceptions.TransportException:
> [/127.0.0.1:9042] Connection has been closed
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException{code}
> profile: stress.yaml[^stress.yaml]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15034) cassandra-stress fails to retry user profile insert and query operations
[
https://issues.apache.org/jira/browse/CASSANDRA-15034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029596#comment-17029596
]
Dmitry Kropachev commented on CASSANDRA-15034:
--
Dinesh Joshi, could you please look into it, this issue is really annoying.
> cassandra-stress fails to retry user profile insert and query operations
> -
>
> Key: CASSANDRA-15034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15034
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Shlomi Livne
>Assignee: Shlomi Livne
>Priority: Normal
> Attachments: 0001-Fix-retry-of-userdefined-operations.patch,
> stress.yaml
>
>
> cassandra-stress that is run with a user profile against a cluster will fail
> to trey operations when a node is killed.
> To reproduce:
> # Create a 3 ndoe cluster with ccm
> {code:java}
> ccm create cas-3 --vnodes -n 1 --version=3.11.3``{code}
> # start the cluster
> {code:java}
> ccm start{code}
> # run
> {code:java}
> tools/bin/cassandra-stress user profile=stress.yaml n=10 ops(insert=1)
> no-warmup cl=QUORUM -node 127.0.0.2 -rate threads=10{code}
> or run
> {code:java}
> tools/bin/cassandra-stress user profile=stress.yaml n=10 ops(simple=1)
> no-warmup cl=QUORUM -node 127.0.0.2 -rate threads=10{code}
> # while the stress is progressing kill a node
> {code:java}
> ccm node1 stop --not-gently{code}
> # wait for cassandra-stress to end
> for the insert case check
> {code:java}
> ccm node2 cqlsh -e " select count(*) FROM stresscql.tb ;"{code}
> we are missing rows
> for the query case (simple) the following errors will be reported
> {code:java}
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.io.IOException: Operation x10 on key(s) [49a26f35297303469236]: Error
> executing: (NoSuchElementException)
> at
> org.apache.cassandra.stress.Operation.error(Operation.java:127)java.util.NoSuchElementException
> at
> org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105)com.datastax.driver.core.exceptions.TransportException:
> [/127.0.0.1:9042] Connection has been closed
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException
> java.util.NoSuchElementException{code}
> profile: stress.yaml[^stress.yaml]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029577#comment-17029577
]
Pooja Nair edited comment on CASSANDRA-15529 at 2/4/20 4:47 AM:
Hi [~ifesdjeen]
I have attached the sstabledump of the table to this ticket.
We are getting an exception while trying to take a sstabledump for the above
mentioned sal_purge table where range deletes are carried out.
We tried taking dump on multiple sstables but was thrown with similar
exception every time.
was (Author: pooja_nair):
Hi [~ifesdjeen]
I have attached the sstabledump of the table to this ticket.
We are getting an exception while trying to take a sstabledump for the above
mentioned sal_purge table where range deletes are carried out.
We tried taking dump on multiple sstables but was thrown the similar exception
every time.
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
> Attachments: sstable_dump.txt
>
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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 = '99.0PERCENTILE';
> {code}
> Things to note:
> # The column2 is always passed a null value during insertion
> # column2 is a part of primary key
> # Range select and Range delete is done through our app.
> Iniatally the cluster was on casssandra version 2.1.16 and have been
> recently upgraded to 3.11.4 post the upgrade, we see that the nodes are going
> down, and log the below exceptions during startup and even after node is up.
> This one node is causing the whole cluster to behave improperly.
> {code:java}
> WARN [Native-Transport-Requests-47] 2020-01-29 13:49:05,190
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[Native-Transport-Requests-47,5,main]: {} java.lang.RuntimeException:
> java.lang.IllegalStateException: UnfilteredRowIterator for SAL.sal_purge has
> an open RT bound as its last item at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2588)
> ~[apache-cassandra-3.11.4.jar:3.11.4] at
>
[jira] [Comment Edited] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029577#comment-17029577
]
Pooja Nair edited comment on CASSANDRA-15529 at 2/4/20 4:47 AM:
Hi [~ifesdjeen]
I have attached the sstabledump of the table to this ticket.
We are getting an exception while trying to take a sstabledump for the above
mentioned sal_purge table where range deletes are carried out.
We tried taking dump on multiple sstables but was thrown the similar exception
every time.
was (Author: pooja_nair):
Hi [~ifesdjeen]
I have attached the sstabledump of the table to this ticket.
We are getting an exception while trying to take a sstabledump for the above
mentioned sal_purge table where range deletes are carried out.
We tried taking dump on multiple sstables but was thrown the same exception
every time.
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
> Attachments: sstable_dump.txt
>
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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 = '99.0PERCENTILE';
> {code}
> Things to note:
> # The column2 is always passed a null value during insertion
> # column2 is a part of primary key
> # Range select and Range delete is done through our app.
> Iniatally the cluster was on casssandra version 2.1.16 and have been
> recently upgraded to 3.11.4 post the upgrade, we see that the nodes are going
> down, and log the below exceptions during startup and even after node is up.
> This one node is causing the whole cluster to behave improperly.
> {code:java}
> WARN [Native-Transport-Requests-47] 2020-01-29 13:49:05,190
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[Native-Transport-Requests-47,5,main]: {} java.lang.RuntimeException:
> java.lang.IllegalStateException: UnfilteredRowIterator for SAL.sal_purge has
> an open RT bound as its last item at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2588)
> ~[apache-cassandra-3.11.4.jar:3.11.4] at
>
[jira] [Comment Edited] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029577#comment-17029577
]
Pooja Nair edited comment on CASSANDRA-15529 at 2/4/20 4:46 AM:
Hi [~ifesdjeen]
I have attached the sstabledump of the table to this ticket.
We are getting an exception while trying to take a sstabledump for the above
mentioned sal_purge table where range deletes are carried out.
We tried taking dump on multiple sstables but was thrown the same exception
every time.
was (Author: pooja_nair):
Hi [~ifesdjeen]
I have attached the sstabledump of the table to this ticket.
We are getting an exception while trying to take a sstabledump for the above
mentioned sal_purge table where range deletes are carried out.
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
> Attachments: sstable_dump.txt
>
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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 = '99.0PERCENTILE';
> {code}
> Things to note:
> # The column2 is always passed a null value during insertion
> # column2 is a part of primary key
> # Range select and Range delete is done through our app.
> Iniatally the cluster was on casssandra version 2.1.16 and have been
> recently upgraded to 3.11.4 post the upgrade, we see that the nodes are going
> down, and log the below exceptions during startup and even after node is up.
> This one node is causing the whole cluster to behave improperly.
> {code:java}
> WARN [Native-Transport-Requests-47] 2020-01-29 13:49:05,190
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[Native-Transport-Requests-47,5,main]: {} java.lang.RuntimeException:
> java.lang.IllegalStateException: UnfilteredRowIterator for SAL.sal_purge has
> an open RT bound as its last item at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2588)
> ~[apache-cassandra-3.11.4.jar:3.11.4] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0-internal] at
>
[jira] [Updated] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nair updated CASSANDRA-15529:
---
Attachment: sstable_dump.txt
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
> Attachments: sstable_dump.txt
>
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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 = '99.0PERCENTILE';
> {code}
> Things to note:
> # The column2 is always passed a null value during insertion
> # column2 is a part of primary key
> # Range select and Range delete is done through our app.
> Iniatally the cluster was on casssandra version 2.1.16 and have been
> recently upgraded to 3.11.4 post the upgrade, we see that the nodes are going
> down, and log the below exceptions during startup and even after node is up.
> This one node is causing the whole cluster to behave improperly.
> {code:java}
> WARN [Native-Transport-Requests-47] 2020-01-29 13:49:05,190
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[Native-Transport-Requests-47,5,main]: {} java.lang.RuntimeException:
> java.lang.IllegalStateException: UnfilteredRowIterator for SAL.sal_purge has
> an open RT bound as its last item at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2588)
> ~[apache-cassandra-3.11.4.jar:3.11.4] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0-internal] at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-3.11.4.jar:3.11.4] at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4] at
> org.apache.cassandra.concurrent.SEPExecutor.maybeExecuteImmediately(SEPExecutor.java:194)
> [apache-cassandra-3.11.4.jar:3.11.4] at
> org.apache.cassandra.service.AbstractReadExecutor.makeRequests(AbstractReadExecutor.java:117)
> [apache-cassandra-3.11.4.jar:3.11.4] at
>
[jira] [Commented] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029577#comment-17029577
]
Pooja Nair commented on CASSANDRA-15529:
Hi [~ifesdjeen]
I have attached the sstabledump of the table to this ticket.
We are getting an exception while trying to take a sstabledump for the above
mentioned sal_purge table where range deletes are carried out.
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
> Attachments: sstable_dump.txt
>
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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 = '99.0PERCENTILE';
> {code}
> Things to note:
> # The column2 is always passed a null value during insertion
> # column2 is a part of primary key
> # Range select and Range delete is done through our app.
> Iniatally the cluster was on casssandra version 2.1.16 and have been
> recently upgraded to 3.11.4 post the upgrade, we see that the nodes are going
> down, and log the below exceptions during startup and even after node is up.
> This one node is causing the whole cluster to behave improperly.
> {code:java}
> WARN [Native-Transport-Requests-47] 2020-01-29 13:49:05,190
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[Native-Transport-Requests-47,5,main]: {} java.lang.RuntimeException:
> java.lang.IllegalStateException: UnfilteredRowIterator for SAL.sal_purge has
> an open RT bound as its last item at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2588)
> ~[apache-cassandra-3.11.4.jar:3.11.4] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0-internal] at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-3.11.4.jar:3.11.4] at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4] at
>
[jira] [Comment Edited] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029481#comment-17029481
]
feroz shaik edited comment on CASSANDRA-15529 at 2/4/20 2:35 AM:
-
Hi [~ifesdjeen] , I am a colleague of [~Pooja_nair] and would like to answer
your questions. # We have all the nodes upgraded to 3.11.4 and also finished
upgradesstables. There are no previous sstables present on any of the
nodes/cluster.
# We have no clue whether the affected node is cordinator or not as it is too
random and the affected node behaves rogue potentially impacting whole cluster.
# The query patterns are like below:
static String INSERT_SCHEDULED_DELETION_QUERY = "INSERT INTO \"sal_purge\"
(key,column1,value) VALUES (?,?,?) USING TIMESTAMP
?;"; static String SELECT_SCHEDULED_DELETION_QUERY = "SELECT column1, value
FROM sal_purge where key=? AND column1>=? LIMIT
?;"; static String DELETE_SCHEDULED_DELETION_QUERY = "DELETE FROM
\"sal_purge\" USING TIMESTAMP ? WHERE key=? AND column1=?;";
I will try to upload the sstable dump soon to this, Appreciate your support
[~ifesdjeen]
was (Author: ferozshaik...@gmail.com):
Hi [~ifesdjeen] , I am a colleague of [~Pooja_nair] and would like to answer
your questions. # We have all the nodes upgraded to 3.11.4 and also finished
upgradesstables. There are no previous sstables present on any of the
nodes/cluster.
# We have no clue whether the affected node is cordinator or not as it is too
random and the affected node behaves rogue potentially bring impacting whole
cluster.
# The query patterns are like below:
static String INSERT_SCHEDULED_DELETION_QUERY = "INSERT INTO \"sal_purge\"
(key,column1,value) VALUES (?,?,?) USING TIMESTAMP
?;"; static String SELECT_SCHEDULED_DELETION_QUERY = "SELECT column1, value
FROM sal_purge where key=? AND column1>=? LIMIT
?;"; static String DELETE_SCHEDULED_DELETION_QUERY = "DELETE FROM \"sal_purge\"
USING TIMESTAMP ? WHERE key=? AND column1=?;";
I will try to upload the sstable dump soon to this, Appreciate your support
[~ifesdjeen]
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
>
[jira] [Commented] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029481#comment-17029481
]
feroz shaik commented on CASSANDRA-15529:
-
Hi [~ifesdjeen] , I am a colleague of [~Pooja_nair] and would like to answer
your questions. # We have all the nodes upgraded to 3.11.4 and also finished
upgradesstables. There are no previous sstables present on any of the
nodes/cluster.
# We have no clue whether the affected node is cordinator or not as it is too
random and the affected node behaves rogue potentially bring impacting whole
cluster.
# The query patterns are like below:
static String INSERT_SCHEDULED_DELETION_QUERY = "INSERT INTO \"sal_purge\"
(key,column1,value) VALUES (?,?,?) USING TIMESTAMP
?;"; static String SELECT_SCHEDULED_DELETION_QUERY = "SELECT column1, value
FROM sal_purge where key=? AND column1>=? LIMIT
?;"; static String DELETE_SCHEDULED_DELETION_QUERY = "DELETE FROM \"sal_purge\"
USING TIMESTAMP ? WHERE key=? AND column1=?;";
I will try to upload the sstable dump soon to this, Appreciate your support
[~ifesdjeen]
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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 = '99.0PERCENTILE';
> {code}
> Things to note:
> # The column2 is always passed a null value during insertion
> # column2 is a part of primary key
> # Range select and Range delete is done through our app.
> Iniatally the cluster was on casssandra version 2.1.16 and have been
> recently upgraded to 3.11.4 post the upgrade, we see that the nodes are going
> down, and log the below exceptions during startup and even after node is up.
> This one node is causing the whole cluster to behave improperly.
> {code:java}
> WARN [Native-Transport-Requests-47] 2020-01-29 13:49:05,190
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[Native-Transport-Requests-47,5,main]: {} java.lang.RuntimeException:
> java.lang.IllegalStateException: UnfilteredRowIterator for SAL.sal_purge has
> an open RT bound as its last item at
[jira] [Updated] (CASSANDRA-15446) Per-thread stack size is too small on aarch64 CentOS
[ https://issues.apache.org/jira/browse/CASSANDRA-15446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15446: --- Fix Version/s: (was: 3.11.5) 3.11.x > Per-thread stack size is too small on aarch64 CentOS > > > Key: CASSANDRA-15446 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15446 > Project: Cassandra > Issue Type: Bug > Components: Local/Config, Local/Startup and Shutdown >Reporter: Heming Fu >Assignee: Heming Fu >Priority: Normal > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x > > > Hi all, > I found an issue when I tried to start cassandra on my aarch64 CentOS7.6, > however no errors on Ubuntu. Of course I could increase -Xss in jvm.options > to fix it, but this issue also caused Cassandra's docker images from docker > hub could not run containers on this OS. > The information of my current environment and root cause of this issue were > shown below. > *Error* > The stack size specified is too small, Specify at least 328k > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > *Version* > Cassandra 2.1.21 2.2.15 3.0.19 3.11.5 > *Environment* > $ lscpu > Architecture: aarch64 > Byte Order: Little Endian > $ uname -m > aarch64 > $ java -version > openjdk version "1.8.0_181" > OpenJDK Runtime Environment (build 1.8.0_181-b13) > OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode) > [root@localhost apache-cassandra-3.11.5]# cat /etc/os-release > $ cat /etc/os-release > NAME="CentOS Linux" > VERSION="7 (AltArch)" > ID="centos" > ID_LIKE="rhel fedora" > VERSION_ID="7" > PRETTY_NAME="CentOS Linux 7 (AltArch)" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:centos:centos:7" > HOME_URL="https://www.centos.org/; > BUG_REPORT_URL="https://bugs.centos.org/; > *Root Cause* > Checked openjdk-1.8.0 source code, the min stack size is calculated by > StackYellowPage, StackRedPage, StackShadowPage, OS page size. Among those > parameters, *default OS page size of aarch64 CentOS 7.6 is 64K, however > aarch64 Ubuntu 18.04 and X86 CentOS are both 4K.* > This difference causes JVM on aarch64 Ubuntu 18.04 needs 164K per-thread > stack size, but 328K required on aarch64 CentOS 7.6. > The formula is > os::Linux::min_stack_allowed = MAX2(os::Linux::min_stack_allowed, > (size_t)(StackYellowPages+StackRedPages+StackShadowPages) * > Linux::page_size() + > (2*BytesPerWord COMPILER2_PRESENT(+1)) * Linux::vm_default_page_size()); > *Parameters on aarch64 CentOS7.6* > intx StackRedPages = 1 > intx StackShadowPages = 1 > intx StackYellowPages = 1 > pageSize 64K > BytesPerWord 8 > vm_default_page_size 8K > As a result, we have min_stack_allowed = (1 + 1 + 1) * 64K + (2 * 8 + 1) * 8K > = 328K > > I could see some similar issues asked for specified achitecture, but no root > cause analyzed. I hope this could help you decide proper stack size for all > common OS. > If you have any suggestion, pls let me know. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15137) Switch http to https URLs in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029172#comment-17029172 ] Michael Shuler commented on CASSANDRA-15137: Committed to 2.1 and merged up. https://github.com/apache/cassandra/commit/b26927d863d5fc5d3251c4ce2aa0cdef9046dd3e > Switch http to https URLs in build.xml > -- > > Key: CASSANDRA-15137 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15137 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Normal > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: 0001-Switch-http-to-https-URLs-in-build.xml.patch, > 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > > > Switch to using https URLs wherever possible in build.xml. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated (b2f2c70 -> bd628ce)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to branch cassandra-2.2 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from b2f2c70 Add message interceptors to in-jvm dtests new b26927d Switch http to https URLs in build.xml new bd628ce Merge branch 'cassandra-2.1' into cassandra-2.2 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (d3b3dcb -> 7c088b9)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d3b3dcb Separate exceptions for CAS write timeout exceptions caused by contention and unkown result new b26927d Switch http to https URLs in build.xml new bd628ce Merge branch 'cassandra-2.1' into cassandra-2.2 new 1710fa0 Merge branch 'cassandra-2.2' into cassandra-3.0 new e4ca96a Merge branch 'cassandra-3.0' into cassandra-3.11 new 7c088b9 Merge branch 'cassandra-3.11' into trunk The 5 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 1710fa0f3d03dacc3056f93b7366c8611e3bccb8 Merge: a270929 bd628ce Author: Michael Shuler AuthorDate: Mon Feb 3 12:31:14 2020 -0600 Merge branch 'cassandra-2.2' into cassandra-3.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (f09e1be -> e4ca96a)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f09e1be Merge branch 'cassandra-3.0' into cassandra-3.11 new b26927d Switch http to https URLs in build.xml new bd628ce Merge branch 'cassandra-2.1' into cassandra-2.2 new 1710fa0 Merge branch 'cassandra-2.2' into cassandra-3.0 new e4ca96a Merge branch 'cassandra-3.0' into cassandra-3.11 The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-2.1' into cassandra-2.2
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a commit to branch cassandra-2.2 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit bd628ce7a25b5b63bf7c0bd92aa655ee6977af4b Merge: b2f2c70 b26927d Author: Michael Shuler AuthorDate: Mon Feb 3 12:30:48 2020 -0600 Merge branch 'cassandra-2.1' into cassandra-2.2 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit e4ca96a28ec1f833f309a3be0e4748837345cde9 Merge: f09e1be 1710fa0 Author: Michael Shuler AuthorDate: Mon Feb 3 12:31:44 2020 -0600 Merge branch 'cassandra-3.0' into cassandra-3.11 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (a270929 -> 1710fa0)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from a270929 Merge branch 'cassandra-2.2' into cassandra-3.0 new b26927d Switch http to https URLs in build.xml new bd628ce Merge branch 'cassandra-2.1' into cassandra-2.2 new 1710fa0 Merge branch 'cassandra-2.2' into cassandra-3.0 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 7c088b97115eb8fe982bac5ce9bf7bfbe6c0dc6e Merge: d3b3dcb e4ca96a Author: Michael Shuler AuthorDate: Mon Feb 3 12:32:01 2020 -0600 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.1 updated: Switch http to https URLs in build.xml
This is an automated email from the ASF dual-hosted git repository.
mshuler pushed a commit to branch cassandra-2.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-2.1 by this push:
new b26927d Switch http to https URLs in build.xml
b26927d is described below
commit b26927d863d5fc5d3251c4ce2aa0cdef9046dd3e
Author: Michael Shuler
AuthorDate: Mon Feb 3 12:29:47 2020 -0600
Switch http to https URLs in build.xml
Patch by Michael Shuler; Reviewed by Joshua McKenzie for CASSANDRA-15137
(Backport to 2.1 to fix build.)
---
build.properties.default | 4 ++--
build.xml| 24
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/build.properties.default b/build.properties.default
index 5291659..11da534 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -1,4 +1,4 @@
# Maven2 Repository Locations (you can override these in "build.properties" to
point to a local proxy, e.g. Nexus)
-artifact.remoteRepository.central: http://repo1.maven.org/maven2
-artifact.remoteRepository.apache: http://repo.maven.apache.org/maven2
+artifact.remoteRepository.central: https://repo1.maven.org/maven2
+artifact.remoteRepository.apache: https://repo.maven.apache.org/maven2
diff --git a/build.xml b/build.xml
index f6fc1f6..c34ec28 100644
--- a/build.xml
+++ b/build.xml
@@ -8,7 +8,7 @@
~ "License"); you may not use this file except in compliance
~ with the License. You may obtain a copy of the License at
~
- ~http://www.apache.org/licenses/LICENSE-2.0
+ ~https://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing,
~ software distributed under the License is distributed on an
@@ -26,9 +26,9 @@
-
-
-http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>
+https://gitbox.apache.org/repos/asf/cassandra.git"/>
+https://gitbox.apache.org/repos/asf/cassandra.git"/>
+https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/>
@@ -79,7 +79,7 @@
http://repo2.maven.org/maven2/org/apache/maven/maven-ant-tasks; />
+
value="https://repo.maven.apache.org/maven2/org/apache/maven/maven-ant-tasks; />
https://repository.apache.org/service/local/staging/deploy/maven2;>
@@ -98,7 +98,7 @@
-
+
@@ -343,11 +343,11 @@
artifactId="cassandra-parent"
packaging="pom"
version="${version}"
-url="http://cassandra.apache.org;
+url="https://cassandra.apache.org;
name="Apache Cassandra"
inceptionYear="2009"
description="The Apache Cassandra Project develops a
highly scalable second-generation distributed database, bringing together
Dynamo's fully distributed design and Bigtable's ColumnFamily-based data
model.">
-http://www.apache.org/licenses/LICENSE-2.0.txt"/>
+https://www.apache.org/licenses/LICENSE-2.0.txt"/>
@@ -480,7 +480,7 @@
http://cassandra.apache.org;
+url="https://cassandra.apache.org;
name="Apache Cassandra">
http://cassandra.apache.org;
+url="https://cassandra.apache.org;
name="Apache Cassandra">
http://cassandra.apache.org;
+url="https://cassandra.apache.org;
name="Apache Cassandra">
http://cassandra.apache.org;
+url="https://cassandra.apache.org;
name="Apache Cassandra">
[jira] [Commented] (CASSANDRA-14773) Overflow of 32-bit integer during compaction.
[
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029159#comment-17029159
]
Vladimir Bukhtoyarov commented on CASSANDRA-14773:
--
Hi [~e.dimitrova]
No, I am not working on this.
> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Vladimir Bukhtoyarov
>Priority: Urgent
> Fix For: 4.0, 4.0-beta
>
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from
> CPU and memory perspective. Hovewer this improvement introduces the bug in
> rounding. When rounding the expriration time which is close to
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow
> happens(because in scope of -CASSANDRA-13444-) data type for point was
> changed from Long to Integer in order to reduce memory footprint), as result
> point became negative and acts as silent poison for internal structures of
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*.
> Then depending of point intervals:
> * The TombstoneHistogram produces wrong values when interval of points is
> less then binSize, it is not critical.
> * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point
> intervals is great then binSize, this case is very critical.
>
> This is pull request [https://github.com/apache/cassandra/pull/273] that
> reproduces the issue and provides the fix.
>
> The stacktrace when running(on codebase without fix)
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
> Source)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
>
> The stacktrace when
[jira] [Commented] (CASSANDRA-15137) Switch http to https URLs in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029150#comment-17029150 ] Stefan Podkowinski commented on CASSANDRA-15137: Can you get this committed to 2.1 [~mshuler]? maven.central turned off non-https downloads, so you won't be able to download any artifacts for that branch anymore, if they are not cached yet. > Switch http to https URLs in build.xml > -- > > Key: CASSANDRA-15137 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15137 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Normal > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: 0001-Switch-http-to-https-URLs-in-build.xml.patch, > 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > > > Switch to using https URLs wherever possible in build.xml. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029143#comment-17029143 ] Ekaterina Dimitrova commented on CASSANDRA-12995: - Hi, Thanks. Dawid Weiss is already on top of it. He said he will be working on it next week. I will keep you posted. > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Packaging >Reporter: Tomas Repik >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: easyfix > Fix For: 4.0 > > Attachments: Screen Shot 2020-01-29 at 11.14.30 AM.png, Screen Shot > 2020-01-29 at 11.20.39 AM.png, Screen Shot 2020-01-29 at 11.20.47 AM.png, > cassandra-3.11.0-hppc.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15535) Documentation gives the wrong instruction to activate remote jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-15535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15535: Change Category: Quality Assurance Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Documentation gives the wrong instruction to activate remote jmx > > > Key: CASSANDRA-15535 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15535 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: jean carlo rivera ura >Assignee: jean carlo rivera ura >Priority: Normal > > In this section [jmx acces > |https://cassandra.apache.org/doc/latest/operating/security.html?highlight=local_jmx#jmx-access], > in order to activate the remove jmx acces, it says to change the value of > LOCAL_JMX to *yes*. However the right configuration is *no* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15531) Improve docs on disk_access_mode, specifically post CASSANDRA-8464
[ https://issues.apache.org/jira/browse/CASSANDRA-15531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15531: Change Category: Quality Assurance Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Improve docs on disk_access_mode, specifically post CASSANDRA-8464 > -- > > Key: CASSANDRA-15531 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15531 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: documentation > > h2. Background > [~tsteinmaurer] brought up [on > Slack|https://the-asf.slack.com/archives/CJZLTM05A/p1580298424288700] that > they've been hit by the `oom-killer` as a result of SSTables being mmaped. > h2. Action > Based on feedback from Thomas Steinmaurer, Jean Carlo & Sam Kearon, I am > going to push the info I've written in this KB article to the official docs – > [Increased memory use on nodes after upgrading to DSE 5.0 or DSE > 5.1|https://support.datastax.com/hc/en-us/articles/360027838911]. > I will revise it specifically for affected OSS versions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029059#comment-17029059
]
Alex Petrov edited comment on CASSANDRA-15529 at 2/3/20 4:04 PM:
-
[~Pooja_nair] is it possible to get a snapshot (possibly, anonymized if it's
produdciton data) of what sstable dump would look like? This looks like it
might be of a concern.
Does this happen on the upgraded SSTables or on the old ones? Do you have a
mixed cluster (as in, some nodes are still running old version)? If yes, does
it happen depending on which node is a coordinator or regardless?
It would be also good to know what kind of insert/update/delete query patterns
you roughly have for that schema, so I could try to reproduce locally.
was (Author: ifesdjeen):
[~Pooja_nair] is it possible to get a snapshot (possibly, anonymized if it's
produdciton data) of what sstable dump would look like? This looks like it
might be of a concern.
It would be also good to know what kind of insert/update/delete query patterns
you roughly have for that schema, so I could try to reproduce locally.
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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 = '99.0PERCENTILE';
> {code}
> Things to note:
> # The column2 is always passed a null value during insertion
> # column2 is a part of primary key
> # Range select and Range delete is done through our app.
> Iniatally the cluster was on casssandra version 2.1.16 and have been
> recently upgraded to 3.11.4 post the upgrade, we see that the nodes are going
> down, and log the below exceptions during startup and even after node is up.
> This one node is causing the whole cluster to behave improperly.
> {code:java}
> WARN [Native-Transport-Requests-47] 2020-01-29 13:49:05,190
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[Native-Transport-Requests-47,5,main]: {} java.lang.RuntimeException:
> java.lang.IllegalStateException: UnfilteredRowIterator for SAL.sal_purge has
> an open RT
[jira] [Updated] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15529:
Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable
Corruption / Loss(12986) (was: Parent values: Code(13163)Level 1 values: Bug -
Unclear Impact(13164))
Status: Open (was: Triage Needed)
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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 = '99.0PERCENTILE';
> {code}
> Things to note:
> # The column2 is always passed a null value during insertion
> # column2 is a part of primary key
> # Range select and Range delete is done through our app.
> Iniatally the cluster was on casssandra version 2.1.16 and have been
> recently upgraded to 3.11.4 post the upgrade, we see that the nodes are going
> down, and log the below exceptions during startup and even after node is up.
> This one node is causing the whole cluster to behave improperly.
> {code:java}
> WARN [Native-Transport-Requests-47] 2020-01-29 13:49:05,190
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[Native-Transport-Requests-47,5,main]: {} java.lang.RuntimeException:
> java.lang.IllegalStateException: UnfilteredRowIterator for SAL.sal_purge has
> an open RT bound as its last item at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2588)
> ~[apache-cassandra-3.11.4.jar:3.11.4] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0-internal] at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-3.11.4.jar:3.11.4] at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4] at
> org.apache.cassandra.concurrent.SEPExecutor.maybeExecuteImmediately(SEPExecutor.java:194)
> [apache-cassandra-3.11.4.jar:3.11.4] at
>
[jira] [Commented] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029059#comment-17029059
]
Alex Petrov commented on CASSANDRA-15529:
-
[~Pooja_nair] is it possible to get a snapshot (possibly, anonymized if it's
produdciton data) of what sstable dump would look like? This looks like it
might be of a concern.
It would be also good to know what kind of insert/update/delete query patterns
you roughly have for that schema, so I could try to reproduce locally.
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
>
> Hello Team,
> We have cluster running on cassandra 3.11.4
> Following is the table schema of the tables that is being used in our system.
> {code:java}
> cqlsh> desc KEYSPACE "SAL"
>
> CREATE KEYSPACE "SAL" WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC_EAST': '3', 'DC_WEST': '3'} AND
> durable_writes = true;
>
> CREATE TABLE "SAL".sal_purge (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = 'Holds items to be removed as
> [shardid][salid][timestamp]. The table records SALIDs to be deleted along
> with their deletion times (which may be modified)'
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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.1
> AND speculative_retry = '99.0PERCENTILE';
>
> CREATE TABLE "SAL".sal_ref (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND bloom_filter_fp_chance = 0.025
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Holds owner references to content as [salid][lcid/opid]'
> AND compaction = {'sstable_size_in_mb': '180', 'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> 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 = '99.0PERCENTILE';
> {code}
> Things to note:
> # The column2 is always passed a null value during insertion
> # column2 is a part of primary key
> # Range select and Range delete is done through our app.
> Iniatally the cluster was on casssandra version 2.1.16 and have been
> recently upgraded to 3.11.4 post the upgrade, we see that the nodes are going
> down, and log the below exceptions during startup and even after node is up.
> This one node is causing the whole cluster to behave improperly.
> {code:java}
> WARN [Native-Transport-Requests-47] 2020-01-29 13:49:05,190
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[Native-Transport-Requests-47,5,main]: {} java.lang.RuntimeException:
> java.lang.IllegalStateException: UnfilteredRowIterator for SAL.sal_purge has
> an open RT bound as its last item at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2588)
> ~[apache-cassandra-3.11.4.jar:3.11.4] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0-internal] at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-3.11.4.jar:3.11.4] at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4] at
>
[jira] [Commented] (CASSANDRA-14773) Overflow of 32-bit integer during compaction.
[
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029050#comment-17029050
]
Ekaterina Dimitrova commented on CASSANDRA-14773:
-
Hi [~vladimir.bukhtoyarov] and [~benedict],
Maybe I can contribute to this one? As far as I see from the latest 2019
updates failing tests had to be fixed at first?
[~vladimir.bukhtoyarov] are you still working on this one?
> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Vladimir Bukhtoyarov
>Priority: Urgent
> Fix For: 4.0, 4.0-beta
>
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from
> CPU and memory perspective. Hovewer this improvement introduces the bug in
> rounding. When rounding the expriration time which is close to
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow
> happens(because in scope of -CASSANDRA-13444-) data type for point was
> changed from Long to Integer in order to reduce memory footprint), as result
> point became negative and acts as silent poison for internal structures of
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*.
> Then depending of point intervals:
> * The TombstoneHistogram produces wrong values when interval of points is
> less then binSize, it is not critical.
> * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point
> intervals is great then binSize, this case is very critical.
>
> This is pull request [https://github.com/apache/cassandra/pull/273] that
> reproduces the issue and provides the fix.
>
> The stacktrace when running(on codebase without fix)
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
> Source)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
>
[jira] [Updated] (CASSANDRA-15350) Separate exceptions for CAS write timeout exceptions caused by contention and unkown result
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15350: Fix Version/s: 4.0 Source Control Link: https://github.com/apache/cassandra/commit/d3b3dcbb353de97220a11f55391babf149410905 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Separate exceptions for CAS write timeout exceptions caused by contention and > unkown result > --- > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > Labels: protocolv5, pull-request-available > Fix For: 4.0 > > Attachments: Utf8StringEncodeBench.java > > Time Spent: 20m > Remaining Estimate: 0h > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-15350) Separate exceptions for CAS write timeout exceptions caused by contention and unkown result
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15350: Comment: was deleted (was: https://github.com/apache/cassandra/commit/d3b3dcbb353de97220a11f55391babf149410905) > Separate exceptions for CAS write timeout exceptions caused by contention and > unkown result > --- > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > Labels: protocolv5, pull-request-available > Fix For: 4.0 > > Attachments: Utf8StringEncodeBench.java > > Time Spent: 20m > Remaining Estimate: 0h > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15350) Separate exceptions for CAS write timeout exceptions caused by contention and unkown result
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15350: Status: Ready to Commit (was: Review In Progress) https://github.com/apache/cassandra/commit/d3b3dcbb353de97220a11f55391babf149410905 > Separate exceptions for CAS write timeout exceptions caused by contention and > unkown result > --- > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > Labels: protocolv5, pull-request-available > Attachments: Utf8StringEncodeBench.java > > Time Spent: 20m > Remaining Estimate: 0h > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15350) Separate exceptions for CAS write timeout exceptions caused by contention and unkown result
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028964#comment-17028964 ] Alex Petrov commented on CASSANDRA-15350: - One more test run before commit: [CI|https://circleci.com/gh/ifesdjeen/cassandra/tree/cas-exception-changes]. +1 on the patch, thank you for patience. Committed now to trunk with [d3b3dcbb353de97220a11f55391babf149410905|https://github.com/apache/cassandra/commit/d3b3dcbb353de97220a11f55391babf149410905]. I was able to slightly simplify the write result unknown exception test as shown [here|https://github.com/apache/cassandra/commit/d3b3dcbb353de97220a11f55391babf149410905#diff-94b9f00830fe29802a8a05183d77d207R237-R262]. As a side note, a corresponding ticket probably should be created for tracking at least the two main drivers (python and Java one, branch 3.6.0, since 4.0 branch breaks compatibility with most of the existing code). > Separate exceptions for CAS write timeout exceptions caused by contention and > unkown result > --- > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > Labels: protocolv5, pull-request-available > Attachments: Utf8StringEncodeBench.java > > Time Spent: 20m > Remaining Estimate: 0h > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Separate exceptions for CAS write timeout exceptions caused by contention and unkown result
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new d3b3dcb Separate exceptions for CAS write timeout exceptions caused by contention and unkown result d3b3dcb is described below commit d3b3dcbb353de97220a11f55391babf149410905 Author: yifan-c AuthorDate: Sun Oct 27 21:01:31 2019 -0700 Separate exceptions for CAS write timeout exceptions caused by contention and unkown result Patch by Yifan Cai; reviewed by Alex Petrov and Dinesh Joshi for CASSANDRA-15350 --- doc/native_protocol_v5.spec| 40 ++- ...xception.java => CasWriteTimeoutException.java} | 10 +- ...on.java => CasWriteUnknownResultException.java} | 7 +- .../apache/cassandra/exceptions/ExceptionCode.java | 3 +- .../exceptions/RequestTimeoutException.java| 8 + .../exceptions/WriteTimeoutException.java | 6 + .../cassandra/metrics/CASClientRequestMetrics.java | 7 +- .../org/apache/cassandra/service/StorageProxy.java | 32 ++- .../cassandra/transport/messages/ErrorMessage.java | 110 ++-- .../cassandra/distributed/test/CasWriteTest.java | 276 + .../distributed/test/DistributedTestBase.java | 4 +- .../cassandra/transport/ErrorMessageTest.java | 80 ++ 12 files changed, 525 insertions(+), 58 deletions(-) diff --git a/doc/native_protocol_v5.spec b/doc/native_protocol_v5.spec index d1b3915..d279453 100644 --- a/doc/native_protocol_v5.spec +++ b/doc/native_protocol_v5.spec @@ -1120,7 +1120,7 @@ Table of Contents 0x1003Truncate_error: error during a truncation error. 0x1100Write_timeout: Timeout exception during a write request. The rest of the ERROR message body will be - + where: is the [consistency] level of the query having triggered the exception. @@ -1144,12 +1144,14 @@ Table of Contents - "BATCH_LOG": the timeout occurred during the write to the batch log when a (logged) batch write was requested. -- "CAS": the timeout occured during the Compare And Set write/update. -- "VIEW": the timeout occured when a write involves - VIEW update and failure to acqiure local view(MV) - lock for key within timeout -- "CDC": the timeout occured when cdc_total_space_in_mb is - exceeded when doing a write to data tracked by cdc. + - "CAS": the timeout occured during the Compare And Set write/update. + - "VIEW": the timeout occured when a write involves + VIEW update and failure to acqiure local view(MV) + lock for key within timeout + - "CDC": the timeout occured when cdc_total_space_in_mb is + exceeded when doing a write to data tracked by cdc. + is a [short] that describes the number of contentions occured during the CAS operation. + The field only presents when the is "CAS". 0x1200Read_timeout: Timeout exception during a read request. The rest of the ERROR message body will be @@ -1225,12 +1227,24 @@ Table of Contents - "BATCH_LOG": the failure occured during the write to the batch log when a (logged) batch write was requested. -- "CAS": the failure occured during the Compare And Set write/update. -- "VIEW": the failure occured when a write involves - VIEW update and failure to acqiure local view(MV) - lock for key within timeout -- "CDC": the failure occured when cdc_total_space_in_mb is - exceeded when doing a write to data tracked by cdc. + - "CAS": the failure occured during the Compare And Set write/update. + - "VIEW": the failure occured when a write involves + VIEW update and failure to acqiure local view(MV) + lock for key within timeout + - "CDC": the failure occured when cdc_total_space_in_mb is + exceeded when doing a write to data tracked by cdc. +0x1600CDC_WRITE_FAILURE: // todo +0x1700CAS_WRITE_UNKNOWN: An exception occured due to
[jira] [Updated] (CASSANDRA-15350) Separate exceptions for CAS write timeout exceptions caused by contention and unkown result
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15350: Summary: Separate exceptions for CAS write timeout exceptions caused by contention and unkown result (was: Separate exceptions for CAS write timeout exceptions due to contention and unkown result) > Separate exceptions for CAS write timeout exceptions caused by contention and > unkown result > --- > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > Labels: protocolv5, pull-request-available > Attachments: Utf8StringEncodeBench.java > > Time Spent: 20m > Remaining Estimate: 0h > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15350) Separate exceptions for CAS write timeout due to contention and unkown result
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15350: Summary: Separate exceptions for CAS write timeout due to contention and unkown result (was: Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.) > Separate exceptions for CAS write timeout due to contention and unkown result > - > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > Labels: protocolv5, pull-request-available > Attachments: Utf8StringEncodeBench.java > > Time Spent: 20m > Remaining Estimate: 0h > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15350) Separate exceptions for CAS write timeout exceptions due to contention and unkown result
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15350: Summary: Separate exceptions for CAS write timeout exceptions due to contention and unkown result (was: Separate exceptions for CAS write timeout due to contention and unkown result) > Separate exceptions for CAS write timeout exceptions due to contention and > unkown result > > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > Labels: protocolv5, pull-request-available > Attachments: Utf8StringEncodeBench.java > > Time Spent: 20m > Remaining Estimate: 0h > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15358) Cassandra alpha 4 testing - Nodes crashing due to bufferpool allocator issue
[
https://issues.apache.org/jira/browse/CASSANDRA-15358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15358:
Reviewers: (was: Alex Petrov)
> Cassandra alpha 4 testing - Nodes crashing due to bufferpool allocator issue
>
>
> Key: CASSANDRA-15358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15358
> Project: Cassandra
> Issue Type: Bug
> Components: Test/benchmark
>Reporter: Santhosh Kumar Ramalingam
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Labels: 4.0, alpha
> Attachments: all_errors.txt, debug_logs_during_repair.txt,
> repair_1_trace.txt, verbose_logs.diff, verbose_logs.txt
>
>
> Hitting a bug with cassandra 4 alpha version. The same bug is repeated with
> difefrent version of Java(8,11 &12) [~benedict]
>
> Stack trace:
> {code:java}
> INFO [main] 2019-10-11 16:07:12,024 Server.java:164 - Starting listening for
> CQL clients on /1.3.0.6:9042 (unencrypted)...
> WARN [OptionalTasks:1] 2019-10-11 16:07:13,961 CassandraRoleManager.java:343
> - CassandraRoleManager skipped default role setup: some nodes were not ready
> INFO [OptionalTasks:1] 2019-10-11 16:07:13,961 CassandraRoleManager.java:369
> - Setup task failed with error, rescheduling
> WARN [Messaging-EventLoop-3-2] 2019-10-11 16:07:22,038 NoSpamLogger.java:94 -
> 10.3x.4x.5x:7000->1.3.0.5:7000-LARGE_MESSAGES-[no-channel] dropping message
> of type PING_REQ whose timeout expired before reaching the network
> WARN [OptionalTasks:1] 2019-10-11 16:07:23,963 CassandraRoleManager.java:343
> - CassandraRoleManager skipped default role setup: some nodes were not ready
> INFO [OptionalTasks:1] 2019-10-11 16:07:23,963 CassandraRoleManager.java:369
> - Setup task failed with error, rescheduling
> INFO [Messaging-EventLoop-3-6] 2019-10-11 16:07:32,759 NoSpamLogger.java:91 -
> 10.3x.4x.5x:7000->1.3.0.2:7000-URGENT_MESSAGES-[no-channel] failed to connect
> io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..)
> failed: Connection refused: /1.3.0.2:7000
> Caused by: java.net.ConnectException: finishConnect(..) failed: Connection
> refused
> at io.netty.channel.unix.Errors.throwConnectException(Errors.java:124)
> at io.netty.channel.unix.Socket.finishConnect(Socket.java:243)
> at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.doFinishConnect(AbstractEpollChannel.java:667)
> at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.finishConnect(AbstractEpollChannel.java:644)
> at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.epollOutReady(AbstractEpollChannel.java:524)
> at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:414)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:326)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> WARN [Messaging-EventLoop-3-3] 2019-10-11 16:11:32,639 NoSpamLogger.java:94 -
> 1.3.4.6:7000->1.3.4.5:7000-URGENT_MESSAGES-[no-channel] dropping message of
> type GOSSIP_DIGEST_SYN whose timeout expired before reaching the network
> INFO [Messaging-EventLoop-3-18] 2019-10-11 16:11:33,077 NoSpamLogger.java:91
> - 1.3.4.5:7000->1.3.4.4:7000-URGENT_MESSAGES-[no-channel] failed to connect
>
> ERROR [Messaging-EventLoop-3-11] 2019-10-10 01:34:34,407
> InboundMessageHandler.java:657 -
> 1.3.4.5:7000->1.3.4.8:7000-LARGE_MESSAGES-0b7d09cd unexpected exception
> caught while processing inbound messages; terminating connection
> java.lang.IllegalArgumentException: initialBuffer is not a direct buffer.
> at io.netty.buffer.UnpooledDirectByteBuf.(UnpooledDirectByteBuf.java:87)
> at
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:59)
> at
> org.apache.cassandra.net.BufferPoolAllocator$Wrapped.(BufferPoolAllocator.java:95)
> at
> org.apache.cassandra.net.BufferPoolAllocator.newDirectBuffer(BufferPoolAllocator.java:56)
> at
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
> at
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:178)
> at
> io.netty.channel.unix.PreferredDirectByteBufAllocator.ioBuffer(PreferredDirectByteBufAllocator.java:53)
> at
> io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:114)
> at
> io.netty.channel.epoll.EpollRecvByteAllocatorHandle.allocate(EpollRecvByteAllocatorHandle.java:75)
> at
>
