[jira] [Updated] (CASSANDRA-19477) Do not go to disk to get HintsStore.getTotalFileSize
[
https://issues.apache.org/jira/browse/CASSANDRA-19477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-19477:
--
Status: Ready to Commit (was: Review In Progress)
+1, good stuff
> Do not go to disk to get HintsStore.getTotalFileSize
>
>
> Key: CASSANDRA-19477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19477
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Attachments: flame-cassandra0-patched-2024-03-25_00-40-47.html,
> flame-cassandra0-release-2024-03-25_00-16-44.html, flamegraph.cpu.html,
> image-2024-03-24-17-57-32-560.png, image-2024-03-24-18-08-36-918.png,
> image-2024-03-24-18-16-50-370.png, image-2024-03-24-18-17-48-334.png,
> image-2024-03-24-18-20-07-734.png
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> When testing a cluster with more requests than it could handle, I noticed
> significant CPU time (25%) spent in HintsStore.getTotalFileSize. Here's what
> I'm seeing from profiling:
> 10% of CPU time spent in HintsDescriptor.fileName which only does this:
>
> {noformat}
> return String.format("%s-%s-%s.hints", hostId, timestamp, version);{noformat}
> At a bare minimum here we should create this string up front with the host
> and version and eliminate 2 of the 3 substitutions, but I think it's probably
> faster to use a StringBuilder and avoid the underlying regular expression
> altogether.
> 12% of the time is spent in org.apache.cassandra.io.util.File.length. It
> looks like this is called once for each hint file on disk for each host we're
> hinting to. In the case of an overloaded cluster, this is significant. It
> would be better if we were to track the file size in memory for each hint
> file and reference that rather than go to the filesystem.
> These fairly small changes should make Cassandra more reliable when under
> load spikes.
> CPU Flame graph attached.
> I only tested this in 4.1 but it looks like this is present up to trunk.
>
--
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-19477) Do not go to disk to get HintsStore.getTotalFileSize
[
https://issues.apache.org/jira/browse/CASSANDRA-19477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-19477:
--
Status: Patch Available (was: Needs Committer)
> Do not go to disk to get HintsStore.getTotalFileSize
>
>
> Key: CASSANDRA-19477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19477
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Attachments: flame-cassandra0-patched-2024-03-25_00-40-47.html,
> flame-cassandra0-release-2024-03-25_00-16-44.html, flamegraph.cpu.html,
> image-2024-03-24-17-57-32-560.png, image-2024-03-24-18-08-36-918.png,
> image-2024-03-24-18-16-50-370.png, image-2024-03-24-18-17-48-334.png,
> image-2024-03-24-18-20-07-734.png
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> When testing a cluster with more requests than it could handle, I noticed
> significant CPU time (25%) spent in HintsStore.getTotalFileSize. Here's what
> I'm seeing from profiling:
> 10% of CPU time spent in HintsDescriptor.fileName which only does this:
>
> {noformat}
> return String.format("%s-%s-%s.hints", hostId, timestamp, version);{noformat}
> At a bare minimum here we should create this string up front with the host
> and version and eliminate 2 of the 3 substitutions, but I think it's probably
> faster to use a StringBuilder and avoid the underlying regular expression
> altogether.
> 12% of the time is spent in org.apache.cassandra.io.util.File.length. It
> looks like this is called once for each hint file on disk for each host we're
> hinting to. In the case of an overloaded cluster, this is significant. It
> would be better if we were to track the file size in memory for each hint
> file and reference that rather than go to the filesystem.
> These fairly small changes should make Cassandra more reliable when under
> load spikes.
> CPU Flame graph attached.
> I only tested this in 4.1 but it looks like this is present up to trunk.
>
--
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-19477) Do not go to disk to get HintsStore.getTotalFileSize
[
https://issues.apache.org/jira/browse/CASSANDRA-19477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-19477:
--
Reviewers: Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko)
Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko)
Status: Review In Progress (was: Patch Available)
> Do not go to disk to get HintsStore.getTotalFileSize
>
>
> Key: CASSANDRA-19477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19477
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Attachments: flame-cassandra0-patched-2024-03-25_00-40-47.html,
> flame-cassandra0-release-2024-03-25_00-16-44.html, flamegraph.cpu.html,
> image-2024-03-24-17-57-32-560.png, image-2024-03-24-18-08-36-918.png,
> image-2024-03-24-18-16-50-370.png, image-2024-03-24-18-17-48-334.png,
> image-2024-03-24-18-20-07-734.png
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> When testing a cluster with more requests than it could handle, I noticed
> significant CPU time (25%) spent in HintsStore.getTotalFileSize. Here's what
> I'm seeing from profiling:
> 10% of CPU time spent in HintsDescriptor.fileName which only does this:
>
> {noformat}
> return String.format("%s-%s-%s.hints", hostId, timestamp, version);{noformat}
> At a bare minimum here we should create this string up front with the host
> and version and eliminate 2 of the 3 substitutions, but I think it's probably
> faster to use a StringBuilder and avoid the underlying regular expression
> altogether.
> 12% of the time is spent in org.apache.cassandra.io.util.File.length. It
> looks like this is called once for each hint file on disk for each host we're
> hinting to. In the case of an overloaded cluster, this is significant. It
> would be better if we were to track the file size in memory for each hint
> file and reference that rather than go to the filesystem.
> These fairly small changes should make Cassandra more reliable when under
> load spikes.
> CPU Flame graph attached.
> I only tested this in 4.1 but it looks like this is present up to trunk.
>
--
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-19477) Do not go to disk to get HintsStore.getTotalFileSize
[
https://issues.apache.org/jira/browse/CASSANDRA-19477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-19477:
--
Reviewers: Aleksey Yeschenko
> Do not go to disk to get HintsStore.getTotalFileSize
>
>
> Key: CASSANDRA-19477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19477
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Attachments: flamegraph.cpu.html
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When testing a cluster with more requests than it could handle, I noticed
> significant CPU time (25%) spent in HintsStore.getTotalFileSize. Here's what
> I'm seeing from profiling:
> 10% of CPU time spent in HintsDescriptor.fileName which only does this:
>
> {noformat}
> return String.format("%s-%s-%s.hints", hostId, timestamp, version);{noformat}
> At a bare minimum here we should create this string up front with the host
> and version and eliminate 2 of the 3 substitutions, but I think it's probably
> faster to use a StringBuilder and avoid the underlying regular expression
> altogether.
> 12% of the time is spent in org.apache.cassandra.io.util.File.length. It
> looks like this is called once for each hint file on disk for each host we're
> hinting to. In the case of an overloaded cluster, this is significant. It
> would be better if we were to track the file size in memory for each hint
> file and reference that rather than go to the filesystem.
> These fairly small changes should make Cassandra more reliable when under
> load spikes.
> CPU Flame graph attached.
> I only tested this in 4.1 but it looks like this is present up to trunk.
>
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809361#comment-17809361
]
Aleksey Yeschenko commented on CASSANDRA-14572:
---
It should be implemented in a way that regular polling is not a problem - no
more than periodic polling of an equivalent regular table read.
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, select keyspaces_group by string prefix.png, select
> keyspaces_group compare with wo.png, select keyspaces_group without
> value.png, systemv_views.metrics_dropped_message.png, thread_pools
> benchmark.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-19265) Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal but this may fail during CommitLogReplay for LocalPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-19265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-19265:
--
Fix Version/s: 5.1
(was: 5.x)
Since Version: 5.1-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/91e8a22d63683e46d26c7d9a25df3b3d80eba500
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal
> but this may fail during CommitLogReplay for LocalPartitioner
> --
>
> Key: CASSANDRA-19265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19265
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.1
>
>
> This was found on the cep-15-accord branch. We have a system table
> all_commands_for_key and it seems that the LocalPartitioner pointer gets
> changed, causing CommitLogReplyer to fail
> {code}
> java.lang.AssertionError: Update to key
> DecoratedKey(11:01c93b4893674349ae:2b74bbca-eae8-3217-a675-115cf5642ef3\:3030312e302e393134,
>
> 0004000b0901c93b4893674349ae2100102b74bbcaeae83217a675115cf5642ef300093030312e302e39313400)
> with partitioner org.apache.cassandra.dht.LocalPartitioner@1fc4de9e (class
> org.apache.cassandra.dht.LocalPartitioner) had an update
> ([system_accord.all_commands_for_key]...) with a different partitioner!
> org.apache.cassandra.dht.LocalPartitioner@c7d8be7 (class
> org.apache.cassandra.dht.LocalPartitioner)
> at org.apache.cassandra.utils.Throwables.unchecked(Throwables.java:308)
> at org.apache.cassandra.utils.Throwables.cleaned(Throwables.java:327)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:544)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleMutation(CommitLogReplayer.java:521)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:478)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:397)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:244)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:147)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:195)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:225)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:206)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:332)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:726)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {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-19265) Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal but this may fail during CommitLogReplay for LocalPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-19265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-19265:
--
Reviewers: Marcus Eriksson (was: Aleksey Yeschenko, Marcus Eriksson)
> Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal
> but this may fail during CommitLogReplay for LocalPartitioner
> --
>
> Key: CASSANDRA-19265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19265
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.1
>
>
> This was found on the cep-15-accord branch. We have a system table
> all_commands_for_key and it seems that the LocalPartitioner pointer gets
> changed, causing CommitLogReplyer to fail
> {code}
> java.lang.AssertionError: Update to key
> DecoratedKey(11:01c93b4893674349ae:2b74bbca-eae8-3217-a675-115cf5642ef3\:3030312e302e393134,
>
> 0004000b0901c93b4893674349ae2100102b74bbcaeae83217a675115cf5642ef300093030312e302e39313400)
> with partitioner org.apache.cassandra.dht.LocalPartitioner@1fc4de9e (class
> org.apache.cassandra.dht.LocalPartitioner) had an update
> ([system_accord.all_commands_for_key]...) with a different partitioner!
> org.apache.cassandra.dht.LocalPartitioner@c7d8be7 (class
> org.apache.cassandra.dht.LocalPartitioner)
> at org.apache.cassandra.utils.Throwables.unchecked(Throwables.java:308)
> at org.apache.cassandra.utils.Throwables.cleaned(Throwables.java:327)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:544)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleMutation(CommitLogReplayer.java:521)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:478)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:397)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:244)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:147)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:195)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:225)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:206)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:332)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:726)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {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-19265) Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal but this may fail during CommitLogReplay for LocalPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-19265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-19265:
--
Reviewers: Marcus Eriksson, Aleksey Yeschenko (was: Marcus Eriksson)
Marcus Eriksson, Aleksey Yeschenko (was: Aleksey Yeschenko,
Marcus Eriksson)
Status: Review In Progress (was: Patch Available)
> Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal
> but this may fail during CommitLogReplay for LocalPartitioner
> --
>
> Key: CASSANDRA-19265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19265
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.x
>
>
> This was found on the cep-15-accord branch. We have a system table
> all_commands_for_key and it seems that the LocalPartitioner pointer gets
> changed, causing CommitLogReplyer to fail
> {code}
> java.lang.AssertionError: Update to key
> DecoratedKey(11:01c93b4893674349ae:2b74bbca-eae8-3217-a675-115cf5642ef3\:3030312e302e393134,
>
> 0004000b0901c93b4893674349ae2100102b74bbcaeae83217a675115cf5642ef300093030312e302e39313400)
> with partitioner org.apache.cassandra.dht.LocalPartitioner@1fc4de9e (class
> org.apache.cassandra.dht.LocalPartitioner) had an update
> ([system_accord.all_commands_for_key]...) with a different partitioner!
> org.apache.cassandra.dht.LocalPartitioner@c7d8be7 (class
> org.apache.cassandra.dht.LocalPartitioner)
> at org.apache.cassandra.utils.Throwables.unchecked(Throwables.java:308)
> at org.apache.cassandra.utils.Throwables.cleaned(Throwables.java:327)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:544)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleMutation(CommitLogReplayer.java:521)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:478)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:397)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:244)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:147)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:195)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:225)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:206)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:332)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:726)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {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-19265) Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal but this may fail during CommitLogReplay for LocalPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-19265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-19265:
--
Reviewers: Marcus Eriksson
> Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal
> but this may fail during CommitLogReplay for LocalPartitioner
> --
>
> Key: CASSANDRA-19265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19265
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: David Capwell
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.x
>
>
> This was found on the cep-15-accord branch. We have a system table
> all_commands_for_key and it seems that the LocalPartitioner pointer gets
> changed, causing CommitLogReplyer to fail
> {code}
> java.lang.AssertionError: Update to key
> DecoratedKey(11:01c93b4893674349ae:2b74bbca-eae8-3217-a675-115cf5642ef3\:3030312e302e393134,
>
> 0004000b0901c93b4893674349ae2100102b74bbcaeae83217a675115cf5642ef300093030312e302e39313400)
> with partitioner org.apache.cassandra.dht.LocalPartitioner@1fc4de9e (class
> org.apache.cassandra.dht.LocalPartitioner) had an update
> ([system_accord.all_commands_for_key]...) with a different partitioner!
> org.apache.cassandra.dht.LocalPartitioner@c7d8be7 (class
> org.apache.cassandra.dht.LocalPartitioner)
> at org.apache.cassandra.utils.Throwables.unchecked(Throwables.java:308)
> at org.apache.cassandra.utils.Throwables.cleaned(Throwables.java:327)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:544)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleMutation(CommitLogReplayer.java:521)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:478)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:397)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:244)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:147)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:195)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:225)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:206)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:332)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:726)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {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-19265) Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal but this may fail during CommitLogReplay for LocalPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-19265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-19265:
--
Test and Documentation Plan: N/A
Status: Patch Available (was: Open)
> Mutation.PartitionUpdateCollector#add asserts Partitioner pointers are equal
> but this may fail during CommitLogReplay for LocalPartitioner
> --
>
> Key: CASSANDRA-19265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19265
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: David Capwell
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.x
>
>
> This was found on the cep-15-accord branch. We have a system table
> all_commands_for_key and it seems that the LocalPartitioner pointer gets
> changed, causing CommitLogReplyer to fail
> {code}
> java.lang.AssertionError: Update to key
> DecoratedKey(11:01c93b4893674349ae:2b74bbca-eae8-3217-a675-115cf5642ef3\:3030312e302e393134,
>
> 0004000b0901c93b4893674349ae2100102b74bbcaeae83217a675115cf5642ef300093030312e302e39313400)
> with partitioner org.apache.cassandra.dht.LocalPartitioner@1fc4de9e (class
> org.apache.cassandra.dht.LocalPartitioner) had an update
> ([system_accord.all_commands_for_key]...) with a different partitioner!
> org.apache.cassandra.dht.LocalPartitioner@c7d8be7 (class
> org.apache.cassandra.dht.LocalPartitioner)
> at org.apache.cassandra.utils.Throwables.unchecked(Throwables.java:308)
> at org.apache.cassandra.utils.Throwables.cleaned(Throwables.java:327)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:544)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleMutation(CommitLogReplayer.java:521)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:478)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:397)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:244)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:147)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:195)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:225)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:206)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:332)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:726)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783192#comment-17783192 ] Aleksey Yeschenko commented on CASSANDRA-7662: -- This was never intended to copy and data. Only copying the structure (metadata) of the original table - params, columns, indexes. > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Labels: AdventCalendar2021, lhf > Fix For: 5.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- 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-18314) Lift MessagingService.minimum_version to 40
[
https://issues.apache.org/jira/browse/CASSANDRA-18314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782118#comment-17782118
]
Aleksey Yeschenko commented on CASSANDRA-18314:
---
I think you may have been overly enthusiastic with these removals.
Specifically, removing 3.0 deser support for {{Mutation}} affects more than
just messaging service. Even in 5.0 you still need to be able to deserialize
old mutations in hints, commit log, and batch log. Someone going from 3.0 via
4.0 to 5.0 will still have those present.
> Lift MessagingService.minimum_version to 40
> ---
>
> Key: CASSANDRA-18314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18314
> Project: Cassandra
> Issue Type: Task
> Components: Messaging/Internode
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0, 5.0-alpha1
>
> Time Spent: 15h 20m
> Remaining Estimate: 0h
>
> MessagingService's VERSION_30 and VERSION_3014 don't have to be supported in
> Cassandra 5.0 anymore.
> (Cassandra 5.0 currently is still using VERSION_40)
> Patch:
> https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/18314/trunk
> Raises the question whether backward compatibility to the previous major is
> defined by the Cassandra version or by the internal component version
> (MessagingService).
--
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-18964) Vector type in UDTs can break schema loading
[
https://issues.apache.org/jira/browse/CASSANDRA-18964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18964:
--
Fix Version/s: 5.0-alpha2
(was: 5.0)
Since Version: 5.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/7d54a62ccc27f89bb6ee55b8f17005cf4c444231
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed to 5.0 and trunk, cheers.
> Vector type in UDTs can break schema loading
> -
>
> Key: CASSANDRA-18964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18964
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0-alpha2
>
>
> {{RawVector}} doesn’t override {{referencesUserType(String name)}}, which
> causes {{Types.RawBuilder.build()}} to not populate UDT dependency DAG
> correctly. Then depending on natural iteration order or the vertices map, a
> UDT with a vector referencing another UDT can fail to resolve, if that
> referenced UDT has not been resolved.
--
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-18964) Vector type in UDTs can break schema loading
[
https://issues.apache.org/jira/browse/CASSANDRA-18964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18964:
--
Status: Ready to Commit (was: Review In Progress)
> Vector type in UDTs can break schema loading
> -
>
> Key: CASSANDRA-18964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18964
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> {{RawVector}} doesn’t override {{referencesUserType(String name)}}, which
> causes {{Types.RawBuilder.build()}} to not populate UDT dependency DAG
> correctly. Then depending on natural iteration order or the vertices map, a
> UDT with a vector referencing another UDT can fail to resolve, if that
> referenced UDT has not been resolved.
--
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-18964) Vector type in UDTs can break schema loading
[
https://issues.apache.org/jira/browse/CASSANDRA-18964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18964:
--
Reviewers: Marcus Eriksson, Aleksey Yeschenko (was: Marcus Eriksson)
Marcus Eriksson, Aleksey Yeschenko (was: Aleksey Yeschenko,
Marcus Eriksson)
Status: Review In Progress (was: Patch Available)
> Vector type in UDTs can break schema loading
> -
>
> Key: CASSANDRA-18964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18964
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> {{RawVector}} doesn’t override {{referencesUserType(String name)}}, which
> causes {{Types.RawBuilder.build()}} to not populate UDT dependency DAG
> correctly. Then depending on natural iteration order or the vertices map, a
> UDT with a vector referencing another UDT can fail to resolve, if that
> referenced UDT has not been resolved.
--
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-18964) Vector type in UDTs can break schema loading
[
https://issues.apache.org/jira/browse/CASSANDRA-18964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18964:
--
Test and Documentation Plan: Existing test coverage
Status: Patch Available (was: Open)
> Vector type in UDTs can break schema loading
> -
>
> Key: CASSANDRA-18964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18964
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> {{RawVector}} doesn’t override {{referencesUserType(String name)}}, which
> causes {{Types.RawBuilder.build()}} to not populate UDT dependency DAG
> correctly. Then depending on natural iteration order or the vertices map, a
> UDT with a vector referencing another UDT can fail to resolve, if that
> referenced UDT has not been resolved.
--
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-18964) Vector type in UDTs can break schema loading
[
https://issues.apache.org/jira/browse/CASSANDRA-18964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18964:
--
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Complexity: Normal
Component/s: Cluster/Schema
Discovered By: Fuzz Test
Fix Version/s: 5.0
Reviewers: Marcus Eriksson
Severity: Normal
Status: Open (was: Triage Needed)
> Vector type in UDTs can break schema loading
> -
>
> Key: CASSANDRA-18964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18964
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> {{RawVector}} doesn’t override {{referencesUserType(String name)}}, which
> causes {{Types.RawBuilder.build()}} to not populate UDT dependency DAG
> correctly. Then depending on natural iteration order or the vertices map, a
> UDT with a vector referencing another UDT can fail to resolve, if that
> referenced UDT has not been resolved.
--
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-18964) Vector type in UDTs can break schema loading
Aleksey Yeschenko created CASSANDRA-18964:
-
Summary: Vector type in UDTs can break schema loading
Key: CASSANDRA-18964
URL: https://issues.apache.org/jira/browse/CASSANDRA-18964
Project: Cassandra
Issue Type: Bug
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
{{RawVector}} doesn’t override {{referencesUserType(String name)}}, which
causes {{Types.RawBuilder.build()}} to not populate UDT dependency DAG
correctly. Then depending on natural iteration order or the vertices map, a
UDT with a vector referencing another UDT can fail to resolve, if that
referenced UDT has not been resolved.
--
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-13911) IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT queries
[
https://issues.apache.org/jira/browse/CASSANDRA-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776585#comment-17776585
]
Aleksey Yeschenko commented on CASSANDRA-13911:
---
Indeed, if hidden is the right word for it. This was a pretty nasty one.
> IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT
> queries
>
>
> Key: CASSANDRA-13911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13911
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 3.0.15, 3.11.1
>
>
> Certain combinations of rows, in presence of per partition limit (set
> explicitly in 3.6+ or implicitly to 1 via DISTINCT) cause
> {{UnfilteredPartitionIterators.Serializer.hasNext()}} to throw
> {{IllegalStateException}} .
> Relevant code snippet:
> {code}
> // We can't answer this until the previously returned iterator has been fully
> consumed,
> // so complain if that's not the case.
> if (next != null && next.hasNext())
> throw new IllegalStateException("Cannot call hasNext() until the previous
> iterator has been fully consumed");
> {code}
> Since {{UnfilteredPartitionIterators.Serializer}} and
> {{UnfilteredRowIteratorSerializer.serializer}} deserialize partitions/rows
> lazily, it is required for correct operation of the partition iterator to
> have the previous partition fully consumed, so that deserializing the next
> one can start from the correct position in the byte buffer. However, that
> condition won’t always be satisfied, as there are legitimate combinations of
> rows that do not consume every row in every partition.
> For example, look at [this
> dtest|https://github.com/iamaleksey/cassandra-dtest/commits/13911].
> In case we end up with a following pattern of rows:
> {code}
> node1, partition 0 | 0
> node2, partition 0 | x x
> {code}
> , where {{x}} and {{x}} a row tombstones for rows 1 and 2, it’s sufficient
> for {{MergeIterator}} to only look at row 0 in partition from node1 and at
> row tombstone 1 from node2 to satisfy the per partition limit of 1. The
> stopping merge result counter will stop iteration right there, leaving row
> tombstone 2 from node2 unvisited and not deseiralized. Switching to the next
> partition will in turn trigger the {{IllegalStateException}} because we
> aren’t done yet.
> The stopping counter is behaving correctly, so is the {{MergeIterator}}. I’ll
> note that simply removing that condition is not enough to fix the problem
> properly - it’d just cause us to deseiralize garbage, trying to deserialize a
> new partition from a position in the bytebuffer that precedes remaining rows
> in the previous partition.
--
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-18928) Simplify handling of Insufficient replies from Commit and Apply
[ https://issues.apache.org/jira/browse/CASSANDRA-18928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18928: -- Fix Version/s: 5.0 Source Control Link: https://github.com/apache/cassandra-accord/commit/1e508d340935fef496f58606a14717bed59e8af4 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Simplify handling of Insufficient replies from Commit and Apply > --- > > Key: CASSANDRA-18928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18928 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.0 > > > Remove the use of Defer for Commit, and reply with Maximal Apply to > Insufficient Apply responses -- 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-18928) Simplify handling of Insufficient replies from Commit and Apply
[ https://issues.apache.org/jira/browse/CASSANDRA-18928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18928: -- Status: Ready to Commit (was: Review In Progress) > Simplify handling of Insufficient replies from Commit and Apply > --- > > Key: CASSANDRA-18928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18928 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Remove the use of Defer for Commit, and reply with Maximal Apply to > Insufficient Apply responses -- 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-18928) Simplify handling of Insufficient replies from Commit and Apply
[ https://issues.apache.org/jira/browse/CASSANDRA-18928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18928: -- Test and Documentation Plan: Existing test coverage Status: Patch Available (was: Open) PR: https://github.com/apache/cassandra-accord/pull/71 > Simplify handling of Insufficient replies from Commit and Apply > --- > > Key: CASSANDRA-18928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18928 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Remove the use of Defer for Commit, and reply with Maximal Apply to > Insufficient Apply responses -- 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-18928) Simplify handling of Insufficient replies from Commit and Apply
[ https://issues.apache.org/jira/browse/CASSANDRA-18928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18928: -- Change Category: Code Clarity Complexity: Normal Reviewers: Benedict Elliott Smith Status: Open (was: Triage Needed) > Simplify handling of Insufficient replies from Commit and Apply > --- > > Key: CASSANDRA-18928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18928 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Remove the use of Defer for Commit, and reply with Maximal Apply to > Insufficient Apply responses -- 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-18928) Simplify handling of Insufficient replies from Commit and Apply
Aleksey Yeschenko created CASSANDRA-18928: - Summary: Simplify handling of Insufficient replies from Commit and Apply Key: CASSANDRA-18928 URL: https://issues.apache.org/jira/browse/CASSANDRA-18928 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Remove the use of Defer for Commit, and reply with Maximal Apply to Insufficient Apply responses -- 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-18573) Minimise state kept in accord system tables by reusing state from message log
[ https://issues.apache.org/jira/browse/CASSANDRA-18573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18573: -- Resolution: Fixed Status: Resolved (was: Open) > Minimise state kept in accord system tables by reusing state from message log > - > > Key: CASSANDRA-18573 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18573 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Stop storing deps, partial txn, and writes in accord system table - fetch > these registers from the message log instead. -- 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-18573) Minimise state kept in accord system tables by reusing state from message log
[ https://issues.apache.org/jira/browse/CASSANDRA-18573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769617#comment-17769617 ] Aleksey Yeschenko edited comment on CASSANDRA-18573 at 10/4/23 10:36 AM: - cassandra-accord PR (reviewed and merged): https://github.com/apache/cassandra-accord/pull/62 cassandra commit: https://github.com/apache/cassandra/commit/1be9ad2a2e69193f7dcaa20351f20fb4ee4981e6 was (Author: iamaleksey): cassandra-accord PR (reviewed and merged): https://github.com/apache/cassandra-accord/pull/62 cassandra PR: pending some dependency merges > Minimise state kept in accord system tables by reusing state from message log > - > > Key: CASSANDRA-18573 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18573 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Stop storing deps, partial txn, and writes in accord system table - fetch > these registers from the message log instead. -- 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-18888) Implement CommandStore state reloading on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-1: -- Component/s: Accord > Implement CommandStore state reloading on startup > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Implement CommandStore state reloading on startup. Selectively replay message > log to restore any missing rows in accord system tables that hadn't made it > to disk due to abnormal node termination, and rehydrate the progress log. -- 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-18888) Implement CommandStore state reloading on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-1: -- Change Category: Semantic Complexity: Normal Status: Open (was: Triage Needed) > Implement CommandStore state reloading on startup > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Implement CommandStore state reloading on startup. Selectively replay message > log to restore any missing rows in accord system tables that hadn't made it > to disk due to abnormal node termination, and rehydrate the progress log. -- 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-18888) Implement CommandStore state reloading on startup
Aleksey Yeschenko created CASSANDRA-1: - Summary: Implement CommandStore state reloading on startup Key: CASSANDRA-1 URL: https://issues.apache.org/jira/browse/CASSANDRA-1 Project: Cassandra Issue Type: New Feature Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Implement CommandStore state reloading on startup. Selectively replay message log to restore any missing rows in accord system tables that hadn't made it to disk due to abnormal node termination, and rehydrate the progress log. -- 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-18573) Minimise state kept in accord system tables by reusing state from message log
[ https://issues.apache.org/jira/browse/CASSANDRA-18573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769617#comment-17769617 ] Aleksey Yeschenko commented on CASSANDRA-18573: --- cassandra-accord PR (reviewed and merged): https://github.com/apache/cassandra-accord/pull/62 cassandra PR: pending some dependency merges > Minimise state kept in accord system tables by reusing state from message log > - > > Key: CASSANDRA-18573 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18573 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Stop storing deps, partial txn, and writes in accord system table - fetch > these registers from the message log instead. -- 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-18573) Minimise state kept in accord system tables by reusing state from message log
[ https://issues.apache.org/jira/browse/CASSANDRA-18573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18573: -- Description: Stop storing deps, partial txn, and writes in accord system table - fetch these registers from the message log instead. > Minimise state kept in accord system tables by reusing state from message log > - > > Key: CASSANDRA-18573 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18573 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Stop storing deps, partial txn, and writes in accord system table - fetch > these registers from the message log instead. -- 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-18573) Minimise state kept in accord system tables by reusing state from message log
[ https://issues.apache.org/jira/browse/CASSANDRA-18573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18573: -- Summary: Minimise state kept in accord system tables by reusing state from message log (was: TBD) > Minimise state kept in accord system tables by reusing state from message log > - > > Key: CASSANDRA-18573 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18573 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18573) TBD
[ https://issues.apache.org/jira/browse/CASSANDRA-18573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18573: -- Change Category: Performance Complexity: Normal Reviewers: Ariel Weisberg Assignee: Aleksey Yeschenko Status: Open (was: Triage Needed) > TBD > --- > > Key: CASSANDRA-18573 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18573 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8303) Create a capability limitation framework
[ https://issues.apache.org/jira/browse/CASSANDRA-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756841#comment-17756841 ] Aleksey Yeschenko commented on CASSANDRA-8303: -- This was supposed to be per-role. Guardrails affecting entire nodes. > Create a capability limitation framework > > > Key: CASSANDRA-8303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8303 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Anupam Arora >Priority: Normal > Fix For: 5.x > > > In addition to our current Auth framework that acts as a white list, and > regulates access to data, functions, and roles, it would be beneficial to > have a different, capability limitation framework, that would be orthogonal > to Auth, and would act as a blacklist. > Example uses: > - take away the ability to TRUNCATE from all users but the admin (TRUNCATE > itself would still require MODIFY permission) > - take away the ability to use ALLOW FILTERING from all users but > Spark/Hadoop (SELECT would still require SELECT permission) > - take away the ability to use UNLOGGED BATCH from everyone (the operation > itself would still require MODIFY permission) > - take away the ability to use certain consistency levels (make certain > tables LWT-only for all users, for example) > Original description: > Please provide a "strict mode" option in cassandra that will kick out any CQL > queries that are expensive, e.g. any query with ALLOWS FILTERING, > multi-partition queries, secondary index queries, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18563) Convert AccordStateCache cache from write-through to write-back
[
https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18563:
--
Source Control Link:
https://github.com/apache/cassandra/commit/bd33015f9310e15c7f7e6b3938f564dd20050466
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as [bd33015
|https://github.com/apache/cassandra/commit/bd33015f9310e15c7f7e6b3938f564dd20050466]
to cassandra only, cheers.
> Convert AccordStateCache cache from write-through to write-back
> ---
>
> Key: CASSANDRA-18563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18563
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> Pre-requisite work for soon to go up PRs that continue shifting the bulk of
> persistence from system tables to {{AccordJournal}}. The switch to write-back
> caching should allow to bypass writes to the system tables entirely for some
> of the transactions.
> Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to
> load an object could cause entries to be forever stuck in {{PENDING}} state
> because it would never reach the code path that submits the load runnables to
> the executor (that is now the job of the cache). Also switched the list
> implementation from a hand-rolled ad-hoc one to the pre-existing
> {{IntrusiveLinkedList}}, plus various simplifications and cleanup.
--
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-18563) Convert AccordStateCache cache from write-through to write-back
[
https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18563:
--
Status: Review In Progress (was: Patch Available)
> Convert AccordStateCache cache from write-through to write-back
> ---
>
> Key: CASSANDRA-18563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18563
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> Pre-requisite work for soon to go up PRs that continue shifting the bulk of
> persistence from system tables to {{AccordJournal}}. The switch to write-back
> caching should allow to bypass writes to the system tables entirely for some
> of the transactions.
> Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to
> load an object could cause entries to be forever stuck in {{PENDING}} state
> because it would never reach the code path that submits the load runnables to
> the executor (that is now the job of the cache). Also switched the list
> implementation from a hand-rolled ad-hoc one to the pre-existing
> {{IntrusiveLinkedList}}, plus various simplifications and cleanup.
--
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-18563) Convert AccordStateCache cache from write-through to write-back
[
https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18563:
--
Status: Ready to Commit (was: Review In Progress)
> Convert AccordStateCache cache from write-through to write-back
> ---
>
> Key: CASSANDRA-18563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18563
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> Pre-requisite work for soon to go up PRs that continue shifting the bulk of
> persistence from system tables to {{AccordJournal}}. The switch to write-back
> caching should allow to bypass writes to the system tables entirely for some
> of the transactions.
> Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to
> load an object could cause entries to be forever stuck in {{PENDING}} state
> because it would never reach the code path that submits the load runnables to
> the executor (that is now the job of the cache). Also switched the list
> implementation from a hand-rolled ad-hoc one to the pre-existing
> {{IntrusiveLinkedList}}, plus various simplifications and cleanup.
--
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-18563) Convert AccordStateCache cache from write-through to write-back
[
https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733169#comment-17733169
]
Aleksey Yeschenko commented on CASSANDRA-18563:
---
Accord PR with a change to {{IntrusiveLinkedList}}:
https://github.com/apache/cassandra-accord/pull/51
> Convert AccordStateCache cache from write-through to write-back
> ---
>
> Key: CASSANDRA-18563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18563
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> Pre-requisite work for soon to go up PRs that continue shifting the bulk of
> persistence from system tables to {{AccordJournal}}. The switch to write-back
> caching should allow to bypass writes to the system tables entirely for some
> of the transactions.
> Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to
> load an object could cause entries to be forever stuck in {{PENDING}} state
> because it would never reach the code path that submits the load runnables to
> the executor (that is now the job of the cache). Also switched the list
> implementation from a hand-rolled ad-hoc one to the pre-existing
> {{IntrusiveLinkedList}}, plus various simplifications and cleanup.
--
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-18573) TBD
Aleksey Yeschenko created CASSANDRA-18573: - Summary: TBD Key: CASSANDRA-18573 URL: https://issues.apache.org/jira/browse/CASSANDRA-18573 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Aleksey Yeschenko -- 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-18563) Convert AccordStateCache cache from write-through to write-back
[
https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18563:
--
Description:
Pre-requisite work for soon to go up PRs that continue shifting the bulk of
persistence from system tables to {{AccordJournal}}. The switch to write-back
caching should allow to bypass writes to the system tables entirely for some of
the transactions.
Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to load
an object could cause entries to be forever stuck in {{PENDING}} state because
it would never reach the code path that submits the load runnables to the
executor (that is now the job of the cache). Also switched the list
implementation from a hand-rolled ad-hoc one to the pre-existing
{{IntrusiveLinkedList}}, plus various simplifications and cleanup.
was:
Pre-requisite work for soon to go up PRs that continue shifting the bulk of
persistence from system tables to {{AccordJournal}}. The switch to write-back
caching should allow to bypass writes to the system tables entirely for some of
the transactions.
Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to load
an object could cause entries to be forever stuck in {{PENDING}} state because
it would never reach the code path that submits the load runnables to the
executor (that is now the job of the cache). Also switched the list
implementation from a hand-rolled adhoc one to the pre-existing
{{IntrusiveLinkedList}}, plus various simplifications and cleanup.
> Convert AccordStateCache cache from write-through to write-back
> ---
>
> Key: CASSANDRA-18563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18563
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> Pre-requisite work for soon to go up PRs that continue shifting the bulk of
> persistence from system tables to {{AccordJournal}}. The switch to write-back
> caching should allow to bypass writes to the system tables entirely for some
> of the transactions.
> Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to
> load an object could cause entries to be forever stuck in {{PENDING}} state
> because it would never reach the code path that submits the load runnables to
> the executor (that is now the job of the cache). Also switched the list
> implementation from a hand-rolled ad-hoc one to the pre-existing
> {{IntrusiveLinkedList}}, plus various simplifications and cleanup.
--
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-18563) Convert AccordStateCache cache from write-through to write-back
[
https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18563:
--
Description:
Pre-requisite work for soon to go up PRs that continue shifting the bulk of
persistence from system tables to {{AccordJournal}}. The switch to write-back
caching should allow to bypass writes to the system tables entirely for some of
the transactions.
Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to load
an object could cause entries to be forever stuck in {{PENDING}} state because
it would never reach the code path that submits the load runnables to the
executor (that is now the job of the cache). Also switched the list
implementation from a hand-rolled adhoc one to the pre-existing
{{IntrusiveLinkedList}}, plus various simplifications and cleanup.
> Convert AccordStateCache cache from write-through to write-back
> ---
>
> Key: CASSANDRA-18563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18563
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> Pre-requisite work for soon to go up PRs that continue shifting the bulk of
> persistence from system tables to {{AccordJournal}}. The switch to write-back
> caching should allow to bypass writes to the system tables entirely for some
> of the transactions.
> Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to
> load an object could cause entries to be forever stuck in {{PENDING}} state
> because it would never reach the code path that submits the load runnables to
> the executor (that is now the job of the cache). Also switched the list
> implementation from a hand-rolled adhoc one to the pre-existing
> {{IntrusiveLinkedList}}, plus various simplifications and cleanup.
--
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-18563) Convert AccordStateCache cache from write-through to write-back
[ https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730124#comment-17730124 ] Aleksey Yeschenko commented on CASSANDRA-18563: --- PR: [https://github.com/apache/cassandra/pull/2395] > Convert AccordStateCache cache from write-through to write-back > --- > > Key: CASSANDRA-18563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18563 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.0 > > -- 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-18563) Convert AccordStateCache cache from write-through to write-back
[ https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18563: -- Test and Documentation Plan: unit tests Status: Patch Available (was: Open) > Convert AccordStateCache cache from write-through to write-back > --- > > Key: CASSANDRA-18563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18563 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.0 > > -- 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-18563) Convert AccordStateCache cache from write-through to write-back
[ https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18563: -- Change Category: Performance Complexity: Normal Component/s: Accord Fix Version/s: 5.0 Reviewers: Blake Eggleston Status: Open (was: Triage Needed) > Convert AccordStateCache cache from write-through to write-back > --- > > Key: CASSANDRA-18563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18563 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.0 > > -- 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-18563) Convert AccordStateCache cache from write-through to write-back
Aleksey Yeschenko created CASSANDRA-18563: - Summary: Convert AccordStateCache cache from write-through to write-back Key: CASSANDRA-18563 URL: https://issues.apache.org/jira/browse/CASSANDRA-18563 Project: Cassandra Issue Type: Improvement Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Test and Documentation Plan: Mechanical change Status: Patch Available (was: In Progress) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Status: Ready to Commit (was: Review In Progress) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Source Control Link: https://github.com/apache/cassandra-accord/commit/8830d97ba517fb2d0f7f22e8e6b886a98839e694 https://github.com/apache/cassandra/commit/2230fb55cd0c0ee9c4d0732ab1a5ad2ffb28e15f Resolution: Fixed Status: Resolved (was: Ready to Commit) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Change Category: Code Clarity Complexity: Low Hanging Fruit Component/s: Accord Fix Version/s: 5.0 Reviewers: Benedict Elliott Smith Assignee: Aleksey Yeschenko Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18561: -- Status: Review In Progress (was: Patch Available) > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Low > Fix For: 5.0 > > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
[ https://issues.apache.org/jira/browse/CASSANDRA-18561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728694#comment-17728694 ] Aleksey Yeschenko commented on CASSANDRA-18561: --- Accord PR: [https://github.com/apache/cassandra-accord/pull/48] Cassandra PR: [https://github.com/apache/cassandra/pull/2383] > Extend Accord MessageType with a side effect flag > - > > Key: CASSANDRA-18561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Priority: Normal > > Tiny change to make it easier for implementations to decide if a protocol > message should be persisted to the log. -- 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-18561) Extend Accord MessageType with a side effect flag
Aleksey Yeschenko created CASSANDRA-18561: - Summary: Extend Accord MessageType with a side effect flag Key: CASSANDRA-18561 URL: https://issues.apache.org/jira/browse/CASSANDRA-18561 Project: Cassandra Issue Type: Improvement Reporter: Aleksey Yeschenko Tiny change to make it easier for implementations to decide if a protocol message should be persisted to the log. -- 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-18344) Store PreAccept, Accept, Commit, and Apply in a durable log before processing by CommandStores
[ https://issues.apache.org/jira/browse/CASSANDRA-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18344: -- Reviewers: David Capwell (was: Benedict Elliott Smith, David Capwell) > Store PreAccept, Accept, Commit, and Apply in a durable log before processing > by CommandStores > -- > > Key: CASSANDRA-18344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.x > > Time Spent: 17h > Remaining Estimate: 0h > > Write PreAccept, Accept, Commit, and Apply messages durably to a journal. > CommandStore will then processes the messages in write order. > > This is a prerequisite JIRA for several incoming improvements, such as > reducing the data we store in system tables, making command stores and > progress log persistent, simplifying caching. > The journal supports invalidating individual entries by id and sets of > owners, and looking up records by id, both needed for near-future Accord work. > > Several complete/near-complete parts of the generic journal implementation > have been temporarily taken out until we need them (soon, once > bootstrap/state reclamation are implemented). > These include invalidation support (in memory and on-disk implementations), > and segment compaction (not needed without invalidations). > -- 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-18344) Store PreAccept, Accept, Commit, and Apply in a durable log before processing by CommandStores
[ https://issues.apache.org/jira/browse/CASSANDRA-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18344: -- Source Control Link: https://github.com/apache/cassandra/commit/6d1d1146a79bda571d94ba5618d00687f11e03fe Resolution: Fixed Status: Resolved (was: Ready to Commit) > Store PreAccept, Accept, Commit, and Apply in a durable log before processing > by CommandStores > -- > > Key: CASSANDRA-18344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.x > > Time Spent: 17h > Remaining Estimate: 0h > > Write PreAccept, Accept, Commit, and Apply messages durably to a journal. > CommandStore will then processes the messages in write order. > > This is a prerequisite JIRA for several incoming improvements, such as > reducing the data we store in system tables, making command stores and > progress log persistent, simplifying caching. > The journal supports invalidating individual entries by id and sets of > owners, and looking up records by id, both needed for near-future Accord work. > > Several complete/near-complete parts of the generic journal implementation > have been temporarily taken out until we need them (soon, once > bootstrap/state reclamation are implemented). > These include invalidation support (in memory and on-disk implementations), > and segment compaction (not needed without invalidations). > -- 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-18344) Store PreAccept, Accept, Commit, and Apply in a durable log before processing by CommandStores
[ https://issues.apache.org/jira/browse/CASSANDRA-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18344: -- Status: Ready to Commit (was: Review In Progress) > Store PreAccept, Accept, Commit, and Apply in a durable log before processing > by CommandStores > -- > > Key: CASSANDRA-18344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.x > > Time Spent: 17h > Remaining Estimate: 0h > > Write PreAccept, Accept, Commit, and Apply messages durably to a journal. > CommandStore will then processes the messages in write order. > > This is a prerequisite JIRA for several incoming improvements, such as > reducing the data we store in system tables, making command stores and > progress log persistent, simplifying caching. > The journal supports invalidating individual entries by id and sets of > owners, and looking up records by id, both needed for near-future Accord work. > > Several complete/near-complete parts of the generic journal implementation > have been temporarily taken out until we need them (soon, once > bootstrap/state reclamation are implemented). > These include invalidation support (in memory and on-disk implementations), > and segment compaction (not needed without invalidations). > -- 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-18344) Store PreAccept, Accept, Commit, and Apply in a durable log before processing by CommandStores
[ https://issues.apache.org/jira/browse/CASSANDRA-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18344: -- Reviewers: Benedict Elliott Smith > Store PreAccept, Accept, Commit, and Apply in a durable log before processing > by CommandStores > -- > > Key: CASSANDRA-18344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Write PreAccept, Accept, Commit, and Apply messages durably to a journal. > CommandStore will then processes the messages in write order. > > This is a prerequisite JIRA for several incoming improvements, such as > reducing the data we store in system tables, making command stores and > progress log persistent, simplifying caching. > The journal supports invalidating individual entries by id and sets of > owners, and looking up records by id, both needed for near-future Accord work. > > Several complete/near-complete parts of the generic journal implementation > have been temporarily taken out until we need them (soon, once > bootstrap/state reclamation are implemented). > These include invalidation support (in memory and on-disk implementations), > and segment compaction (not needed without invalidations). > -- 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-18421) TBD
Aleksey Yeschenko created CASSANDRA-18421: - Summary: TBD Key: CASSANDRA-18421 URL: https://issues.apache.org/jira/browse/CASSANDRA-18421 Project: Cassandra Issue Type: New Feature Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko TBD -- 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-18344) Store PreAccept, Accept, Commit, and Apply in a durable log before processing by CommandStores
[ https://issues.apache.org/jira/browse/CASSANDRA-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707343#comment-17707343 ] Aleksey Yeschenko commented on CASSANDRA-18344: --- [https://github.com/apache/cassandra/pull/2256] Pre-requisite patch-set for several upcoming Accord changes. Introduces an append-only journal for Accord messages. The journal supports invalidating individual entries by id and sets of owners, and looking up records by id, among other things. Several complete/near-complete parts of the generic journal implementation have been temporarily taken out until we need them (soon, once bootstrap/state reclamation are implemented). These include: * invalidation support (in memory and on-disk implementations), and * segment compaction (not needed without invalidations) PreAccept, Accept, Commit, and Apply are now written to a journal but aren't yet being read/used. Test coverage needs and comments around certain areas need work before commit. Coming soon. > Store PreAccept, Accept, Commit, and Apply in a durable log before processing > by CommandStores > -- > > Key: CASSANDRA-18344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Write PreAccept, Accept, Commit, and Apply messages durably to a journal. > CommandStore will then processes the messages in write order. > > This is a prerequisite JIRA for several incoming improvements, such as > reducing the data we store in system tables, making command stores and > progress log persistent, simplifying caching. > The journal supports invalidating individual entries by id and sets of > owners, and looking up records by id, both needed for near-future Accord work. > > Several complete/near-complete parts of the generic journal implementation > have been temporarily taken out until we need them (soon, once > bootstrap/state reclamation are implemented). > These include invalidation support (in memory and on-disk implementations), > and segment compaction (not needed without invalidations). > -- 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-18344) Store PreAccept, Accept, Commit, and Apply in a durable log before processing by CommandStores
[ https://issues.apache.org/jira/browse/CASSANDRA-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18344: -- Change Category: Performance Complexity: Normal Status: Open (was: Triage Needed) > Store PreAccept, Accept, Commit, and Apply in a durable log before processing > by CommandStores > -- > > Key: CASSANDRA-18344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Write PreAccept, Accept, Commit, and Apply messages durably to a journal. > CommandStore will then processes the messages in write order. > > This is a prerequisite JIRA for several incoming improvements, such as > reducing the data we store in system tables, making command stores and > progress log persistent, simplifying caching. > The journal supports invalidating individual entries by id and sets of > owners, and looking up records by id, both needed for near-future Accord work. > > Several complete/near-complete parts of the generic journal implementation > have been temporarily taken out until we need them (soon, once > bootstrap/state reclamation are implemented). > These include invalidation support (in memory and on-disk implementations), > and segment compaction (not needed without invalidations). > -- 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-18344) Store PreAccept, Accept, Commit, and Apply in a durable log before processing by CommandStores
[ https://issues.apache.org/jira/browse/CASSANDRA-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18344: -- Component/s: Accord > Store PreAccept, Accept, Commit, and Apply in a durable log before processing > by CommandStores > -- > > Key: CASSANDRA-18344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Write PreAccept, Accept, Commit, and Apply messages durably to a journal. > CommandStore will then processes the messages in write order. > > This is a prerequisite JIRA for several incoming improvements, such as > reducing the data we store in system tables, making command stores and > progress log persistent, simplifying caching. > The journal supports invalidating individual entries by id and sets of > owners, and looking up records by id, both needed for near-future Accord work. > > Several complete/near-complete parts of the generic journal implementation > have been temporarily taken out until we need them (soon, once > bootstrap/state reclamation are implemented). > These include invalidation support (in memory and on-disk implementations), > and segment compaction (not needed without invalidations). > -- 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-18344) Store PreAccept, Accept, Commit, and Apply in a durable log before processing by CommandStores
[ https://issues.apache.org/jira/browse/CASSANDRA-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18344: -- Description: Write PreAccept, Accept, Commit, and Apply messages durably to a journal. CommandStore will then processes the messages in write order. This is a prerequisite JIRA for several incoming improvements, such as reducing the data we store in system tables, making command stores and progress log persistent, simplifying caching. The journal supports invalidating individual entries by id and sets of owners, and looking up records by id, both needed for near-future Accord work. Several complete/near-complete parts of the generic journal implementation have been temporarily taken out until we need them (soon, once bootstrap/state reclamation are implemented). These include invalidation support (in memory and on-disk implementations), and segment compaction (not needed without invalidations). was:TBD Summary: Store PreAccept, Accept, Commit, and Apply in a durable log before processing by CommandStores (was: TBD) > Store PreAccept, Accept, Commit, and Apply in a durable log before processing > by CommandStores > -- > > Key: CASSANDRA-18344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 > Project: Cassandra > Issue Type: New Feature >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Write PreAccept, Accept, Commit, and Apply messages durably to a journal. > CommandStore will then processes the messages in write order. > > This is a prerequisite JIRA for several incoming improvements, such as > reducing the data we store in system tables, making command stores and > progress log persistent, simplifying caching. > The journal supports invalidating individual entries by id and sets of > owners, and looking up records by id, both needed for near-future Accord work. > > Several complete/near-complete parts of the generic journal implementation > have been temporarily taken out until we need them (soon, once > bootstrap/state reclamation are implemented). > These include invalidation support (in memory and on-disk implementations), > and segment compaction (not needed without invalidations). > -- 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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18304:
--
Reviewers: Aleksey Yeschenko, Stefan Miklosovic, Aleksey Yeschenko (was:
Aleksey Yeschenko, Stefan Miklosovic)
Aleksey Yeschenko, Stefan Miklosovic, Aleksey Yeschenko (was:
Aleksey Yeschenko, Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703703#comment-17703703
]
Aleksey Yeschenko commented on CASSANDRA-18304:
---
+1. I can't say that the code around hint submission is currently correct, but
the changes are strictly an improvement, and don't make anything worse.
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18304:
--
Status: Ready to Commit (was: Review In Progress)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
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-18344) TBD
Aleksey Yeschenko created CASSANDRA-18344: - Summary: TBD Key: CASSANDRA-18344 URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 Project: Cassandra Issue Type: New Feature Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko TBD -- 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-18331) Extend implicit allow-filtering to clustering keys as well
[ https://issues.apache.org/jira/browse/CASSANDRA-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700631#comment-17700631 ] Aleksey Yeschenko commented on CASSANDRA-18331: --- Sure. +1d with a small nit mentioned. Feel free to ignore it or change on commit. No need to rerun CI. > Extend implicit allow-filtering to clustering keys as well > -- > > Key: CASSANDRA-18331 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18331 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > This was overlooked in CASSANDRA-18238. > We should be able to do selects on vtables not only when selecting on regular > columns but also on clustering ones. Currently we can do that on regulars > only. -- 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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698453#comment-17698453
]
Aleksey Yeschenko commented on CASSANDRA-18304:
---
As for the {{shouldHint()}} check, that could easily live in
{{{}AbstractWriteResponseHandler#onFailure(){}}}, which would be a more direct
translation of previous logic, without risk of unintended consequences of
introducing filtering to the {{StorageProxy}} method.
{code}
if (hintOnFailure != null &&
StorageProxy.shouldHint(replicaPlan.lookup(from)))
{
StorageProxy.submitHint(hintOnFailure.get(),
replicaPlan.lookup(from), null);
}
{code}
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18304:
--
Reviewers: Aleksey Yeschenko, Stefan Miklosovic (was: Stefan Miklosovic)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698376#comment-17698376
]
Aleksey Yeschenko commented on CASSANDRA-18304:
---
So, {{WriteCallbackInfo}} code is all dead weight and should be removed. Pushed
a commit that does it here:
https://github.com/iamaleksey/cassandra/commits/18304-dead-code-removal
{{allowHints}} argument to some of the upstream methods needs to make its way
to {{AbstractWriteResponseHandler}}, or, alternatively, we need to make sure
that mutation supplier is always null when when {{!allowHints}} and never null
when {{allowHints}}.
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697497#comment-17697497
]
Aleksey Yeschenko commented on CASSANDRA-18304:
---
Sure, let me see.
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690514#comment-17690514
]
Aleksey Yeschenko commented on CASSANDRA-18134:
---
bq. Let me ask question as simple as possible: Can I merge it to trunk given CI
is OK?
Go for it.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690393#comment-17690393
]
Aleksey Yeschenko commented on CASSANDRA-18134:
---
You can also defer committing -nc- support to 4.0.x until something else
warrants an sstable version change on 4.0.x - if that ever happens.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690387#comment-17690387
]
Aleksey Yeschenko commented on CASSANDRA-18134:
---
You can push -nc- support to both 4.0.x and trunk.
If the changes are perceived to be too risky for a 4.0.x release at this point,
then the 4.0.x patch can be a minimal version of that for trunk: only writing
the additional data but not using it for queries, or writing some sentinel
values instead.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690244#comment-17690244
]
Aleksey Yeschenko commented on CASSANDRA-18134:
---
We do not and should not base the decision on whether to bump the major sstable
version on what branch it's going into. That's why we have independent
versioning schemes for some of the components in the first place - instead of
using the singular C* version everywhere.
Regarding major, minor, and patch, this does not track our historic use of the
language. Since we don't and never have followed semver here, we've only ever
had two components to our versioning: first two numbers designated to the major
(1.2 in 1.2.10, 2.0 in 2.0.3, 2.1 in 2.1.2, 3.11 in 3.11.9, etc) and one number
designated to the minor, less often referred to as patch (10 in 1.2.10, 3 in
2.0.3, 2 in 2.1.2, 9 in 3.11.9, etc).
And yes we also use the words release and mention pretty much interchangeably
and that's okay.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18238) Implicitly enable ALLOW FILTERING on virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684755#comment-17684755 ] Aleksey Yeschenko commented on CASSANDRA-18238: --- +1 > Implicitly enable ALLOW FILTERING on virtual tables > --- > > Key: CASSANDRA-18238 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18238 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Ticket to track work / discussion of this thread (1) > (1) https://lists.apache.org/thread/104fld746d6qtggq5132n3hqtjqqpkjp -- 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-18135) Accord: transition Node.Id from long to int
[ https://issues.apache.org/jira/browse/CASSANDRA-18135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18135: -- Resolution: Fixed Status: Resolved (was: Triage Needed) > Accord: transition Node.Id from long to int > --- > > Key: CASSANDRA-18135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18135 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.2 > > > Trimmed down version of the patch, swapping long for int, but still keeping > Node.Id class. Delaying the rest (elimination of Node.Id as a class) until > immutability work lands, to ease rebase pain. -- 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-18238) Implicitly enable ALLOW FILTERING on virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684655#comment-17684655 ] Aleksey Yeschenko commented on CASSANDRA-18238: --- It doesn't need to be a table param and doesn't need to be put in schema. > Implicitly enable ALLOW FILTERING on virtual tables > --- > > Key: CASSANDRA-18238 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18238 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Ticket to track work / discussion of this thread (1) > (1) https://lists.apache.org/thread/104fld746d6qtggq5132n3hqtjqqpkjp -- 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-18238) Implicitly enable ALLOW FILTERING on virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684631#comment-17684631 ] Aleksey Yeschenko commented on CASSANDRA-18238: --- Comment param is not there to encode arbitrary attributes, let's not hijack that field, please. > Implicitly enable ALLOW FILTERING on virtual tables > --- > > Key: CASSANDRA-18238 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18238 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Ticket to track work / discussion of this thread (1) > (1) https://lists.apache.org/thread/104fld746d6qtggq5132n3hqtjqqpkjp -- 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-18135) Accord: transition Node.Id from long to int
[ https://issues.apache.org/jira/browse/CASSANDRA-18135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683940#comment-17683940 ] Aleksey Yeschenko commented on CASSANDRA-18135: --- https://github.com/apache/cassandra-accord/pull/34 https://github.com/apache/cassandra/pull/2134 https://app.circleci.com/pipelines/github/iamaleksey/cassandra?branch=18135 > Accord: transition Node.Id from long to int > --- > > Key: CASSANDRA-18135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18135 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.2 > > > Trimmed down version of the patch, swapping long for int, but still keeping > Node.Id class. Delaying the rest (elimination of Node.Id as a class) until > immutability work lands, to ease rebase pain. -- 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-18135) Accord: transition Node.Id from long to int
[ https://issues.apache.org/jira/browse/CASSANDRA-18135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18135: -- Fix Version/s: 4.2 > Accord: transition Node.Id from long to int > --- > > Key: CASSANDRA-18135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18135 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.2 > > > Trimmed down version of the patch, swapping long for int, but still keeping > Node.Id class. Delaying the rest (elimination of Node.Id as a class) until > immutability work lands, to ease rebase pain. -- 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-18135) Accord: transition Node.Id from long to int
[ https://issues.apache.org/jira/browse/CASSANDRA-18135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18135: -- Component/s: Accord > Accord: transition Node.Id from long to int > --- > > Key: CASSANDRA-18135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18135 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Trimmed down version of the patch, swapping long for int, but still keeping > Node.Id class. Delaying the rest (elimination of Node.Id as a class) until > immutability work lands, to ease rebase pain. -- 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-18135) Accord: transition Node.Id from long to int
[ https://issues.apache.org/jira/browse/CASSANDRA-18135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18135: -- Change Category: Performance Complexity: Normal Reviewers: Benedict Elliott Smith Description: Trimmed down version of the patch, swapping long for int, but still keeping Node.Id class. Delaying the rest (elimination of Node.Id as a class) until immutability work lands, to ease rebase pain. (was: TBD) Summary: Accord: transition Node.Id from long to int (was: TBD) > Accord: transition Node.Id from long to int > --- > > Key: CASSANDRA-18135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18135 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > > Trimmed down version of the patch, swapping long for int, but still keeping > Node.Id class. Delaying the rest (elimination of Node.Id as a class) until > immutability work lands, to ease rebase pain. -- 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-17973) Change trunk 4.2 to 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680742#comment-17680742
]
Aleksey Yeschenko commented on CASSANDRA-17973:
---
Should we consider dropping JDK8 support while at it? Supporting three JDKs (8,
11, 17) would likely be an unreasonable burden that might not be worth it at
this point in Java8 long life.
> Change trunk 4.2 to 5.0
> ---
>
> Key: CASSANDRA-17973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17973
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> 1. Bump trunk's version
> {code}
> git switch trunk
> # increment version to 5.0
> edit build.xml debian/changelog CHANGES.txt NEWS.txt README.asc
> {code}
> 2. Update jvm-dtest supported upgrade paths
> -
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
>
> 3. Update `4.2` to jira versions
> Change `4.2` to `5.0`
> Change `4.x` to `5.x`
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> 6. Add dtest version and upgrade paths
> -
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
> - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
> -
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
> 7. Update how_to_commit documentation
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc
--
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-18142) CEP-15: (Accord/C*) Shard CommandStores by contiguous ranges
[ https://issues.apache.org/jira/browse/CASSANDRA-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18142: -- Authors: Benedict Elliott Smith Reviewers: Aleksey Yeschenko > CEP-15: (Accord/C*) Shard CommandStores by contiguous ranges > > > Key: CASSANDRA-18142 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18142 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Priority: Normal > > For efficiency and simplicity, nodes should internally shard on contiguous > ranges. -- 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-18172) CEP-15: (Accord/C*) Refactor Timestamp/TxnId
[ https://issues.apache.org/jira/browse/CASSANDRA-18172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18172: -- Authors: Benedict Elliott Smith Reviewers: Aleksey Yeschenko > CEP-15: (Accord/C*) Refactor Timestamp/TxnId > > > Key: CASSANDRA-18172 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18172 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Priority: Normal > > Reduce the amount of storage required for Timestamp and TxnId by compressing > epoch to 48 bits, and real/logical to a single 64-bit HLC, while also > supporting flag carrier bits for communicating protocol state information. -- 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-18126) Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
[
https://issues.apache.org/jira/browse/CASSANDRA-18126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656048#comment-17656048
]
Aleksey Yeschenko commented on CASSANDRA-18126:
---
No reason to not commit to 3.0+. Please go ahead, thanks Stefan.
> Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
> -
>
> Key: CASSANDRA-18126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18126
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 4.x
>
> Attachments: Cassandra Apache Jira Link.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is possible to navigate from the IntelliJ IDEA Git window to a
> corresponding Cassandra issue, the Apache Jira if mentioned in the git
> message. The example in the attachments shows how _CASSANDRA-*_ letters are
> turned on in the commit message to an appropriate Cassandra Jira link.
> We should update the IntelliJ IDEA configuration and make this behaviour a
> default for the {{ant generate-idea-files}} process.
> To achieve this manually you can update your {{.idea/vcs.xml}} file in the
> Cassandra project with the following:
> {code:java}
>
>
>
>
>
>
>
>
>
>
> name="linkRegexp"value="https://issues.apache.org/jira/browse/CASSANDRA-$1"/>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18135) TBD
Aleksey Yeschenko created CASSANDRA-18135: - Summary: TBD Key: CASSANDRA-18135 URL: https://issues.apache.org/jira/browse/CASSANDRA-18135 Project: Cassandra Issue Type: Improvement Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko TBD -- 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-17970) Avoid anticompaction mixing data from two different time windows with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-17970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17970: -- Status: Ready to Commit (was: Review In Progress) +1, with one ignorable test nit in PR comments. > Avoid anticompaction mixing data from two different time windows with TWCS > -- > > Key: CASSANDRA-17970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17970 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/TWCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > When grouping sstables for anticompaction we can currently get sstables from > different time windows when running TWCS -- 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-17970) Avoid anticompaction mixing data from two different time windows with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-17970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17970: -- Reviewers: Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko) Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko) Status: Review In Progress (was: Patch Available) > Avoid anticompaction mixing data from two different time windows with TWCS > -- > > Key: CASSANDRA-17970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17970 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/TWCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > When grouping sstables for anticompaction we can currently get sstables from > different time windows when running TWCS -- 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-17970) Avoid anticompaction mixing data from two different time windows with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-17970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17970: -- Reviewers: Aleksey Yeschenko (was: Jon Meredith) > Avoid anticompaction mixing data from two different time windows with TWCS > -- > > Key: CASSANDRA-17970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17970 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/TWCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > When grouping sstables for anticompaction we can currently get sstables from > different time windows when running TWCS -- 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-18126) Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
[
https://issues.apache.org/jira/browse/CASSANDRA-18126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18126:
--
Status: Ready to Commit (was: Review In Progress)
+1, nifty, works as advertised.
> Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
> -
>
> Key: CASSANDRA-18126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18126
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 4.x
>
> Attachments: Cassandra Apache Jira Link.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is possible to navigate from the IntelliJ IDEA Git window to a
> corresponding Cassandra issue, the Apache Jira if mentioned in the git
> message. The example in the attachments shows how _CASSANDRA-*_ letters are
> turned on in the commit message to an appropriate Cassandra Jira link.
> We should update the IntelliJ IDEA configuration and make this behaviour a
> default for the {{ant generate-idea-files}} process.
> To achieve this manually you can update your {{.idea/vcs.xml}} file in the
> Cassandra project with the following:
> {code:java}
>
>
>
>
>
>
>
>
>
>
> name="linkRegexp"value="https://issues.apache.org/jira/browse/CASSANDRA-$1"/>
>
>
>
>
>
> {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-18126) Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
[
https://issues.apache.org/jira/browse/CASSANDRA-18126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18126:
--
Reviewers: Aleksey Yeschenko, David Capwell (was: David Capwell)
> Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
> -
>
> Key: CASSANDRA-18126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18126
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 4.x
>
> Attachments: Cassandra Apache Jira Link.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is possible to navigate from the IntelliJ IDEA Git window to a
> corresponding Cassandra issue, the Apache Jira if mentioned in the git
> message. The example in the attachments shows how _CASSANDRA-*_ letters are
> turned on in the commit message to an appropriate Cassandra Jira link.
> We should update the IntelliJ IDEA configuration and make this behaviour a
> default for the {{ant generate-idea-files}} process.
> To achieve this manually you can update your {{.idea/vcs.xml}} file in the
> Cassandra project with the following:
> {code:java}
>
>
>
>
>
>
>
>
>
>
> name="linkRegexp"value="https://issues.apache.org/jira/browse/CASSANDRA-$1"/>
>
>
>
>
>
> {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-17977) CME in STCS/DTCS/TWCS.getSSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-17977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17977: -- Reviewers: Aleksey Yeschenko, Aleksey Yeschenko (was: Jon Meredith) Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko) Status: Review In Progress (was: Patch Available) +1 > CME in STCS/DTCS/TWCS.getSSTables > - > > Key: CASSANDRA-17977 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17977 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > This method should be synchronized to avoid ConcurrentModificationException -- 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-17977) CME in STCS/DTCS/TWCS.getSSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-17977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17977: -- Status: Ready to Commit (was: Review In Progress) > CME in STCS/DTCS/TWCS.getSSTables > - > > Key: CASSANDRA-17977 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17977 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > This method should be synchronized to avoid ConcurrentModificationException -- 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-18108) Data loss after a system restart/upgrade (3.11.14)
[
https://issues.apache.org/jira/browse/CASSANDRA-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646651#comment-17646651
]
Aleksey Yeschenko commented on CASSANDRA-18108:
---
[~maedhroz] It should be perfectly safe, seeing as you are essentially changing
an alias for an component that is positionally set in stone. There is no reason
to forbid it, and it has never been problematic. If there is a bug somewhere,
it's the bug that needs to be fixed.
> Data loss after a system restart/upgrade (3.11.14)
> --
>
> Key: CASSANDRA-18108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18108
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ke Han
>Priority: Normal
>
> When we upgrade Cassandra from 3.11.14 to 4.0.7, we found a data loss during
> the upgrade process. This bug can also be triggered if simply performing a
> system restart.
> h1. Steps to reproduce
> Start a 3.11.14 or 4.0.7 Cassandra node using default configurations. Execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE IF NOT EXISTS ks.tb (c1 INT,c3 INT,c2 TEXT, PRIMARY KEY (c1 ))
> WITH speculative_retry = 'ALWAYS';
> INSERT INTO ks.tb (c1, c2) VALUES (2,'val');
> ALTER TABLE ks.tb DROP c2 ;
> ALTER TABLE ks.tb RENAME c1 TO c2; {code}
> Then execute a SELECT command, we get the correct data
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +--
> 2 | null
> (1 rows){code}
> Flush and stop the Cassandra daemon.
> {code:java}
> bin/nodetool flush
> bin/nodetool stopdaemon{code}
> Then restart the node.
> {code:java}
> bin/cassandra{code}
> Start cqlsh, and execute the same SELECT command. The data in ks.tb is lost.
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +
> (0 rows){code}
>
> During the node restart, we found an error log about initializing the table,
> but it didn't prevent the system from starting up.
> {code:java}
> INFO [main] 2022-12-09 21:37:54,234 ColumnFamilyStore.java:432 -
> Initializing ks.tb
> ERROR [SSTableBatchOpen:1] 2022-12-09 21:37:54,237 CassandraDaemon.java:244 -
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:340)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:522)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:385)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader$3.run(SSTableReader.java:570)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> This bug can also be triggered if we perform an upgrade from 3.11.14 to 4.0.7
> and execute the SELECT command in the new version. (*The token_num
> configuration in 4.0.7 is modified to 16 for upgrade compatibility purposes,
> all the other configurations are using default values)
--
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-17874) Only reload compaction strategies if disk boundaries change
[
https://issues.apache.org/jira/browse/CASSANDRA-17874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-17874:
--
Status: Ready to Commit (was: Review In Progress)
Suggested some cleanup to pre-existing code as part of the patch, since this is
going to trunk, to make {{CSM#reload()}} and its callsites easier to reason
about, ultimately splitting it into several. Patch LGTM with or without
accepting cleanup suggestions.
> Only reload compaction strategies if disk boundaries change
> ---
>
> Key: CASSANDRA-17874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17874
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
>
> We currently reload compaction strategies every time ringVersion changes - we
> should change this to only reload if the ring version change actually changes
> the disk boundaries.
--
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-17985) Handle timeouts when shutting down MessagingService
[ https://issues.apache.org/jira/browse/CASSANDRA-17985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17985: -- Status: Changes Suggested (was: Review In Progress) > Handle timeouts when shutting down MessagingService > --- > > Key: CASSANDRA-17985 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17985 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > Sometimes when shutting down messaging service during decommission we get a > timeout exception, which leaves StorageService.operationMode in "LEAVING" > instead of "DECOMMISSIONED" > We should catch the exception, improve logging and increase the timeout -- 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-17874) Only reload compaction strategies if disk boundaries change
[ https://issues.apache.org/jira/browse/CASSANDRA-17874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17874: -- Status: Review In Progress (was: Patch Available) > Only reload compaction strategies if disk boundaries change > --- > > Key: CASSANDRA-17874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17874 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > Fix For: 4.x > > > We currently reload compaction strategies every time ringVersion changes - we > should change this to only reload if the ring version change actually changes > the disk boundaries. -- 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-17985) Handle timeouts when shutting down MessagingService
[ https://issues.apache.org/jira/browse/CASSANDRA-17985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17985: -- Reviewers: Aleksey Yeschenko, Aleksey Yeschenko Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko) Status: Review In Progress (was: Patch Available) > Handle timeouts when shutting down MessagingService > --- > > Key: CASSANDRA-17985 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17985 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > Sometimes when shutting down messaging service during decommission we get a > timeout exception, which leaves StorageService.operationMode in "LEAVING" > instead of "DECOMMISSIONED" > We should catch the exception, improve logging and increase the timeout -- 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-15080) Paxos tables should allow a configurable chunk length
[
https://issues.apache.org/jira/browse/CASSANDRA-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634824#comment-17634824
]
Aleksey Yeschenko commented on CASSANDRA-15080:
---
Actually allowing to modify these via {{ALTER}} would be unfortunately quite a
bit involved. But we can load these from cassandra.yaml when defining the table
as a compromise?
> Paxos tables should allow a configurable chunk length
> -
>
> Key: CASSANDRA-15080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15080
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Normal
> Labels: performance
> Attachments: flamegraph-bad-perf.svg
>
>
> In doing some research for a client on LWTs, I found that once we start
> pushing a node hard enough, with enough LWTs, decompressing the data in the
> paxos table takes up quite a bit of time. I've attached an SVG flame graph
> showing about 10% of time is spent in LZ4_decompress_fast in queries hitting
> the paxos table.
> We should allow the user to modify the compression settings on this table.
--
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
