[jira] [Commented] (CASSANDRA-18845) Waiting for gossip to settle on live endpoints
[
https://issues.apache.org/jira/browse/CASSANDRA-18845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836370#comment-17836370
]
Cameron Zemek commented on CASSANDRA-18845:
---
I have reworked the patch more so it a new method instead of modifying the
existing waitToSettle. So it has the least change to any existing behavior. It
directly called in MigrationCoordinator::awaitSchemaRequests to handle if node
bootstrapping (since need nodes in UP state in order to get schema and stream
sstables from). And just before enabling native transport.
https://issues.apache.org/jira/secure/attachment/13068153/CASSANDRA-18845-4_0_12.patch
> Waiting for gossip to settle on live endpoints
> --
>
> Key: CASSANDRA-18845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18845
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Cameron Zemek
>Priority: Normal
> Attachments: 18845-seperate.patch, CASSANDRA-18845-4_0_12.patch,
> delay.log, example.log, image-2023-09-14-11-16-23-020.png, stream.log,
> test1.log, test2.log, test3.log
>
>
> This is a follow up to CASSANDRA-18543
> Although that ticket added ability to set cassandra.gossip_settle_min_wait_ms
> this is tedious and error prone. On a node just observed a 79 second gap
> between waiting for gossip and the first echo response to indicate a node is
> UP.
> The problem being that do not want to start Native Transport until gossip
> settles otherwise queries can fail consistency such as LOCAL_QUORUM as it
> thinks the replicas are still in DOWN state.
> Instead of having to set gossip_settle_min_wait_ms I am proposing that
> (outside single node cluster) wait for UP message from another node before
> considering gossip as settled. Eg.
> {code:java}
> if (currentSize == epSize && currentLive == liveSize && liveSize
> > 1)
> {
> logger.debug("Gossip looks settled.");
> numOkay++;
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18845) Waiting for gossip to settle on live endpoints
[
https://issues.apache.org/jira/browse/CASSANDRA-18845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836370#comment-17836370
]
Cameron Zemek edited comment on CASSANDRA-18845 at 4/11/24 10:18 PM:
-
I have reworked the [patch| [^CASSANDRA-18845-4_0_12.patch]] more so it a new
method instead of modifying the existing waitToSettle, so it has the least
change to any existing behavior. It directly called in
MigrationCoordinator::awaitSchemaRequests to handle if node bootstrapping
(since need nodes in UP state in order to get schema and stream sstables from).
And just before enabling native transport.
was (Author: cam1982):
I have reworked the patch more so it a new method instead of modifying the
existing waitToSettle. So it has the least change to any existing behavior. It
directly called in MigrationCoordinator::awaitSchemaRequests to handle if node
bootstrapping (since need nodes in UP state in order to get schema and stream
sstables from). And just before enabling native transport.
https://issues.apache.org/jira/secure/attachment/13068153/CASSANDRA-18845-4_0_12.patch
> Waiting for gossip to settle on live endpoints
> --
>
> Key: CASSANDRA-18845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18845
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Cameron Zemek
>Priority: Normal
> Attachments: 18845-seperate.patch, CASSANDRA-18845-4_0_12.patch,
> delay.log, example.log, image-2023-09-14-11-16-23-020.png, stream.log,
> test1.log, test2.log, test3.log
>
>
> This is a follow up to CASSANDRA-18543
> Although that ticket added ability to set cassandra.gossip_settle_min_wait_ms
> this is tedious and error prone. On a node just observed a 79 second gap
> between waiting for gossip and the first echo response to indicate a node is
> UP.
> The problem being that do not want to start Native Transport until gossip
> settles otherwise queries can fail consistency such as LOCAL_QUORUM as it
> thinks the replicas are still in DOWN state.
> Instead of having to set gossip_settle_min_wait_ms I am proposing that
> (outside single node cluster) wait for UP message from another node before
> considering gossip as settled. Eg.
> {code:java}
> if (currentSize == epSize && currentLive == liveSize && liveSize
> > 1)
> {
> logger.debug("Gossip looks settled.");
> numOkay++;
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18845) Waiting for gossip to settle on live endpoints
[
https://issues.apache.org/jira/browse/CASSANDRA-18845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cameron Zemek updated CASSANDRA-18845:
--
Attachment: CASSANDRA-18845-4_0_12.patch
> Waiting for gossip to settle on live endpoints
> --
>
> Key: CASSANDRA-18845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18845
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Cameron Zemek
>Priority: Normal
> Attachments: 18845-seperate.patch, CASSANDRA-18845-4_0_12.patch,
> delay.log, example.log, image-2023-09-14-11-16-23-020.png, stream.log,
> test1.log, test2.log, test3.log
>
>
> This is a follow up to CASSANDRA-18543
> Although that ticket added ability to set cassandra.gossip_settle_min_wait_ms
> this is tedious and error prone. On a node just observed a 79 second gap
> between waiting for gossip and the first echo response to indicate a node is
> UP.
> The problem being that do not want to start Native Transport until gossip
> settles otherwise queries can fail consistency such as LOCAL_QUORUM as it
> thinks the replicas are still in DOWN state.
> Instead of having to set gossip_settle_min_wait_ms I am proposing that
> (outside single node cluster) wait for UP message from another node before
> considering gossip as settled. Eg.
> {code:java}
> if (currentSize == epSize && currentLive == liveSize && liveSize
> > 1)
> {
> logger.debug("Gossip looks settled.");
> numOkay++;
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-19557:
Description:
When we read rows from a large partition stored in an SSTable and
ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
multiple times, it happens per every read row.
The following stacktrace shows the execution path:
{code:java}
at
org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
at
org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
<=== here we retrieve the current index entry
at
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
<== here we iterate over rows
at
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
at
org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
at
org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
at
org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
at
org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
at
org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
at org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:829)
{code}
This Cassandra logic was originally written for the case when there is a small
number of index entries and all of them are fetched in memory, so it was cheap
to retrieve the IndexInfo again and again for this case. Later a support of
ShallowIndexedEntry case was added (CASSANDRA-11206) which shares the same
IndexState logic but in this case the cost to fetch IndexInfo is much higher -
we read it from disk every time.
I have "disk_access_mode: standard" enabled and for each IndexInfo retrieval
there are two read syscalls:
1) to find an offset for the correspondent IndexInfo
2) to read the IndexInfo itself
If we trace pread syscall we will see the following disk read syscall pattern:
{code:java}
2722116 14:20:00.769513
pread64(102, ""..., 65536, 338611) =
65536 <0.21>
2722116 14:20:00.769562
pread64(102, ""..., 65536, 164405) =
65536 <0.20>
2722116 14:20:00.769616
pread64(102, ""..., 65536, 338611) =
65536 <0.21>
2722116 14:20:00.769664
pread64(102, ""..., 65536,
[jira] [Updated] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-19557:
Attachment: 19557-4.1.patch
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Attachments: 19557-4.1.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when there is a
> small number of index entries and all of them are fetched in memory, so it
> was cheap to retrieve the IndexInfo again and again for this case. Later a
> support of ShallowIndexedEntry case was added (CASSANDRA-11206) which shares
> the same
[jira] [Updated] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-19557:
Bug Category: Parent values: Degradation(12984)Level 1 values: Performance
Bug/Regression(12997)
Discovered By: User Report
Since Version: 3.6
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Priority: Normal
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when there is a
> small number of index entries and all of them are fetched in memory, so it
> was cheap to retrieve the IndexInfo again and again for this case. Later a
> support
[jira] [Created] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
Dmitry Konstantinov created CASSANDRA-19557:
---
Summary: ShallowIndexedEntry scenario: the same IndexInfo is read
multiple times, per every read row
Key: CASSANDRA-19557
URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
Project: Cassandra
Issue Type: Bug
Components: Local/SSTable
Reporter: Dmitry Konstantinov
When we read rows from a large partition stored in an SSTable and
ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
multiple times, it happens per every read row.
The following stacktrace shows the execution path:
{code:java}
at
org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
at
org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
<=== here we retrieve the current index entry
at
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
<== here we iterate over rows
at
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
at
org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
at
org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
at
org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
at
org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
at
org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
at org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:829)
{code}
This Cassandra logic was originally written for the case when there is a small
number of index entries and all of them are fetched in memory, so it was cheap
to retrieve the IndexInfo again and again for this case. Later a support of
ShallowIndexedEntry case was added (CASSANDRA-11206) which shares the same
IndexState logic but in this case the cost to fetch IndexInfo is much higher -
we read it from disk every time.
I have "disk_access_mode: standard" enabled and for each IndexInfo retrieval
there are two read syscalls:
1) to find an offset for the correspondent IndexInfo
2) to read the IndexInfo itself
If we trace pread syscall we will see the following disk read syscall pattern:
{code:java}
2722116 14:20:00.769513
pread64(102, ""..., 65536, 338611) =
65536
[jira] [Updated] (CASSANDRA-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19532: -- Status: Ready to Commit (was: Review In Progress) > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836334#comment-17836334 ] Stefan Miklosovic commented on CASSANDRA-19532: --- I don't see that anything which failed is related to this change. +1. > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19532: -- Fix Version/s: 5.x > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836331#comment-17836331 ] Abe Ratnofsky commented on CASSANDRA-19532: --- Attached test results > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Attachment: ci_summary.html result_details.tar.gz > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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
(cassandra) 01/01: Merge branch 'cassandra-5.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 3e4f1e2839cff2ed2d51076e1cb016c381282c56 Merge: 728b9ec4c6 a620a9df86 Author: Brandon Williams AuthorDate: Thu Apr 11 13:51:41 2024 -0500 Merge branch 'cassandra-5.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-4.1 updated (39bd3c2261 -> b3bca0ad6a)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 39bd3c2261 Merge branch 'cassandra-4.0' into cassandra-4.1 add ccb83d0b6b Prepare debian changelog for 3.0.30 add 00c45611c9 Prepare debian changelog for 3.0.30 add 296b9cb889 Prepare debian changelog for 3.0.30 add 657e595b78 Prepare debian changelog for 3.0.30 new a766c18481 Merge branch 'cassandra-3.0' into cassandra-3.11 new 9a1d7912ef Merge branch 'cassandra-3.11' into cassandra-4.0 new b3bca0ad6a Merge branch 'cassandra-4.0' into cassandra-4.1 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9a1d7912efcebe7555142876f7052c0e2faa22b2 Merge: 0974a3656d a766c18481 Author: Brandon Williams AuthorDate: Thu Apr 11 13:51:08 2024 -0500 Merge branch 'cassandra-3.11' into cassandra-4.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-3.0 updated (46bf9bcace -> 657e595b78)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 46bf9bcace Add properties for redirecting build-resolve to mirrors add ccb83d0b6b Prepare debian changelog for 3.0.30 add 00c45611c9 Prepare debian changelog for 3.0.30 add 296b9cb889 Prepare debian changelog for 3.0.30 add 657e595b78 Prepare debian changelog for 3.0.30 No new revisions were added by this update. Summary of changes: debian/changelog | 6 ++ 1 file changed, 6 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-3.11 updated (338e4ed618 -> a766c18481)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 338e4ed618 Docs: deprecate the usage of apt-key and adopt distribution name add ccb83d0b6b Prepare debian changelog for 3.0.30 add 00c45611c9 Prepare debian changelog for 3.0.30 add 296b9cb889 Prepare debian changelog for 3.0.30 add 657e595b78 Prepare debian changelog for 3.0.30 new a766c18481 Merge branch 'cassandra-3.0' into cassandra-3.11 The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated (728b9ec4c6 -> 3e4f1e2839)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 728b9ec4c6 Revisit metadata log schema to remove period field add ccb83d0b6b Prepare debian changelog for 3.0.30 add 00c45611c9 Prepare debian changelog for 3.0.30 add 296b9cb889 Prepare debian changelog for 3.0.30 add 657e595b78 Prepare debian changelog for 3.0.30 new a766c18481 Merge branch 'cassandra-3.0' into cassandra-3.11 new 9a1d7912ef Merge branch 'cassandra-3.11' into cassandra-4.0 new b3bca0ad6a Merge branch 'cassandra-4.0' into cassandra-4.1 new a620a9df86 Merge branch 'cassandra-4.1' into cassandra-5.0 new 3e4f1e2839 Merge branch 'cassandra-5.0' into trunk The 5 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit a766c18481827a0ed7e2612fd3a5dfcbbb8ac199 Merge: 338e4ed618 657e595b78 Author: Brandon Williams AuthorDate: Thu Apr 11 13:50:48 2024 -0500 Merge branch 'cassandra-3.0' into cassandra-3.11 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b3bca0ad6a0d9eff6353c17df7766c2dfd750ab7 Merge: 39bd3c2261 9a1d7912ef Author: Brandon Williams AuthorDate: Thu Apr 11 13:51:17 2024 -0500 Merge branch 'cassandra-4.0' into cassandra-4.1 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-5.0 updated (cada1a13c8 -> a620a9df86)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from cada1a13c8 Vector search should be able to restrict on clustering keys when filtering isn't required add ccb83d0b6b Prepare debian changelog for 3.0.30 add 00c45611c9 Prepare debian changelog for 3.0.30 add 296b9cb889 Prepare debian changelog for 3.0.30 add 657e595b78 Prepare debian changelog for 3.0.30 new a766c18481 Merge branch 'cassandra-3.0' into cassandra-3.11 new 9a1d7912ef Merge branch 'cassandra-3.11' into cassandra-4.0 new b3bca0ad6a Merge branch 'cassandra-4.0' into cassandra-4.1 new a620a9df86 Merge branch 'cassandra-4.1' into cassandra-5.0 The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-4.0 updated (0974a3656d -> 9a1d7912ef)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 0974a3656d Optionally avoid hint transfer during decommission add ccb83d0b6b Prepare debian changelog for 3.0.30 add 00c45611c9 Prepare debian changelog for 3.0.30 add 296b9cb889 Prepare debian changelog for 3.0.30 add 657e595b78 Prepare debian changelog for 3.0.30 new a766c18481 Merge branch 'cassandra-3.0' into cassandra-3.11 new 9a1d7912ef Merge branch 'cassandra-3.11' into cassandra-4.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-4.1' into cassandra-5.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit a620a9df86e06d56c260533d40a86212a73c0215 Merge: cada1a13c8 b3bca0ad6a Author: Brandon Williams AuthorDate: Thu Apr 11 13:51:29 2024 -0500 Merge branch 'cassandra-4.1' into cassandra-5.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19552) Nodetool to get/set guardrails configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-19552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836313#comment-17836313 ] Stefan Miklosovic commented on CASSANDRA-19552: --- We do. https://issues.apache.org/jira/browse/CASSANDRA-16806 Since 4.1-alpha1 That being said, I do not think that it will make it to 4.1 branch as that is just a bug fix one. As a new feature, our best shot is to do that for trunk only. > Nodetool to get/set guardrails configurations > - > > Key: CASSANDRA-19552 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19552 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 4.1.x > > > Currently guardrails are only configurable through JMX / cassandra.yaml > This provides a nodetool command to interact with all the getters/setters for > guardrails. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3243] > trunk PR: [https://github.com/apache/cassandra/pull/3244] -- 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-19552) Nodetool to get/set guardrails configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-19552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836307#comment-17836307 ] Yuqi Yan commented on CASSANDRA-19552: -- [~smiklosovic] thanks, I'm quite new to the community and wasn't aware of this trend. Yes I agree we should have vtable approach for 5.x. Looking at your patch it seems that we don't have mutable vtable in 4.1 yet. > Nodetool to get/set guardrails configurations > - > > Key: CASSANDRA-19552 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19552 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 4.1.x > > > Currently guardrails are only configurable through JMX / cassandra.yaml > This provides a nodetool command to interact with all the getters/setters for > guardrails. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3243] > trunk PR: [https://github.com/apache/cassandra/pull/3244] -- 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
svn commit: r68442 - in /dev/cassandra/3.0.30/redhat: ./ repodata/
Author: brandonwilliams Date: Thu Apr 11 18:26:31 2024 New Revision: 68442 Log: staging cassandra rpm packages for 3.0.30 Added: dev/cassandra/3.0.30/redhat/ dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.noarch.rpm (with props) dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.src.rpm (with props) dev/cassandra/3.0.30/redhat/cassandra-tools-3.0.30-1.noarch.rpm (with props) dev/cassandra/3.0.30/redhat/repodata/ dev/cassandra/3.0.30/redhat/repodata/453def65fa3902d1868d37aad56a260ff0f6d8889ef6e9054a1a1acc5dd1c0d5-filelists.sqlite.bz2 (with props) dev/cassandra/3.0.30/redhat/repodata/453def65fa3902d1868d37aad56a260ff0f6d8889ef6e9054a1a1acc5dd1c0d5-filelists.sqlite.bz2.asc dev/cassandra/3.0.30/redhat/repodata/4b07211e2c5baf06f47672925e3031f080dfe7f7a957d594bd40cba4963eaf20-other.sqlite.bz2 (with props) dev/cassandra/3.0.30/redhat/repodata/4b07211e2c5baf06f47672925e3031f080dfe7f7a957d594bd40cba4963eaf20-other.sqlite.bz2.asc dev/cassandra/3.0.30/redhat/repodata/bdfca184393c00c01506a1f60d70cfd401872d810c66105a5e8c62a960103eb0-other.xml.gz (with props) dev/cassandra/3.0.30/redhat/repodata/bdfca184393c00c01506a1f60d70cfd401872d810c66105a5e8c62a960103eb0-other.xml.gz.asc dev/cassandra/3.0.30/redhat/repodata/d65aff426b2253e38150471f5c4be1e74f449663fd833fda8e590c25ddee2c0f-primary.sqlite.bz2 (with props) dev/cassandra/3.0.30/redhat/repodata/d65aff426b2253e38150471f5c4be1e74f449663fd833fda8e590c25ddee2c0f-primary.sqlite.bz2.asc dev/cassandra/3.0.30/redhat/repodata/f40c229281c4599f78f2eb3279c96a2e80b34e022b482ee6d3ff8421edff0f10-filelists.xml.gz (with props) dev/cassandra/3.0.30/redhat/repodata/f40c229281c4599f78f2eb3279c96a2e80b34e022b482ee6d3ff8421edff0f10-filelists.xml.gz.asc dev/cassandra/3.0.30/redhat/repodata/f597ad5974f34fc327177658a2791b2a1b4b1da08885341c8ab615cffa7c6968-primary.xml.gz (with props) dev/cassandra/3.0.30/redhat/repodata/f597ad5974f34fc327177658a2791b2a1b4b1da08885341c8ab615cffa7c6968-primary.xml.gz.asc dev/cassandra/3.0.30/redhat/repodata/repomd.xml dev/cassandra/3.0.30/redhat/repodata/repomd.xml.asc Added: dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.src.rpm == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.src.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/redhat/cassandra-tools-3.0.30-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/redhat/cassandra-tools-3.0.30-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/redhat/repodata/453def65fa3902d1868d37aad56a260ff0f6d8889ef6e9054a1a1acc5dd1c0d5-filelists.sqlite.bz2 == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/redhat/repodata/453def65fa3902d1868d37aad56a260ff0f6d8889ef6e9054a1a1acc5dd1c0d5-filelists.sqlite.bz2 -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/redhat/repodata/453def65fa3902d1868d37aad56a260ff0f6d8889ef6e9054a1a1acc5dd1c0d5-filelists.sqlite.bz2.asc == --- dev/cassandra/3.0.30/redhat/repodata/453def65fa3902d1868d37aad56a260ff0f6d8889ef6e9054a1a1acc5dd1c0d5-filelists.sqlite.bz2.asc (added) +++ dev/cassandra/3.0.30/redhat/repodata/453def65fa3902d1868d37aad56a260ff0f6d8889ef6e9054a1a1acc5dd1c0d5-filelists.sqlite.bz2.asc Thu Apr 11 18:26:31 2024 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEt4Qs2vNuajIU+uNdXoW5rguEwEEFAmYYKzMACgkQXoW5rguE +wEFmvBAAroOY1S3TF8GkIGXVAgKp5Dds7To4XYu2jjBa4glOuVP/EYSvduvxdQAp +60TaXbSVGQp+QsNpEd7inGrJsjJ9I92aKD7I6egAHYvEJalBoxVDCWmoWoqzLeST +A4l31DN92TbkWZrflCZ2Vnm1T/qmEn0yZeqngeaMW6Y1NBGrzZS42i6GQHXgX39u +5XiU+XSPnZcjvdLnb29CGjzeXjtKy+6uPsf5HM8w6FA4yjCwlV0b7e5I/Gm8xqUV +AvIPdrZ+Z0IUftg/JEGq6sEnEfjnnUAgEx2VLcNgRr+DQ92py0BAzSDNnaLlH6XF +QOYKlQbZafFoTHcOE+IJ0iBFV87Ax7O3O+Lft84jOLWygN8bA5WqRSYgsWHR6Gfq +FmL6GY/PgrE/pE3kMOh38FX5Nr9cqx+cLNDs/KRf5fmTTKa5hWm69ZX+rQyoGuQb +aHd1wDAu3ekm4qr7rfCwgV5K5xlUreywrXGJJYW5Bccc74QyFbbKrC7p128u3Zc6
svn commit: r68441 - in /dev/cassandra/3.0.30/debian: ./ dists/ dists/30x/ dists/30x/main/ dists/30x/main/binary-amd64/ dists/30x/main/binary-arm64/ dists/30x/main/binary-i386/ dists/30x/main/source/
Author: brandonwilliams Date: Thu Apr 11 18:24:59 2024 New Revision: 68441 Log: staging cassandra debian packages for 3.0.30 Added: dev/cassandra/3.0.30/debian/ dev/cassandra/3.0.30/debian/cassandra-tools_3.0.30_all.deb (with props) dev/cassandra/3.0.30/debian/cassandra_3.0.30.dsc dev/cassandra/3.0.30/debian/cassandra_3.0.30.tar.gz (with props) dev/cassandra/3.0.30/debian/cassandra_3.0.30_all.deb (with props) dev/cassandra/3.0.30/debian/cassandra_3.0.30_amd64.buildinfo dev/cassandra/3.0.30/debian/cassandra_3.0.30_amd64.changes dev/cassandra/3.0.30/debian/dists/ dev/cassandra/3.0.30/debian/dists/30x/ dev/cassandra/3.0.30/debian/dists/30x/InRelease dev/cassandra/3.0.30/debian/dists/30x/Release dev/cassandra/3.0.30/debian/dists/30x/Release.gpg dev/cassandra/3.0.30/debian/dists/30x/main/ dev/cassandra/3.0.30/debian/dists/30x/main/binary-amd64/ dev/cassandra/3.0.30/debian/dists/30x/main/binary-amd64/Packages dev/cassandra/3.0.30/debian/dists/30x/main/binary-amd64/Packages.gz (with props) dev/cassandra/3.0.30/debian/dists/30x/main/binary-amd64/Release dev/cassandra/3.0.30/debian/dists/30x/main/binary-arm64/ dev/cassandra/3.0.30/debian/dists/30x/main/binary-arm64/Packages dev/cassandra/3.0.30/debian/dists/30x/main/binary-arm64/Packages.gz (with props) dev/cassandra/3.0.30/debian/dists/30x/main/binary-arm64/Release dev/cassandra/3.0.30/debian/dists/30x/main/binary-i386/ dev/cassandra/3.0.30/debian/dists/30x/main/binary-i386/Packages dev/cassandra/3.0.30/debian/dists/30x/main/binary-i386/Packages.gz (with props) dev/cassandra/3.0.30/debian/dists/30x/main/binary-i386/Release dev/cassandra/3.0.30/debian/dists/30x/main/source/ dev/cassandra/3.0.30/debian/dists/30x/main/source/Release dev/cassandra/3.0.30/debian/dists/30x/main/source/Sources.gz (with props) dev/cassandra/3.0.30/debian/pool/ dev/cassandra/3.0.30/debian/pool/main/ dev/cassandra/3.0.30/debian/pool/main/c/ dev/cassandra/3.0.30/debian/pool/main/c/cassandra/ dev/cassandra/3.0.30/debian/pool/main/c/cassandra/cassandra-tools_3.0.30_all.deb (with props) dev/cassandra/3.0.30/debian/pool/main/c/cassandra/cassandra_3.0.30.dsc dev/cassandra/3.0.30/debian/pool/main/c/cassandra/cassandra_3.0.30.tar.gz (with props) dev/cassandra/3.0.30/debian/pool/main/c/cassandra/cassandra_3.0.30_all.deb (with props) Added: dev/cassandra/3.0.30/debian/cassandra-tools_3.0.30_all.deb == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/debian/cassandra-tools_3.0.30_all.deb -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/debian/cassandra_3.0.30.dsc == --- dev/cassandra/3.0.30/debian/cassandra_3.0.30.dsc (added) +++ dev/cassandra/3.0.30/debian/cassandra_3.0.30.dsc Thu Apr 11 18:24:59 2024 @@ -0,0 +1,41 @@ +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA512 + +Format: 1.0 +Source: cassandra +Binary: cassandra, cassandra-tools +Architecture: all +Version: 3.0.30 +Maintainer: Eric Evans +Uploaders: Sylvain Lebresne +Homepage: http://cassandra.apache.org +Standards-Version: 3.8.3 +Vcs-Browser: https://git-wip-us.apache.org/repos/asf?p=cassandra.git +Vcs-Git: http://git-wip-us.apache.org/repos/asf/cassandra.git +Build-Depends: debhelper (>= 5), openjdk-8-jdk | java8-jdk, ant (>= 1.9), ant-optional (>= 1.9), dh-python, python-dev (>= 2.7) | python2-dev (>= 2.7), dpatch, bash-completion +Package-List: + cassandra deb misc extra arch=all + cassandra-tools deb misc extra arch=all +Checksums-Sha1: + 3f12f4c1bb73809b765b83f2eedf78d002a8de3c 9045829 cassandra_3.0.30.tar.gz +Checksums-Sha256: + cf61416de969624755200fefff6979f65cb9e4bc2fe75ed9c562a493ccb54790 9045829 cassandra_3.0.30.tar.gz +Files: + 5a882165f3d7e2224f37f86d81b1f501 9045829 cassandra_3.0.30.tar.gz + +-BEGIN PGP SIGNATURE- + +iQIzBAEBCgAdFiEEt4Qs2vNuajIU+uNdXoW5rguEwEEFAmYYKqUACgkQXoW5rguE +wEFKmhAAl6O7DJefAMLm11bApGUf+LTOxeB+DVhECeFGYbXnPN+sQPxRXLtZFWr2 +eU4Tc/qszwkAVoFj/sW4hXynNx4QcRT3j67USP2U6TBkJKgZs2C/wxvJ+pgJ3jt6 +EP52kS0YJ30zWyRAdCUicg8vwMlNbSqCtGwVa5JRer6SP5L5yBtmxHazayLtSCxr +hcQrpUKHPyp+IPot5wW1prQDJb303u8WO8albNxe+gjko/TzGLHB4hQnROzSn9LB +S/eflGO4Dc8ipvsmdA0fJ8/aMLuRLPTYsNJIWn+UHpAXnUwO2ky6BL7pr7QUCq9Q +zMSukDUgItljNZaGDc8fbj+CrBsfotfN8QDWOfAcvhc4kU+mgkO88qUcduYpVhuS +UB2byF1RBRS6CsfHiWjvlq5X/liHLlwxhia19ciIJfMO/I+CaVloH3hWMqngAQZr +DZ12HPE4qkHkY3mBQWWDs8fTFrtk28TL0F4IWdQrehoD4YwTnpm8OMPeYqGchT+p +ij/1lIvW7VdyhSbx6yZyOYpAgU4+N+WhdS0376iIS1rS06Tx+nl1Zl1wMW5uUC/U +4hbEbj5z2aIm7mTsaZs6RqaKR+gQNIrxHDjWUPaJhZYm9XLFrOZB3/M96ionvmQf +2Skobiip9XtCdC5ohVZ46/CUm2tf5qE7DCVNIhItgMKkKlbckKs= +=y4K5 +-END PGP SIGNATURE- Added: dev/cassandra/3.0.30/debian/cassandra_3.0.30.tar.gz
svn commit: r68440 - /dev/cassandra/3.0.30/
Author: brandonwilliams Date: Thu Apr 11 18:22:45 2024 New Revision: 68440 Log: staging cassandra 3.0.30 Added: dev/cassandra/3.0.30/ dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz (with props) dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.asc dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha256 dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha512 dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz (with props) dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.asc dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha256 dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha512 Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.asc == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.asc (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.asc Thu Apr 11 18:22:45 2024 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEt4Qs2vNuajIU+uNdXoW5rguEwEEFAmYYKhwACgkQXoW5rguE +wEFT4g//UKi9VdjO+DrgmQOpfe3FOdqIasjrc/BkH4iuvrrTlyEl9YO8ZFNCwXhe +zGMC+YQEL8ciQcIHDIQHe36b/Zml1IUgffRJGMcpL2nr1YUdCzJzKm6SxLFkANl/ +dfEcf+mM7kF4FnnEiPs+8fZEbXodVmQm+qOkUp/XRNyl8CfPSLFbBNnPyHSO7npH +Ay7TCLtwuLuN7RXeq3/u7g19iCXr9dtSRoqwJO5eRhZQ9tkfjY4YH9yN8MQXAYlP +JLVMgjHDew7p44IW/j9dd+AZFD2rn+LsB1NtKi1tCzctJF4dJN3fRzfmK3+C9rmh +TsMZxSC6HgiBh45tXJ2Wp1b0A0CxKg07jwX+HS+fRDrTj3IlEM9Y+Tis7SUIzVgJ +2E/9VANAFGcqLqbozZLRn/xiOa8nMD1G6RiEyca0AXU5JEtQ4dC7QNHyilPWxVCP +ZWzH8HauuhEsYxrbar1kQYqWwp0FM+44eo3REf0BwCH1vw3UhaNIPvDl8Xwd3WoR +q41GQgnkuNKTmMPRKFozdXOl3O16QXQXxBcxYtfn2TdJlrH3CEG6W91Gk0YoU8qS +TPygrViVmcbbaJXXCDalE4i/hPIpHUE5KtPRpuVfagaGYUO6WHJmSNNF0OzmO/ck +uuALBlVPihnh64qm6Ktz3lE/90gAQ3K8PHXtEPXIs7b23CNpuck= +=GGIa +-END PGP SIGNATURE- Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha256 == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha256 (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha256 Thu Apr 11 18:22:45 2024 @@ -0,0 +1 @@ +ce633b60cb3c42b0b9524a5551c86961553b1f561718fe8f5057b9dff5a750e2 Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha512 == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha512 (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha512 Thu Apr 11 18:22:45 2024 @@ -0,0 +1 @@ +d239ae8c51ec9f3c789ed858e2daa8c3a6ee84ba8697c7e7e4037ac3c747451b91b894229aa68d6c829917afe68da408d403d5ac6c29c2d866f01e050b81f43f Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.asc == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.asc (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.asc Thu Apr 11 18:22:45 2024 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEt4Qs2vNuajIU+uNdXoW5rguEwEEFAmYYKh4ACgkQXoW5rguE +wEH2nQ/+P9h6GmTWZWQVtGpnw1oqWW9NjJpUCqdplVwHrO8HuMwKX5MStqJxg6Lt +ThHFTRvRw611kCxTctMWBN9fRznLsU5/tdpLOnvhBHXJHi9WOeU4DfyV+YcaE66f +3XXY0Cj/gGupnosSlkalQVSLBUppoYJPFF9AR22zUU55e2m1maYxleG0lKcVIQlz +e+qHMlaYWgiKyNY/exK0wO6/qoth07Q9BwbNChmgZ9NLP/J1D4HeKdNxOX0q/vof +wKgWqb/N9QUlg1+USbvXuOjZbwjqVqbBuNWjuq5jJCtMgR78c08ZjOf+0jX1VW0p +dhqJLbEmdaczktovULbEmlbbmYdqOk0no80jMUhy2Sk87qOpnDcVzCuQbPKW621V +rEtnf/USO/mO+t1I+eyNXqdQ7CevG8/0HqExcdazCd8X3VrUshRlCixpZ8T404xY +yuYWScCttEX3/9dlOt+fEQy7akm1uKapV+V2sSJhtf+ies/cLrZyR2IvQrJMrZkt +WiUgJPx6r8ErIX2dAMMqiIwbXKc1x7dQ6YFhEQ5sakJJ3pSXlTpK2fTpgAsEsp8u +z7jIkJngiTG3Dm0DoUABm0tDegaxXOJr0ZtAZAB2rF18YXc+GhRcqxhLFRNsNEpw +QDn5x7maEuEZGI08WYwJdP6UehLtffKYajFXn2WR7sQ59fviwlc= +=fsKx +-END PGP SIGNATURE- Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha256 == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha256 (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha256 Thu Apr 11 18:22:45 2024 @@ -0,0 +1 @@
(cassandra) 03/04: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 296b9cb88960b6e90390d873f1afb7b8c1c9c795 Author: Brandon Williams AuthorDate: Thu Apr 11 11:24:51 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index ca25260488..e1fc3e5c3b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (3.0.30) unstable; urgency=medium * New release - -- Brandon Williams Thu, 11 Apr 2024 11:23:02 -0500 + -- Brandon Williams Thu, 11 Apr 2024 11:24:46 -0500 cassandra (3.0.29) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 02/04: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 00c45611c9e81a8f69cf795bd72905326a697dab Author: Brandon Williams AuthorDate: Thu Apr 11 11:23:07 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 1ac140df4c..ca25260488 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (3.0.30) unstable; urgency=medium * New release - -- Brandon Williams Thu, 11 Apr 2024 11:12:18 -0500 + -- Brandon Williams Thu, 11 Apr 2024 11:23:02 -0500 cassandra (3.0.29) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/04: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ccb83d0b6b726393f745aff24e29d93f5faee922 Author: Brandon Williams AuthorDate: Thu Apr 11 11:13:02 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/changelog b/debian/changelog index fe2bb9b324..1ac140df4c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.0.30) unstable; urgency=medium + + * New release + + -- Brandon Williams Thu, 11 Apr 2024 11:12:18 -0500 + cassandra (3.0.29) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative created (now 657e595b78)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git at 657e595b78 (commit) This tag includes the following new commits: new ccb83d0b6b Prepare debian changelog for 3.0.30 new 00c45611c9 Prepare debian changelog for 3.0.30 new 296b9cb889 Prepare debian changelog for 3.0.30 new 657e595b78 Prepare debian changelog for 3.0.30 The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 04/04: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 657e595b78227c28a6b8808ef9bf62f646029f3b Author: Brandon Williams AuthorDate: Thu Apr 11 11:30:02 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index e1fc3e5c3b..ca25260488 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (3.0.30) unstable; urgency=medium * New release - -- Brandon Williams Thu, 11 Apr 2024 11:24:46 -0500 + -- Brandon Williams Thu, 11 Apr 2024 11:23:02 -0500 cassandra (3.0.29) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative deleted (was 657e595b78)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git *** WARNING: tag 3.0.30-tentative was deleted! *** was 657e595b78 Prepare debian changelog for 3.0.30 This change permanently discards the following revisions: discard 657e595b78 Prepare debian changelog for 3.0.30 discard 296b9cb889 Prepare debian changelog for 3.0.30 discard 00c45611c9 Prepare debian changelog for 3.0.30 discard ccb83d0b6b Prepare debian changelog for 3.0.30 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r68439 - /dev/cassandra/3.0.30/
Author: brandonwilliams Date: Thu Apr 11 18:14:51 2024 New Revision: 68439 Log: Remove 3.0.30 because prepare_release sucks Removed: dev/cassandra/3.0.30/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuqi Yan updated CASSANDRA-19556: - Description: Sometimes we want to block DDL/DCL queries to stop new schemas being created or roles created. (e.g. when doing live-upgrade) For DDL guardrail current implementation won't block the query if it's no-op (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The guardrail check is added in apply() right after all the existence check) I don't have preference on either block every DDL query or check whether if it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. at startup, which is no-op but will be blocked by this guardrail and failed to start. 4.1 PR: [https://github.com/apache/cassandra/pull/3248] was: Sometimes we want to block DDL/DCL queries to stop new schemas being created. (e.g. when doing live-upgrade) For DDL guardrail current implementation won't block the query if it's no-op (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The guardrail check is added in apply() right after all the existence check) I don't have preference on either block every DDL query or check whether if it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. at startup, which is no-op but will be blocked by this guardrail and failed to start. 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > -- 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-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuqi Yan updated CASSANDRA-19556: - Description: Sometimes we want to block DDL/DCL queries to stop new schemas being created. (e.g. when doing live-upgrade) For DDL guardrail current implementation won't block the query if it's no-op (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The guardrail check is added in apply() right after all the existence check) I don't have preference on either block every DDL query or check whether if it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. at startup, which is no-op but will be blocked by this guardrail and failed to start. 4.1 PR: [https://github.com/apache/cassandra/pull/3248] was: Sometimes we want to block DDL/DCL queries to stop new schemas being created. (e.g. when doing live-upgrade) For DDL guardrail current implementation won't block the query if it's no-op (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The guardrail check is added in apply() right after all the existence check) I don't have preference on either block every DDL query or check whether if it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. at startup, which is no-op but will be blocked by this guardrail and failed to start. > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > > Sometimes we want to block DDL/DCL queries to stop new schemas being created. > (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > -- 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-19344) Range movements involving transient replicas must safely enact changes to read and write replica sets
[
https://issues.apache.org/jira/browse/CASSANDRA-19344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19344:
Attachment: remove-n4-pre-19344.txt
remove-n4-post-19344.txt
> Range movements involving transient replicas must safely enact changes to
> read and write replica sets
> -
>
> Key: CASSANDRA-19344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19344
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html, remove-n4-post-19344.txt,
> remove-n4-pre-19344.txt, result_details.tar.gz
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> (edit) This was originally opened due to a flaky test
> {{org.apache.cassandra.distributed.test.TransientRangeMovementTest.testRemoveNode-_jdk17}}
> The test can fail in two different ways:
> {code:java}
> junit.framework.AssertionFailedError: NOT IN CURRENT: 31 -- [(00,20),
> (31,50)] at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.assertAllContained(TransientRangeMovementTest.java:203)
> at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.testRemoveNode(TransientRangeMovementTest.java:183)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
> as in here -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2639/workflows/32b92ce7-5e9d-4efb-8362-d200d2414597/jobs/55139/tests#failed-test-0]
> and
> {code:java}
> junit.framework.AssertionFailedError: nodetool command [removenode,
> 6d194555-f6eb-41d0-c000-0003, --force] was not successful stdout:
> stderr: error: Node /127.0.0.4:7012 is alive and owns this ID. Use
> decommission command to remove it from the ring -- StackTrace --
> java.lang.UnsupportedOperationException: Node /127.0.0.4:7012 is alive and
> owns this ID. Use decommission command to remove it from the ring at
> org.apache.cassandra.tcm.sequences.SingleNodeSequences.removeNode(SingleNodeSequences.java:110)
> at
> org.apache.cassandra.service.StorageService.removeNode(StorageService.java:3682)
> at org.apache.cassandra.tools.NodeProbe.removeNode(NodeProbe.java:1020) at
> org.apache.cassandra.tools.nodetool.RemoveNode.execute(RemoveNode.java:51) at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:388)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:373) at
> org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:272) at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:1129)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$51(Instance.java:1038)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833) Notifications: Error:
> java.lang.UnsupportedOperationException: Node /127.0.0.4:7012 is alive and
> owns this ID. Use decommission command to remove it from the ring at
> org.apache.cassandra.tcm.sequences.SingleNodeSequences.removeNode(SingleNodeSequences.java:110)
> at
> org.apache.cassandra.service.StorageService.removeNode(StorageService.java:3682)
> at org.apache.cassandra.tools.NodeProbe.removeNode(NodeProbe.java:1020) at
> org.apache.cassandra.tools.nodetool.RemoveNode.execute(RemoveNode.java:51) at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:388)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:373) at
> org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:272) at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:1129)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$51(Instance.java:1038)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
>
[jira] [Commented] (CASSANDRA-19344) Range movements involving transient replicas must safely enact changes to read and write replica sets
[
https://issues.apache.org/jira/browse/CASSANDRA-19344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836302#comment-17836302
]
Sam Tunnicliffe commented on CASSANDRA-19344:
-
The actual cause was that the way we construct placement deltas for a
PlacementTransitionPlan did not properly consider transientness. Multi-step
operations always follow the pattern:
* add new write replicas
* add new read replicas/remove old read replicas
* remove old write replicas
So when an operation causes a replica to transition from TRANSIENT to FULL for
the same range (or part of a range), it could become a FULL read replica before
becoming a FULL write replica.
Consider this simplified example where we remove N4 and the effect on N2:
{code}
RF=3/1
At START
10203040
+-+-+-+-+-+
N1N2N3N4
N2 replicates:
(10,20] - FULL (Primary Range)
(,10] + (40,] - FULL
(30,40] - TRANSIENT
After FINISH
102030
+-+-+-+---+
N1N2N3
N2 replicates:
(10,20] - FULL (Primary Range)
(,10] + (30,] - FULL
(20,30] - TRANSIENT
In removing N4, N2 gains (20,30] TRANSIENT and (30,40] TRANSIENT -> FULL
Potential problem ->
for READS N2 becomes FULL(30,40] after MID_LEAVE
for WRITES N2 only becomes FULL(30,40] after FINISH_LEAVE
so between the 2 events, coordinators will not send writes to N2 unless one
of the other replicas is unresponsive.
Coordinators will send reads to N2 during this window though.
If cleanup is run before N2 becomes a FULL replica for (30,40], any data
for that range (including that which was
just streamed to it) will be purged.
{code}
Below is an illustration of the ranges replicated by N2 at each step:
{code}
+-+--+
|EPOCH| STATE | RANGES REPLICATED BY N2
|
|-++-|
|0| START STATE| WRITES -> FULL: [(40,], (,10], (10,20]]
TRANSIENT: [(30,40]]|
| || READS -> FULL: [(40,], (,10], (10,20]]
TRANSIENT: [(30,40]]|
|-++-|
|1| ENACT START_LEAVE(N4) | WRITES -> FULL: [(40,], (,10], (10,20]]
TRANSIENT: [(20,30], (30,40]] |
| || READS -> FULL: [(40,], (,10], (10,20]]
TRANSIENT: [(30,40]]|
|-++-|
|2| ENACT MID_LEAVE(N4)| WRITES -> FULL: [(40,], (,10], (10,20]]
TRANSIENT: [(20,30], (30,40]] |
| || READS -> FULL: [(40,], (,10], (10,20],
(30,40]] TRANSIENT: [(20,30]] |
|-++-|
|3| ENACT FINISH_LEAVE(N4) | WRITES -> FULL: [(30,], (,10], (10,20]]
TRANSIENT: [(20,30]]|
| || READS -> FULL: [(30,], (,10], (10,20]]
TRANSIENT: [(20,30]]|
+-++-+
{code}
After applying the fix here, these are changed so that the {{(30,40]}} changing
from {{TRANSIENT}} to {{FULL}} for
writes is part of enacting the {{START_LEAVE(N4)}} in epoch 1, i.e. before N2
becomes a FULL replica for reads of
{{(30,40]}} when {{MID_LEAVE(N4)}} is enacted in epoch 2.
{code}
+-+--+
|EPOCH| STATE | RANGES REPLICATED BY N2
|
|-++-|
|0| START STATE| WRITES -> FULL: [(40,], (,10], (10,20]]
TRANSIENT: [(30,40]] |
| || READS -> FULL: [(40,], (,10], (10,20]]
TRANSIENT: [(30,40]] |
|-++-|
|1| ENACT START_LEAVE(N4) | WRITES -> FULL: [(40,], (,10], (10,20],
(30,40]] TRANSIENT: [(20,30]] |
| || READS -> FULL: [(40,], (,10], (10,20]]
TRANSIENT: [(30,40]] |
svn commit: r68438 - in /dev/cassandra/3.0.30/redhat: ./ repodata/
Author: brandonwilliams Date: Thu Apr 11 17:13:25 2024 New Revision: 68438 Log: staging cassandra rpm packages for 3.0.30 Added: dev/cassandra/3.0.30/redhat/ dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.noarch.rpm (with props) dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.src.rpm (with props) dev/cassandra/3.0.30/redhat/cassandra-tools-3.0.30-1.noarch.rpm (with props) dev/cassandra/3.0.30/redhat/repodata/ dev/cassandra/3.0.30/redhat/repodata/8bf6bbb51b796828eb9a32e3dc065d2d8a9f53a06f09ba05d52b079e54030965-primary.sqlite.bz2 (with props) dev/cassandra/3.0.30/redhat/repodata/8bf6bbb51b796828eb9a32e3dc065d2d8a9f53a06f09ba05d52b079e54030965-primary.sqlite.bz2.asc dev/cassandra/3.0.30/redhat/repodata/8ff6dae551b55ee9badc3e1377caeaa1a26af4421638f62616a91e540a62902a-filelists.sqlite.bz2 (with props) dev/cassandra/3.0.30/redhat/repodata/8ff6dae551b55ee9badc3e1377caeaa1a26af4421638f62616a91e540a62902a-filelists.sqlite.bz2.asc dev/cassandra/3.0.30/redhat/repodata/aec3e3990b2c6eccb6ba90a184b14f700e5971b3afca9440e841159e125f1c95-filelists.xml.gz (with props) dev/cassandra/3.0.30/redhat/repodata/aec3e3990b2c6eccb6ba90a184b14f700e5971b3afca9440e841159e125f1c95-filelists.xml.gz.asc dev/cassandra/3.0.30/redhat/repodata/c2e800f4826aced150b52a8040bf0c20a8e2e3d5c32a08ac0c76b1d03245f21e-primary.xml.gz (with props) dev/cassandra/3.0.30/redhat/repodata/c2e800f4826aced150b52a8040bf0c20a8e2e3d5c32a08ac0c76b1d03245f21e-primary.xml.gz.asc dev/cassandra/3.0.30/redhat/repodata/d343ebc4904dd1925df72ba25e20c667110e2aa09c6b8c38640255db1634c3f9-other.xml.gz (with props) dev/cassandra/3.0.30/redhat/repodata/d343ebc4904dd1925df72ba25e20c667110e2aa09c6b8c38640255db1634c3f9-other.xml.gz.asc dev/cassandra/3.0.30/redhat/repodata/fa87ac4ffd9506ec4e0c7a242e940bd4dd405e69da58c66e15263559d9f235ca-other.sqlite.bz2 (with props) dev/cassandra/3.0.30/redhat/repodata/fa87ac4ffd9506ec4e0c7a242e940bd4dd405e69da58c66e15263559d9f235ca-other.sqlite.bz2.asc dev/cassandra/3.0.30/redhat/repodata/repomd.xml dev/cassandra/3.0.30/redhat/repodata/repomd.xml.asc Added: dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.src.rpm == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/redhat/cassandra-3.0.30-1.src.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/redhat/cassandra-tools-3.0.30-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/redhat/cassandra-tools-3.0.30-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/redhat/repodata/8bf6bbb51b796828eb9a32e3dc065d2d8a9f53a06f09ba05d52b079e54030965-primary.sqlite.bz2 == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/redhat/repodata/8bf6bbb51b796828eb9a32e3dc065d2d8a9f53a06f09ba05d52b079e54030965-primary.sqlite.bz2 -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/redhat/repodata/8bf6bbb51b796828eb9a32e3dc065d2d8a9f53a06f09ba05d52b079e54030965-primary.sqlite.bz2.asc == --- dev/cassandra/3.0.30/redhat/repodata/8bf6bbb51b796828eb9a32e3dc065d2d8a9f53a06f09ba05d52b079e54030965-primary.sqlite.bz2.asc (added) +++ dev/cassandra/3.0.30/redhat/repodata/8bf6bbb51b796828eb9a32e3dc065d2d8a9f53a06f09ba05d52b079e54030965-primary.sqlite.bz2.asc Thu Apr 11 17:13:25 2024 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEt4Qs2vNuajIU+uNdXoW5rguEwEEFAmYYGhUACgkQXoW5rguE +wEGTCQ/9HYWlTdi6tJkqtH+Ri2lDJvWOtPB/wJqCZN7vhuibrXFDILeQ/Dx5UZJL +rYrm/C9aFU9uwtujbdFzBRjK9v31WDlP+U5EFCIvMmQAl9HiyNfDQvD0DUDePRuz +vE+EgmlaTPBLP5zfG0JXBtTxMwSaYFrgL3MXLNWnH69WR7KV5LtpYnuP5pAgRT74 +PlYbHQkdr51hOJBNaTxFZ1SWP2c4CggQi5780/S8buynxCMkXErXDxZ/FPSiUJsw +gWjz059ZVv/maPNLTs1frAu+f3brWKtkw28QrhAOHgSDnNp85ivjH/vlXZl4Pfwr +1yOpYY67uu+ZPSU6E7xMwn2QijM8mm7HjwQ0Gs0w5C+qpYJae+meNj1QpoW4ux1Z +ESFx8H7g347zJGaJIGC3TL3BhCXQmH1+HpLOw4lYhxaFsrPQn81SkL/sAWy8orbR +K/kg2Gz/wCi3/3utxbgEtRARCY6H3oDUguN7vJ3jPKNOT1cQbyy9KgoM3Njn25P2
[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=17836282#comment-17836282
]
Ekaterina Dimitrova commented on CASSANDRA-18831:
-
{quote}We bumped many of the dependencies already with 5.0
{quote}
{quote}Yep. Some of these I'm having to bump again were updated late last year
or .ea versions released in the past few months for JDK21 support since so much
more keeps getting locked down. Happening in spaces heavy with reflection (i.e.
testing, debugging, logging), not in production data serving paths, so I'm not
too worried about the introduction of the deps in their current forms.
{quote}
I agree with everything said. My point was more about the fact that you don't
have to update dependencies that haven't been touched in 5-6 years (there are
plenty of versions in between with breaking changes and long change logs to
consider). I hope that it makes it at least a bit easier and faster. Thanks
again for moving forward with this one!
> Enable Cassandra to build and run under JDK21
> -
>
> Key: CASSANDRA-18831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18831
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Achilles Benetopoulos
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.x
>
> Attachments: jdk21-patch
>
>
> This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list
> of supported Java versions, and extends that work to enable building and
> running Cassandra under JDK21.
> The following commits comprise the changes included in the attached patch:
> -
> [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47]
> -
> [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897]
> -
> [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913]
> -
> [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19516) Use Transformation.Kind.id in local and distributed log tables
[
https://issues.apache.org/jira/browse/CASSANDRA-19516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836280#comment-17836280
]
Sam Tunnicliffe commented on CASSANDRA-19516:
-
+1
> Use Transformation.Kind.id in local and distributed log tables
> --
>
> Key: CASSANDRA-19516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19516
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Attachments: ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should store {{Kind.id}} added in CASSANDRA-19390 in the local and
> distributed log tables. Virtual table will still do the id -> string lookup
> for easier reading
--
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-19516) Use Transformation.Kind.id in local and distributed log tables
[
https://issues.apache.org/jira/browse/CASSANDRA-19516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19516:
Status: Review In Progress (was: Patch Available)
> Use Transformation.Kind.id in local and distributed log tables
> --
>
> Key: CASSANDRA-19516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19516
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Attachments: ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should store {{Kind.id}} added in CASSANDRA-19390 in the local and
> distributed log tables. Virtual table will still do the id -> string lookup
> for easier reading
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836278#comment-17836278
]
Stefan Miklosovic edited comment on CASSANDRA-19553 at 4/11/24 5:01 PM:
I'll park this ticket for a while as I am done (minus tests) and this might
receive first round of reviews, I want to have an agreement on the approach.
for warning / failure thresholds, there are two columns, warn and fail, but it
would be great if these thresholds are set together at once. When we update a
column in a vtable, I get just that column, I do not have any visibility what
other column is set to. So when I have "fail" set to 10 and "warn" set to 20,
then this is a valid CQL but it does not make sense on guardrail level.
What I did in system_guardrails.thresholds table is that I made apply method
non final to get all row to operate on.
I think this is a no-no and only other approach I can think of is to use a
tuple like this:
{code:java}
cqlsh> select * from system_guardrails.thresholds_on_tuple ;
name | value
---+--
collection_size | (0, 0)
column_value_size | (-1, -1)
columns_per_table | (-1, -1)
fields_per_udt | (-1, -1)
in_select_cartesian_product | (-1, -1)
items_per_collection | (-1, -1)
keyspaces | (-1, -1)
local_data_disk_usage | (-1, -1)
materialized_views_per_table | (-1, -1)
maximum_replication_factor | (-1, -1)
maximum_timestamp | (0, 0)
minimum_replication_factor | (-1, -1)
minimum_timestamp | (0, 0)
page_size | (-1, -1)
partition_keys_in_select | (-1, -1)
partition_size | (0, 0)
partition_tombstones | (-1, -1)
sai_sstable_indexes_per_query | (32, -1)
secondary_indexes_per_table | (-1, -1)
tables | (-1, -1)
vector_dimensions | (-1, -1)
cqlsh> update system_guardrails.thresholds_on_tuple set value = (10, 20) where
name = 'vector_dimensions';
cqlsh> select value from system_guardrails.thresholds_on_tuple where name =
'vector_dimensions';
value
--
(10, 20)
{code}
Values guardrails look like this:
{code:java}
cqlsh> select * from system_guardrails.values ;
name | disallowed | ignored | warned
--++-+
read_consistency_levels | {} |{} | {}
table_properties | {} |{} | {}
write_consistency_levels | {} |{} | {}
(3 rows)
cqlsh> update system_guardrails.values set warned = {'EACH_QUORUM', 'ALL'}
where name = 'read_consistency_levels';
(3 rows)
cqlsh> select warned from system_guardrails.values where name =
'read_consistency_levels';
warned
{'ALL', 'EACH_QUORUM'}
(1 rows)
{code}
I think we are fully covered.
was (Author: smiklosovic):
I'll park this ticket for a while as I am done (minus tests) and this might
receive first round of reviews, I want to have an agreement on the approach.
for warning / failure thresholds, there are two columns, warn and fail, but it
would be great if these thresholds are set together at once. When we update a
column in a vtable, I get just that column, I do not have any visibility what
other column is set to. So when I have "fail" set to 10 and "warn" set to 20,
then this is a valid CQL but it does not make sense on guardrail level.
What I did in system_guardrails.thresholds table is that I made apply method
non final to get all row to operate on.
I think this is a no-no and only other approach I can think of is to use a
tuple like this:
{code:java}
cqlsh> select * from system_guardrails.thresholds_on_tuple ;
name | value
---+--
collection_size | (0, 0)
column_value_size | (-1, -1)
columns_per_table | (-1, -1)
fields_per_udt | (-1, -1)
in_select_cartesian_product | (-1, -1)
items_per_collection | (-1, -1)
keyspaces | (-1, -1)
local_data_disk_usage | (-1, -1)
materialized_views_per_table | (-1, -1)
maximum_replication_factor | (-1, -1)
maximum_timestamp | (0, 0)
minimum_replication_factor | (-1, -1)
minimum_timestamp | (0, 0)
page_size | (-1, -1)
partition_keys_in_select | (-1, -1)
partition_size | (0, 0)
partition_tombstones | (-1, -1)
sai_sstable_indexes_per_query | (32, -1)
secondary_indexes_per_table | (-1, -1)
tables | (-1, -1)
vector_dimensions | (-1, -1)
cqlsh> update system_guardrails.thresholds_on_tuple set value = (10, 20) where
name =
[jira] [Updated] (CASSANDRA-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19553:
--
Test and Documentation Plan: still need to finish test, I am just
interested in the review for a general approach
Status: Patch Available (was: In Progress)
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name = 'sai_sstable_indexes_per_query';
> {code}
> {code}
> cqlsh> select * from system_views.guardrails_threshold where name =
> 'sai_sstable_indexes_per_query';
> name | fail | warn
> ---+--+--
> sai_sstable_indexes_per_query | 20 | 16
> {code}
> {code}
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_warn_threshold from 32 to 16
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_fail_threshold from -1 to 20
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 10, fail = 5 where
> name = 'sai_sstable_indexes_per_query';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="The
> warn threshold 10 for sai_sstable_indexes_per_query_warn_threshold should be
> lower than the fail threshold 5"
> {code}
> We can easily extend this to EnableFlag guardrails for which we would
> dedicate a separate table (system_views.guadrails_flag).
> Other guardrail types are being investigated.
--
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-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836278#comment-17836278
]
Stefan Miklosovic commented on CASSANDRA-19553:
---
I'll park this ticket for a while as I am done (minus tests) and this might
receive first round of reviews, I want to have an agreement on the approach.
for warning / failure thresholds, there are two columns, warn and fail, but it
would be great if these thresholds are set together at once. When we update a
column in a vtable, I get just that column, I do not have any visibility what
other column is set to. So when I have "fail" set to 10 and "warn" set to 20,
then this is a valid CQL but it does not make sense on guardrail level.
What I did in system_guardrails.thresholds table is that I made apply method
non final to get all row to operate on.
I think this is a no-no and only other approach I can think of is to use a
tuple like this:
{code:java}
cqlsh> select * from system_guardrails.thresholds_on_tuple ;
name | value
---+--
collection_size | (0, 0)
column_value_size | (-1, -1)
columns_per_table | (-1, -1)
fields_per_udt | (-1, -1)
in_select_cartesian_product | (-1, -1)
items_per_collection | (-1, -1)
keyspaces | (-1, -1)
local_data_disk_usage | (-1, -1)
materialized_views_per_table | (-1, -1)
maximum_replication_factor | (-1, -1)
maximum_timestamp | (0, 0)
minimum_replication_factor | (-1, -1)
minimum_timestamp | (0, 0)
page_size | (-1, -1)
partition_keys_in_select | (-1, -1)
partition_size | (0, 0)
partition_tombstones | (-1, -1)
sai_sstable_indexes_per_query | (32, -1)
secondary_indexes_per_table | (-1, -1)
tables | (-1, -1)
vector_dimensions | (-1, -1)
cqlsh> update system_guardrails.thresholds_on_tuple set value = (10, 20) where
name = 'vector_dimensions';
cqlsh> select value from system_guardrails.thresholds_on_tuple where name =
'vector_dimensions'; value
--
(10, 20)
{code}
Values guardrails look like this:
{code}
cqlsh> select * from system_guardrails.values ;
name | disallowed | ignored | warned
--++-+
read_consistency_levels | {} |{} | {}
table_properties | {} |{} | {}
write_consistency_levels | {} |{} | {}
(3 rows)
cqlsh> update system_guardrails.values set warned = {'EACH_QUORUM', 'ALL'}
where name = 'read_consistency_levels';
(3 rows)
cqlsh> select warned from system_guardrails.values where name =
'read_consistency_levels';
warned
{'ALL', 'EACH_QUORUM'}
(1 rows)
{code}
I think we are fully covered.
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name =
svn commit: r68437 - in /dev/cassandra/3.0.30/debian: ./ dists/ dists/30x/ dists/30x/main/ dists/30x/main/binary-amd64/ dists/30x/main/binary-arm64/ dists/30x/main/binary-i386/ dists/30x/main/source/
Author: brandonwilliams Date: Thu Apr 11 16:40:06 2024 New Revision: 68437 Log: staging cassandra debian packages for 3.0.30 Added: dev/cassandra/3.0.30/debian/ dev/cassandra/3.0.30/debian/cassandra-tools_3.0.30_all.deb (with props) dev/cassandra/3.0.30/debian/cassandra_3.0.30.dsc dev/cassandra/3.0.30/debian/cassandra_3.0.30.tar.gz (with props) dev/cassandra/3.0.30/debian/cassandra_3.0.30_all.deb (with props) dev/cassandra/3.0.30/debian/cassandra_3.0.30_amd64.buildinfo dev/cassandra/3.0.30/debian/cassandra_3.0.30_amd64.changes dev/cassandra/3.0.30/debian/dists/ dev/cassandra/3.0.30/debian/dists/30x/ dev/cassandra/3.0.30/debian/dists/30x/InRelease dev/cassandra/3.0.30/debian/dists/30x/Release dev/cassandra/3.0.30/debian/dists/30x/Release.gpg dev/cassandra/3.0.30/debian/dists/30x/main/ dev/cassandra/3.0.30/debian/dists/30x/main/binary-amd64/ dev/cassandra/3.0.30/debian/dists/30x/main/binary-amd64/Packages dev/cassandra/3.0.30/debian/dists/30x/main/binary-amd64/Packages.gz (with props) dev/cassandra/3.0.30/debian/dists/30x/main/binary-amd64/Release dev/cassandra/3.0.30/debian/dists/30x/main/binary-arm64/ dev/cassandra/3.0.30/debian/dists/30x/main/binary-arm64/Packages dev/cassandra/3.0.30/debian/dists/30x/main/binary-arm64/Packages.gz (with props) dev/cassandra/3.0.30/debian/dists/30x/main/binary-arm64/Release dev/cassandra/3.0.30/debian/dists/30x/main/binary-i386/ dev/cassandra/3.0.30/debian/dists/30x/main/binary-i386/Packages dev/cassandra/3.0.30/debian/dists/30x/main/binary-i386/Packages.gz (with props) dev/cassandra/3.0.30/debian/dists/30x/main/binary-i386/Release dev/cassandra/3.0.30/debian/dists/30x/main/source/ dev/cassandra/3.0.30/debian/dists/30x/main/source/Release dev/cassandra/3.0.30/debian/dists/30x/main/source/Sources.gz (with props) dev/cassandra/3.0.30/debian/pool/ dev/cassandra/3.0.30/debian/pool/main/ dev/cassandra/3.0.30/debian/pool/main/c/ dev/cassandra/3.0.30/debian/pool/main/c/cassandra/ dev/cassandra/3.0.30/debian/pool/main/c/cassandra/cassandra-tools_3.0.30_all.deb (with props) dev/cassandra/3.0.30/debian/pool/main/c/cassandra/cassandra_3.0.30.dsc dev/cassandra/3.0.30/debian/pool/main/c/cassandra/cassandra_3.0.30.tar.gz (with props) dev/cassandra/3.0.30/debian/pool/main/c/cassandra/cassandra_3.0.30_all.deb (with props) Added: dev/cassandra/3.0.30/debian/cassandra-tools_3.0.30_all.deb == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/debian/cassandra-tools_3.0.30_all.deb -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/debian/cassandra_3.0.30.dsc == --- dev/cassandra/3.0.30/debian/cassandra_3.0.30.dsc (added) +++ dev/cassandra/3.0.30/debian/cassandra_3.0.30.dsc Thu Apr 11 16:40:06 2024 @@ -0,0 +1,41 @@ +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA512 + +Format: 1.0 +Source: cassandra +Binary: cassandra, cassandra-tools +Architecture: all +Version: 3.0.30 +Maintainer: Eric Evans +Uploaders: Sylvain Lebresne +Homepage: http://cassandra.apache.org +Standards-Version: 3.8.3 +Vcs-Browser: https://git-wip-us.apache.org/repos/asf?p=cassandra.git +Vcs-Git: http://git-wip-us.apache.org/repos/asf/cassandra.git +Build-Depends: debhelper (>= 5), openjdk-8-jdk | java8-jdk, ant (>= 1.9), ant-optional (>= 1.9), dh-python, python-dev (>= 2.7) | python2-dev (>= 2.7), dpatch, bash-completion +Package-List: + cassandra deb misc extra arch=all + cassandra-tools deb misc extra arch=all +Checksums-Sha1: + 64398d79abb4a3f0d9e63ccd010c17c9003b569b 9045833 cassandra_3.0.30.tar.gz +Checksums-Sha256: + a6acc56d768e71bf22548cab63f7cccaf023af07b5b4028e828c95c1213b23ac 9045833 cassandra_3.0.30.tar.gz +Files: + fe619dd69248cad683d1ebb5d9e1ec42 9045833 cassandra_3.0.30.tar.gz + +-BEGIN PGP SIGNATURE- + +iQIzBAEBCgAdFiEEt4Qs2vNuajIU+uNdXoW5rguEwEEFAmYYEiUACgkQXoW5rguE +wEEl3Q//ZJZjwFURdbCY3Dsn7ksYYHLL0EHUnXbU714XgniVI1R3N1MvWTLMoLQq +8xj8zRoSGmWePzyV8PSCCGKufGD9I3p9+GfQxSAvGpFSx5B19BWEwsrXE/Kpf/0J +wYCWTbKizjeiGftlR1/F9nc17NU/PvmDPZnfjGoUY2pCwr27wNV3qEYNg57vb7vS +SgxgQxNJBlvvw2WwHOYhpGJX4FBMmu0ChXLumXDnopByE11eI/SByaTKZM1LEr5D +B6S9I8kB1be7LYeZCPUL4Ui35R7NBq+A9L9qPBOGv2Ykd1waWdFK6J8RLaiG7erG +VItDjkmSF85y5nH6gMWFN7EQf8vvyvSz1N1FNgSXW4JfAdRwrD3fufrCxQiidd+B +GfqtJtcmrf4rglEPuX/nEOSsAdjB+Kjqnq+JFU1v2AcTj1WnZIrIQJ3rJVx3Nc0y +DPFjxr3OI1PF1vn7W7CLLd1hbMF/TxCwlE80YDK0WekCWuIWG/WQPAY1ub9JK1Er +vFbDCGcNO+WXjCO+pjdML0FtsdPdiRFcGq0bAw7FmBCejGSRLf8rPts/LxGO+sdH +aYWAWwW36F5ylSwHQ3bFMPFZrXr0ilWk//hkM0/Uk9H7RZbHzvyjFT2cE/4aQv/s +fyup6y1NVCuEj3VNIBixmcE+wh84ze5Y/U2OxlxU6yNxs9csSVI= +=ai+1 +-END PGP SIGNATURE- Added: dev/cassandra/3.0.30/debian/cassandra_3.0.30.tar.gz
svn commit: r68436 - /dev/cassandra/3.0.30/
Author: brandonwilliams Date: Thu Apr 11 16:35:25 2024 New Revision: 68436 Log: staging cassandra 3.0.30 Added: dev/cassandra/3.0.30/ dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz (with props) dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.asc dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha256 dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha512 dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz (with props) dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.asc dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha256 dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha512 Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.asc == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.asc (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.asc Thu Apr 11 16:35:25 2024 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEt4Qs2vNuajIU+uNdXoW5rguEwEEFAmYYEM0ACgkQXoW5rguE +wEELuRAA3UfWi+gIdv/MfEiti/pRIBmhRnvtZwhusa28mG9chM6pco1K8k/PLHKa +a7Tlrlu0HtgnniOZGy7QCLPsvZpoyWbofCnPpsn7Oj2GRVrtzAhKKwv3ETvAXRFN +lSi6PNMXVjyRnSJYoEM0x2COAasbT0JZmEJVtPsqr1Ks9iMByVoey6QbbVDQBuz1 +j4GX6Yc+rVLQJC58PW2arJTVNGTQRo3/PIR2pUVudMXtSKml/6m7ZD6XEWIvNYrS +6sdpsZHLg+bCUqTelSHEQlN7miQ9nbWn2xtK5eHNe4fstiNAwW4ep+hILMHWGJZt +CPYcuRkwcnGrb/qHeJrzB05l97AMkbQAPxL5YhDj3TEGfrT8Yiq9O6IJG14/6bCY +5B48i1q3ZgM8jmtGXXH+Y9DtLpF8Njl6yKHTS5S8QoghxcJ/ZZZpn3LbpEWoTgpD +Jtu3Xdq7RH8vpU3Q3738aa0ge3ubwcD9K54nkcirxyLTjjUUDZVnlQYS4SxF7Yj7 ++LO9wC0re3O0U5HXQyTaGF8JLbORAMNhB02ot42/uuqK7TBMWdEkFZFAdoOWkt7q +nMoUQxBlA8B6K6iTsenvXH5aJP795bgiHBoAhwOsQlfjUEFcfl4fi/upLHlbR4ce +l698GC2oFMSl/ARkjIm8/beFk4yS/VfvBJwP8CL51C1Ka9YhU/4= +=yfO7 +-END PGP SIGNATURE- Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha256 == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha256 (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha256 Thu Apr 11 16:35:25 2024 @@ -0,0 +1 @@ +e0bb426f9a887f1981bf748ef02760d85bd43a8402b60360d1212fce7fad6637 Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha512 == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha512 (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-bin.tar.gz.sha512 Thu Apr 11 16:35:25 2024 @@ -0,0 +1 @@ +05ade4b05642a7adb5cb27842dc32b700abccb2ea5a480a33638365e32efdaedcefa276443180c288a705a33cc8c403584fef2d2cd8aa09baedd0b187e0a3f91 Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.asc == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.asc (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.asc Thu Apr 11 16:35:25 2024 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEt4Qs2vNuajIU+uNdXoW5rguEwEEFAmYYEM8ACgkQXoW5rguE +wEFvXQ/+L5jtEC1HfYF2kKbxzwVc0S9ZoLjqmEi52Q+M4tygLF5nv2jUxLQVrY/b +VLSCUsOa8Z/uETy3m5DWrpt2HAawUQwF967HPBqLsOtloy037rPnALiplvdJ8X+R +4wYEAb5qGIMizSHxiW9bThzCn+InxX71MrC2+sKaZj8LoQZLSxcPBw3+vu7EGMUU +d+eICkWmP3+UlYc8+NIuki8IQEcRe6GvUEJV/izJJEVBplnJkQxZ9dRwqOpjgNQw +oY9I3eiVA67Q4aOX7Z+l52IzeS77UjGH2rCkPF0WgJeH30PI6yQtW5df1K/UaaE3 +NNIrLcAj9Pq0r51fMbdCJI4F6cBncN+G05I/y8dRu0khZGFX7glrBfaiSkJM0fxE +zCcM2/Oxh/uZ4o+UzgUuTarhID+TnnEd0mR6dzuLodZKtxKZ+aIQ6uhy0VT7rFk9 +QnDLX6ss5NftauNPJmAw+//Qr7bkGHz7/OlgY+sPug+8i0cBlbwCZRauU7VgnF2/ +4HUYAoJipei5WFLZjjBFK5/qMBtIqNNT1s0aSHDFCIUgJiZ7Xc2zUQFblYW9E/6e +Xz9lmr1pU2KdpdfmH8MwR8wTAgSV+KOnHNPzyo0xO7sJK4mAnDu3yps93nVejV/R +U4jeMdwAWWvguQ1LuR4eXRTJlzp3YMXCKCLi1+At4fpBtfGZJoE= +=qyD4 +-END PGP SIGNATURE- Added: dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha256 == --- dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha256 (added) +++ dev/cassandra/3.0.30/apache-cassandra-3.0.30-src.tar.gz.sha256 Thu Apr 11 16:35:25 2024 @@ -0,0 +1 @@
(cassandra) 02/04: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 00c45611c9e81a8f69cf795bd72905326a697dab Author: Brandon Williams AuthorDate: Thu Apr 11 11:23:07 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 1ac140df4c..ca25260488 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (3.0.30) unstable; urgency=medium * New release - -- Brandon Williams Thu, 11 Apr 2024 11:12:18 -0500 + -- Brandon Williams Thu, 11 Apr 2024 11:23:02 -0500 cassandra (3.0.29) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 04/04: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 657e595b78227c28a6b8808ef9bf62f646029f3b Author: Brandon Williams AuthorDate: Thu Apr 11 11:30:02 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index e1fc3e5c3b..ca25260488 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (3.0.30) unstable; urgency=medium * New release - -- Brandon Williams Thu, 11 Apr 2024 11:24:46 -0500 + -- Brandon Williams Thu, 11 Apr 2024 11:23:02 -0500 cassandra (3.0.29) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 03/04: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 296b9cb88960b6e90390d873f1afb7b8c1c9c795 Author: Brandon Williams AuthorDate: Thu Apr 11 11:24:51 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index ca25260488..e1fc3e5c3b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (3.0.30) unstable; urgency=medium * New release - -- Brandon Williams Thu, 11 Apr 2024 11:23:02 -0500 + -- Brandon Williams Thu, 11 Apr 2024 11:24:46 -0500 cassandra (3.0.29) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/04: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ccb83d0b6b726393f745aff24e29d93f5faee922 Author: Brandon Williams AuthorDate: Thu Apr 11 11:13:02 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/changelog b/debian/changelog index fe2bb9b324..1ac140df4c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.0.30) unstable; urgency=medium + + * New release + + -- Brandon Williams Thu, 11 Apr 2024 11:12:18 -0500 + cassandra (3.0.29) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative created (now 657e595b78)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git at 657e595b78 (commit) This tag includes the following new commits: new ccb83d0b6b Prepare debian changelog for 3.0.30 new 00c45611c9 Prepare debian changelog for 3.0.30 new 296b9cb889 Prepare debian changelog for 3.0.30 new 657e595b78 Prepare debian changelog for 3.0.30 The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative deleted (was 296b9cb889)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git *** WARNING: tag 3.0.30-tentative was deleted! *** was 296b9cb889 Prepare debian changelog for 3.0.30 This change permanently discards the following revisions: discard 296b9cb889 Prepare debian changelog for 3.0.30 discard 00c45611c9 Prepare debian changelog for 3.0.30 discard ccb83d0b6b Prepare debian changelog for 3.0.30 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative created (now 296b9cb889)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git at 296b9cb889 (commit) This tag includes the following new commits: new ccb83d0b6b Prepare debian changelog for 3.0.30 new 00c45611c9 Prepare debian changelog for 3.0.30 new 296b9cb889 Prepare debian changelog for 3.0.30 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/03: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ccb83d0b6b726393f745aff24e29d93f5faee922 Author: Brandon Williams AuthorDate: Thu Apr 11 11:13:02 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/changelog b/debian/changelog index fe2bb9b324..1ac140df4c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.0.30) unstable; urgency=medium + + * New release + + -- Brandon Williams Thu, 11 Apr 2024 11:12:18 -0500 + cassandra (3.0.29) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 03/03: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 296b9cb88960b6e90390d873f1afb7b8c1c9c795 Author: Brandon Williams AuthorDate: Thu Apr 11 11:24:51 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index ca25260488..e1fc3e5c3b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (3.0.30) unstable; urgency=medium * New release - -- Brandon Williams Thu, 11 Apr 2024 11:23:02 -0500 + -- Brandon Williams Thu, 11 Apr 2024 11:24:46 -0500 cassandra (3.0.29) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 02/03: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 00c45611c9e81a8f69cf795bd72905326a697dab Author: Brandon Williams AuthorDate: Thu Apr 11 11:23:07 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 1ac140df4c..ca25260488 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (3.0.30) unstable; urgency=medium * New release - -- Brandon Williams Thu, 11 Apr 2024 11:12:18 -0500 + -- Brandon Williams Thu, 11 Apr 2024 11:23:02 -0500 cassandra (3.0.29) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative deleted (was 00c45611c9)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git *** WARNING: tag 3.0.30-tentative was deleted! *** was 00c45611c9 Prepare debian changelog for 3.0.30 This change permanently discards the following revisions: discard 00c45611c9 Prepare debian changelog for 3.0.30 discard ccb83d0b6b Prepare debian changelog for 3.0.30 - 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=17836266#comment-17836266 ] Ekaterina Dimitrova commented on CASSANDRA-18831: - Thanks [~jmckenzie], I am happy to see this progressing! bq. I'll pursue getting that set up formally in the ASF space after we have general support merged That is what we were doing before, too - whatever can be merged and it is not breaking with the previous versions, gets merged. Some of the updates that were needed for JDK17 were committed from 4.1. Whatever will require a previous JDK version to be dropped (we maintain two) - it waits until the drop. The only issue is that there will be breakages until we have it in CI, as people do not test their patches on the new version, but we can't have everything. I was also fixing every now and then the broken trunk. We bumped many of the dependencies already with 5.0 > Enable Cassandra to build and run under JDK21 > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Assignee: Josh McKenzie >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 02/02: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 00c45611c9e81a8f69cf795bd72905326a697dab Author: Brandon Williams AuthorDate: Thu Apr 11 11:23:07 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 1ac140df4c..ca25260488 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (3.0.30) unstable; urgency=medium * New release - -- Brandon Williams Thu, 11 Apr 2024 11:12:18 -0500 + -- Brandon Williams Thu, 11 Apr 2024 11:23:02 -0500 cassandra (3.0.29) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/02: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ccb83d0b6b726393f745aff24e29d93f5faee922 Author: Brandon Williams AuthorDate: Thu Apr 11 11:13:02 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/changelog b/debian/changelog index fe2bb9b324..1ac140df4c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.0.30) unstable; urgency=medium + + * New release + + -- Brandon Williams Thu, 11 Apr 2024 11:12:18 -0500 + cassandra (3.0.29) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative created (now 00c45611c9)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git at 00c45611c9 (commit) This tag includes the following new commits: new ccb83d0b6b Prepare debian changelog for 3.0.30 new 00c45611c9 Prepare debian changelog for 3.0.30 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative deleted (was ccb83d0b6b)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git *** WARNING: tag 3.0.30-tentative was deleted! *** was ccb83d0b6b Prepare debian changelog for 3.0.30 This change permanently discards the following revisions: discard ccb83d0b6b Prepare debian changelog for 3.0.30 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Prepare debian changelog for 3.0.30
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ccb83d0b6b726393f745aff24e29d93f5faee922 Author: Brandon Williams AuthorDate: Thu Apr 11 11:13:02 2024 -0500 Prepare debian changelog for 3.0.30 --- debian/changelog | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/changelog b/debian/changelog index fe2bb9b324..1ac140df4c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.0.30) unstable; urgency=medium + + * New release + + -- Brandon Williams Thu, 11 Apr 2024 11:12:18 -0500 + cassandra (3.0.29) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) tag 3.0.30-tentative created (now ccb83d0b6b)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 3.0.30-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git at ccb83d0b6b (commit) This tag includes the following new commits: new ccb83d0b6b Prepare debian changelog for 3.0.30 The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - 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=17836255#comment-17836255 ] Josh McKenzie commented on CASSANDRA-18831: --- Can provide a brief update on this. We have some dependencies that need to be bumped (chronicle*, mockito, bytebuddy), some startup args that need to be tweaked, and some various and sundry other things. I'm working through test failures now but when I have something that builds and passes on CI my plan is to attach it here even if we don't yet have things configured on CI. I'll pursue getting that set up formally in the ASF space after we have general support merged, at the risk of said support atrophying between when we merge it in and when we get it integrated into CI. > Enable Cassandra to build and run under JDK21 > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Assignee: Josh McKenzie >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19279) Test Failure: org.apache.cassandra.simulator.test.HarrySimulatorTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836244#comment-17836244
]
Michael Semb Wever commented on CASSANDRA-19279:
I'm seeing this a lot, especially in the trunk builds. Are we just running
simulator-dtest with too little ram ? (It looks like it needs 8gb heap, and
probably the same off-heap?)
> Test Failure: org.apache.cassandra.simulator.test.HarrySimulatorTest
>
>
> Key: CASSANDRA-19279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19279
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing 421 times out of 468 runs as visible in this repeated run:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2619/workflows/5a5c0104-16a8-493b-99a2-092e2aba2799/jobs/53164/tests]
> {code:java}
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Direct
> buffer memory
> at org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:547)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
> at
> org.apache.cassandra.simulator.ClusterSimulation.close(ClusterSimulation.java:854)
> at
> org.apache.cassandra.simulator.test.HarrySimulatorTest.simulate(HarrySimulatorTest.java:543)
> at
> org.apache.cassandra.simulator.test.HarrySimulatorTest.harryTest(HarrySimulatorTest.java:228)
> at
> org.apache.cassandra.simulator.test.HarrySimulatorTest.test(HarrySimulatorTest.java:204)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.util.concurrent.ExecutionException:
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Direct
> buffer memory
> at
> org.apache.cassandra.utils.concurrent.AbstractFuture.getWhenDone(AbstractFuture.java:239)
> at
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:254)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:539)
> Suppressed: java.util.concurrent.ExecutionException:
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Direct
> buffer memory
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.OutOfMemoryError: Direct buffer memory
> at
> org.apache.cassandra.utils.concurrent.AbstractFuture.getWhenDone(AbstractFuture.java:239)
> at
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:246)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$shutdown$47(Instance.java:975)
> at
> org.apache.cassandra.concurrent.SyncFutureTask.run(SyncFutureTask.java:68)
> at
> org.apache.cassandra.simulator.systems.SimulatedExecution$NoIntercept$1Run.run(SimulatedExecution.java:82)
> at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$InterceptingPooledExecutor$WaitingThread.lambda$new$1(InterceptingExecutor.java:318)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.RuntimeException:
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Direct
> buffer memory
> at
> org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$shutdown$46(Instance.java:969)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$async$10(IsolatedExecutor.java:156)
> at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.OutOfMemoryError: Direct buffer memory
> at
> org.apache.cassandra.utils.concurrent.AbstractFuture.getWhenDone(AbstractFuture.java:239)
> at
>
Re: [PR] CASSANDRA-19457: Object reference in Micrometer metrics prevent GC from reclaiming Session instances [cassandra-java-driver]
SiyaoIsHiding commented on PR #1916: URL: https://github.com/apache/cassandra-java-driver/pull/1916#issuecomment-2049909475 Hi, I reverted the revert of the revert and it should be good now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19555) Docs should mention auth caching post-12988
[ https://issues.apache.org/jira/browse/CASSANDRA-19555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19555: - Summary: Docs should mention auth caching post-12988 (was: Docs should mention auth caching) > Docs should mention auth caching post-12988 > --- > > Key: CASSANDRA-19555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19555 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Brandon Williams >Priority: Normal > > After CASSANDRA-12988, a performance impact may be seen (see CASSANDRA-19529) > by the increased consistency level which can be mitigated with caching. The > [documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#authentication] > should mention this. -- 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-19555) Docs should mention auth caching
[ https://issues.apache.org/jira/browse/CASSANDRA-19555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19555: - Change Category: Semantic Complexity: Low Hanging Fruit Component/s: Documentation/Website Status: Open (was: Triage Needed) > Docs should mention auth caching > > > Key: CASSANDRA-19555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19555 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Brandon Williams >Priority: Normal > > After CASSANDRA-12988, a performance impact may be seen (see CASSANDRA-19529) > by the increased consistency level which can be mitigated with caching. The > [documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#authentication] > should mention this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19555) Docs should mention auth caching
Brandon Williams created CASSANDRA-19555: Summary: Docs should mention auth caching Key: CASSANDRA-19555 URL: https://issues.apache.org/jira/browse/CASSANDRA-19555 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams After CASSANDRA-12988, a performance impact may be seen (see CASSANDRA-19529) by the increased consistency level which can be mitigated with caching. The [documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#authentication] should mention this. -- 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-19529) Latency regression on 4.1 comparing to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19529: - Resolution: Not A Problem Status: Resolved (was: Open) > Latency regression on 4.1 comparing to 4.0 > -- > > Key: CASSANDRA-19529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19529 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Nicolas Henneaux >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > When upgrading from Cassandra 4.0.10 to 4.1.3, I noticed an increase from > application point of view latency from ~8ms to ~15ms when upgrading to > Cassandra. The latency includes 3 simple queries (INSERT + SELECT (PK+CK) + > UPDATE) plus application overhead. > It has been investigated in CASSANDRA-18766 to realize it is not related. > I tested to downgrade to 4.1alpha1 and the latency regression is still there > with same value. > The version 4.1.4 has the same issue. > In a graph how it looks like > !screenshot-1.png! -- 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-19529) Latency regression on 4.1 comparing to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-19529: Assignee: Brandon Williams > Latency regression on 4.1 comparing to 4.0 > -- > > Key: CASSANDRA-19529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19529 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Nicolas Henneaux >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > When upgrading from Cassandra 4.0.10 to 4.1.3, I noticed an increase from > application point of view latency from ~8ms to ~15ms when upgrading to > Cassandra. The latency includes 3 simple queries (INSERT + SELECT (PK+CK) + > UPDATE) plus application overhead. > It has been investigated in CASSANDRA-18766 to realize it is not related. > I tested to downgrade to 4.1alpha1 and the latency regression is still there > with same value. > The version 4.1.4 has the same issue. > In a graph how it looks like > !screenshot-1.png! -- 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-19529) Latency regression on 4.1 comparing to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836220#comment-17836220 ] Brandon Williams commented on CASSANDRA-19529: -- Alright, I'll take care of it :) > Latency regression on 4.1 comparing to 4.0 > -- > > Key: CASSANDRA-19529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19529 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Nicolas Henneaux >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > When upgrading from Cassandra 4.0.10 to 4.1.3, I noticed an increase from > application point of view latency from ~8ms to ~15ms when upgrading to > Cassandra. The latency includes 3 simple queries (INSERT + SELECT (PK+CK) + > UPDATE) plus application overhead. > It has been investigated in CASSANDRA-18766 to realize it is not related. > I tested to downgrade to 4.1alpha1 and the latency regression is still there > with same value. > The version 4.1.4 has the same issue. > In a graph how it looks like > !screenshot-1.png! -- 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-19529) Latency regression on 4.1 comparing to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836217#comment-17836217 ] Nicolas Henneaux commented on CASSANDRA-19529: -- I don't mind about documentation, it's for me since I got the information now ;) > Latency regression on 4.1 comparing to 4.0 > -- > > Key: CASSANDRA-19529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19529 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Nicolas Henneaux >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > When upgrading from Cassandra 4.0.10 to 4.1.3, I noticed an increase from > application point of view latency from ~8ms to ~15ms when upgrading to > Cassandra. The latency includes 3 simple queries (INSERT + SELECT (PK+CK) + > UPDATE) plus application overhead. > It has been investigated in CASSANDRA-18766 to realize it is not related. > I tested to downgrade to 4.1alpha1 and the latency regression is still there > with same value. > The version 4.1.4 has the same issue. > In a graph how it looks like > !screenshot-1.png! -- 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-19529) Latency regression on 4.1 comparing to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836216#comment-17836216 ] Brandon Williams commented on CASSANDRA-19529: -- Do you want to create a ticket for the docs update? > Latency regression on 4.1 comparing to 4.0 > -- > > Key: CASSANDRA-19529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19529 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Nicolas Henneaux >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > When upgrading from Cassandra 4.0.10 to 4.1.3, I noticed an increase from > application point of view latency from ~8ms to ~15ms when upgrading to > Cassandra. The latency includes 3 simple queries (INSERT + SELECT (PK+CK) + > UPDATE) plus application overhead. > It has been investigated in CASSANDRA-18766 to realize it is not related. > I tested to downgrade to 4.1alpha1 and the latency regression is still there > with same value. > The version 4.1.4 has the same issue. > In a graph how it looks like > !screenshot-1.png! -- 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-19516) Use Transformation.Kind.id in local and distributed log tables
[
https://issues.apache.org/jira/browse/CASSANDRA-19516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-19516:
Attachment: ci_summary.html
> Use Transformation.Kind.id in local and distributed log tables
> --
>
> Key: CASSANDRA-19516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19516
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Attachments: ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should store {{Kind.id}} added in CASSANDRA-19390 in the local and
> distributed log tables. Virtual table will still do the id -> string lookup
> for easier reading
--
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-19516) Use Transformation.Kind.id in local and distributed log tables
[
https://issues.apache.org/jira/browse/CASSANDRA-19516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-19516:
Change Category: Performance
Complexity: Low Hanging Fruit
Component/s: Transactional Cluster Metadata
Reviewers: Alex Petrov, Sam Tunnicliffe
Status: Open (was: Triage Needed)
> Use Transformation.Kind.id in local and distributed log tables
> --
>
> Key: CASSANDRA-19516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19516
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should store {{Kind.id}} added in CASSANDRA-19390 in the local and
> distributed log tables. Virtual table will still do the id -> string lookup
> for easier reading
--
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-19516) Use Transformation.Kind.id in local and distributed log tables
[
https://issues.apache.org/jira/browse/CASSANDRA-19516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-19516:
Test and Documentation Plan: ci run
Status: Patch Available (was: Open)
> Use Transformation.Kind.id in local and distributed log tables
> --
>
> Key: CASSANDRA-19516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19516
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should store {{Kind.id}} added in CASSANDRA-19390 in the local and
> distributed log tables. Virtual table will still do the id -> string lookup
> for easier reading
--
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-19529) Latency regression on 4.1 comparing to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836151#comment-17836151 ] Nicolas Henneaux commented on CASSANDRA-19529: -- Yes for sure I can choose another but the default is quite big change in term of fail-over mechanism when you have authentication or authorization enabled. It takes an hypothesis on how the cluster will be used. I will configure 4.1 clusters with LOCAL_ONE. For the rest, it's all clear. Thanks a lot for the help! > Latency regression on 4.1 comparing to 4.0 > -- > > Key: CASSANDRA-19529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19529 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Nicolas Henneaux >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > When upgrading from Cassandra 4.0.10 to 4.1.3, I noticed an increase from > application point of view latency from ~8ms to ~15ms when upgrading to > Cassandra. The latency includes 3 simple queries (INSERT + SELECT (PK+CK) + > UPDATE) plus application overhead. > It has been investigated in CASSANDRA-18766 to realize it is not related. > I tested to downgrade to 4.1alpha1 and the latency regression is still there > with same value. > The version 4.1.4 has the same issue. > In a graph how it looks like > !screenshot-1.png! -- 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-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18824: --- Fix Version/s: 5.0-beta2 5.0 (was: 5.0-rc) > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.30, 3.11.17, 4.0.13, 4.1.4, 5.0-beta2, 5.0, 5.1 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- 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-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836130#comment-17836130
]
Stefan Miklosovic commented on CASSANDRA-19553:
---
for guardrail type of "Predicates", we have only replicaDiskUsage guardrail.
What it does is that it guards if replicas for a write do not have disk usages
above some threshold and I do think this is applicable to be settable/gettable
from a vtable.
We have PercentageThreshold of name localDataDiskUsage which is subtype of
Threshold, that tracks warn and fail levels for a node a CQL query was executed
against. That one we do show to a user and she can modify it.
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name = 'sai_sstable_indexes_per_query';
> {code}
> {code}
> cqlsh> select * from system_views.guardrails_threshold where name =
> 'sai_sstable_indexes_per_query';
> name | fail | warn
> ---+--+--
> sai_sstable_indexes_per_query | 20 | 16
> {code}
> {code}
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_warn_threshold from 32 to 16
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_fail_threshold from -1 to 20
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 10, fail = 5 where
> name = 'sai_sstable_indexes_per_query';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="The
> warn threshold 10 for sai_sstable_indexes_per_query_warn_threshold should be
> lower than the fail threshold 5"
> {code}
> We can easily extend this to EnableFlag guardrails for which we would
> dedicate a separate table (system_views.guadrails_flag).
> Other guardrail types are being investigated.
--
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-19554) Website - Download section - Update / remove EOL dates
[ https://issues.apache.org/jira/browse/CASSANDRA-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836124#comment-17836124 ] Brandon Williams commented on CASSANDRA-19554: -- I think we should probably we remove them. We don't do time-based releases and we're bad at estimating when we will do major releases. > Website - Download section - Update / remove EOL dates > -- > > Key: CASSANDRA-19554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Thomas Steinmaurer >Priority: Normal > Attachments: image-2024-04-11-13-15-52-317.png > > > Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in > terms of EOL, running unsupported Cassandra versions and they often refer to > what is stated in https://cassandra.apache.org/_/download.html (as the only > source available?) and don't really think about the dependency to 5.0 GA, but > just reflecting EOL date information there. > As of April 11, 2024, the download section states the following information: > !image-2024-04-11-13-15-52-317.png! > According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... > Either remove these EOL estimates or keep them strongly maintained aligned > with an updated 5.0 GA timeline. > Thanks! -- 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-19554) Website - Download section - Update / remove EOL dates
[ https://issues.apache.org/jira/browse/CASSANDRA-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19554: - Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Website - Download section - Update / remove EOL dates > -- > > Key: CASSANDRA-19554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Thomas Steinmaurer >Priority: Normal > Attachments: image-2024-04-11-13-15-52-317.png > > > Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in > terms of EOL, running unsupported Cassandra versions and they often refer to > what is stated in https://cassandra.apache.org/_/download.html (as the only > source available?) and don't really think about the dependency to 5.0 GA, but > just reflecting EOL date information there. > As of April 11, 2024, the download section states the following information: > !image-2024-04-11-13-15-52-317.png! > According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... > Either remove these EOL estimates or keep them strongly maintained aligned > with an updated 5.0 GA timeline. > Thanks! -- 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-19554) Website - Download section - Update / remove EOL dates
[ https://issues.apache.org/jira/browse/CASSANDRA-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Steinmaurer updated CASSANDRA-19554: --- Description: Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in terms of EOL, running unsupported Cassandra versions and they often refer to what is stated in https://cassandra.apache.org/_/download.html (as the only source available?) and don't really think about the dependency to 5.0 GA, but just reflecting EOL date information there. As of April 11, 2024, the download section states the following information: !image-2024-04-11-13-15-52-317.png! According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... Either remove these EOL estimates or keep them stronly maintained aligned with an updated 5.0 GA timeline. Thanks! was: Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in terms of EOL, running unsupported Cassandra versions and they often refer to what is stated in https://cassandra.apache.org/_/download.html (as the only source available) and don't really think about the dependency to 5.0 GA, but just reflecting EOL date information there. As of April 11, 2024, the download section states the following information: !image-2024-04-11-13-15-52-317.png! According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... Either remove these EOL estimates or keep them stronly maintained aligned with an updated 5.0 GA timeline. Thanks! > Website - Download section - Update / remove EOL dates > -- > > Key: CASSANDRA-19554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Thomas Steinmaurer >Priority: Normal > Attachments: image-2024-04-11-13-15-52-317.png > > > Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in > terms of EOL, running unsupported Cassandra versions and they often refer to > what is stated in https://cassandra.apache.org/_/download.html (as the only > source available?) and don't really think about the dependency to 5.0 GA, but > just reflecting EOL date information there. > As of April 11, 2024, the download section states the following information: > !image-2024-04-11-13-15-52-317.png! > According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... > Either remove these EOL estimates or keep them stronly maintained aligned > with an updated 5.0 GA timeline. > Thanks! -- 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-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19553:
--
Change Category: Operability
Complexity: Normal
Component/s: Feature/Virtual Tables
Fix Version/s: 5.x
Status: Open (was: Triage Needed)
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name = 'sai_sstable_indexes_per_query';
> {code}
> {code}
> cqlsh> select * from system_views.guardrails_threshold where name =
> 'sai_sstable_indexes_per_query';
> name | fail | warn
> ---+--+--
> sai_sstable_indexes_per_query | 20 | 16
> {code}
> {code}
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_warn_threshold from 32 to 16
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_fail_threshold from -1 to 20
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 10, fail = 5 where
> name = 'sai_sstable_indexes_per_query';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="The
> warn threshold 10 for sai_sstable_indexes_per_query_warn_threshold should be
> lower than the fail threshold 5"
> {code}
> We can easily extend this to EnableFlag guardrails for which we would
> dedicate a separate table (system_views.guadrails_flag).
> Other guardrail types are being investigated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19554) Website - Download section - Update / remove EOL dates
Thomas Steinmaurer created CASSANDRA-19554: -- Summary: Website - Download section - Update / remove EOL dates Key: CASSANDRA-19554 URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 Project: Cassandra Issue Type: Task Components: Documentation/Website Reporter: Thomas Steinmaurer Attachments: image-2024-04-11-13-15-52-317.png Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in terms of EOL, running unsupported Cassandra versions and they often refer to what is stated in https://cassandra.apache.org/_/download.html (as the only source available) and don't really think about the dependency to 5.0 GA, but just reflecting EOL date information there. As of April 11, 2024, the download section states the following information: !image-2024-04-11-13-15-52-317.png! According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... Either remove these EOL estimates or keep them stronly maintained aligned with an updated 5.0 GA timeline. Thanks! -- 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-19554) Website - Download section - Update / remove EOL dates
[ https://issues.apache.org/jira/browse/CASSANDRA-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Steinmaurer updated CASSANDRA-19554: --- Description: Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in terms of EOL, running unsupported Cassandra versions and they often refer to what is stated in https://cassandra.apache.org/_/download.html (as the only source available?) and don't really think about the dependency to 5.0 GA, but just reflecting EOL date information there. As of April 11, 2024, the download section states the following information: !image-2024-04-11-13-15-52-317.png! According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... Either remove these EOL estimates or keep them strongly maintained aligned with an updated 5.0 GA timeline. Thanks! was: Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in terms of EOL, running unsupported Cassandra versions and they often refer to what is stated in https://cassandra.apache.org/_/download.html (as the only source available?) and don't really think about the dependency to 5.0 GA, but just reflecting EOL date information there. As of April 11, 2024, the download section states the following information: !image-2024-04-11-13-15-52-317.png! According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... Either remove these EOL estimates or keep them stronly maintained aligned with an updated 5.0 GA timeline. Thanks! > Website - Download section - Update / remove EOL dates > -- > > Key: CASSANDRA-19554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Thomas Steinmaurer >Priority: Normal > Attachments: image-2024-04-11-13-15-52-317.png > > > Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in > terms of EOL, running unsupported Cassandra versions and they often refer to > what is stated in https://cassandra.apache.org/_/download.html (as the only > source available?) and don't really think about the dependency to 5.0 GA, but > just reflecting EOL date information there. > As of April 11, 2024, the download section states the following information: > !image-2024-04-11-13-15-52-317.png! > According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... > Either remove these EOL estimates or keep them strongly maintained aligned > with an updated 5.0 GA timeline. > Thanks! -- 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-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836121#comment-17836121
]
Stefan Miklosovic commented on CASSANDRA-19553:
---
Added enabled flags:
{code}
cqlsh> select * from system_views.guardrails_enable_flags ;
name | value
--+---
allow_filtering | True
alter_table | True
bulk_load_enabled | True
compact_tables | True
drop_keyspace_enabled | True
drop_truncate_table_enabled | True
group_by | True
intersect_filtering_query | True
non_partition_restricted_index_query_enabled | True
read_before_write_list_operations | True
secondary_indexes | True
simplestrategy | True
uncompressed_tables_enabled | False
user_timestamps | True
zero_ttl_on_twcs | True
(15 rows)
cqlsh> update system_views.guardrails_enable_flags SET value = false where name
= 'group_by';
{code}
{code}
INFO [Native-Transport-Requests-1] 2024-04-11 13:15:51,861
GuardrailsOptions.java:998 - Updated group_by_enabled from true to false
{code}
{code}
cqlsh> select value from system_views.guardrails_enable_flags where name =
'group_by';
value
---
False
(1 rows)
{code}
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name = 'sai_sstable_indexes_per_query';
> {code}
> {code}
> cqlsh> select * from system_views.guardrails_threshold where name =
> 'sai_sstable_indexes_per_query';
> name | fail | warn
> ---+--+--
> sai_sstable_indexes_per_query | 20 | 16
> {code}
> {code}
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_warn_threshold from 32 to 16
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_fail_threshold from -1 to 20
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 10, fail = 5 where
> name = 'sai_sstable_indexes_per_query';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="The
> warn threshold 10 for sai_sstable_indexes_per_query_warn_threshold should be
> lower than the fail threshold 5"
> {code}
> We can easily extend this to EnableFlag guardrails for which we would
> dedicate a separate table (system_views.guadrails_flag).
> Other guardrail types are being investigated.
--
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-19552) Nodetool to get/set guardrails configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-19552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836118#comment-17836118 ] Brandon Williams commented on CASSANDRA-19552: -- I think we want both until vtables have complete parity, otherwise you have to mix and match which doesn't seem great. > Nodetool to get/set guardrails configurations > - > > Key: CASSANDRA-19552 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19552 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 4.1.x > > > Currently guardrails are only configurable through JMX / cassandra.yaml > This provides a nodetool command to interact with all the getters/setters for > guardrails. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3243] > trunk PR: [https://github.com/apache/cassandra/pull/3244] -- 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-19529) Latency regression on 4.1 comparing to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836116#comment-17836116 ] Brandon Williams commented on CASSANDRA-19529: -- You can also use QUORUM for authentication if you choose. I am not sure there is anything actionable left on this ticket. > Latency regression on 4.1 comparing to 4.0 > -- > > Key: CASSANDRA-19529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19529 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Nicolas Henneaux >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > When upgrading from Cassandra 4.0.10 to 4.1.3, I noticed an increase from > application point of view latency from ~8ms to ~15ms when upgrading to > Cassandra. The latency includes 3 simple queries (INSERT + SELECT (PK+CK) + > UPDATE) plus application overhead. > It has been investigated in CASSANDRA-18766 to realize it is not related. > I tested to downgrade to 4.1alpha1 and the latency regression is still there > with same value. > The version 4.1.4 has the same issue. > In a graph how it looks like > !screenshot-1.png! -- 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-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836103#comment-17836103
]
Stefan Miklosovic commented on CASSANDRA-19479:
---
+1, I do not see anything suspicious in build's test results.
> Fix type issues and provide tests for type compatibility between 4.1 and 5.0
>
>
> Key: CASSANDRA-19479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19479
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Core, Test/unit
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This is a part of CASSANDRA-14476 - we should verify whether the type
> compatibility matrix is upgradable from 4.0 and 4.1 to 5.0, and if not, fix
> the remaining issues.
> The implemented tests verify the following:
> - assumed compatibility between primitive types
> - equals method symmetricity
> - freezing/unfreezing
> - value compatibility by using a serializer of one type to deserialize a
> value serialized using a serializer of another type
> - serialization compatibility by serializing a row with a column of one type
> as a column of another type for simple and complex cells (multicell types)
> - (comparison) compatibility by comparing serialized values of one type using
> a comparator of another type; for multicell types - build rows and compare
> cell paths of a complex type using a cell path comparator of another complex
> type
> - verify whether types that are (value/serialization/comparison) compatible
> in a previous release are still compatible with this release
> - store the compatibility matrix in a compressed JSON file so that we can
> copy it to future releases to assert backward compatibility (similar approach
> to LegacySSTableTest)
> - verify that type serializers are different for non-compatible type pairs
> which use custom comparisons
> Additionally:
> - the equals method in {{TupleType}} and {{UserType}} was fixed to be
> symmetric. Previously, comparing two values gave a different outcome when
> inverted.
> - fixed a condition in comparison method of {{AbstractCompositeType}}
> - ported a fix for composite and dynamic composite types which adds a
> distinct serializers for them so that the serializers for those types and for
> {{BytesType}} are considered different; similar thing was done for
> {{LexicalUUIDType}} to make its serializer different to {{UUIDType}}
> serializer (see
> https://the-asf.slack.com/archives/CK23JSY2K/p1712060572432959)
> - fixed a problem with DCT builder - in 5.0+ the {{DynamicCompositeType}}
> generation has a problem with inverse alias-type mapping which makes it
> vulnerable to problems when the same type has two different aliases
--
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-19552) Nodetool to get/set guardrails configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-19552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836085#comment-17836085 ] Stefan Miklosovic commented on CASSANDRA-19552: --- I created CASSANDRA-19553 for vtable approach. > Nodetool to get/set guardrails configurations > - > > Key: CASSANDRA-19552 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19552 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 4.1.x > > > Currently guardrails are only configurable through JMX / cassandra.yaml > This provides a nodetool command to interact with all the getters/setters for > guardrails. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3243] > trunk PR: [https://github.com/apache/cassandra/pull/3244] -- 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-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19553:
--
Description:
In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool and
via reflection.
I think that it will be better if we do that via CQL.
So far, I have this:
{code}
cqlsh> select * from system_views.guardrails_threshold ;
name | fail | warn
---+---+---
collection_size | 0 | 0
column_value_size |-1 |-1
columns_per_table |-1 |-1
fields_per_udt |-1 |-1
in_select_cartesian_product |-1 |-1
items_per_collection |-1 |-1
keyspaces |-1 |-1
materialized_views_per_table |-1 |-1
maximum_replication_factor |-1 |-1
maximum_timestamp | 0 | 0
minimum_replication_factor |-1 |-1
minimum_timestamp | 0 | 0
page_size |-1 |-1
partition_keys_in_select |-1 |-1
partition_size | 40960 | 20480
partition_tombstones |-1 |-1
sai_sstable_indexes_per_query |-1 |32
secondary_indexes_per_table |-1 |-1
tables |-1 |-1
vector_dimensions |-1 |-1
{code}
{code}
cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20 where
name = 'sai_sstable_indexes_per_query';
{code}
{code}
cqlsh> select * from system_views.guardrails_threshold where name =
'sai_sstable_indexes_per_query';
name | fail | warn
---+--+--
sai_sstable_indexes_per_query | 20 | 16
{code}
{code}
INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
GuardrailsOptions.java:998 - Updated
sai_sstable_indexes_per_query_warn_threshold from 32 to 16
INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
GuardrailsOptions.java:998 - Updated
sai_sstable_indexes_per_query_fail_threshold from -1 to 20
{code}
{code}
cqlsh> update system_views.guardrails_threshold SET warn = 10, fail = 5 where
name = 'sai_sstable_indexes_per_query';
InvalidRequest: Error from server: code=2200 [Invalid query] message="The warn
threshold 10 for sai_sstable_indexes_per_query_warn_threshold should be lower
than the fail threshold 5"
{code}
We can easily extend this to EnableFlag guardrails for which we would dedicate
a separate table (system_views.guadrails_flag).
Other guardrail types are being investigated.
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name = 'sai_sstable_indexes_per_query';
> {code}
> {code}
> cqlsh> select * from system_views.guardrails_threshold where name =
> 'sai_sstable_indexes_per_query';
> name | fail | warn
> ---+--+--
> sai_sstable_indexes_per_query | 20 | 16
> {code}
> {code}
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
>
[jira] [Updated] (CASSANDRA-19517) Raise priority of TCM internode messages during critical operations
[
https://issues.apache.org/jira/browse/CASSANDRA-19517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-19517:
Test and Documentation Plan: Includes tests. Additional stress testing will
be done during release qualification.
Status: Patch Available (was: Open)
> Raise priority of TCM internode messages during critical operations
> ---
>
> Key: CASSANDRA-19517
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19517
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> In a busy cluster, TCM messages may not get propagated throughout the
> cluster, since they will be ordered together with other P1 messages (for
> {{TCM_}} prefixed verbs), and with P2 with all Paxos operations.
> To avoid this, and make sure we can continue cluster metadata changes, all
> {{TCM_}}-prefixed verbs should have {{P0}} priority, just like Gossip
> messages used to. All Paxos messages that involve distributed metadata
> keyspace should now get an {{URGENT}} flag, which will instruct internode
> messaging to schedule them on the {{URGENT_MESSAGES}} connection.
--
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-19517) Raise priority of TCM internode messages during critical operations
[
https://issues.apache.org/jira/browse/CASSANDRA-19517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-19517:
Attachment: result_details.tar.gz
> Raise priority of TCM internode messages during critical operations
> ---
>
> Key: CASSANDRA-19517
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19517
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> In a busy cluster, TCM messages may not get propagated throughout the
> cluster, since they will be ordered together with other P1 messages (for
> {{TCM_}} prefixed verbs), and with P2 with all Paxos operations.
> To avoid this, and make sure we can continue cluster metadata changes, all
> {{TCM_}}-prefixed verbs should have {{P0}} priority, just like Gossip
> messages used to. All Paxos messages that involve distributed metadata
> keyspace should now get an {{URGENT}} flag, which will instruct internode
> messaging to schedule them on the {{URGENT_MESSAGES}} connection.
--
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-19517) Raise priority of TCM internode messages during critical operations
[
https://issues.apache.org/jira/browse/CASSANDRA-19517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-19517:
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Raise priority of TCM internode messages during critical operations
> ---
>
> Key: CASSANDRA-19517
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19517
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> In a busy cluster, TCM messages may not get propagated throughout the
> cluster, since they will be ordered together with other P1 messages (for
> {{TCM_}} prefixed verbs), and with P2 with all Paxos operations.
> To avoid this, and make sure we can continue cluster metadata changes, all
> {{TCM_}}-prefixed verbs should have {{P0}} priority, just like Gossip
> messages used to. All Paxos messages that involve distributed metadata
> keyspace should now get an {{URGENT}} flag, which will instruct internode
> messaging to schedule them on the {{URGENT_MESSAGES}} connection.
--
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-19517) Raise priority of TCM internode messages during critical operations
[
https://issues.apache.org/jira/browse/CASSANDRA-19517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-19517:
Description:
In a busy cluster, TCM messages may not get propagated throughout the cluster,
since they will be ordered together with other P1 messages (for {{TCM_}}
prefixed verbs), and with P2 with all Paxos operations.
To avoid this, and make sure we can continue cluster metadata changes, all
{{TCM_}}-prefixed verbs should have {{P0}} priority, just like Gossip messages
used to. All Paxos messages that involve distributed metadata keyspace should
now get an {{URGENT}} flag, which will instruct internode messaging to schedule
them on the {{URGENT_MESSAGES}} connection.
was:Hopefully, title says it all: it is important to make sure that TCM
internode messages do not get stuck behind read/write workload, especially in
clusters that have heavy load.
> Raise priority of TCM internode messages during critical operations
> ---
>
> Key: CASSANDRA-19517
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19517
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> In a busy cluster, TCM messages may not get propagated throughout the
> cluster, since they will be ordered together with other P1 messages (for
> {{TCM_}} prefixed verbs), and with P2 with all Paxos operations.
> To avoid this, and make sure we can continue cluster metadata changes, all
> {{TCM_}}-prefixed verbs should have {{P0}} priority, just like Gossip
> messages used to. All Paxos messages that involve distributed metadata
> keyspace should now get an {{URGENT}} flag, which will instruct internode
> messaging to schedule them on the {{URGENT_MESSAGES}} connection.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19553) get/set guardrails configuration via CQL
Stefan Miklosovic created CASSANDRA-19553: - Summary: get/set guardrails configuration via CQL Key: CASSANDRA-19553 URL: https://issues.apache.org/jira/browse/CASSANDRA-19553 Project: Cassandra Issue Type: New Feature Reporter: Stefan Miklosovic Assignee: Stefan Miklosovic -- 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
