[jira] [Commented] (CASSANDRA-16935) Use paxos_variant to specify Paxos behaviour
[ https://issues.apache.org/jira/browse/CASSANDRA-16935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425259#comment-17425259 ] Paulo Motta commented on CASSANDRA-16935: - sounds good to me, thank you! > Use paxos_variant to specify Paxos behaviour > > > Key: CASSANDRA-16935 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16935 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Benedict Elliott Smith >Priority: Normal > Fix For: 4.x > > > This patch introduces a config property for specifying the desired Paxos > implementation and semantics. Initially, this will support only v1_norrl and > v2, with “norrl” meaning “no read/read linearizability” i.e. supporting those > use cases that need to restore prior performance, but only for read/read > interactions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16935) Use paxos_variant to specify Paxos behaviour
[
https://issues.apache.org/jira/browse/CASSANDRA-16935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425245#comment-17425245
]
Benedict Elliott Smith commented on CASSANDRA-16935:
Sure, how about {{v1_without_linearizable_reads}} (no real need to keep the
read/read part)
> Use paxos_variant to specify Paxos behaviour
>
>
> Key: CASSANDRA-16935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16935
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.x
>
>
> This patch introduces a config property for specifying the desired Paxos
> implementation and semantics. Initially, this will support only v1_norrl and
> v2, with “norrl” meaning “no read/read linearizability” i.e. supporting those
> use cases that need to restore prior performance, but only for read/read
> interactions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16935) Use paxos_variant to specify Paxos behaviour
[
https://issues.apache.org/jira/browse/CASSANDRA-16935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425242#comment-17425242
]
Paulo Motta edited comment on CASSANDRA-16935 at 10/6/21, 10:07 PM:
Thanks for the prompt response.
{quote}It's never too late to bikeshed
{quote}
It can definitely be too late to bikeshed - once a property name is out in the
wild, changing can be a nightmare. ;)
{quote}Happy to bikeshed the names, but doubt there are good options here.
{quote}
I tend to prefer more meaningful names, if even they are bigger, versus cryptic
acronyms. How about v1_legacy_semantics or v1_no_read_read_linearizability?
obviously this is just extreme bikeshedding so feel free to disregard.
was (Author: paulo):
Thanks for the prompt response.
bq. It's never too late to bikeshed
It can definitely be too late to bikeshed - once a property name is out in the
wild, changing can be a nightmare. ;-)
bq. Happy to bikeshed the names, but doubt there are good options here.
I tend to prefer more meaningful names, if even they are bigger, versus cryptic
acronyms. How about v1_legacy_semantics or v1_no_read_read_linearizibility?
obviously this is just extreme bikeshedding so feel free to disregard.
> Use paxos_variant to specify Paxos behaviour
>
>
> Key: CASSANDRA-16935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16935
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.x
>
>
> This patch introduces a config property for specifying the desired Paxos
> implementation and semantics. Initially, this will support only v1_norrl and
> v2, with “norrl” meaning “no read/read linearizability” i.e. supporting those
> use cases that need to restore prior performance, but only for read/read
> interactions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16935) Use paxos_variant to specify Paxos behaviour
[ https://issues.apache.org/jira/browse/CASSANDRA-16935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425242#comment-17425242 ] Paulo Motta commented on CASSANDRA-16935: - Thanks for the prompt response. bq. It's never too late to bikeshed It can definitely be too late to bikeshed - once a property name is out in the wild, changing can be a nightmare. ;-) bq. Happy to bikeshed the names, but doubt there are good options here. I tend to prefer more meaningful names, if even they are bigger, versus cryptic acronyms. How about v1_legacy_semantics or v1_no_read_read_linearizibility? obviously this is just extreme bikeshedding so feel free to disregard. > Use paxos_variant to specify Paxos behaviour > > > Key: CASSANDRA-16935 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16935 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Benedict Elliott Smith >Priority: Normal > Fix For: 4.x > > > This patch introduces a config property for specifying the desired Paxos > implementation and semantics. Initially, this will support only v1_norrl and > v2, with “norrl” meaning “no read/read linearizability” i.e. supporting those > use cases that need to restore prior performance, but only for read/read > interactions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16935) Use paxos_variant to specify Paxos behaviour
[ https://issues.apache.org/jira/browse/CASSANDRA-16935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425236#comment-17425236 ] Benedict Elliott Smith commented on CASSANDRA-16935: It's never too late to bikeshed, but the "norrl" isn't about legacy/not, it's about the lack of read/read linearizability. i.e. nor(ead)r(ead)l(inearizability). Specifically this is whether or not we fix CASSANDRA-12126. When CEP-14 lands there will be a v2 introduced (and a v2_norrl) Happy to bikeshed the names, but doubt there are _good_ options here. > Use paxos_variant to specify Paxos behaviour > > > Key: CASSANDRA-16935 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16935 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Benedict Elliott Smith >Priority: Normal > Fix For: 4.x > > > This patch introduces a config property for specifying the desired Paxos > implementation and semantics. Initially, this will support only v1_norrl and > v2, with “norrl” meaning “no read/read linearizability” i.e. supporting those > use cases that need to restore prior performance, but only for read/read > interactions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16935) Use paxos_variant to specify Paxos behaviour
[
https://issues.apache.org/jira/browse/CASSANDRA-16935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425233#comment-17425233
]
Paulo Motta edited comment on CASSANDRA-16935 at 10/6/21, 9:47 PM:
---
Is it to late to bikeshed the property name {{v1_norrl}} sounds a bit cryptic
to me but I don't have a more meaningful suggestion. Perhaps just {{v1}} or
{{v1_legacy}}?
Btw I just checked that the patch has variant names {{v1_norrl}} and {{v1}},
was the latter supposed to be {{v2}} or is it a typo on the JIRA description?
was (Author: paulo):
Is it to late to bikeshed the property name {{v1_norrl}} sounds a bit cryptic
to me but I don't have a more meaningful suggestion. Perhaps just {{v1}} or
{{v1_legacy}}?
Btw I just checked that the patch has variant names {{v1_norrl}} and {{v1}},
was the latter supposed to be {{v2}}?
> Use paxos_variant to specify Paxos behaviour
>
>
> Key: CASSANDRA-16935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16935
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.x
>
>
> This patch introduces a config property for specifying the desired Paxos
> implementation and semantics. Initially, this will support only v1_norrl and
> v2, with “norrl” meaning “no read/read linearizability” i.e. supporting those
> use cases that need to restore prior performance, but only for read/read
> interactions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16935) Use paxos_variant to specify Paxos behaviour
[
https://issues.apache.org/jira/browse/CASSANDRA-16935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425233#comment-17425233
]
Paulo Motta commented on CASSANDRA-16935:
-
Is it to late to bikeshed the property name {{v1_norrl}} sounds a bit cryptic
to me but I don't have a more meaningful suggestion. Perhaps just {{v1}} or
{{v1_legacy}}?
Btw I just checked that the patch has variant names {{v1_norrl}} and {{v1}},
was the latter supposed to be {{v2}}?
> Use paxos_variant to specify Paxos behaviour
>
>
> Key: CASSANDRA-16935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16935
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.x
>
>
> This patch introduces a config property for specifying the desired Paxos
> implementation and semantics. Initially, this will support only v1_norrl and
> v2, with “norrl” meaning “no read/read linearizability” i.e. supporting those
> use cases that need to restore prior performance, but only for read/read
> interactions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14795) Expose information about stored hints via JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425170#comment-17425170
]
Ekaterina Dimitrova commented on CASSANDRA-14795:
-
The last version looks good to me but
_org.apache.cassandra.hints.HintsServiceTest.testListPendingHints_ is failing
in Jenkins unfortunately. It seems a test issue? [~Ge], can you check it,
please?
> Expose information about stored hints via JMX
> -
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16839) Truncation snapshots unnecessarily created on node startup
[
https://issues.apache.org/jira/browse/CASSANDRA-16839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16839:
-
Test and Documentation Plan: Run CI
Status: Patch Available (was: Open)
> Truncation snapshots unnecessarily created on node startup
> --
>
> Key: CASSANDRA-16839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16839
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> When testing cassandra 4.0 on ccm I noticed that everytime I restart a node,
> truncation snapshots are created for the tables {{system.table_estimates}}
> and {{system.size_estimates}}:
> {noformat}
> $ ccm create -n 1 test -s
> $ ccm node1 stop
> $ ccm node1 start
> $ ccm node1 stop
> $ ccm node1 start
> $ ccm node1 nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True
> size Size on disk
> truncated-1628599001857-table_estimates systemtable_estimates0
> bytes 13 bytes
> truncated-1628599099560-table_estimates systemtable_estimates0
> bytes 13 bytes
> truncated-1628599001736-size_estimates systemsize_estimates 0
> bytes 13 bytes
> truncated-1628599057438-table_estimates systemtable_estimates6.16
> KiB 6.19 KiB
> truncated-1628599099458-size_estimates systemsize_estimates 0
> bytes 13 bytes
> truncated-1628599057340-size_estimates systemsize_estimates 5.73
> KiB 5.76 KiB
> Total TrueDiskSpaceUsed: 0 bytes
> {noformat}
> Not sure if this is expected behavior, but feels like a bug to me.
> Reproduced on 4.0, not sure if it reproduces on lower versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17017) Add required -f / --force option to nodetool verify
[ https://issues.apache.org/jira/browse/CASSANDRA-17017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425163#comment-17425163 ] Josh McKenzie commented on CASSANDRA-17017: --- Yeah; was hoping to get done w/the code changes and agree on that front before triggering CI. I'll go ahead and wander through dtests and update the verify calls to use the new flag as well before kicking those off. > Add required -f / --force option to nodetool verify > --- > > Key: CASSANDRA-17017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17017 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > nodetool verify has some pretty significant problems with it (see > CASSANDRA-9947). > Until such time as we do the heavy(er) lift to fix the command, we should > make it harder for people to shoot themselves in the foot with it. Adding a > required "-f" flag to it with a requisite "Do you really know what you're > doing? Check out this JIRA first" seems like it'd be the right thing to do in > the interim. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r50302 - /release/cassandra/KEYS
Author: brandonwilliams Date: Wed Oct 6 18:42:37 2021 New Revision: 50302 Log: Remove Benedict's ed25519 key Modified: release/cassandra/KEYS Modified: release/cassandra/KEYS == --- release/cassandra/KEYS (original) +++ release/cassandra/KEYS Wed Oct 6 18:42:37 2021 @@ -4266,23 +4266,3 @@ hnMm1r+QheupQkD2gkQHuZBDDL4uzPn1G8h10AVW mez8B8JRgiMU =eGHt -END PGP PUBLIC KEY BLOCK- -pub ed25519 2021-10-05 [SC] - 7882099F3A0033DDD63D100C92BBDF5FAD055BC2 -uid [ultimate] Benedict Elliott Smith -sig 392BBDF5FAD055BC2 2021-10-05 Benedict Elliott Smith -sub cv25519 2021-10-05 [E] -sig 92BBDF5FAD055BC2 2021-10-05 Benedict Elliott Smith - --BEGIN PGP PUBLIC KEY BLOCK- - -mDMEYVyGMxYJKwYBBAHaRw8BAQdAgLIC4s/cwQBN+/beBYX/MQulVk/PYs/hdzfS -4bOw/he0LEJlbmVkaWN0IEVsbGlvdHQgU21pdGggPGJlbmVkaWN0QGFwYWNoZS5v -cmc+iJQEExYKADwWIQR4ggmfOgAz3dY9EAySu99frQVbwgUCYVyGMwIbAwULCQgH -AgMiAgEGFQoJCAsCBBYCAwECHgcCF4AACgkQkrvfX60FW8IBtAEAnD6yp5ndOzTP -rdrloTlvZlYpn5z2lfWTK6BEiNphun8BANAet8onvoXhXgA0/yGrVz20v38b7jIY -ItUFg1+TGbsJuDgEYVyGMxIKKwYBBAGXVQEFAQEHQM6pAPOOFbVIHhsI+Pb8HE97 -TWiyyuQw4BwZ+4eJ7x4UAwEIB4h4BBgWCgAgFiEEeIIJnzoAM93WPRAMkrvfX60F -W8IFAmFchjMCGwwACgkQkrvfX60FW8Kx/AD+Il8Z/BDMQ1GK0SgMHmScS0T8PatV -vyBv4lwlBDD64dEBAINUEUlq/wVVAi44SQx7g4fc19yLJ4aZeAxMxAFnxiEF -=iT8j --END PGP PUBLIC KEY BLOCK- \ No newline at end of file - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16334) Replica failure causes timeout on multi-DC write
[
https://issues.apache.org/jira/browse/CASSANDRA-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov updated CASSANDRA-16334:
-
Description:
Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws a
write error on a single DC keyspace with RF=3:
{noformat}
cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
execute write] message="Operation failed - received 0 responses and 3 failures:
UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN from
/127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses': 1,
'received_responses': 0, 'failures': 3}
{noformat}
The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
{noformat}
cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
out waiting for replica nodes' responses] message="Operation timed out -
received only 0 responses." info={'consistency': 'LOCAL_ONE',
'required_responses': 1, 'received_responses': 0}
{noformat}
Reproduction steps:
{noformat}
# Setup cluster
ccm create -n 3:3 test
for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
~/.ccm/test/node$i/conf/cassandra.yaml; done
ccm start
# Create schema
ccm node1 cqlsh
CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': 3, 'dc2': 3};
CREATE TABLE test.test (key int PRIMARY KEY, val blob);
exit;
# Insert data
python
from cassandra.cluster import Cluster
cluster = Cluster()
session = cluster.connect('test')
blob = f = open("2mbBlob", "rb").read().hex()
session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob +
"'))")
{noformat}
Reproduced in 3.0, 3.11, 4.0, trunk.
was:
Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws a
write error on a single DC keyspace with RF=3:
{noformat}
cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
execute write] message="Operation failed - received 0 responses and 3 failures:
UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN from
/127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses': 1,
'received_responses': 0, 'failures': 3}
{noformat}
The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
{noformat}
cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
out waiting for replica nodes' responses] message="Operation timed out -
received only 0 responses." info={'consistency': 'LOCAL_ONE',
'required_responses': 1, 'received_responses': 0}
{noformat}
Reproduction steps:
{noformat}
# Setup cluster
ccm create -n 3:3 test
for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
~/.ccm/test/node$i/conf/cassandra.yaml; done
ccm start
# Create schema
ccm node1 cqlsh
CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': 3, 'dc2': 3};
CREATE TABLE test.test (key int PRIMARY KEY, val blob);
exit;
# Insert data
python
from cassandra.cluster import Cluster
cluster = Cluster()
session = cluster.connect('test')
blob = f = open("2mbBlob", "rb").read().hex()
session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob +
"'))")
{noformat}
Reproduced in 3.0, 3.11, trunk.
> Replica failure causes timeout on multi-DC write
>
>
> Key: CASSANDRA-16334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16334
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Messaging/Internode
>Reporter: Paulo Motta
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
>
> Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws
> a write error on a single DC keyspace with RF=3:
> {noformat}
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 0 responses and 3
> failures: UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN
> from /127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 3}
> {noformat}
> The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
> {noformat}
> cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
> out waiting for replica nodes' responses] message="Operation timed out -
> received only 0 responses." info={'consistency': 'LOCAL_ONE',
> 'required_responses': 1, 'received_responses': 0}
> {noformat}
> Reproduction steps:
> {noformat}
> # Setup cluster
> ccm create -n 3:3 test
> for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
> ~/.ccm/test/node$i/conf/cassandra.yaml; done
> ccm start
> # Create schema
> ccm node1 cqlsh
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
[jira] [Updated] (CASSANDRA-16334) Replica failure causes timeout on multi-DC write
[
https://issues.apache.org/jira/browse/CASSANDRA-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov updated CASSANDRA-16334:
-
Description:
Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws a
write error on a single DC keyspace with RF=3:
{noformat}
cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
execute write] message="Operation failed - received 0 responses and 3 failures:
UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN from
/127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses': 1,
'received_responses': 0, 'failures': 3}
{noformat}
The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
{noformat}
cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
out waiting for replica nodes' responses] message="Operation timed out -
received only 0 responses." info={'consistency': 'LOCAL_ONE',
'required_responses': 1, 'received_responses': 0}
{noformat}
Reproduction steps:
{noformat}
# Setup cluster
ccm create -n 3:3 test
for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
~/.ccm/test/node$i/conf/cassandra.yaml; done
ccm start
# Create schema
ccm node1 cqlsh
CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': 3, 'dc2': 3};
CREATE TABLE test.test (key int PRIMARY KEY, val blob);
exit;
# Insert data
python
from cassandra.cluster import Cluster
cluster = Cluster()
session = cluster.connect('test')
blob = f = open("2mbBlob", "rb").read().hex()
session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob +
"'))")
{noformat}
Reproduced in 3.0, 3.11, trunk.
was:
Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws a
write error on a single DC keyspace with RF=3:
{noformat}
cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
execute write] message="Operation failed - received 0 responses and 3 failures:
UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN from
/127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses': 1,
'received_responses': 0, 'failures': 3}
{noformat}
The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
{noformat}
cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
out waiting for replica nodes' responses] message="Operation timed out -
received only 0 responses." info={'consistency': 'LOCAL_ONE',
'required_responses': 1, 'received_responses': 0}
{noformat}
Reproduction steps:
{noformat}
# Setup cluster
ccm create -n 3:3 test
for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
~/.ccm/test/node$i/conf/cassandra.yaml; done
ccm start
# Create schema
ccm node1 cqlsh
CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': 3, 'dc2': 3};
CREATE TABLE test.test (key int PRIMARY KEY, val blob);
exit;
# Insert data
python
from cassandra.cluster import Cluster
cluster = Cluster()
session = cluster.connect('test')
blob = f = open("2mbBlob", "rb").read().hex()
session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob +
"'))")
{noformat}
Reproduced in 3.11, trunk.
> Replica failure causes timeout on multi-DC write
>
>
> Key: CASSANDRA-16334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16334
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Messaging/Internode
>Reporter: Paulo Motta
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
>
> Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws
> a write error on a single DC keyspace with RF=3:
> {noformat}
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 0 responses and 3
> failures: UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN
> from /127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 3}
> {noformat}
> The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
> {noformat}
> cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
> out waiting for replica nodes' responses] message="Operation timed out -
> received only 0 responses." info={'consistency': 'LOCAL_ONE',
> 'required_responses': 1, 'received_responses': 0}
> {noformat}
> Reproduction steps:
> {noformat}
> # Setup cluster
> ccm create -n 3:3 test
> for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
> ~/.ccm/test/node$i/conf/cassandra.yaml; done
> ccm start
> # Create schema
> ccm node1 cqlsh
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
>
[jira] [Updated] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-14752:
Fix Version/s: 4.0.x
3.11.x
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-14752:
Test and Documentation Plan:
https://issues.apache.org/jira/browse/CASSANDRA-14752?focusedCommentId=17425118=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17425118
Unit test testBooleanCompositeKey added plus full CI run
was:
https://issues.apache.org/jira/browse/CASSANDRA-14752?focusedCommentId=17425118=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17425118
Unit test testBooleanCompositeKey
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-14752:
Test and Documentation Plan:
https://issues.apache.org/jira/browse/CASSANDRA-14752?focusedCommentId=17425118=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17425118
Unit test testBooleanCompositeKey
Status: Patch Available (was: In Progress)
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425118#comment-17425118
]
Ekaterina Dimitrova edited comment on CASSANDRA-14752 at 10/6/21, 5:37 PM:
---
I reworked 3.11 and 4.0 and pushed additional changes for trunk based on
Stefania Alborghetti's patch. (I will add her as author at the end before
commit)
*trunk:* Byte buffers of {{BooleanSerializer}} are now read-only. We cannot
make them on-heap read-only, as we would need to change our code in several key
places which seems not worth it at this point. However, buffers can be off-heap
read-only. Note that this only offers partial protection against put calls done
on the buffer itself. It will not protect, amongst several cases, for put calls
where the read-only buffer is the source, as it was the case in
{{AbstractCompositeType}}. In this case, the position will still be advanced.
To make these buffers completely safe we would need to duplicate them and
accept the additional GC pressure.
||Patch||CI||
|[3.11|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-3.11?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1171/#showFailuresLink]|
|[4.0|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-4.0?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1172/#showFailuresLink]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-trunk?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1183/#showFailuresLink]|
I don't see any related issues in the CI runs.
[~blerer], [~ifesdjeen], as you are already familiar with this, does anyone of
you have time for review?
was (Author: e.dimitrova):
I reworked 3.11 and 4.0 and pushed another additional changes for trunk based
on Stefania Alborghetti's patch. (I will add her as author at the end before
commit)
*trunk:* Byte buffers of {{BooleanSerializer}} are now read-only. We cannot
make them on-heap read-only, as we would need to change our code in several key
places which seems not worth it at this point. However, buffers can be off-heap
read-only. Note that this only offers partial protection against put calls done
on the buffer itself. It will not protect, amongst several cases, for put calls
where the read-only buffer is the source, as it was the case in
{{AbstractCompositeType}}. In this case, the position will still be advanced.
To make these buffers completely safe we would need to duplicate them and
accept the additional GC pressure.
||Patch||CI||
|[3.11|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-3.11?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1171/#showFailuresLink]|
|[4.0|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-4.0?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1172/#showFailuresLink]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-trunk?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1183/#showFailuresLink]|
I don't see any related issues in the CI runs.
[~blerer], [~ifesdjeen], as you are already familiar with this, does anyone of
you have time for review?
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
>
[jira] [Comment Edited] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425118#comment-17425118
]
Ekaterina Dimitrova edited comment on CASSANDRA-14752 at 10/6/21, 5:36 PM:
---
I reworked 3.11 and 4.0 and pushed another additional changes for trunk based
on Stefania Alborghetti's patch. (I will add her as author at the end before
commit)
*trunk:* Byte buffers of {{BooleanSerializer}} are now read-only. We cannot
make them on-heap read-only, as we would need to change our code in several key
places which seems not worth it at this point. However, buffers can be off-heap
read-only. Note that this only offers partial protection against put calls done
on the buffer itself. It will not protect, amongst several cases, for put calls
where the read-only buffer is the source, as it was the case in
{{AbstractCompositeType}}. In this case, the position will still be advanced.
To make these buffers completely safe we would need to duplicate them and
accept the additional GC pressure.
||Patch||CI||
|[3.11|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-3.11?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1171/#showFailuresLink]|
|[4.0|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-4.0?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1172/#showFailuresLink]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-trunk?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1183/#showFailuresLink]|
I don't see any related issues in the CI runs.
[~blerer], [~ifesdjeen], as you are already familiar with this, does anyone of
you have time for review?
was (Author: e.dimitrova):
I reworked 3.11 and 4.0 and pushed another additional changes for trunk based
on Stefania Alborghetti's patch. (I will add her as author at the end before
commit)
4.0: Byte buffers of {{BooleanSerializer}} are now read-only. We cannot make
them on-heap read-only, as we would need to change our code in several key
places which seems not worth it at this point. However, buffers can be off-heap
read-only. Note that this only offers partial protection against put calls done
on the buffer itself. It will not protect, amongst several cases, for put calls
where the read-only buffer is the source, as it was the case in
{{AbstractCompositeType}}. In this case, the position will still be advanced.
To make these buffers completely safe we would need to duplicate them and
accept the additional GC pressure.
||Patch||CI||
|[3.11|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-3.11?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1171/#showFailuresLink]|
|[4.0|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-4.0?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1172/#showFailuresLink]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-trunk?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1183/#showFailuresLink]|
I don't see any related issues in the CI runs.
[~blerer], [~ifesdjeen], as you are already familiar with this, does anyone of
you have time for review?
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
>
[jira] [Commented] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425118#comment-17425118
]
Ekaterina Dimitrova commented on CASSANDRA-14752:
-
I reworked 3.11 and 4.0 and pushed another additional changes for trunk based
on Stefania Alborghetti's patch. (I will add her as author at the end before
commit)
4.0: Byte buffers of {{BooleanSerializer}} are now read-only. We cannot make
them on-heap read-only, as we would need to change our code in several key
places which seems not worth it at this point. However, buffers can be off-heap
read-only. Note that this only offers partial protection against put calls done
on the buffer itself. It will not protect, amongst several cases, for put calls
where the read-only buffer is the source, as it was the case in
{{AbstractCompositeType}}. In this case, the position will still be advanced.
To make these buffers completely safe we would need to duplicate them and
accept the additional GC pressure.
||Patch||CI||
|[3.11|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-3.11?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1171/#showFailuresLink]|
|[4.0|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-4.0?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1172/#showFailuresLink]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-trunk?expand=1]|[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1183/#showFailuresLink]|
I don't see any related issues in the CI runs.
[~blerer], [~ifesdjeen], as you are already familiar with this, does anyone of
you have time for review?
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14612) Please add OWASP Dependency Check to the build (pom.xml)
[ https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-14612: -- Resolution: Fixed Status: Resolved (was: Ready to Commit) > Please add OWASP Dependency Check to the build (pom.xml) > > > Key: CASSANDRA-14612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14612 > Project: Cassandra > Issue Type: New Feature > Components: Build > Environment: All development, build, test, environments. >Reporter: Albert Baker >Assignee: Stefan Miklosovic >Priority: Normal > Labels: build, security > Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1 > > Original Estimate: 1h > Remaining Estimate: 1h > > Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an > outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to > perform a lookup for each dependant .jar to list any/all known > vulnerabilities for each jar. This step is needed because a manual MITRE CVE > lookup/check on the main component does not include checking for > vulnerabilities in components or in dependant libraries. > OWASP Dependency check : > https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most > Java build/make types (ant, maven, ivy, gradle). > Also, add the appropriate command to the nightly build to generate a report > of all known vulnerabilities in any/all third party libraries/dependencies > that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false > clean aggregate > Generating this report nightly/weekly will help inform the project's > development team if any dependant libraries have a reported known > vulnerailities. Project teams that keep up with removing vulnerabilities on a > weekly basis will help protect businesses that rely on these open source > componets. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14612) Please add OWASP Dependency Check to the build (pom.xml)
[ https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-14612: -- Status: Review In Progress (was: Patch Available) > Please add OWASP Dependency Check to the build (pom.xml) > > > Key: CASSANDRA-14612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14612 > Project: Cassandra > Issue Type: New Feature > Components: Build > Environment: All development, build, test, environments. >Reporter: Albert Baker >Assignee: Stefan Miklosovic >Priority: Normal > Labels: build, security > Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1 > > Original Estimate: 1h > Remaining Estimate: 1h > > Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an > outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to > perform a lookup for each dependant .jar to list any/all known > vulnerabilities for each jar. This step is needed because a manual MITRE CVE > lookup/check on the main component does not include checking for > vulnerabilities in components or in dependant libraries. > OWASP Dependency check : > https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most > Java build/make types (ant, maven, ivy, gradle). > Also, add the appropriate command to the nightly build to generate a report > of all known vulnerabilities in any/all third party libraries/dependencies > that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false > clean aggregate > Generating this report nightly/weekly will help inform the project's > development team if any dependant libraries have a reported known > vulnerailities. Project teams that keep up with removing vulnerabilities on a > weekly basis will help protect businesses that rely on these open source > componets. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14612) Please add OWASP Dependency Check to the build (pom.xml)
[ https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-14612: -- Status: Ready to Commit (was: Review In Progress) > Please add OWASP Dependency Check to the build (pom.xml) > > > Key: CASSANDRA-14612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14612 > Project: Cassandra > Issue Type: New Feature > Components: Build > Environment: All development, build, test, environments. >Reporter: Albert Baker >Assignee: Stefan Miklosovic >Priority: Normal > Labels: build, security > Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1 > > Original Estimate: 1h > Remaining Estimate: 1h > > Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an > outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to > perform a lookup for each dependant .jar to list any/all known > vulnerabilities for each jar. This step is needed because a manual MITRE CVE > lookup/check on the main component does not include checking for > vulnerabilities in components or in dependant libraries. > OWASP Dependency check : > https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most > Java build/make types (ant, maven, ivy, gradle). > Also, add the appropriate command to the nightly build to generate a report > of all known vulnerabilities in any/all third party libraries/dependencies > that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false > clean aggregate > Generating this report nightly/weekly will help inform the project's > development team if any dependant libraries have a reported known > vulnerailities. Project teams that keep up with removing vulnerabilities on a > weekly basis will help protect businesses that rely on these open source > componets. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16334) Replica failure causes timeout on multi-DC write
[
https://issues.apache.org/jira/browse/CASSANDRA-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov updated CASSANDRA-16334:
-
Description:
Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws a
write error on a single DC keyspace with RF=3:
{noformat}
cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
execute write] message="Operation failed - received 0 responses and 3 failures:
UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN from
/127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses': 1,
'received_responses': 0, 'failures': 3}
{noformat}
The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
{noformat}
cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
out waiting for replica nodes' responses] message="Operation timed out -
received only 0 responses." info={'consistency': 'LOCAL_ONE',
'required_responses': 1, 'received_responses': 0}
{noformat}
Reproduction steps:
{noformat}
# Setup cluster
ccm create -n 3:3 test
for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
~/.ccm/test/node$i/conf/cassandra.yaml; done
ccm start
# Create schema
ccm node1 cqlsh
CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': 3, 'dc2': 3};
CREATE TABLE test.test (key int PRIMARY KEY, val blob);
exit;
# Insert data
python
from cassandra.cluster import Cluster
cluster = Cluster()
session = cluster.connect('test')
blob = f = open("2mbBlob", "rb").read().hex()
session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob +
"'))")
{noformat}
Reproduced in 3.11, trunk.
was:
Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws a
write error on a single DC keyspace with RF=3:
{noformat}
cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
execute write] message="Operation failed - received 0 responses and 3 failures:
UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN from
/127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses': 1,
'received_responses': 0, 'failures': 3}
{noformat}
The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
{noformat}
cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
out waiting for replica nodes' responses] message="Operation timed out -
received only 0 responses." info={'consistency': 'LOCAL_ONE',
'required_responses': 1, 'received_responses': 0}
{noformat}
Reproduction steps:
{noformat}
# Setup cluster
ccm create -n 3:3 test
for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
~/.ccm/test/node$i/conf/cassandra.yaml; done
ccm start
# Create schema
ccm node1 cqlsh
CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': 3, 'dc2': 3};
CREATE TABLE test.test (key int PRIMARY KEY, val blob);
exit;
# Insert data
python
from cassandra.cluster import Cluster
session = cluster.connect('test')
blob = f = open("2mbBlob", "rb").read().hex()
session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob +
"'))")
{noformat}
Reproduced in 3.11, trunk.
> Replica failure causes timeout on multi-DC write
>
>
> Key: CASSANDRA-16334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16334
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Messaging/Internode
>Reporter: Paulo Motta
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
>
> Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws
> a write error on a single DC keyspace with RF=3:
> {noformat}
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 0 responses and 3
> failures: UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN
> from /127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 3}
> {noformat}
> The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
> {noformat}
> cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
> out waiting for replica nodes' responses] message="Operation timed out -
> received only 0 responses." info={'consistency': 'LOCAL_ONE',
> 'required_responses': 1, 'received_responses': 0}
> {noformat}
> Reproduction steps:
> {noformat}
> # Setup cluster
> ccm create -n 3:3 test
> for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
> ~/.ccm/test/node$i/conf/cassandra.yaml; done
> ccm start
> # Create schema
> ccm node1 cqlsh
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': 3, 'dc2': 3};
>
[jira] [Commented] (CASSANDRA-16334) Replica failure causes timeout on multi-DC write
[
https://issues.apache.org/jira/browse/CASSANDRA-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425115#comment-17425115
]
Aleksandr Sorokoumov commented on CASSANDRA-16334:
--
This bug happens in the
[AbstractWriteResponseHandler#onFailure|https://github.com/apache/cassandra/blob/2e2db4dc40c4935305b9a2d5d271580e96dabe42/src/java/org/apache/cassandra/service/AbstractWriteResponseHandler.java#L252-L265]:
{code}
@Override
public void onFailure(InetAddressAndPort from, RequestFailureReason
failureReason)
{
logger.trace("Got failure from {}", from);
int n = waitingFor(from)
? failuresUpdater.incrementAndGet(this)
: failures;
failureReasonByEndpoint.put(from, failureReason);
if (blockFor() + n > candidateReplicaCount())
signal();
}
{code}
In the reproduction steps, {{INSERT INTO TEST}} uses CL {{LOCAL_ONE}}.
Accordingly,
[DatacenterWriteResponseHandler#waitingFor|https://github.com/apache/cassandra/blob/2e2db4dc40c4935305b9a2d5d271580e96dabe42/src/java/org/apache/cassandra/service/DatacenterWriteResponseHandler.java#L59-L63]
only waits for the local nodes:
{code}
private final Predicate waitingFor =
InOurDcTester.endpoints();
@Override
protected boolean waitingFor(InetAddressAndPort from)
{
return waitingFor.test(from);
}
{code}
[AbstractWriteResponseHandler#candidateReplicaCount()|https://github.com/apache/cassandra/blob/2e2db4dc40c4935305b9a2d5d271580e96dabe42/src/java/org/apache/cassandra/service/AbstractWriteResponseHandler.java#L205-L213]
in the condition above, however, counts live and down replicas in ALL DCs as
valid candidates:
{code}
protected int candidateReplicaCount()
{
return replicaPlan.liveAndDown().size();
}
{code}
As a result, even after all local nodes respond with {{FAILURE_RSP}}, the
coordinator waits for responses from nodes in other DCs... but never counts
them in.
There is more! Following the timeout or request failure, the coordinator
creates hints for the nodes in other DCs which it will try to deliver forever.
> Replica failure causes timeout on multi-DC write
>
>
> Key: CASSANDRA-16334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16334
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Messaging/Internode
>Reporter: Paulo Motta
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
>
> Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws
> a write error on a single DC keyspace with RF=3:
> {noformat}
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 0 responses and 3
> failures: UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN
> from /127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 3}
> {noformat}
> The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
> {noformat}
> cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
> out waiting for replica nodes' responses] message="Operation timed out -
> received only 0 responses." info={'consistency': 'LOCAL_ONE',
> 'required_responses': 1, 'received_responses': 0}
> {noformat}
> Reproduction steps:
> {noformat}
> # Setup cluster
> ccm create -n 3:3 test
> for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
> ~/.ccm/test/node$i/conf/cassandra.yaml; done
> ccm start
> # Create schema
> ccm node1 cqlsh
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': 3, 'dc2': 3};
> CREATE TABLE test.test (key int PRIMARY KEY, val blob);
> exit;
> # Insert data
> python
> from cassandra.cluster import Cluster
> session = cluster.connect('test')
> blob = f = open("2mbBlob", "rb").read().hex()
> session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob
> + "'))")
> {noformat}
> Reproduced in 3.11, trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16839) Truncation snapshots unnecessarily created on node startup
[
https://issues.apache.org/jira/browse/CASSANDRA-16839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425071#comment-17425071
]
Brandon Williams commented on CASSANDRA-16839:
--
This is caused by CASSANDRA-15776 truncating these tables via CQL, which does
not have a mechanism for truncation without snapshotting. I actually couldn't
find a way to truncate without snapshotting, so this patch adds one, uses it
instead, and additionally replaces the other two truncateBlocking instances
that generate snapshots for prepared statements and available ranges.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-16839-4.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16839-4.0],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1184/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1184/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16839-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16839-trunk],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1185/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1185/pipeline]|
> Truncation snapshots unnecessarily created on node startup
> --
>
> Key: CASSANDRA-16839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16839
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> When testing cassandra 4.0 on ccm I noticed that everytime I restart a node,
> truncation snapshots are created for the tables {{system.table_estimates}}
> and {{system.size_estimates}}:
> {noformat}
> $ ccm create -n 1 test -s
> $ ccm node1 stop
> $ ccm node1 start
> $ ccm node1 stop
> $ ccm node1 start
> $ ccm node1 nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True
> size Size on disk
> truncated-1628599001857-table_estimates systemtable_estimates0
> bytes 13 bytes
> truncated-1628599099560-table_estimates systemtable_estimates0
> bytes 13 bytes
> truncated-1628599001736-size_estimates systemsize_estimates 0
> bytes 13 bytes
> truncated-1628599057438-table_estimates systemtable_estimates6.16
> KiB 6.19 KiB
> truncated-1628599099458-size_estimates systemsize_estimates 0
> bytes 13 bytes
> truncated-1628599057340-size_estimates systemsize_estimates 5.73
> KiB 5.76 KiB
> Total TrueDiskSpaceUsed: 0 bytes
> {noformat}
> Not sure if this is expected behavior, but feels like a bug to me.
> Reproduced on 4.0, not sure if it reproduces on lower versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-16839) Truncation snapshots unnecessarily created on node startup
[
https://issues.apache.org/jira/browse/CASSANDRA-16839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16839:
-
Comment: was deleted
(was: This is caused by CASSANDRA-15776 truncating these tables via CQL, which
does not have a mechanism for truncation without snapshotting. Instead if we
don't use CQL we can invoke ColumnFamilyStore.discardSSTables.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-16839-4.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16839-4.0],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1180/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1180/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16839-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16839-trunk],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1181/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1181/pipeline]|
)
> Truncation snapshots unnecessarily created on node startup
> --
>
> Key: CASSANDRA-16839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16839
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> When testing cassandra 4.0 on ccm I noticed that everytime I restart a node,
> truncation snapshots are created for the tables {{system.table_estimates}}
> and {{system.size_estimates}}:
> {noformat}
> $ ccm create -n 1 test -s
> $ ccm node1 stop
> $ ccm node1 start
> $ ccm node1 stop
> $ ccm node1 start
> $ ccm node1 nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True
> size Size on disk
> truncated-1628599001857-table_estimates systemtable_estimates0
> bytes 13 bytes
> truncated-1628599099560-table_estimates systemtable_estimates0
> bytes 13 bytes
> truncated-1628599001736-size_estimates systemsize_estimates 0
> bytes 13 bytes
> truncated-1628599057438-table_estimates systemtable_estimates6.16
> KiB 6.19 KiB
> truncated-1628599099458-size_estimates systemsize_estimates 0
> bytes 13 bytes
> truncated-1628599057340-size_estimates systemsize_estimates 5.73
> KiB 5.76 KiB
> Total TrueDiskSpaceUsed: 0 bytes
> {noformat}
> Not sure if this is expected behavior, but feels like a bug to me.
> Reproduced on 4.0, not sure if it reproduces on lower versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16839) Truncation snapshots unnecessarily created on node startup
[
https://issues.apache.org/jira/browse/CASSANDRA-16839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424710#comment-17424710
]
Brandon Williams edited comment on CASSANDRA-16839 at 10/6/21, 1:08 PM:
This is caused by CASSANDRA-15776 truncating these tables via CQL, which does
not have a mechanism for truncation without snapshotting. Instead if we don't
use CQL we can invoke ColumnFamilyStore.discardSSTables.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-16839-4.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16839-4.0],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1180/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1180/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16839-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16839-trunk],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1181/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1181/pipeline]|
was (Author: brandon.williams):
This is caused by CASSANDRA-15776 truncating these tables via CQL, which does
not have a mechanism for truncation without snapshotting. Instead if we don't
use CQL we can invoke ColumnFamilyStore.discardSSTables.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-16839-4.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16839-4.0],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1176/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1176/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16839-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16839-trunk],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1177/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1177/pipeline]|
> Truncation snapshots unnecessarily created on node startup
> --
>
> Key: CASSANDRA-16839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16839
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> When testing cassandra 4.0 on ccm I noticed that everytime I restart a node,
> truncation snapshots are created for the tables {{system.table_estimates}}
> and {{system.size_estimates}}:
> {noformat}
> $ ccm create -n 1 test -s
> $ ccm node1 stop
> $ ccm node1 start
> $ ccm node1 stop
> $ ccm node1 start
> $ ccm node1 nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True
> size Size on disk
> truncated-1628599001857-table_estimates systemtable_estimates0
> bytes 13 bytes
> truncated-1628599099560-table_estimates systemtable_estimates0
> bytes 13 bytes
> truncated-1628599001736-size_estimates systemsize_estimates 0
> bytes 13 bytes
> truncated-1628599057438-table_estimates systemtable_estimates6.16
> KiB 6.19 KiB
> truncated-1628599099458-size_estimates systemsize_estimates 0
> bytes 13 bytes
> truncated-1628599057340-size_estimates systemsize_estimates 5.73
> KiB 5.76 KiB
> Total TrueDiskSpaceUsed: 0 bytes
> {noformat}
> Not sure if this is expected behavior, but feels like a bug to me.
> Reproduced on 4.0, not sure if it reproduces on lower versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17024) Artificial Latency Injection
[
https://issues.apache.org/jira/browse/CASSANDRA-17024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-17024:
---
Impacts: Clients (was: None)
Test and Documentation Plan: Additional dtest for injecting LWT latency
Status: Patch Available (was: Open)
[Patch|https://github.com/belliottsmith/cassandra/tree/17024-trunk]
> Artificial Latency Injection
>
>
> Key: CASSANDRA-17024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17024
> Project: Cassandra
> Issue Type: New Feature
> Components: Messaging/Internode
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.x
>
>
> *Motivation*
> Cassandra aims to enable user’s applications to continue to function in the
> presence of major incidents. To support this clusters must support
> high-availability topologies, i.e. at present at least 3 DCs at remote
> distances from each other. Operators wanting to migrate clusters initially
> created in topologies that do not support this capability, or to move from
> LOCAL_X to (GLOBAL) X consistency levels, have no mechanism for determining
> the viability of the strategy for their applications. This is particularly
> critical for applications that use LWTs, for which the degradation may be
> unpredictable due to contention effects.
> *Goals*
> Support cluster-wide latency injection for some subset of messages
> User Impact
> *User Impact*
> Users will be able to specify the set of Verbs that should be affected, and
> also which queries within their client-side application.
> Clients will be supported by the introduction of new {{UNSAFE_DELAY_X}}
> consistency levels that mark queries as suitable to experience additional
> artificial latency.
> Latency will be controlled by JMX properties specifying whether only
> {{UNSAFE_DELAY_X}} operations are affected, alongside which verbs and the
> length of the delay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17024) Artificial Latency Injection
[
https://issues.apache.org/jira/browse/CASSANDRA-17024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-17024:
---
Change Category: Semantic
Complexity: Normal
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Artificial Latency Injection
>
>
> Key: CASSANDRA-17024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17024
> Project: Cassandra
> Issue Type: New Feature
> Components: Messaging/Internode
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.x
>
>
> *Motivation*
> Cassandra aims to enable user’s applications to continue to function in the
> presence of major incidents. To support this clusters must support
> high-availability topologies, i.e. at present at least 3 DCs at remote
> distances from each other. Operators wanting to migrate clusters initially
> created in topologies that do not support this capability, or to move from
> LOCAL_X to (GLOBAL) X consistency levels, have no mechanism for determining
> the viability of the strategy for their applications. This is particularly
> critical for applications that use LWTs, for which the degradation may be
> unpredictable due to contention effects.
> *Goals*
> Support cluster-wide latency injection for some subset of messages
> User Impact
> *User Impact*
> Users will be able to specify the set of Verbs that should be affected, and
> also which queries within their client-side application.
> Clients will be supported by the introduction of new {{UNSAFE_DELAY_X}}
> consistency levels that mark queries as suitable to experience additional
> artificial latency.
> Latency will be controlled by JMX properties specifying whether only
> {{UNSAFE_DELAY_X}} operations are affected, alongside which verbs and the
> length of the delay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17017) Add required -f / --force option to nodetool verify
[ https://issues.apache.org/jira/browse/CASSANDRA-17017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424966#comment-17424966 ] Brandon Williams commented on CASSANDRA-17017: -- There's definitely a test that uses it, I just fixed it in CASSANDRA-16948 > Add required -f / --force option to nodetool verify > --- > > Key: CASSANDRA-17017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17017 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > nodetool verify has some pretty significant problems with it (see > CASSANDRA-9947). > Until such time as we do the heavy(er) lift to fix the command, we should > make it harder for people to shoot themselves in the foot with it. Adding a > required "-f" flag to it with a requisite "Do you really know what you're > doing? Check out this JIRA first" seems like it'd be the right thing to do in > the interim. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17024) Artificial Latency Injection
Benedict Elliott Smith created CASSANDRA-17024:
--
Summary: Artificial Latency Injection
Key: CASSANDRA-17024
URL: https://issues.apache.org/jira/browse/CASSANDRA-17024
Project: Cassandra
Issue Type: New Feature
Components: Messaging/Internode
Reporter: Benedict Elliott Smith
Assignee: Benedict Elliott Smith
*Motivation*
Cassandra aims to enable user’s applications to continue to function in the
presence of major incidents. To support this clusters must support
high-availability topologies, i.e. at present at least 3 DCs at remote
distances from each other. Operators wanting to migrate clusters initially
created in topologies that do not support this capability, or to move from
LOCAL_X to (GLOBAL) X consistency levels, have no mechanism for determining the
viability of the strategy for their applications. This is particularly critical
for applications that use LWTs, for which the degradation may be unpredictable
due to contention effects.
*Goals*
Support cluster-wide latency injection for some subset of messages
User Impact
*User Impact*
Users will be able to specify the set of Verbs that should be affected, and
also which queries within their client-side application.
Clients will be supported by the introduction of new {{UNSAFE_DELAY_X}}
consistency levels that mark queries as suitable to experience additional
artificial latency.
Latency will be controlled by JMX properties specifying whether only
{{UNSAFE_DELAY_X}} operations are affected, alongside which verbs and the
length of the delay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17018) WEBSITE - October 2021 blog post for Apache Cassandra Changelog #10
[ https://issues.apache.org/jira/browse/CASSANDRA-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17018: --- Status: Patch Available (was: Open) > WEBSITE - October 2021 blog post for Apache Cassandra Changelog #10 > --- > > Key: CASSANDRA-17018 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17018 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the October > 2021 blog post for the Apache Cassandra Changelog #10. > We can close this once the blog post has gone live on the website. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17018) WEBSITE - October 2021 blog post for Apache Cassandra Changelog #10
[ https://issues.apache.org/jira/browse/CASSANDRA-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17018: --- Status: Review In Progress (was: Patch Available) > WEBSITE - October 2021 blog post for Apache Cassandra Changelog #10 > --- > > Key: CASSANDRA-17018 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17018 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the October > 2021 blog post for the Apache Cassandra Changelog #10. > We can close this once the blog post has gone live on the website. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17018) WEBSITE - October 2021 blog post for Apache Cassandra Changelog #10
[ https://issues.apache.org/jira/browse/CASSANDRA-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17018: --- Reviewers: Anthony Grasso, Benjamin Lerer, Erick Ramirez (was: Anthony Grasso, Erick Ramirez, Michael Semb Wever) Status: Open (was: Triage Needed) > WEBSITE - October 2021 blog post for Apache Cassandra Changelog #10 > --- > > Key: CASSANDRA-17018 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17018 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the October > 2021 blog post for the Apache Cassandra Changelog #10. > We can close this once the blog post has gone live on the website. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14795) Expose information about stored hints via JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424934#comment-17424934
]
Aleksandr Sorokoumov commented on CASSANDRA-14795:
--
Thank you for the review [~stefan.miklosovic]!
I do not think that CASSANDRA-14309 collides with this patch. Brief review of
the code did not show any conceptual clash - the changes in 14309 should not be
affected by the changes in my patch. I also cherry-picked
[https://github.com/instaclustr/cassandra/tree/CASSANDRA-14309] and
[https://github.com/apache/cassandra-dtest/pull/153.] Resolving git conflicts
was trivial and all tests added by both patches passed.
> Expose information about stored hints via JMX
> -
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14795) Expose information about stored hints via JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424905#comment-17424905
]
Stefan Miklosovic commented on CASSANDRA-14795:
---
I would like to know if this patch collides with (1) and if it does, what
impact it has, mostly related to timestamps here. By mere looking, I do not
think that the logic / code introduced here would interfere with that patch.
Just something to raise awareness of as I would like to merge that one sooner
or later and I do not want to break other stuff.
Otherwise I am fine with this.
https://issues.apache.org/jira/browse/CASSANDRA-14309
> Expose information about stored hints via JMX
> -
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16882) Save CircleCI resources with optional test jobs
[ https://issues.apache.org/jira/browse/CASSANDRA-16882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424879#comment-17424879 ] Berenguer Blasi commented on CASSANDRA-16882: - I don't have a strong preference here but lgtm so far. +1 > Save CircleCI resources with optional test jobs > --- > > Key: CASSANDRA-16882 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16882 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > This ticket implements the addition of approval steps in the CircleCI > workflows as it was proposed in [this > email|https://lists.apache.org/thread.html/r57bab800d037c087af01b3779fd266d83b538cdd29c120f74a5dbe63%40%3Cdev.cassandra.apache.org%3E] > sent to the dev list: > The current CircleCI configuration automatically runs the unit tests, JVM > dtests and cqhshlib tests. This is done by default for every commit or, with > some configuration, for every push. > Along the lifecycle of a ticket it is quite frequent to have multiple commits > and pushes, all running these test jobs. I'd say that frequently it is not > necessary to run the tests for some of those intermediate commits and pushes. > For example, one can show proofs of concept, or have multiple rounds of > review before actually running the tests. Running the tests for every change > can produce an unnecessary expense of CircleCI resources. > I think we could make running those tests optional, as well as clearly > specifying in the documentation what are the tests runs that are mandatory > before actually committing. We could do this in different ways: > # Make the entire CircleCI workflow optional, so the build job requires > manual approval. Once the build is approved the mandatory test jobs would > be run without any further approval, exactly as it's currently done. > # Make all the test jobs optional, so every test job requires manual > approval, and the documentation specifies which tests are mandatory in the > final steps of a ticket. > # Make all the mandatory test jobs depend on a single optional job, so we > have a single button to optionally run all the mandatory tests. > I think any of these changes, or a combination of them, would significantly > reduce the usage of resources without making things less tested. The only > downside I can think of is that we would need some additional clicks on the > CircleCI GUI. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16882) Save CircleCI resources with optional test jobs
[ https://issues.apache.org/jira/browse/CASSANDRA-16882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16882: Reviewers: Berenguer Blasi, Ekaterina Dimitrova (was: Ekaterina Dimitrova) > Save CircleCI resources with optional test jobs > --- > > Key: CASSANDRA-16882 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16882 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > This ticket implements the addition of approval steps in the CircleCI > workflows as it was proposed in [this > email|https://lists.apache.org/thread.html/r57bab800d037c087af01b3779fd266d83b538cdd29c120f74a5dbe63%40%3Cdev.cassandra.apache.org%3E] > sent to the dev list: > The current CircleCI configuration automatically runs the unit tests, JVM > dtests and cqhshlib tests. This is done by default for every commit or, with > some configuration, for every push. > Along the lifecycle of a ticket it is quite frequent to have multiple commits > and pushes, all running these test jobs. I'd say that frequently it is not > necessary to run the tests for some of those intermediate commits and pushes. > For example, one can show proofs of concept, or have multiple rounds of > review before actually running the tests. Running the tests for every change > can produce an unnecessary expense of CircleCI resources. > I think we could make running those tests optional, as well as clearly > specifying in the documentation what are the tests runs that are mandatory > before actually committing. We could do this in different ways: > # Make the entire CircleCI workflow optional, so the build job requires > manual approval. Once the build is approved the mandatory test jobs would > be run without any further approval, exactly as it's currently done. > # Make all the test jobs optional, so every test job requires manual > approval, and the documentation specifies which tests are mandatory in the > final steps of a ticket. > # Make all the mandatory test jobs depend on a single optional job, so we > have a single button to optionally run all the mandatory tests. > I think any of these changes, or a combination of them, would significantly > reduce the usage of resources without making things less tested. The only > downside I can think of is that we would need some additional clicks on the > CircleCI GUI. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: Added blog post and card to blog index
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new b7b6e8b Added blog post and card to blog index b7b6e8b is described below commit b7b6e8bd1a8e81a4ea7741124e8938059dabac40 Author: Diogenese Topper AuthorDate: Thu Sep 30 15:49:03 2021 -0700 Added blog post and card to blog index - Blog post is titled "Apache Cassandra Changelog #10" - Modified blog index page for added blog --- site-content/source/modules/ROOT/pages/blog.adoc | 25 ++ ...Apache-Cassandra-Changelog-10-October-2021.adoc | 93 ++ 2 files changed, 118 insertions(+) diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index 268f404..e73eb44 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -14,6 +14,31 @@ NOTES FOR CONTENT CREATORS [openblock,card-header] -- [discrete] +=== Apache Cassandra Changelog #10 +[discrete] + October 5, 2021 +-- +[openblock,card-content] +-- +Apache Cassandra 4.0.1 is released, and Aleksei Zotov becomes a committer. Discussions are underway for some key, new feature proposals, including support for general-purpose transactions and Storage Attached Index (SAI). CEP-11, the pluggable memtable implementations proposal, has been approved, as has CEP-13 for a denylisting partitions feature.l-making. + +[openblock,card-btn card-btn--blog] + + +[.btn.btn--alt] +xref:blog/Apache-Cassandra-Changelog-10-October-2021.adoc[Read More] + + +-- + +//end card + +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] === Join Cassandra at Apachecon 2021 [discrete] August 27, 2021 diff --git a/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-Changelog-10-October-2021.adoc b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-Changelog-10-October-2021.adoc new file mode 100644 index 000..f8f9c81 --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-Changelog-10-October-2021.adoc @@ -0,0 +1,93 @@ += Apache Cassandra Changelog #10 +:page-layout: single-post +:page-role: blog-post +:page-post-date: October 5, 2021 +:page-post-author: The Apache Cassandra Community +:description: The Apache Cassandra Community +:keywords: + +image::blog/changelog_header.jpg[Apache Cassandra Changelog] +Our monthly roundup of key activities and knowledge to keep the community informed. + +== Release Notes +=== Released + +The latest release of Apache Cassandra is https://www.apache.org/dyn/closer.lua/cassandra/4.0.1[4.0.1,window=_blank] (https://archive.apache.org/dist/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.asc[pgp,window=_blank], https://archive.apache.org/dist/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha256[sha256,window=_blank], and https://archive.apache.org/dist/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha512[sha512). This is a rapid release to fix a https://issues.apache [...] + +Note: As the docs are not yet updated, the bintray location for Debian users is replaced with the https://apache.jfrog.io/artifactory/cassandra/[ASF's JFrog Artifactory location,window=_blank]. + +See the https://cassandra.apache.org/download/[download section] for the latest stable and older supported versions of source and binary distributions. + +To stay up-to-date, we recommend joining the Cassandra xref:community.adoc#join-the-conversation[mailing list]. + +== Community Notes + +_Updates on Cassandra Enhancement Proposals (CEPs), how to contribute, and other community activities._ + +_Are you new to the project? We have established a https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484.[New Release tracking Kanboard,window=_blank] and a "https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484=2162=2160[Starter Tickets,window=_blank]" quick label that corresponds to our Low Hanging Fruit status. Any of these tickets should be of appropriate complexity for someone new to the project to tackle._ + +Read PMC member Josh McKenzie’s https://lists.apache.org/list.html?d...@cassandra.apache.org:2021-9[bi-weekly update,window=_blank] for ongoing discussions and the latest on ticket progress. + +=== Added + +The Project Management Committee (PMC) is pleased to announce that *Aleksei Zotov* has been invited to https://lists.apache.org/thread.html/r6ff82e48720931055f5eb0bc494434f5be7959ef78345a642a980419%40%3Cdev.cassandra.apache.org%3E[become a committer,window=_blank], and he has accepted! Thank you for all your contributions over the years, Aleksei, and congratulations! + +=== Discussed + +After the release of Apache Cassandra 4.0, we have many proposed
[jira] [Comment Edited] (CASSANDRA-17017) Add required -f / --force option to nodetool verify
[
https://issues.apache.org/jira/browse/CASSANDRA-17017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424789#comment-17424789
]
Berenguer Blasi edited comment on CASSANDRA-17017 at 10/6/21, 7:25 AM:
---
Your new docs change test fails on circle and can you trigger dtests please? I
wouldn't be surprised if some dtest used {{sstableverify}} which should fail
now (i.e. offline_tools_test.py).
was (Author: bereng):
Your new docs change test fails on circle and can you trigger dtests please? I
wouldn't be surprised if some dtest used {{sstableverify}} which should fail
now.
> Add required -f / --force option to nodetool verify
> ---
>
> Key: CASSANDRA-17017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17017
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> nodetool verify has some pretty significant problems with it (see
> CASSANDRA-9947).
> Until such time as we do the heavy(er) lift to fix the command, we should
> make it harder for people to shoot themselves in the foot with it. Adding a
> required "-f" flag to it with a requisite "Do you really know what you're
> doing? Check out this JIRA first" seems like it'd be the right thing to do in
> the interim.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
