[jira] [Commented] (CASSANDRA-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848673#comment-17848673 ] C. Scott Andreas commented on CASSANDRA-19656: -- Brandon, good catch on the upgrade and on revisiting. +1 on proactively disabling to make sure we don't get surprised in the future. Would be supportive of revisiting alternate libs in a future major to avoid the need to explicitly disable as well. > Revisit disabling chronicle analytics > - > > Key: CASSANDRA-19656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 > Project: Cassandra > Issue Type: Task > Components: Local/Other >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0.x, 5.x > > > We first considered this in CASSANDRA-18538 but determined it wasn't a > problem. We have upgraded chronicle in CASSANDRA-18049 so we should > reconfirm with packet analysis that nothing is phoning home, and perhaps > consider taking further precautions by proactively disabling it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[ https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825359#comment-17825359 ] C. Scott Andreas commented on CASSANDRA-18831: -- Hi [~e.dimitrova], I think [~jmckenzie] is picking this up from Achilles. > Enable Cassandra to build and run under JDK21 > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas reassigned CASSANDRA-16733:
Assignee: C. Scott Andreas (was: Benjamin Lerer)
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: C. Scott Andreas
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas reassigned CASSANDRA-16733:
Assignee: Benjamin Lerer (was: C. Scott Andreas)
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19425) Tests failing for ppc64le architecture.
[
https://issues.apache.org/jira/browse/CASSANDRA-19425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820153#comment-17820153
]
C. Scott Andreas commented on CASSANDRA-19425:
--
Hi Sunidhi, thanks for reaching out.
The Apache Cassandra project doesn't publish official builds for PPC64le. It
will likely be necessary for you to undertake work to review the causes of
failures of the various test suites and address them.
Please take a look at the "Caused by" entries in the stacktraces from the test
failure logs you have attached, as they have helpful information that will
point you to the source of the failures.
As an example in the "FullQueryLoggerTest.txt" output you've attached, the
"Caused by" line reports that a PPC64le-native library for tcnative can't be
located in the compiled project's native resources path: "Caused by:
java.io.FileNotFoundException:
META-INF/native/libnetty_tcnative_linux_ppcle_64_fedora.so". In this case you'd
need to supply a PPC64le-compiled tcnative library.
> Tests failing for ppc64le architecture.
> ---
>
> Key: CASSANDRA-19425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19425
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sunidhi Gaonkar
>Priority: Normal
> Attachments: DescriptorTest.txt, FileTest.txt,
> FullQueryLoggerTest.txt, SSTableReaderTest.txt,
> SystemPropertiesBasedFileSystemOwnershipCheckTest.txt,
> YamlBasedFileSystemOwnershipCheckTest.txt
>
>
> {color:#00}Hi Team,{color}
> {color:#00}I am working on validating Cassandra on ppc64le architecture,
> I have followed the following steps to build Cassandra-4.1.4 from
> source:{color}
> {color:#00} {color}
> {color:#00}1. Install java-11, python3.7, ant, cmake,ninja.{color}
> {color:#00}2. Build netty-tcnative and transport-native-epoll from source
> since jars are not available for ppc64le.{color}
> {color:#00}3. Clone Cassandra repository, checked out to cassandra-4.1.4.
> {color}
> {color:#00}4. Command used to build: ant{color}
> {color:#00}5. Command used to test: ant test
> {color}
> {color:#00}6 tests mentioned below are failing:{color}
> {color:#00}FullQueryLoggerTest {color}
> {color:#00}SSTableReaderTest {color}
> {color:#00}FileTest {color}
> {color:#00}SystemPropertiesBasedFileSystemOwnershipCheckTest{color}
> {color:#00}YamlBasedFileSystemOwnershipCheckTest
> DescriptorTest
> {color}{color:#00}I have observed same tests failing on x86 architecture.
> Please find attached the logs for the failing tests below.{color}
> {color:#00}
> Additional details:{color}
> {color:#00}OS: Red Hat Enterprise Linux 8.7{color}
> {color:#00} {color}
> {color:#00}Any suggestions and pointers regarding the same will be
> helpful.{color}
> {color:#00} {color}
> {color:#00} {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19211) Paxos repair failed when upgrading from 3.11.16 to 4.1.3
[
https://issues.apache.org/jira/browse/CASSANDRA-19211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-19211:
-
Resolution: Not A Bug
Status: Resolved (was: Triage Needed)
> Paxos repair failed when upgrading from 3.11.16 to 4.1.3
>
>
> Key: CASSANDRA-19211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19211
> Project: Cassandra
> Issue Type: Bug
>Reporter: Zbyszek Z
>Priority: Normal
>
> I am upgrading from 3.11.16 to 4.1.3 and come up with following error
> messages:
> {code:java}
> INFO [OptionalTasks:1] 2023-12-20 14:44:53,811 PaxosRepair.java:687 -
> PaxosRepair isn't supported by
> Full(/192.168.117.175:7000,(-9100045633799031437,-9090844491356996692]) on
> version 3.11.16
> INFO [OptionalTasks:1] 2023-12-20 14:44:53,811
> PaxosCleanupLocalCoordinator.java:179 - Failing paxos cleanup session
> ---- for... {code}
> The upgrade path is to upgrade one DC to new version while leaving second DC
> in old version. I have read upgrade doc and seems there is no info on how to
> proceed with Paxos in cluster mixed mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19211) Paxos repair failed when upgrading from 3.11.16 to 4.1.3
[
https://issues.apache.org/jira/browse/CASSANDRA-19211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799045#comment-17799045
]
C. Scott Andreas commented on CASSANDRA-19211:
--
Hi Zbyszek, the error message is correct. Repair (and streaming in general) are
not supported when multiple major versions are running in the cluster. This is
inclusive of paxos repair.
Disabling full repair, preview repair, incremental repair, and paxos repair for
the duration of the upgrade should allow you to complete the upgrade without
issue.
> Paxos repair failed when upgrading from 3.11.16 to 4.1.3
>
>
> Key: CASSANDRA-19211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19211
> Project: Cassandra
> Issue Type: Bug
>Reporter: Zbyszek Z
>Priority: Normal
>
> I am upgrading from 3.11.16 to 4.1.3 and come up with following error
> messages:
> {code:java}
> INFO [OptionalTasks:1] 2023-12-20 14:44:53,811 PaxosRepair.java:687 -
> PaxosRepair isn't supported by
> Full(/192.168.117.175:7000,(-9100045633799031437,-9090844491356996692]) on
> version 3.11.16
> INFO [OptionalTasks:1] 2023-12-20 14:44:53,811
> PaxosCleanupLocalCoordinator.java:179 - Failing paxos cleanup session
> ---- for... {code}
> The upgrade path is to upgrade one DC to new version while leaving second DC
> in old version. I have read upgrade doc and seems there is no info on how to
> proceed with Paxos in cluster mixed mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15464) Inserts to set slow due to AtomicBTreePartition for ComplexColumnData.dataSize
[
https://issues.apache.org/jira/browse/CASSANDRA-15464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798698#comment-17798698
]
C. Scott Andreas commented on CASSANDRA-15464:
--
[~benedict] Was this issue resolved by the work you'd done in
https://issues.apache.org/jira/browse/CASSANDRA-18125?
> Inserts to set slow due to AtomicBTreePartition for
> ComplexColumnData.dataSize
>
>
> Key: CASSANDRA-15464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15464
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Eric Jacobsen
>Priority: Normal
>
> Concurrent inserts to set can cause client timeouts and excessive CPU
> due to compare and swap in AtomicBTreePartition for
> ComplexColumnData.dataSize. As the length of the set gets longer, the
> probability of doing the compare decreases.
> The problem we saw in production was with insertions into a set with
> len(set) hundreds to thousands. Because of the semantics of what we
> store in the set, we had not anticipated the length being more than about 10.
> (Almost all rows have length <= 6, the largest observed was 7032. Total
> number of rows < 4000. 3 machines were used.)
> The bad behavior we saw was all machines went to 100% cpu on all cores, and
> clients were timing out. Our immediate solution in production was adding more
> machines (went from 3 machines to 6 machines). The stack included
> partitions.AtomicBTreePartition.addAllWithSizeDelta …
> ComplexColumnData.dataSize.
> The AtomicBTreePartition code uses a Compare And Swap approach, yet the time
> between compares is dependent on the length of the set. When the length of
> the set is long, with concurrent updates, each loop is unlikely to make
> forward progress and can be delayed looping.
> Here is one example call stack:
> {noformat}
> "SharedPool-Worker-40" #167 daemon prio=10 os_prio=0 tid=0x7f9bb4032800
> nid=0x2ee5 runnable [0x7f9b067f4000]
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.cassandra.db.rows.ComplexColumnData.dataSize(ComplexColumnData.java:114)
> at org.apache.cassandra.db.rows.BTreeRow.dataSize(BTreeRow.java:373)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:292)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:235)
> at org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:159)
> at org.apache.cassandra.utils.btree.TreeBuilder.update(TreeBuilder.java:73)
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:181)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:155)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:254)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1204)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:573)
> at org.apache.cassandra.db.Keyspace.applyFuture(Keyspace.java:384)
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205)
> at org.apache.cassandra.hints.Hint.applyFuture(Hint.java:99)
> at org.apache.cassandra.hints.HintVerbHandler.doVerb(HintVerbHandler.java:95)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> In a test program to repro the problem, we raise the number of concurrent
> users and lower the think time between queries. Updating elements of
> low-length sets can occur without errors, and with long-length sets, clients
> time out with errors and there are periods with all cores 99.x% CPU and with
> jstack shows time going to ComplexColumnData.dataSize.
> Here is the schema. Our long term application solution was to just have the
> set elements be part of the primary key and avoid using set, thus
> guaranteeing the code does not go through ComplexColumnData.dataSize
> {noformat}
> CREATE TABLE x.x (
> x int PRIMARY KEY,
> y set ) ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18874) Add Jepsen's Elle to Accord and Paxos validation
[ https://issues.apache.org/jira/browse/CASSANDRA-18874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-18874: - Summary: Add Jepsen's Elle to Accord and Paxos validation (was: Add Jepson's Elle to Accord and Paxos validation) > Add Jepsen's Elle to Accord and Paxos validation > > > Key: CASSANDRA-18874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18874 > Project: Cassandra > Issue Type: Improvement > Components: Accord, Feature/Lightweight Transactions >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > > Paxos and Accord both use a custom validator to make sure we offer Strict > Serializability, but to increase confidence we should use external validators > as well, such as Jepson’s Elle. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18365) CEP-15: Accord Protocol Correctness issue
[ https://issues.apache.org/jira/browse/CASSANDRA-18365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-18365: - Summary: CEP-15: Accord Protocol Correctness issue (was: Correctness issue) > CEP-15: Accord Protocol Correctness issue > - > > Key: CASSANDRA-18365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18365 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Pierre Sutra >Priority: Normal > Attachments: bug.pdf > > > There is a bug in the Accord protocol which might break linearizability, even > in the single partition case. > The file in attachment details this issue following the pseudo-code in the > white paper describing Accord [1]. If the Java implementation follows this > pseudo-code, it should be subject to the very same problem. > This bug was found by Fedor Ryabinin, Alexey Gotsman and Pierre Sutra. > [1] > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-15%3A+General+Purpose+Transactions?preview=/188744725/188744736/Accord.pdf -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17689970#comment-17689970
]
C. Scott Andreas commented on CASSANDRA-18134:
--
[~mck] At the time of the comment, the fix version on the ticket was set to
"4.x." Looks like it's since been updated to "5.x."
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688601#comment-17688601
]
C. Scott Andreas commented on CASSANDRA-18134:
--
Jacek, I think the -nc proposal sounds great. It's really nice that there's a
way to implement the optimization without a major version rev.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice instead of min/max clusterings.
> The difference is that for slices there is available the type of a bound
> rather than just a clustering. In particular it will provide the information
> whether the lower and upper bound of an sstable is opened or closed.
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # The above two changes required to introduce a new major format for SSTables
> - {{oa}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688571#comment-17688571
]
C. Scott Andreas commented on CASSANDRA-18134:
--
I disagree that downgradeability is a concern that should be pushed to a
separate ticket. It's important that we address all aspects of SSTable format
changes in the ticket that proposes them rather than deferring to future work.
Fortunately, there are a couple great strategies that work to provide
downgradability - and they're not mutually exclusive.
* One is to implement forward-compatibility. That would involve implementing
the ability to read "-oa" format SSTables in 4.x. This would satisfy the
property of downgradeability such that a user who has upgraded to 5.x can
safely revert to a 4.x build (say, 4.2) that is capable of reading the new
format.
* Another is to adopt a flag to begin writing the new format once an operator
has determined that post-upgrade their clusters are sufficiently stable. This
is an approach that HDFS has adopted. Following a rolling upgrade of HDFS,
downgrade remains possible until an operator executes a "finalize" operation to
migrate NameNode metadata to the new version's.
One of the biggest hurdles in completing 4.0 upgrades was explaining to
hundreds of people that the upgrade is a completely irreversible, one-way trip.
The vast majority of upgrades went completely fine, but those that weren't had
some very unpleasant followups due to the inability to back it out.
I'd love to see us approach SSTable format changes with the dual approaches
described above: forward-compatibility in a previous release; and a flag to
adopt the new data format post-upgrade.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice instead of min/max clusterings.
> The difference is that for slices there is available the type of a bound
> rather than just a clustering. In particular it will provide the information
> whether the lower and upper bound of an sstable is opened or closed.
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # The above two changes required to introduce a new major format for SSTables
> - {{oa}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688164#comment-17688164
]
C. Scott Andreas commented on CASSANDRA-18134:
--
A discuss thread for this would be good.
I like the idea that the patch proposes. I worry about a major SSTable version
rev in a minor release of the database. Lots of folks have tooling that
generates or reads SSTables that would need to be modified to read a new major
version which might restrict adoptability of the new change.
It would also be excellent to introduce randomized/fuzz test coverage for
SSTable format changes via Harry or similar to catch potential edge cases not
exercised by unit tests with static inputs.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice instead of min/max clusterings.
> The difference is that for slices there is available the type of a bound
> rather than just a clustering. In particular it will provide the information
> whether the lower and upper bound of an sstable is opened or closed.
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # The above two changes required to introduce a new major format for SSTables
> - {{oa}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18259) Upgrade Zstd to 1.5.4
[ https://issues.apache.org/jira/browse/CASSANDRA-18259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17687631#comment-17687631 ] C. Scott Andreas commented on CASSANDRA-18259: -- +1 for inclusion in a 4.0 patchlevel release. No interface changes and a nice improvement. No need to delay that benefit to users. > Upgrade Zstd to 1.5.4 > - > > Key: CASSANDRA-18259 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18259 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Compression >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > > Zstd 1.5.4 was released yesterday. There is a lot of non-trivial performance > improvements. > Upgrade zstd-jni 1.5.0 to 1.5.4. > (1) https://github.com/facebook/zstd/releases/tag/v1.5.4 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18259) Upgrade Zstd to 1.5.4
[ https://issues.apache.org/jira/browse/CASSANDRA-18259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17687472#comment-17687472 ] C. Scott Andreas commented on CASSANDRA-18259: -- This looks great, thanks for flagging the new release. > Upgrade Zstd to 1.5.4 > - > > Key: CASSANDRA-18259 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18259 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Compression >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > Zstd 1.5.4 was released yesterday. There is a lot of non-trivial performance > improvements. > Upgrade zstd-jni 1.5.0 to 1.5.4. > (1) https://github.com/facebook/zstd/releases/tag/v1.5.4 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18240) Using SELECT COUNT(*) FROM... LIMIT 1 in the returning section results in ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-18240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685339#comment-17685339
]
C. Scott Andreas commented on CASSANDRA-18240:
--
cc: [~maedhroz]
> Using SELECT COUNT(*) FROM... LIMIT 1 in the returning section results in
> ClassCastException
>
>
> Key: CASSANDRA-18240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18240
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> {noformat}
> cqlsh>
> BEGIN TRANSACTION
> LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 5);
> SELECT COUNT(*) FROM ks.tbl1 LIMIT 1;
> IF row1 IS NULL THEN
> INSERT INTO ks.tbl1 (k, v) VALUES (5, 10);
> END IF
> COMMIT TRANSACTION;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: error] message="java.lang.ClassCastException:
> org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to
> org.apache.cassandra.db.SinglePartitionReadQuery$Group">})
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18110) Streaming fails during multiple concurrent host replacements
[
https://issues.apache.org/jira/browse/CASSANDRA-18110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654100#comment-17654100
]
C. Scott Andreas commented on CASSANDRA-18110:
--
This one's a hall-of-famer for sure.
> Streaming fails during multiple concurrent host replacements
>
>
> Key: CASSANDRA-18110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18110
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1.x
>
>
> Running four concurrent host replacements on a 4.1.0 development cluster has
> repeatably failed to complete bootstrap with all four hosts failing bootsrrap
> and staying in JOINING, logging the message.
> {code:java}
> ERROR 2022-12-07T21:15:48,860 [main]
> org.apache.cassandra.service.StorageService:2019 - Error while waiting on
> bootstrap to complete. Bootstrap will have to be restarted.
> {code}
> Bootstrap fails as the the FileStreamTasks on the streaming followers
> encounter an EOF while transmitting the files.
> {code:java}
> ERROR 2022-12-07T15:49:39,164 [NettyStreaming-Outbound-/1.2.3.4.7000:2]
> org.apache.cassandra.streaming.StreamSession:718 - [Stream
> #8d313690-7674-11ed-813f-95c261b64a82] Streaming error occurred on session
> with peer 1.2.3.4:7000 through 1.2.3.4:40292
> org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException: The channel
> this output stream was writing to has been closed
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:200)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitForSpace(AsyncChannelOutputPlus.java:140)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.beginFlush(AsyncChannelOutputPlus.java:97)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.lambda$writeToChannel$0(AsyncStreamingOutputPlus.java:124)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.lambda$write$0(CassandraCompressedStreamWriter.java:89)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.writeToChannel(AsyncStreamingOutputPlus.java:120)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.write(CassandraCompressedStreamWriter.java:88)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraOutgoingFile.write(CassandraOutgoingFile.java:177)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage.serialize(OutgoingStreamMessage.java:87)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:45)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:34)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:39)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.async.StreamingMultiplexedChannel$FileStreamTask.run(StreamingMultiplexedChannel.java:311)
> [cassandra.jar]
>at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [cassandra.jar]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
>at java.lang.Thread.run(Thread.java:829) [?:?]
>Suppressed: java.nio.channels.ClosedChannelException
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.doFlush(AsyncStreamingOutputPlus.java:82)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:229)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.close(AsyncChannelOutputPlus.java:248)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.async.NettyStreamingChannel$1.close(NettyStreamingChannel.java:141)
> ~[cassandra.jar]
>
[jira] [Updated] (CASSANDRA-17954) fgrtytyt
[ https://issues.apache.org/jira/browse/CASSANDRA-17954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-17954: - Epic Link: (was: CASSANDRA-17940) Description: (was: [https://wiki.opendaylight.org/plugins/viewsource/viewpagesrc.action?pageId=27067621] [https://wiki.onap.org/plugins/viewsource/viewpagesrc.action?pageId=149030291] [https://wiki.tungsten.io/plugins/viewsource/viewpagesrc.action?pageId=62718075] [https://wiki.lfnetworking.org/plugins/viewsource/viewpagesrc.action?pageId=74648204] [https://goframe.org/plugins/viewsource/viewpagesrc.action?pageId=62103043] [https://wiki.openidl.org/plugins/viewsource/viewpagesrc.action?pageId=24053543] [https://wiki.odim.io/plugins/viewsource/viewpagesrc.action?pageId=25165947] [https://wiki.aswf.io/plugins/viewsource/viewpagesrc.action?pageId=43410883] [https://wiki.trustoverip.org/plugins/viewsource/viewpagesrc.action?pageId=27723250]) > fgrtytyt > > > Key: CASSANDRA-17954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17954 > Project: Cassandra > Issue Type: Bug >Reporter: akian uba >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17954) fgrtytyt
[ https://issues.apache.org/jira/browse/CASSANDRA-17954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-17954: - Resolution: Invalid Status: Resolved (was: Triage Needed) > fgrtytyt > > > Key: CASSANDRA-17954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17954 > Project: Cassandra > Issue Type: Bug >Reporter: akian uba >Priority: Normal > > [https://wiki.opendaylight.org/plugins/viewsource/viewpagesrc.action?pageId=27067621] > [https://wiki.onap.org/plugins/viewsource/viewpagesrc.action?pageId=149030291] > [https://wiki.tungsten.io/plugins/viewsource/viewpagesrc.action?pageId=62718075] > [https://wiki.lfnetworking.org/plugins/viewsource/viewpagesrc.action?pageId=74648204] > [https://goframe.org/plugins/viewsource/viewpagesrc.action?pageId=62103043] > [https://wiki.openidl.org/plugins/viewsource/viewpagesrc.action?pageId=24053543] > [https://wiki.odim.io/plugins/viewsource/viewpagesrc.action?pageId=25165947] > [https://wiki.aswf.io/plugins/viewsource/viewpagesrc.action?pageId=43410883] > [https://wiki.trustoverip.org/plugins/viewsource/viewpagesrc.action?pageId=27723250] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17604) java.lang.IllegalArgumentException during Cassandra 4.x upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-17604:
-
Resolution: Duplicate
Status: Resolved (was: Open)
> java.lang.IllegalArgumentException during Cassandra 4.x upgrade
> ---
>
> Key: CASSANDRA-17604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17604
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Paul Ayers
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> This has happened only twice so far and only on the first node being upgraded
> in a large cluster, so not sure it would be easy to repro, but the steps took
> to hit this were the following on an existing Cassandra 3.11.6 cluster:
> * nodetool drain
> * stop Cassandra
> * install Cassandra 4.0.1 binaries
> * start Cassandra
> Upon starting the first node, it failed with the following log entry and
> nothing more:
> {code:java}
> INFO [main] 2022-04-28 13:06:27,978 SystemKeyspace.java:1470 - Detected
> version upgrade from 3.11.6 to 4.0.1, snapshotting system keyspaces
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,981
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> compaction_history
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,988
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> IndexInfo
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,989
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> repairs
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,990
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> size_estimates
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,992
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> table_estimates
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,992
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> paxos
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,994
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> built_views
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,994
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> peer_events
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,995
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> peers_v2
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,995
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> peers
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,998
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> peer_events_v2
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,998
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> batches
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,999
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> transferred_ranges
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,999
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> transferred_ranges_v2
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,000
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> view_builds_in_progress
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,000
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> local
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,002
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> sstable_activity
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,005
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> available_ranges_v2
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,005
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> available_ranges
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,007
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> prepared_statements
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,011
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> columns
> ERROR [main] 2022-04-28 13:06:28,016 CassandraDaemon.java:909 - Exception
> encountered during startupjava.lang.IllegalArgumentException: Requested
> permits (0) must be positive at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:189)
> at
> com.google.common.util.concurrent.RateLimiter.checkPermits(RateLimiter.java:430)
> at
> com.google.common.util.concurrent.RateLimiter.reserve(RateLimiter.java:285)
> at
>
[jira] [Commented] (CASSANDRA-17604) java.lang.IllegalArgumentException during Cassandra 4.x upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532597#comment-17532597
]
C. Scott Andreas commented on CASSANDRA-17604:
--
Hi Paul, thank you for reporting this issue!
I've shared this with colleagues; this looks like CASSANDRA-16872, which is
resolved in Apache Cassandra 4.0.2+.
> java.lang.IllegalArgumentException during Cassandra 4.x upgrade
> ---
>
> Key: CASSANDRA-17604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17604
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Paul Ayers
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> This has happened only twice so far and only on the first node being upgraded
> in a large cluster, so not sure it would be easy to repro, but the steps took
> to hit this were the following on an existing Cassandra 3.11.6 cluster:
> * nodetool drain
> * stop Cassandra
> * install Cassandra 4.0.1 binaries
> * start Cassandra
> Upon starting the first node, it failed with the following log entry and
> nothing more:
> {code:java}
> INFO [main] 2022-04-28 13:06:27,978 SystemKeyspace.java:1470 - Detected
> version upgrade from 3.11.6 to 4.0.1, snapshotting system keyspaces
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,981
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> compaction_history
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,988
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> IndexInfo
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,989
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> repairs
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,990
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> size_estimates
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,992
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> table_estimates
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,992
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> paxos
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,994
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> built_views
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,994
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> peer_events
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,995
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> peers_v2
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,995
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> peers
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,998
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> peer_events_v2
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,998
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> batches
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,999
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> transferred_ranges
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:27,999
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> transferred_ranges_v2
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,000
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> view_builds_in_progress
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,000
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> local
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,002
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> sstable_activity
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,005
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> available_ranges_v2
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,005
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> available_ranges
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,007
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> prepared_statements
> DEBUG [MemtablePostFlush:1] 2022-04-28 13:06:28,011
> ColumnFamilyStore.java:933 - forceFlush requested but everything is clean in
> columns
> ERROR [main] 2022-04-28 13:06:28,016 CassandraDaemon.java:909 - Exception
> encountered during startupjava.lang.IllegalArgumentException: Requested
> permits (0) must be positive at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:189)
> at
> com.google.common.util.concurrent.RateLimiter.checkPermits(RateLimiter.java:430)
>
[jira] [Commented] (CASSANDRA-17502) Security enforcement by enabling "two-man rule" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514835#comment-17514835
]
C. Scott Andreas commented on CASSANDRA-17502:
--
Tibor, thank you for bringing discussion on this feature to the mailing list
and proposing the feature in JIRA!
Project contributors have recently made an effort to update some areas of the
Apache Cassandra codebase to adopt inclusive language. Can I propose we discuss
this feature in terms of a "two-person rule" for authorization and
"administrator_1" rather than "admin_guy1" or similar?
Thanks!
> Security enforcement by enabling "two-man rule" authorization
> -
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce "two-man
> rule" grant of roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.
> {quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
> CREATE ROLE security_admin;
> GRANT AUTHORIZE patientdata_access TO security_admin;
> GRANT security_admin TO admin_guy1;
> GRANT security_admin TO admin_guy2;
> GRANT security_admin TO admin_guy3;
> {code}
> Security admins are allowed to grant the role, but it would need at least two
> of them (as defined by GRANTORS) to do so to allow the user to actually
> access the data.
> Thus,
> {code}
> GRANT patientdata_access TO doctor_house;
> {code}
> must be conducted by at least two of the three admin_guys above.
> When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11262) Repair scheduling - Global configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas reassigned CASSANDRA-11262: Assignee: Marcus Olsson (was: C. Scott Andreas) > Repair scheduling - Global configuration > > > Key: CASSANDRA-11262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11262 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: Marcus Olsson >Assignee: Marcus Olsson >Priority: Low > > Make it possible to configure the maintenance scheduler on all nodes. Should > include the possibility to pause repairs on all nodes. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11262) Repair scheduling - Global configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas reassigned CASSANDRA-11262: Assignee: C. Scott Andreas (was: Marcus Olsson) > Repair scheduling - Global configuration > > > Key: CASSANDRA-11262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11262 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: Marcus Olsson >Assignee: C. Scott Andreas >Priority: Low > > Make it possible to configure the maintenance scheduler on all nodes. Should > include the possibility to pause repairs on all nodes. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460181#comment-17460181
]
C. Scott Andreas commented on CASSANDRA-17212:
--
Will the property be respected if declared as it exists in the yaml today?
Would like to make sure that compatibility with existing config files is
preserved.
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16984) Remove org.apache.cassandra.hadoop code
[ https://issues.apache.org/jira/browse/CASSANDRA-16984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418278#comment-17418278 ] C. Scott Andreas commented on CASSANDRA-16984: -- I'm aware of several active users of Apache Cassandra's Hadoop integration (e.g., CqlInputFormat). I'd like to propose as an alternative that we consider the goals of this ticket and approaches to meet them - such as upgrading dependency versions if transitive deps were flagged in a scan or similar. If there is desire to remove o.a.c.hadoop from the Apache Cassandra codebase, this package could also be extracted and published as a separate artifact. That may be preferable for users as well to avoid taking a dep on cassandra-all.jar. However, I'd propose we not move quickly to kill off the integration as each time we cut major features / integrations, we place a large burden upon users of Apache Cassandra to migrate, which is not a pain point users of most cloud databases experience. > Remove org.apache.cassandra.hadoop code > --- > > Key: CASSANDRA-16984 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16984 > Project: Cassandra > Issue Type: Task > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > The code under org.apache.cassandra.hadoop is becoming a legacy and probably > should be deleted. > The code does not have any example / test how to use it, it is not documented > and it depends on Hadoop of version 1 which is hardly used nowadays. > This ticket should track its deletion. > Feel free to object and we might revisit this decision. If we remove it in > 4.1, it will still be present in 4.0.x where we can still patch. -- 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-16135) Separate in-JVM test into smaller packages
[ https://issues.apache.org/jira/browse/CASSANDRA-16135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16135: - Fix Version/s: (was: 4.0-rc) 4.0.x > Separate in-JVM test into smaller packages > -- > > Key: CASSANDRA-16135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16135 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > Introduce a structure similar to how tags are organised in Cassandra Jira for > corresponding in-jvm dtests to help people find a right place for their tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16541) LGPL dependency in cassandra-all 3.11.10
[
https://issues.apache.org/jira/browse/CASSANDRA-16541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315258#comment-17315258
]
C. Scott Andreas commented on CASSANDRA-16541:
--
Byteman is a test-only dependency used for bytecode weaving to induce specific
fault scenarios for validation. AFAIK there should be no instance in which the
dependency is required for use of Apache Cassandra.
> LGPL dependency in cassandra-all 3.11.10
>
>
> Key: CASSANDRA-16541
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16541
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Matt Casters
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0
>
>
> Dear Cassandra devs.
> While integrating Cassandra in Apache Hop functionality we found out that the
> cassandra-all maven package drags in an older version of jboss-logging via
> reporter-config3:
> {code:java}
> +- org.apache.cassandra:cassandra-all:jar:3.11.10:compile
> | +- com.addthis.metrics:reporter-config3:jar:3.0.3:compile
> | | +- com.addthis.metrics:reporter-config-base:jar:3.0.3:compile
> | | \- org.hibernate:hibernate-validator:jar:4.3.0.Final:compile
> | | +- javax.validation:validation-api:jar:1.0.0.GA:compile
> | | \- org.jboss.logging:jboss-logging:jar:3.1.0.CR2:compile
> {code}
> jboss-logging 3.1.0.CR2 is from November 2011 and the library only changed to
> APL in 2012.
> [https://github.com/jboss-logging/jboss-logging/blob/master/src/main/resources/META-INF/LICENSE.txt]
>
--
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-16423) Grammatically updated the tech docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16423: - Change Category: Semantic Complexity: Low Hanging Fruit Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Grammatically updated the tech docs > --- > > Key: CASSANDRA-16423 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16423 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Shachar Almagor >Priority: Low > > small grammaticall update to the tech docs. > > https://github.com/shachar-almagor/cassandra/tree/my-contribution -- 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-16423) Grammatically updated the tech docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16423: - Authors: Shachar Almagor Test and Documentation Plan: N/A; doc update. Status: Patch Available (was: In Progress) [https://github.com/shachar-almagor/cassandra/tree/my-contribution] > Grammatically updated the tech docs > --- > > Key: CASSANDRA-16423 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16423 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Shachar Almagor >Priority: Low > > small grammaticall update to the tech docs. > > https://github.com/shachar-almagor/cassandra/tree/my-contribution -- 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-16423) Grammatically updated the tech docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305522#comment-17305522 ] C. Scott Andreas commented on CASSANDRA-16423: -- Thanks for this patch; the changes look good to me. Moving to Patch Available. > Grammatically updated the tech docs > --- > > Key: CASSANDRA-16423 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16423 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Shachar Almagor >Priority: Normal > > small grammaticall update to the tech docs. > > https://github.com/shachar-almagor/cassandra/tree/my-contribution -- 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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305518#comment-17305518 ] C. Scott Andreas commented on CASSANDRA-16262: -- Thanks [~ifesdjeen]. Do you have a sense of what specific scope we should cover under this ticket, and/or what a definition of done might look like? > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-15585) 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation
[ https://issues.apache.org/jira/browse/CASSANDRA-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305517#comment-17305517 ] C. Scott Andreas commented on CASSANDRA-15585: -- [~blerer] Based on what's described above, I don't think there's anything left here that should be considered blocking scope for 4.0. Harry coverage and use has expanded quite a bit; many of the new tests added to C* utilize random input and assert based on properties; cassandra-diff has been widely used by contributors to compare 3.0 and 4.0 clusters, etc. If there's anything further, we should track it under a more specific follow-up ticket – but I don't see such tickets as blocking in scope, either. I'll mark this resolved. > 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation > - > > Key: CASSANDRA-15585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15585 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Josh McKenzie >Priority: Normal > Fix For: 4.0-rc > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Jordan West* > This area refers to contributions to test frameworks/tooling (e.g., dtests, > QuickTheories, CASSANDRA-14821), and automation enabling those tools to be > applied at scale (e.g., replay testing via Spark-based replay of captured FQL > logs). -- 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-15585) 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation
[ https://issues.apache.org/jira/browse/CASSANDRA-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15585: - Resolution: Done Status: Resolved (was: Open) > 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation > - > > Key: CASSANDRA-15585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15585 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Josh McKenzie >Priority: Normal > Fix For: 4.0-rc > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Jordan West* > This area refers to contributions to test frameworks/tooling (e.g., dtests, > QuickTheories, CASSANDRA-14821), and automation enabling those tools to be > applied at scale (e.g., replay testing via Spark-based replay of captured FQL > logs). -- 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-16245) Implement repair quality test scenarios
[ https://issues.apache.org/jira/browse/CASSANDRA-16245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305516#comment-17305516 ] C. Scott Andreas commented on CASSANDRA-16245: -- This is great! [~adejanovski] I see that the last PR mentioned above has been merged. Is there anything left on this ticket? > Implement repair quality test scenarios > --- > > Key: CASSANDRA-16245 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16245 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alexander Dejanovski >Assignee: Radovan Zvoncek >Priority: Normal > Fix For: 4.0-rc > > > Implement the following test scenarios in a new test suite for repair > integration testing with significant load: > Generate/restore a workload of ~100GB per node. Medusa should be considered > to create the initial backup which could then be restored from an S3 bucket > to speed up node population. > Data should on purpose require repair and be generated accordingly. > Perform repairs for a 3 nodes cluster with 4 cores each and 16GB-32GB RAM > (m5d.xlarge instances would be the most cost efficient type). > Repaired keyspaces will use RF=3 or RF=2 in some cases (the latter is for > subranges with different sets of replicas). > ||Mode||Version||Settings||Checks|| > |Full repair|trunk|Sequential + All token ranges|"No anticompaction > (repairedAt==0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range"| > |Full repair|trunk|Parallel + Primary range|"No anticompaction (repairedAt==0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range"| > |Full repair|trunk|Force terminate repair shortly after it was > triggered|Repair threads must be cleaned up| > |Subrange repair|trunk|Sequential + single token range|"No anticompaction > (repairedAt==0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range"| > |Subrange repair|trunk|Parallel + 10 token ranges which have the same > replicas|"No anticompaction (repairedAt == 0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range > A single repair session will handle all subranges at once"| > |Subrange repair|trunk|Parallel + 10 token ranges which have different > replicas|"No anticompaction (repairedAt==0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range > More than one repair session is triggered to process all subranges"| > |Incremental repair|trunk|"Parallel (mandatory) > No compaction during repair"|"Anticompaction status (repairedAt != 0) on all > SSTables > No pending repair on SSTables after completion (could require to wait a bit > as this will happen asynchronously) > Out of sync ranges > 0 + Subsequent run must show no out of sync range"| > |Incremental repair|trunk|"Parallel (mandatory) > Major compaction triggered during repair"|"Anticompaction status (repairedAt > != 0) on all SSTables > No pending repair on SSTables after completion (could require to wait a bit > as this will happen asynchronously) > Out of sync ranges > 0 + Subsequent run must show no out of sync range"| > |Incremental repair|trunk|Force terminate repair shortly after it was > triggered.|Repair threads must be cleaned up| -- 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-16295) upgradesstables/scrub support for 2.x sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-16295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304500#comment-17304500
]
C. Scott Andreas commented on CASSANDRA-16295:
--
[~e.dimitrova] I'm not sure I follow; could you say more about why this is a
4.0 blocker?
Users would need to run upgradesstables on 3.x after upgrading from 2.x (which
is expected). Let me know what more is needed here.
> upgradesstables/scrub support for 2.x sstables
> --
>
> Key: CASSANDRA-16295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16295
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> This support is important for 2.0/3.0 cluster or 3.0/4.0 cluster that
> can/might contain 2.x sstables.
> 4.0 supports versions down to {{ma}}, and 3.0 supports versions down to
> {{jb}} (3.0 and 2.0.1 correspondingly). So by the time you're on 4.0, you
> should have no 2.0 sstables either way, and this needs to be fixed for 3.11
>
> *NOTE: I just marked the ticket with both 3.11 and 4.0 rc versions even if
> the bug is presented only in 3.11 but to make it appear as a blocker on the
> 4.0 board!!*
--
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-16187) Add test to check the ReconcileRead ReadRepair metric
[
https://issues.apache.org/jira/browse/CASSANDRA-16187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304498#comment-17304498
]
C. Scott Andreas commented on CASSANDRA-16187:
--
How do we feel about the possibility of deferring adding further tests for
metrics to 4.0.x, given that we've dramatically improved coverage of most
metrics relative to 3.x?
> Add test to check the ReconcileRead ReadRepair metric
> -
>
> Key: CASSANDRA-16187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16187
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc
>
>
> While going through the metrics for {{ReadRepair}} in CASSANDRA-15582. I
> discovered that we are not testing the {{ReconcileRead}} metric.
--
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-15582) 4.0 quality testing: metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304497#comment-17304497
]
C. Scott Andreas commented on CASSANDRA-15582:
--
How do we feel about the possibility of deferring adding further tests for
metrics to 4.0.x, given that we've dramatically improved coverage relative to
3.x?
> 4.0 quality testing: metrics
>
>
> Key: CASSANDRA-15582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15582
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: Screen Shot 2020-04-07 at 5.47.17 PM.png
>
>
> The goal of this ticket is to have a proper testing of the different metrics
> exposed via JMX, and to ensure that metrics that are not in used in 4.0 have
> been properly deprecated.
> The following table show the current status of the metric tests and can be
> used to track the progress of that ticket:
> || Metrics || Status || test types || JIRA tickets ||
> | Batch | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15718 |
> | BufferPool | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15773
> |
> | Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
> | Client | {color:#DE350B}*TESTS MISSING*{color}| unit tests |
> CASSANDRA-16216 |
> | ClientRequest | {color:#00875A}*COVERED*{color} | in-jvm tests |
> CASSANDRA-16183 |
> | ClientRequestSize | {color:#00875A}*COVERED*{color} | unit tests |
> CASSANDRA-16184 |
> | Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
> | CommitLog | {color:#DE350B}*TESTS MISSING*{color} | unit tests |
> CASSANDRA-16185 |
> | Compaction | {color:#DE350B}*TESTS MISSING*{color} | unit tests |
> CASSANDRA-16192 |
> | CQL | {color:#00875A}*COVERED*{color}| unit tests | |
> | HintService | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16189 |
> | Messaging/Internode| {color:#DE350B}*NO TESTS*{color} | in-jvm dtests |
> CASSANDRA-16193 |
> | ReadRepair| {color:#DE350B}*TESTS MISSING*{color} | dtests,in-jvm dtests |
> CASSANDRA-16187 |
> | Repair | {color:#00875A}*COVERED*{color} | in-jvm dtests | CASSANDRA-16191 |
> | Storage | {color:#00875A}*COVERED*{color}| unit tests | |
> | Streaming | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16190 |
> | Keyspace | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests
> | CASSANDRA-16188 |
> | Table | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests |
> CASSANDRA-16188 |
> | ThreadPoolMetrics |{color:#00875A}*COVERED*{color} | unit tests |
> CASSANDRA-16186 |
--
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-16190) Add tests for streaming metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304495#comment-17304495 ] C. Scott Andreas commented on CASSANDRA-16190: -- Proposing as a candidate for 4.0.x > Add tests for streaming metrics > --- > > Key: CASSANDRA-16190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16190 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0-rc > > > We currently have no tests to checks the streaming metrics -- 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-15537) 4.0 quality testing: Local Read/Write Path: Upgrade and Diff Test
[ https://issues.apache.org/jira/browse/CASSANDRA-15537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304469#comment-17304469 ] C. Scott Andreas commented on CASSANDRA-15537: -- Nice! Is there any scope outstanding then? If not we can move CASSANDRA-16211 to 4.0.x and call this complete. > 4.0 quality testing: Local Read/Write Path: Upgrade and Diff Test > - > > Key: CASSANDRA-15537 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15537 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python >Reporter: Josh McKenzie >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0 > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > Execution of upgrade and diff tests via cassandra-diff have proven to be one > of the most effective approaches toward identifying issues with the local > read/write path. These include instances of data loss, data corruption, data > resurrection, incorrect responses to queries, incomplete responses, and > others. Upgrade and diff tests can be executed concurrent with fault > injection (such as host or network failure); as well as during mixed-version > scenarios (such as upgrading half of the instances in a cluster, and running > upgradesstables on only half of the upgraded instances). > Upgrade and diff tests are expected to continue through the release cycle, > and are a great way for contributors to gain confidence in the correctness of > the database under their own workloads. -- 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-14764) Test Messaging Refactor with: 12 Node Breaking Point, compression=none, encryption=none, coalescing=off
[
https://issues.apache.org/jira/browse/CASSANDRA-14764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304468#comment-17304468
]
C. Scott Andreas commented on CASSANDRA-14764:
--
Proposing from the perspective of GA that we consider this ticket complete.
It's been idle for a long time, and many contributors have exercised perf
pretty heavily since these changes landed.
> Test Messaging Refactor with: 12 Node Breaking Point, compression=none,
> encryption=none, coalescing=off
> ---
>
> Key: CASSANDRA-14764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14764
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Streaming and Messaging
>Reporter: Joey Lynch
>Assignee: Vinay Chella
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: i-03341e1c52de6ea3e-after-queue-change.svg,
> i-07cd92e844d66d801-after-queue-bound.svg, i-07cd92e844d66d801-hint-play.svg,
> i-07cd92e844d66d801-uninlined-with-jvm-methods.svg, ttop.txt
>
>
> *Setup:*
> * Cassandra: 12 (2*6) node i3.xlarge AWS instance (4 cpu cores, 30GB ram)
> running cassandra trunk off of jasobrown/14503 jdd7ec5a2 (Jasons patched
> internode messaging branch) vs the same footprint running 3.0.17
> * Two datacenters with 100ms latency between them
> * No compression, encryption, or coalescing turned on
> *Test #1:*
> ndbench sent 1.5k QPS at a coordinator level to one datacenter (RF=3*2 = 6 so
> 3k global replica QPS) of 4kb single partition BATCH mutations at LOCAL_ONE.
> This represents about 250 QPS per coordinator in the first datacenter or 60
> QPS per core. The goal was to observe P99 write and read latencies under
> various QPS.
> *Result:*
> The good news is since the CASSANDRA-14503 changes, instead of keeping the
> mutations on heap we put the message into hints instead and don't run out of
> memory. The bad news is that the {{MessagingService-NettyOutbound-Thread's}}
> would occasionally enter a degraded state where they would just spin on a
> core. I've attached flame graphs showing the CPU state as [~jasobrown]
> applied fixes to the {{OutboundMessagingConnection}} class.
> *Follow Ups:*
> [~jasobrown] has committed a number of fixes onto his
> {{jasobrown/14503-collab}} branch including:
> 1. Limiting the amount of time spent dequeuing messages if they are expired
> (previously if messages entered the queue faster than we could dequeue them
> we'd just inifinte loop on the consumer side)
> 2. Don't call {{dequeueMessages}} from within {{dequeueMessages}} created
> callbacks.
> We're continuing to use CPU flamegraphs to figure out where we're looping and
> fixing bugs as we find them.
--
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-14747) Test Messaging Refactor with: 200 node, compression=none, encryption=none, coalescing=off
[ https://issues.apache.org/jira/browse/CASSANDRA-14747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304466#comment-17304466 ] C. Scott Andreas commented on CASSANDRA-14747: -- Proposing we mark this not-to-be-fixed from the perspective of 4.0 GA scope. Contributors have exercised perf pretty heavily here and fixed a few issues identified. Further perf improvements would be a good candidate for 4.0.x. > Test Messaging Refactor with: 200 node, compression=none, encryption=none, > coalescing=off > -- > > Key: CASSANDRA-14747 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14747 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Testing >Reporter: Joey Lynch >Assignee: Joey Lynch >Priority: Normal > Fix For: 4.0-rc > > Attachments: 3.0.17-QPS.png, 4.0.1-QPS.png, > 4.0.11-after-jolynch-tweaks.svg, 4.0.12-after-unconditional-flush.svg, > 4.0.15-after-sndbuf-fix.svg, 4.0.7-before-my-changes.svg, > 4.0_errors_showing_heap_pressure.txt, > 4.0_heap_histogram_showing_many_MessageOuts.txt, > i-0ed2acd2dfacab7c1-after-looping-fixes.svg, > trunk_14503_v2_cpuflamegraph.svg, trunk_vs_3.0.17_latency_under_load.png, > ttop_NettyOutbound-Thread_spinning.txt, > useast1c-i-0e1ddfe8b2f769060-mutation-flame.svg, > useast1e-i-08635fa1631601538_flamegraph_96node.svg, > useast1e-i-08635fa1631601538_ttop_netty_outbound_threads_96nodes, > useast1e-i-08635fa1631601538_uninlinedcpuflamegraph.0_96node_60sec_profile.svg > > > Tracks evaluating a 200 node cluster with all internode settings off (no > compression, no encryption, no coalescing). -- 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-15181) Ensure Nodes can Start and Stop
[ https://issues.apache.org/jira/browse/CASSANDRA-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304461#comment-17304461 ] C. Scott Andreas commented on CASSANDRA-15181: -- Proposing we consider this ticket complete from the perspective of RC/GA. We've had no issues provisioning clusters, executing rolling restarts, performing host replacements, expanding/shrinking clusters, or other issues related to instance lifecycle. > Ensure Nodes can Start and Stop > --- > > Key: CASSANDRA-15181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15181 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Streaming and Messaging, Test/benchmark >Reporter: Joey Lynch >Assignee: Vinay Chella >Priority: High > Fix For: 4.0-rc > > > Let's load a cluster up with data and start killing nodes. We can do hard > failures (node terminations) and soft failures (process kills) We plan to > observe the following: > * Can nodes successfully bootstrap? > * How long does it take to bootstrap > * What are the effects of TLS on and off (e.g. on stream time) > * Are hints properly played after a node restart > * Do nodes properly shutdown and start back up. -- 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-16421) [Spam issue]
[
https://issues.apache.org/jira/browse/CASSANDRA-16421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-16421:
-
Description: Content removed due to spam. (was:
{color:#22}An issue most regularly associated with the printer driver or
*[{color:#598fde}brother printer in error
state{color}|https://www.brotherprintersupportpro.net/brother-printer-in-error-state/]*.
To determine this issue, first, you need to endeavor to reset the printer
initially and subsequently reinstall the ink cartridge. If you really get this
issue, by then, it might be a gear issue. In this way, contact the assistance
bunch for the help. {color}
{color:#22}[https://www.brotherprintersupportpro.net/brother-printer-in-error-state/]{color})
Summary: [Spam issue] (was: Why might I get a brother printer in error
state?)
> [Spam issue]
>
>
> Key: CASSANDRA-16421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16421
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Adom Stark
>Priority: Normal
>
> Content removed due to spam.
--
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-16421) Why might I get a brother printer in error state?
[
https://issues.apache.org/jira/browse/CASSANDRA-16421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-16421:
-
Resolution: Invalid
Status: Resolved (was: Triage Needed)
> Why might I get a brother printer in error state?
> -
>
> Key: CASSANDRA-16421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16421
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Adom Stark
>Priority: Normal
>
>
> {color:#22}An issue most regularly associated with the printer driver or
> *[{color:#598fde}brother printer in error
> state{color}|https://www.brotherprintersupportpro.net/brother-printer-in-error-state/]*.
> To determine this issue, first, you need to endeavor to reset the printer
> initially and subsequently reinstall the ink cartridge. If you really get
> this issue, by then, it might be a gear issue. In this way, contact the
> assistance bunch for the help. {color}
> {color:#22}[https://www.brotherprintersupportpro.net/brother-printer-in-error-state/]{color}
--
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-16420) [Spam Issue]
[ https://issues.apache.org/jira/browse/CASSANDRA-16420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16420: - Summary: [Spam Issue] (was: [Phishing scam]) > [Spam Issue] > > > Key: CASSANDRA-16420 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16420 > Project: Cassandra > Issue Type: Improvement >Reporter: Adom Stark >Priority: Normal > > [ Issue text removed due to phishing scam. ] > -- 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-16420) [Spam Issue]
[ https://issues.apache.org/jira/browse/CASSANDRA-16420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16420: - Description: [ Issue text removed due to SEO spam / potential phishing scam. ] was: [ Issue text removed due to phishing scam. ] > [Spam Issue] > > > Key: CASSANDRA-16420 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16420 > Project: Cassandra > Issue Type: Improvement >Reporter: Adom Stark >Priority: Normal > > [ Issue text removed due to SEO spam / potential phishing scam. ] > -- 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-16420) [Phishing scam]
[ https://issues.apache.org/jira/browse/CASSANDRA-16420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16420: - Summary: [Phishing scam] (was: How may you recover your record if you forget Yahoo password?) > [Phishing scam] > --- > > Key: CASSANDRA-16420 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16420 > Project: Cassandra > Issue Type: Improvement >Reporter: Adom Stark >Priority: Normal > > [ Issue text removed due to phishing scam. ] > -- 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-16420) How may you recover your record if you forget Yahoo password?
[ https://issues.apache.org/jira/browse/CASSANDRA-16420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16420: - Resolution: Invalid Status: Resolved (was: Triage Needed) > How may you recover your record if you forget Yahoo password? > - > > Key: CASSANDRA-16420 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16420 > Project: Cassandra > Issue Type: Improvement >Reporter: Adom Stark >Priority: Normal > > [ Issue text removed due to phishing scam. ] > -- 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-16420) How may you recover your record if you forget Yahoo password?
[
https://issues.apache.org/jira/browse/CASSANDRA-16420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-16420:
-
Description:
[ Issue text removed due to phishing scam. ]
was:
Hi, you may recover your account if you *[{color:#598fde}forget Yahoo
password{color}|https://www.contact-customer-service.net/blog/forgot-yahoo-password/]*,
if you open yahoo.com on your web program. Starting there, you are drawn
nearer to type your email address and snap on the Continue tab. Further, you
mentioned snapping on the Forget Password associate which will take you to the
record page. As of now, you ought to enter the email address again and
thereafter snap on the Continue button.
> How may you recover your record if you forget Yahoo password?
> -
>
> Key: CASSANDRA-16420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16420
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Adom Stark
>Priority: Normal
>
> [ Issue text removed due to phishing scam. ]
>
--
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-16286) Make TokenMetadata's ring version increments atomic
[
https://issues.apache.org/jira/browse/CASSANDRA-16286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269718#comment-17269718
]
C. Scott Andreas commented on CASSANDRA-16286:
--
[~maedhroz] Would it be reasonable to target this for 4.0.x?
> Make TokenMetadata's ring version increments atomic
> ---
>
> Key: CASSANDRA-16286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16286
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> The update semantics of the ring version in {{TokenMetadata}} are not clear.
> The instance variable itself is {{volatile}}, but it is still incremented by
> a non-atomic check-and-set, and not all codepaths do that while holding the
> {{TokenMetadata}} write lock. We could make this more intelligible by forcing
> the external callers to use both the write when invalidating the ring and
> read lock when reading the current ring version. Most of the readers of the
> ring version (ex. compaction) don't need it to be fast, but it shouldn't be a
> problem even if they do. If we do this, we should be able to avoid a
> situation where concurrent invalidations don't produce two distinct version
> increments.
--
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-15181) Ensure Nodes can Start and Stop
[ https://issues.apache.org/jira/browse/CASSANDRA-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269717#comment-17269717 ] C. Scott Andreas commented on CASSANDRA-15181: -- [~b.le...@gmail.com] Thanks for untagging this for beta. This ticket may be a candidate for deferral as well. While we don't have exhaustive metrics for the items listed in the description, I'm not aware of regression in these areas and regularly exercise the host replacement path on trunk. > Ensure Nodes can Start and Stop > --- > > Key: CASSANDRA-15181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15181 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Streaming and Messaging, Test/benchmark >Reporter: Joey Lynch >Assignee: Vinay Chella >Priority: High > Fix For: 4.0-rc > > > Let's load a cluster up with data and start killing nodes. We can do hard > failures (node terminations) and soft failures (process kills) We plan to > observe the following: > * Can nodes successfully bootstrap? > * How long does it take to bootstrap > * What are the effects of TLS on and off (e.g. on stream time) > * Are hints properly played after a node restart > * Do nodes properly shutdown and start back up. -- 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-16364) Simultaneous bootstrap can cause token collision
[
https://issues.apache.org/jira/browse/CASSANDRA-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269711#comment-17269711
]
C. Scott Andreas commented on CASSANDRA-16364:
--
Hi [~paulo], do you know if this is a regression from 3.0.x/3.11.x? If not,
would it be worth considering targeting 4.0.x?
Apologies for asking if work's active on it - just doing a spot-check of open
issues tagged for beta.
> Simultaneous bootstrap can cause token collision
>
>
> Key: CASSANDRA-16364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16364
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
> Fix For: 4.0-beta
>
>
> While raising a 6-node ccm cluster to test 4.0-beta4, 2 nodes chosen the same
> tokens using the default {{allocate_tokens_for_local_rf}}. However they both
> succeeded bootstrap with colliding tokens.
> We were familiar with this issue from CASSANDRA-13701 and CASSANDRA-16079,
> and the workaround to fix this is to avoid parallel bootstrap when using
> {{allocate_tokens_for_local_rf}}.
> However, since this is the default behavior, we should try to detect and
> prevent this situation when possible, since it can break users relying on
> parallel bootstrap behavior.
> I think we could prevent this as following:
> 1. announce intent to bootstrap via gossip (ie. add node on gossip without
> token information)
> 2. wait for gossip to settle for a longer period (ie. ring delay)
> 3. allocate tokens (if multiple bootstrap attempts are detected, tie break
> via node-id)
> 4. broadcast tokens and move on with bootstrap
--
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-15472) Read failure due to exception from metrics-core dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-15472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269706#comment-17269706
]
C. Scott Andreas commented on CASSANDRA-15472:
--
(Alternately as the issue isn't a regression, it may also be reasonable to
designate the ticket as not being a release blocker by updating the fix version
to 4.0.x).
> Read failure due to exception from metrics-core dependency
> --
>
> Key: CASSANDRA-15472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15472
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> Stacktrace
> {code:java}
> Uncaught exception on thread Thread[SharedPool-Worker-27,5,main]: {}
> java.util.NoSuchElementException: null
> at
> java.util.concurrent.ConcurrentSkipListMap.firstKey(ConcurrentSkipListMap.java:2053)
> ~[na:1.8.0_222]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:102)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:81)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.update(Histogram.java:110)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:198)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:76)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:108)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:114)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1897)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_222]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
> {code}
> This [issue|https://github.com/dropwizard/metrics/issues/1278] has been
> [fixed|https://github.com/dropwizard/metrics/pull/1436] in
> [v4.0.6|https://github.com/dropwizard/metrics/releases/tag/v4.0.6].
> This is observed on a 2.1.19 cluster, but this would impact pretty much any
> version of C* since we depend on lower versions of metrics-core that do not
> have the fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas reassigned CASSANDRA-16091:
Assignee: David Capwell (was: C. Scott Andreas)
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas reassigned CASSANDRA-16091:
Assignee: C. Scott Andreas (was: David Capwell)
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: C. Scott Andreas
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
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-16223) Reading dense table yields invalid results in case of row scan queries
[
https://issues.apache.org/jira/browse/CASSANDRA-16223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219340#comment-17219340
]
C. Scott Andreas commented on CASSANDRA-16223:
--
Great find! Does this impact 3.0.x as well?
> Reading dense table yields invalid results in case of row scan queries
> --
>
> Key: CASSANDRA-16223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16223
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ThriftIntegrationTest}} is broken in the way that it does not actually test
> reads before and after flushing, because it does not do flush at all (see
> https://github.com/apache/cassandra/blob/cassandra-3.11/test/unit/org/apache/cassandra/cql3/validation/ThriftIntegrationTest.java#L939).
> After fixing that method so that it really flushes memtables to disk, we can
> see inconsistency in reads from dense table - the results returned from
> memtable differs from the results returned from sstable (the later are wrong,
> cell values are skipped unexpectedly).
> {noformat}
> java.lang.AssertionError: Invalid value for row 0 column 0 (value of type
> ascii), expected but got <>
> {noformat}
> In principle this problems is about skipping column values when doing row
> scan queries with explicitly selected columns (not wildcard), when the
> columns belong to a super column. This happens only when reading from
> sstables, it does not happen when reading from memtables.
--
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-14157) [DTEST] [TRUNK] test_tracing_does_not_interfere_with_digest_calculation - cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1
[
https://issues.apache.org/jira/browse/CASSANDRA-14157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14157:
-
Fix Version/s: (was: 4.0-triage)
> [DTEST] [TRUNK] test_tracing_does_not_interfere_with_digest_calculation -
> cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1
> -
>
> Key: CASSANDRA-14157
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14157
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Michael Kjellman
>Assignee: Adam Holmberg
>Priority: Normal
> Labels: dtest
> Fix For: 4.0-beta3
>
>
> test_tracing_does_not_interfere_with_digest_calculation -
> cql_tracing_test.TestCqlTracing failed it's assertion once today in a
> circleci run. the dtests were running against trunk.
> Although it has failed once so far, a quick read of the comments in the test
> seems to indicate that the assertion failing this way might mean that
> CASSANDRA-13964 didn't fully fix the issue.
> {code:python}
> if jmx.has_mbean(rr_count):
> # expect 0 digest mismatches
> > assert 0 == jmx.read_attribute(rr_count, 'Count')
> E AssertionError: assert 0 == 1
> E+ where 1 = 0x7f62d4156898>>('org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlocking',
> 'Count')
> E+where > =
> .read_attribute
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14030) disk_balance_bootstrap_test - disk_balance_test.TestDiskBalance fails: Missing: ['127.0.0.5.* now UP']:
[
https://issues.apache.org/jira/browse/CASSANDRA-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14030:
-
Fix Version/s: (was: 4.0-triage)
> disk_balance_bootstrap_test - disk_balance_test.TestDiskBalance fails:
> Missing: ['127.0.0.5.* now UP']:
> ---
>
> Key: CASSANDRA-14030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14030
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing
>Reporter: Michael Kjellman
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> disk_balance_bootstrap_test - disk_balance_test.TestDiskBalance fails:
> Missing: ['127.0.0.5.* now UP']:
> {code}
> 15 Nov 2017 11:28:03 [node4] Missing: ['127.0.0.5.* now UP']:
> .
> See system.log for remainder
> >> begin captured logging <<
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-NZzhNb
> dtest: DEBUG: Done setting configuration options:
> { 'initial_token': None,
> 'num_tokens': '32',
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> - >> end captured logging << -
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/cassandra/cassandra-dtest/disk_balance_test.py", line 44, in
> disk_balance_bootstrap_test
> node5.start(wait_for_binary_proto=True)
> File
> "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py", line
> 706, in start
> node.watch_log_for_alive(self, from_mark=mark)
> File
> "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py", line
> 520, in watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> File
> "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py", line
> 488, in watch_log_for
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + "
> [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" +
> reads[:50] + ".\nSee {} for remainder".format(filename))
> "15 Nov 2017 11:28:03 [node4] Missing: ['127.0.0.5.* now UP']:\n.\nSee
> system.log for remainder\n >> begin captured logging <<
> \ndtest: DEBUG: cluster ccm directory:
> /tmp/dtest-NZzhNb\ndtest: DEBUG: Done setting configuration options:\n{
> 'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
> 5,\n'range_request_timeout_in_ms': 1,\n
> 'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
> 'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
> 1}\n- >> end captured logging <<
> -"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14688) Update protocol spec and class level doc with protocol checksumming details
[
https://issues.apache.org/jira/browse/CASSANDRA-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14688:
-
Fix Version/s: (was: 4.0-triage)
> Update protocol spec and class level doc with protocol checksumming details
> ---
>
> Key: CASSANDRA-14688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14688
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-rc
>
>
> CASSANDRA-13304 provides an option to add checksumming to the frame body of
> native protocol messages. The native protocol spec needs to be updated to
> reflect this ASAP. We should also verify that the javadoc comments describing
> the on-wire format in
> {{o.a.c.transport.frame.checksum.ChecksummingTransformer}} are up to date.
--
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-14793) Improve system table handling when losing a disk when using JBOD
[ https://issues.apache.org/jira/browse/CASSANDRA-14793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14793: - Fix Version/s: (was: 4.0-triage) > Improve system table handling when losing a disk when using JBOD > > > Key: CASSANDRA-14793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14793 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Marcus Eriksson >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We should improve the way we handle disk failures when losing a disk in a > JBOD setup > One way could be to pin the system tables to a special data directory. -- 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-14753) Document incremental repair session timeouts and repair_admin usage
[ https://issues.apache.org/jira/browse/CASSANDRA-14753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14753: - Fix Version/s: (was: 4.0-triage) > Document incremental repair session timeouts and repair_admin usage > --- > > Key: CASSANDRA-14753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14753 > Project: Cassandra > Issue Type: Task > Components: Legacy/Documentation and Website >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Low > Fix For: 4.0 > > > As seen in CASSANDRA-14685, the behavior of incremental repair sessions with > failed streams is not obvious and appears to be a bug (although it's working > as expected). The incremental repair documentation should be updated to > describe what happens if an incremental repair session fails mid-stream, the > session timeouts, and how and when to use nodetool repair_admin. The sstable > acquisition error should also be updated to mention this as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15158: - Fix Version/s: (was: 4.0-triage) > Wait for schema agreement rather than in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Blake Eggleston >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- 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-14834) Avoid keeping StreamingTombstoneHistogramBuilder.Spool in memory during the whole compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-14834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14834:
-
Fix Version/s: (was: 4.0-triage)
> Avoid keeping StreamingTombstoneHistogramBuilder.Spool in memory during the
> whole compaction
>
>
> Key: CASSANDRA-14834
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14834
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> Since CASSANDRA-13444 {{StreamingTombstoneHistogramBuilder.Spool}} is
> allocated to keep around an array with 131072 * 2 * 2 integers *per written
> sstable* during the whole compaction. With LCS at times creating 1000s of
> sstables during a compaction it kills the node.
--
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-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
[
https://issues.apache.org/jira/browse/CASSANDRA-15369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15369:
-
Fix Version/s: (was: 4.0-triage)
> Fake row deletions and range tombstones, causing digest mismatch and sstable
> growth
> ---
>
> Key: CASSANDRA-15369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Benedict Elliott Smith
>Assignee: Zhao Yang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> As assessed in CASSANDRA-15363, we generate fake row deletions and fake
> tombstone markers under various circumstances:
> * If we perform a clustering key query (or select a compact column):
> * Serving from a {{Memtable}}, we will generate fake row deletions
> * Serving from an sstable, we will generate fake row tombstone markers
> * If we perform a slice query, we will generate only fake row tombstone
> markers for any range tombstone that begins or ends outside of the limit of
> the requested slice
> * If we perform a multi-slice or IN query, this will occur for each
> slice/clustering
> Unfortunately, these different behaviours can lead to very different data
> stored in sstables until a full repair is run. When we read-repair, we only
> send these fake deletions or range tombstones. A fake row deletion,
> clustering RT and slice RT, each produces a different digest. So for each
> single point lookup we can produce a digest mismatch twice, and until a full
> repair is run we can encounter an unlimited number of digest mismatches
> across different overlapping queries.
> Relatedly, this seems a more problematic variant of our atomicity failures
> caused by our monotonic reads, since RTs can have an atomic effect across (up
> to) the entire partition, whereas the propagation may happen on an
> arbitrarily small portion. If the RT exists on only one node, this could
> plausibly lead to fairly problematic scenario if that node fails before the
> range can be repaired.
> At the very least, this behaviour can lead to an almost unlimited amount of
> extraneous data being stored until the range is repaired and compaction
> happens to overwrite the sub-range RTs and row deletions.
--
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-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15313:
-
Fix Version/s: (was: 4.0-triage)
> Fix flaky - ChecksummingTransformerTest -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> ---
>
> Key: CASSANDRA-15313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Vinay Chella
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15313-hack.patch
>
>
> During the recent runs, this test appears to be flaky.
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
> corruptionCausesFailure-compression -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> {code:java}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at org.quicktheories.impl.Precursor.(Precursor.java:17)
> at
> org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
> at
> org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
> at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
> at
> org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
> at
> org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
> at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
> at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
> Source)
> at
> org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
> at
> org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.impl.Core.generate(Core.java:150)
> at org.quicktheories.impl.Core.shrink(Core.java:103)
> at org.quicktheories.impl.Core.run(Core.java:39)
> at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
> at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
> at
> org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
> at
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15299:
-
Fix Version/s: (was: 4.0-triage)
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Alex Petrov
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-alpha
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
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-15536) 4.0 Quality: Components and Test Plans
[ https://issues.apache.org/jira/browse/CASSANDRA-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15536: - Fix Version/s: (was: 4.0-triage) > 4.0 Quality: Components and Test Plans > -- > > Key: CASSANDRA-15536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15536 > Project: Cassandra > Issue Type: Epic > Components: Test/benchmark, Test/dtest/python, Test/fuzz, Test/unit >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: High > Fix For: 4.0 > > > [Source doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#]. > Jira migrated from > [cwiki|https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality:+Components+and+Test+Plans] > The overarching goal of the 4.0 release is that Cassandra 4.0 should be at a > state where major users would run it in production when it is cut. To gain > this confidence there are various ongoing testing efforts involving > correctness, performance, and ease of use. In this page we try to coordinate > and identify blockers for subsystems before we can release 4.0 > For each component we strive to have shepherds and contributors involved. > Shepherds should be committers or knowledgeable component owners and are > responsible for driving their blocking tickets to completion and ensuring > quality in their claimed area, while contributors have signed up to help > verify that subsystem by running tests or contributing fixes. Shepherds also > ideally help set testing standards and ensure that we meet a high standard of > quality in their claimed area. > If you are interested in contributing to testing 4.0, please add your name as > assignee if you want to drive things, reviewer if just participate and > review, and get involved in the the tracking ticket, and dev list/IRC > discussions involving that component. > h3. Targeted Components / Subsystems > We've tried to collect some of the major components or subsystems that we > want to ensure work properly towards having a great 4.0 release. If you think > something is missing please add it. Better yet volunteer to contribute to > testing it! > h4. Internode Messaging > In 4.0 we're getting a new Netty based inter-node communication system > (CASSANDRA-8457). As internode messaging is vital to the correctness and > performance of the database we should make sure that all forms (TLS, > compressed, low latency, high latency, etc ...) of internode messaging > function correctly. > h4. Test Infrastructure / Automation: Diff Testing > Diff testing is a form of model-based testing in which two clusters are > exhaustively compared to assert identity. To support Apache Cassandra 4.0 > validation, contributors have developed cassandra-diff. This is a Spark > application that distributes the token range over a configurable number of > Spark executors, then parallelizes randomized forward and reverse reads with > varying paging sizes to read and compare every row present in the cluster, > persisting a record of mismatches for investigation. This methodology has > been instrumental to identifying data loss, data corruption, and incorrect > response issues introduced in early Cassandra 3.0 releases. > cassandra-diff and associated documentation can be found at: > [https://github.com/apache/cassandra-diff]. Contributors are encouraged to > run diff tests against clusters they manage and report issues to ensure > workload diversity across the project. > h4. System Tables and Internal Schema > This task covers a review of and minor bug fixes to local and distributed > system keyspaces. Planned work in this area is now complete. > h4. Source Audit and Performance Testing: Streaming > This task covers an audit of the Streaming implementation in Apache Cassandra > 4.0. In this release, contributors have implemented full-SSTable streaming to > improve performance and reduce memory pressure. Internode messaging changes > implemented in CASSANDRA-15066 adjacent to streaming suggested that review of > the streaming implementation itself may be desirable. Prior work also covered > performance testing of full-SSTable streaming. > h4. Test Infrastructure / Automation: "Harry" > CASSANDRA-15348 - Harry: generator library and extensible framework for fuzz > testing Apache Cassandra TRIAGE NEEDED > Harry is a component for fuzz testing and verification of the Apache > Cassandra clusters at scale. Harry allows to run tests that are able to > validate state of both dense nodes (to test local read-write path) and large > clusters (to test distributed read-write path), and do it efficiently. Harry > defines a model that holds the state of the database, generators that produce > reproducible,
[jira] [Updated] (CASSANDRA-15865) Flaky dtest hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow
[ https://issues.apache.org/jira/browse/CASSANDRA-15865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15865: - Fix Version/s: (was: 4.0-triage) > Flaky dtest > hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow > --- > > Key: CASSANDRA-15865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15865 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Sam Tunnicliffe >Assignee: Charles Attwood Thomas >Priority: Normal > Fix For: 4.0-beta > > > I've seen this fail a couple of times under JDK11, when it doesn't appear to > be related to the changes under test. > > -- 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-15962) Digest for some queries is different depending whether the data are retrieved from sstable or memtable
[
https://issues.apache.org/jira/browse/CASSANDRA-15962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15962:
-
Fix Version/s: (was: 4.0-triage)
> Digest for some queries is different depending whether the data are retrieved
> from sstable or memtable
> --
>
> Key: CASSANDRA-15962
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15962
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
> Attachments: DigestTest.java
>
>
> Not sure into which category should I assign this ticket.
>
> Basically when reading using certain column filters, the digest is different
> depending whether we read from sstable and memtable. This happens on
> {{trunk}} and {{cassandra-3.11}} branches. However it works properly on
> {{cassandra-3.0}} branch.
>
> I'm attaching a simple test for trunk to demonstrate what I mean.
>
> Please verify my test and my conclusions
>
--
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-15903) Doc update: stream-entire-sstable supports all compaction strategies and internode encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-15903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15903: - Fix Version/s: (was: 4.0-triage) > Doc update: stream-entire-sstable supports all compaction strategies and > internode encryption > - > > Key: CASSANDRA-15903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15903 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Zhao Yang >Priority: Normal > Fix For: 4.0 > > > As [~mck] point out, doc needs to be updated for CASSANDRA-15657 and > CASSANDRA-15740. -- 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-15997) TestBootstrap::test_cleanup failing on unexpected number of SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15997:
-
Fix Version/s: (was: 4.0-triage)
> TestBootstrap::test_cleanup failing on unexpected number of SSTables
>
>
> Key: CASSANDRA-15997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15997
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Caleb Rackliffe
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-beta
>
>
> This failure has now occurred in a number of places on trunk (4.0), including
> both Java 8 and 11 dtest runs. Nominally, there appear to be more SSTables
> after cleanup than the test is expecting.
> {noformat}
> if len(sstables) > basecount + jobs:
> logger.debug("Current count is {}, basecount was
> {}".format(len(sstables), basecount))
> failed.set()
> {noformat}
> Examples:
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/92/workflows/c59be4f8-329e-4d76-9c59-d49c38e58dd2/jobs/448
> https://app.circleci.com/pipelines/github/jolynch/cassandra/20/workflows/9d6c3b86-6207-4ead-aa4b-79022fc84182/jobs/893
--
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-15996) Fix flaky python dtest test_expiration_overflow_policy_capnowarn - ttl_test.TestTTL
[
https://issues.apache.org/jira/browse/CASSANDRA-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15996:
-
Fix Version/s: (was: 4.0-triage)
> Fix flaky python dtest test_expiration_overflow_policy_capnowarn -
> ttl_test.TestTTL
> ---
>
> Key: CASSANDRA-15996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15996
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/361/workflows/3a42fa45-1f60-4c95-86a4-15a6773e384e/jobs/1860
> {code}
> > assert warning, 'Log message should be print for CAP and
> > CAP_NOWARN policy'
> E AssertionError: Log message should be print for CAP and
> CAP_NOWARN policy
> E assert []
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16048: - Fix Version/s: (was: 4.0-triage) > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16061) transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16061: - Fix Version/s: (was: 4.0-triage) > transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup > > > Key: CASSANDRA-16061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16061 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta > > > Failing here, also locally: > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/312/workflows/da4ce69c-e778-467e-b9f3-27ab166a8321/jobs/1945] -- 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-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16074: - Fix Version/s: (was: 4.0-triage) > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Fix For: 4.0-beta > > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- 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-16113) Consolidate dead nodes check in force repair
[ https://issues.apache.org/jira/browse/CASSANDRA-16113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16113: - Fix Version/s: (was: 4.0-triage) > Consolidate dead nodes check in force repair > > > Key: CASSANDRA-16113 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16113 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 4h 10m > Remaining Estimate: 0h > > The check for dead nodes during force repair is duplicated in the normal and > incremental repair. We could consolidate those 2 checks to make the code more > dry. > The check should throw a more meaningful error message to indicate that all > neighbor nodes are down, instead of "java.lang.IllegalArgumentException: > Endpoints can not be empty" -- 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-16135) Separate in-JVM test into smaller packages
[ https://issues.apache.org/jira/browse/CASSANDRA-16135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16135: - Fix Version/s: (was: 4.0-triage) > Separate in-JVM test into smaller packages > -- > > Key: CASSANDRA-16135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16135 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Introduce a structure similar to how tags are organised in Cassandra Jira for > corresponding in-jvm dtests to help people find a right place for their tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16143) Streaming fails when s SSTable writer finish() exceeds internode_tcp_user_timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-16143:
-
Fix Version/s: (was: 4.0-triage)
> Streaming fails when s SSTable writer finish() exceeds
> internode_tcp_user_timeout
> -
>
> Key: CASSANDRA-16143
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16143
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
>
> tl;dr The internode TCP user timeout that provides more responsive detection
> of dead nodes for internode message will cause streaming to fail if system
> calls to fsync/fdatasync exceed the timeout (default 30s).
> To workaround, explicitly set internode_tcp_user_timeout to longer than
> fsync/fdatasync, or to zero to revert to the operating system default.
> Details:
> While bootstrapping a replacement 4.0beta3 node in an existing cluster,
> bootstrap streaming repeatedly failed with the streaming follower logging
> {code:java}
> ERROR 2020-09-10T14:29:34,711 [NettyStreaming-Outbound-1.1.1.1.7000:1]
> org.apache.cassandra.streaming.StreamSession:693 - [Stream
> #7cb67c00-f3ac-11ea-b940-f7836f164528] Streaming error occurred on session
> with peer 1.1.1.1:7000
> org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException: The channel
> this output stream was writing to has been closed
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:200)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitForSpace(AsyncChannelOutputPlus.java:140)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.beginFlush(AsyncChannelOutputPlus.java:97)
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.lambda$writeToChannel$0(AsyncStreamingOutputPlus.java:142)
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.lambda$write$0(CassandraCompressedStreamWriter.java:90)
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.writeToChannel(AsyncStreamingOutputPlus.java:138)
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.write(CassandraCompressedStreamWriter.java:89)
>at
> org.apache.cassandra.db.streaming.CassandraOutgoingFile.write(CassandraOutgoingFile.java:180)
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage.serialize(OutgoingStreamMessage.java:87)
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:45)
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:34)
>at
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:40)
>at
> org.apache.cassandra.streaming.async.NettyStreamingMessageSender$FileStreamTask.run(NettyStreamingMessageSender.java:347)
>at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
>at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.lang.Thread.run(Thread.java:834) [?:?]
>Suppressed: java.nio.channels.ClosedChannelException
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.doFlush(AsyncStreamingOutputPlus.java:78)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:229)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.close(AsyncChannelOutputPlus.java:248)
>at
> org.apache.cassandra.streaming.async.NettyStreamingMessageSender$FileStreamTask.run(NettyStreamingMessageSender.java:348)
>at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
>at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[jira] [Updated] (CASSANDRA-16144) TLS connections to the storage port on a node without server encryption configured causes java.io.IOException accessing missing keystore
[
https://issues.apache.org/jira/browse/CASSANDRA-16144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-16144:
-
Fix Version/s: (was: 4.0-triage)
> TLS connections to the storage port on a node without server encryption
> configured causes java.io.IOException accessing missing keystore
>
>
> Key: CASSANDRA-16144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16144
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If a TLS connection is requested against a node with all encryption disabled
> by configuration,
> configured with
> {code}
> server_encryption_options: {optional:false, internode_encryption: none}
> {code}
> it logs the following error if no keystore exists for the node.
> {code}
> INFO [Messaging-EventLoop-3-3] 2020-09-15T14:30:02,952 : -
> 127.0.0.1:7000->127.0.1.1:7000-URGENT_MESSAGES-[no-channel] failed to connect
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: local1-i1/127.0.1.1:7000
> Caused by: java.net.ConnectException: Connection refused
>at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:?]
>at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779) ~[?:?]
>at
> io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:702)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.lang.Thread.run(Thread.java:834) [?:?]
> WARN [Messaging-EventLoop-3-9] 2020-09-15T14:30:06,375 : - Failed to
> initialize a channel. Closing: [id: 0x0746c157, L:/127.0.0.1:7000 -
> R:/127.0.0.1:59623]
> java.io.IOException: failed to build trust manager store for secure
> connections
>at
> org.apache.cassandra.security.SSLFactory.buildKeyManagerFactory(SSLFactory.java:232)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:300)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:276)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:257)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.net.InboundConnectionInitiator$Initializer.initChannel(InboundConnectionInitiator.java:107)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.net.InboundConnectionInitiator$Initializer.initChannel(InboundConnectionInitiator.java:71)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:938)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
>
[jira] [Commented] (CASSANDRA-15833) Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657
[ https://issues.apache.org/jira/browse/CASSANDRA-15833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202383#comment-17202383 ] C. Scott Andreas commented on CASSANDRA-15833: -- Checking back as this has been in "Ready to Commit" for a bit – anything outstanding before landing it, or is this ready to go? > Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657 > > > Key: CASSANDRA-15833 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15833 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > Attachments: CASSANDRA-15833-3.11.patch, CASSANDRA-15833-4.0.patch > > > CASSANDRA-10657 introduced changes in how the ColumnFilter is interpreted. > This results in digest mismatch when querying incomplete set of columns from > a table with consistency that requires reaching instances running pre > CASSANDRA-10657 from nodes that include CASSANDRA-10657 (it was introduced in > Cassandra 3.4). > The fix is to bring back the previous behaviour until there are no instances > running pre CASSANDRA-10657 version. -- 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-13994) Remove COMPACT STORAGE internals before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129840#comment-17129840
]
C. Scott Andreas commented on CASSANDRA-13994:
--
Echoing that, yes; removing protocol V3 at this point would delay the ability
of many to upgrade to Cassandra 4.0 and reduce the amount of prerelease testing
that can be performed due to use of older driver versions.
> Remove COMPACT STORAGE internals before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
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-15750) Upgrade Cassandra Java Driver to 4.6
[ https://issues.apache.org/jira/browse/CASSANDRA-15750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092291#comment-17092291 ] C. Scott Andreas commented on CASSANDRA-15750: -- Is this issue a duplicate of CASSANDRA-13951? And yes, I also share David's concerns about upgrading to the 4.0 series of the Java driver. Could we consider the latest release of the 3.6.0 series? > Upgrade Cassandra Java Driver to 4.6 > > > Key: CASSANDRA-15750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15750 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Eduard Tudenhoefner >Assignee: Eduard Tudenhoefner >Priority: Normal > Fix For: 4.0-beta, 4.0-rc > > > Before releasing C* 4.0 I think it would be a good idea to upgrade to the > latest Cassandra Java Driver that is being used internally. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15721) any open source management tool for appache cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-15721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas reassigned CASSANDRA-15721: Assignee: Chirantan > any open source management tool for appache cassandra > -- > > Key: CASSANDRA-15721 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15721 > Project: Cassandra > Issue Type: Task >Reporter: Chirantan >Assignee: Chirantan >Priority: Normal > > pls recomend any open source management tool for appache cassandra similare > to ops center -- 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-15721) any open source management tool for appache cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-15721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15721: - Resolution: Not A Problem Status: Resolved (was: Triage Needed) > any open source management tool for appache cassandra > -- > > Key: CASSANDRA-15721 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15721 > Project: Cassandra > Issue Type: Task >Reporter: Chirantan >Priority: Normal > > pls recomend any open source management tool for appache cassandra similare > to ops center -- 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-15721) any open source management tool for appache cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-15721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082783#comment-17082783 ] C. Scott Andreas commented on CASSANDRA-15721: -- Hi Chirantan, this bug tracker is used to track bugs in the database and feature development. For questions like this, please refer to the documentation at [https://cassandra.apache.org|https://cassandra.apache.org/] or reach out to the user community via email or Slack. Information regarding how to join the mailing list or ASF Slack channel (#cassandra) is located here: https://cassandra.apache.org/community/ > any open source management tool for appache cassandra > -- > > Key: CASSANDRA-15721 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15721 > Project: Cassandra > Issue Type: Task >Reporter: Chirantan >Priority: Normal > > pls recomend any open source management tool for appache cassandra similare > to ops center -- 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-15720) Simplify the documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15720: - Summary: Simplify the documentation (was: Fix the documentation) > Simplify the documentation > -- > > Key: CASSANDRA-15720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15720 > Project: Cassandra > Issue Type: Improvement >Reporter: nikhil karnik >Priority: Normal > > Can you fix the documentation, > [https://github.com/apache/cassandra/blob/trunk/doc/source/new/streaming.rst] > In the zero copying section, it says "Pre-4.0, during streaming Cassandra > reifies the SSTables into objects." > The word reifies makes no sense. Its not easy to understand and as end user > if you can update it with some simple English would help. > I think it "It serializes the data, the meta data needs to be re-built on the > receiving node" but a better and simple explanation would help. -- 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-15631) Add AssertJ test dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17061814#comment-17061814 ] C. Scott Andreas commented on CASSANDRA-15631: -- No concern from me – though I'm also not a stakeholder. Discussion on the dev list was supportive. > Add AssertJ test dependency > --- > > Key: CASSANDRA-15631 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15631 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest, Test/unit >Reporter: Kevin Gallardo >Assignee: Kevin Gallardo >Priority: Normal > Fix For: 4.0-beta > > > See > [proposal|https://lists.apache.org/thread.html/rc562ec47578d0ae6f346ba9e3d7469c1cd3f8b521a72ddcb2accc47b%40%3Cdev.cassandra.apache.org%3E]. > The goal is to add [AssertJ|https://assertj.github.io/doc/] to the test > framework to allow for more comprehensible and easier to write tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15472) Read failure due to exception from metrics-core dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-15472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15472:
-
Bug Category: Parent values: Availability(12983)Level 1 values: Response
Crash(12991)
Complexity: Normal
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Read failure due to exception from metrics-core dependency
> --
>
> Key: CASSANDRA-15472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15472
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> Stacktrace
> {code:java}
> Uncaught exception on thread Thread[SharedPool-Worker-27,5,main]: {}
> java.util.NoSuchElementException: null
> at
> java.util.concurrent.ConcurrentSkipListMap.firstKey(ConcurrentSkipListMap.java:2053)
> ~[na:1.8.0_222]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:102)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:81)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.update(Histogram.java:110)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:198)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:76)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:108)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:114)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1897)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_222]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
> {code}
> This [issue|https://github.com/dropwizard/metrics/issues/1278] has been
> [fixed|https://github.com/dropwizard/metrics/pull/1436] in
> [v4.0.6|https://github.com/dropwizard/metrics/releases/tag/v4.0.6].
> This is observed on a 2.1.19 cluster, but this would impact pretty much any
> version of C* since we depend on lower versions of metrics-core that do not
> have the fix.
--
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-15474) Audit Logging - New Feature
[ https://issues.apache.org/jira/browse/CASSANDRA-15474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15474: - Test and Documentation Plan: [ Review of documentation ] Status: Patch Available (was: Open) > Audit Logging - New Feature > --- > > Key: CASSANDRA-15474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15474 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on audit logging, a new feature. > https://github.com/apache/cassandra/pull/403 -- 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-15474) Audit Logging - New Feature
[ https://issues.apache.org/jira/browse/CASSANDRA-15474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15474: - Change Category: Code Clarity Complexity: Normal Status: Open (was: Triage Needed) > Audit Logging - New Feature > --- > > Key: CASSANDRA-15474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15474 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on audit logging, a new feature. > https://github.com/apache/cassandra/pull/403 -- 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-15473) New feature - Virtual Tables
[ https://issues.apache.org/jira/browse/CASSANDRA-15473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15473: - Change Category: Code Clarity Complexity: Normal Status: Open (was: Triage Needed) > New feature - Virtual Tables > > > Key: CASSANDRA-15473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15473 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on virtual tables, a new feature. > https://github.com/apache/cassandra/pull/402 -- 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-15473) New feature - Virtual Tables
[ https://issues.apache.org/jira/browse/CASSANDRA-15473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15473: - Test and Documentation Plan: [ Review of documentation ] Status: Patch Available (was: Open) > New feature - Virtual Tables > > > Key: CASSANDRA-15473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15473 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on virtual tables, a new feature. > https://github.com/apache/cassandra/pull/402 -- 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-15476) Transient Replication - New Feature
[ https://issues.apache.org/jira/browse/CASSANDRA-15476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15476: - Change Category: Code Clarity Complexity: Normal Status: Open (was: Triage Needed) > Transient Replication - New Feature > --- > > Key: CASSANDRA-15476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15476 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on transient replication, a new feature. > https://github.com/apache/cassandra/pull/405 -- 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-15479) Backups - updated
[ https://issues.apache.org/jira/browse/CASSANDRA-15479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15479: - Change Category: Code Clarity Complexity: Normal Status: Open (was: Triage Needed) > Backups - updated > - > > Key: CASSANDRA-15479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15479 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added Backups page. > https://github.com/apache/cassandra/pull/408 -- 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-15480) Bulk Loading
[ https://issues.apache.org/jira/browse/CASSANDRA-15480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15480: - Test and Documentation Plan: [ Review of documentation ] Status: Patch Available (was: Open) > Bulk Loading > > > Key: CASSANDRA-15480 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15480 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added bulk loading page. > https://github.com/apache/cassandra/pull/409 -- 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-15476) Transient Replication - New Feature
[ https://issues.apache.org/jira/browse/CASSANDRA-15476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15476: - Test and Documentation Plan: [ Review of documentation ] Status: Patch Available (was: Open) > Transient Replication - New Feature > --- > > Key: CASSANDRA-15476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15476 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on transient replication, a new feature. > https://github.com/apache/cassandra/pull/405 -- 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-15479) Backups - updated
[ https://issues.apache.org/jira/browse/CASSANDRA-15479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15479: - Test and Documentation Plan: [ Review of documentation ] Status: Patch Available (was: Open) > Backups - updated > - > > Key: CASSANDRA-15479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15479 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added Backups page. > https://github.com/apache/cassandra/pull/408 -- 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-15480) Bulk Loading
[ https://issues.apache.org/jira/browse/CASSANDRA-15480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15480: - Change Category: Code Clarity Complexity: Normal Status: Open (was: Triage Needed) > Bulk Loading > > > Key: CASSANDRA-15480 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15480 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added bulk loading page. > https://github.com/apache/cassandra/pull/409 -- 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
