[jira] [Commented] (CASSANDRA-17737) Validate that JMX updates properly any properties that were moved to the new config classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571189#comment-17571189 ] Ekaterina Dimitrova commented on CASSANDRA-17737: - Restarted some of the 4.1 and trunk Python tests which failed due to environmental problem > Validate that JMX updates properly any properties that were moved to the new > config classes > --- > > Key: CASSANDRA-17737 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17737 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1-beta, 4.1.x, 4.x > > > Check that any properties moved to the new types in 4.1 (Duration, Data > Storage, Data Rate) are always updated by JMX and there are no inconsistent > validations that might cover bugs. Validate proper update in Settings Virtual > Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > *DataRateSpec* - entire_sstable_stream_throughput_outbound, > inter_dc_stream_throughput_outbound, > entire_sstable_inter_dc_stream_throughput_outbound, compaction_throughput, > stream_throughput_outbound - we have setGet* tests and those seem solid, no > issues found. > *DurationSpec* - gc_log_threshold, permissions_validity, denylist_refresh, > request_timeout, hints_flush_period, read_request_timeout, > index_summary_resize_interval, streaming_keep_alive_period, max_hint_window, > roles_update_interval, user_defined_functions_fail_timeout, > write_request_timeout, cdc_free_space_check_interval, roles_validity, > internode_streaming_tcp_user_timeout, gc_warn_threshold, > range_request_timeout, credentials_update_interval, truncate_request_timeout, > cas_contention_timeout, periodic_commitlog_sync_lag_block, > streaming_state_expires, repair_request_timeout, permissions_update_interval, > dynamic_snitch_reset_interval, internode_tcp_connect_timeout, > paxos_purge_grace_period, dynamic_snitch_update_interval, > trace_type_query_ttl, denylist_initial_load_retry, commitlog_sync_period, > native_transport_idle_timeout, credentials_validity, > validation_preview_purge_head_start, repair_state_expires, > internode_tcp_user_timeout, trace_type_repair_ttl, cache_load_timeout, > commitlog_sync_group_window, slow_query_log_timeout, > counter_write_request_timeout, user_defined_functions_warn_timeout > *DataStorageSpec* - > internode_application_send_queue_reserve_endpoint_capacity, cdc_total_space, > networking_cache_size, commitlog_total_space, > internode_application_send_queue_capacity, key_cache_size, > memtable_heap_space, trickle_fsync_interval, max_hints_size_per_host, > internode_application_receive_queue_reserve_endpoint_capacity, > native_transport_max_frame_size, coordinator_read_size_warn_threshold , > internode_application_receive_queue_reserve_global_capacity, > internode_max_message_size, file_cache_size, local_read_size_fail_threshold, > data_disk_usage_max_disk_size, memtable_offheap_space, > coordinator_read_size_fail_threshold, counter_cache_size, > prepared_statements_cache_size, batchlog_replay_throttle, > row_index_read_size_fail_threshold, index_summary_capacity, > repair_session_space, paxos_cache_size, collection_size_fail_threshold, > internode_application_send_queue_reserve_global_capacity, column_index_size, > native_transport_receive_queue_capacity, sstable_preemptive_open_interval, > max_mutation_size, min_free_space_per_drive, batch_size_fail_threshold, > hinted_handoff_throttle, row_index_read_size_warn_threshold, max_value_size, > column_index_cache_size, compaction_large_partition_warning_threshold, > max_hints_file_size, collection_size_warn_threshold, > native_transport_max_request_data_in_flight, > internode_socket_receive_buffer_size, > internode_application_receive_queue_capacity, > internode_socket_send_buffer_size, row_cache_size, > min_tracked_partition_size, local_read_size_warn_threshold, > commitlog_segment_size, batch_size_warn_threshold, streaming_state_size, > native_transport_max_request_data_in_flight_per_ip > NOTE: Some of those were checked/fixed in other tickets but I post the full > lists for completeness -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail:
[jira] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571175#comment-17571175
]
Brad Schoening edited comment on CASSANDRA-17667 at 7/26/22 3:52 AM:
-
[~ahomoki], looking at this a little further, safescanner.py, which inherits
from the python re.Scanner, is tokenizing the input. An example from
[https://mail.python.org/pipermail/python-dev/2003-April/035075.html] shows how
input is parsed:
{code:java}
import re
def s_ident(scanner, token): return token
def s_operator(scanner, token): return "op%s" % token
def s_float(scanner, token): return float(token)
def s_int(scanner, token): return int(token)
scanner = re.Scanner([
(r"[a-zA-Z_]\w*", s_ident),
(r"\d+\.\d*", s_float),
(r"\d+", s_int),
(r"=|\+|-|\*|/", s_operator),
(r"\s+", None),
])
# sanity check
test('scanner.scan("sum = 3*foo + 312.50 + bar")',
(['sum', 'op=', 3, 'op*', 'foo', 'op+', 312.5, 'op+', 'bar'], ''))
{code}
In pylexotron this is implemented as:
{code:java}
RuleSpecScanner = SaferScanner([
(r'::=', lambda s, t: t),
(r'\[[a-z0-9_]+\]=', lambda s, t: ('named_collector', t[1:-2])),
(r'[a-z0-9_]+=', lambda s, t: ('named_symbol', t[:-1])),
(r'/(\[\^?.[^]]*\]|[^/]|\\.)*/', lambda s, t: ('regex',
t[1:-1].replace(r'\/', '/'))),
(r'"([^"]|\\.)*"', lambda s, t: ('litstring', t)),
(r'<[^>]*>', lambda s, t: ('reference', t[1:-1])),
(r'\bJUNK\b', lambda s, t: ('junk', t)),
(r'[@()|?*;]', lambda s, t: t),
(r'\s+', None),
(r'#[^\n]*', None),
], re.I | re.S | re.U) {code}
r'\s+' is skipping whitespace
I'm uncertain what r'#[^\n]*' and r'\bJUNK\b' are doing. Adding comments could
be helpful.
The Scanner flags used are re.I | re.S | re.U for IgnoreCase, DotAll and
Unicode, but it doesn't use re.M for Multiline. So, either that could be added
if it doesn't break anything, or the tokenizer would have to tokenize a start
comment and end comment token.
There doesn't seem to be unit tests for pylexotron or SafeScanner, however.
That might be a good thing to add. There could be tests for each type of
token, named_collector, named_symbol, regex, litstring, reference and junk.
was (Author: bschoeni):
[~ahomoki], looking at this a little further, safescanner.py, which inherits
from the python re.Scanner, is tokenizing the input. An example from
[https://mail.python.org/pipermail/python-dev/2003-April/035075.html] shows
input is parsed:
{code:java}
import re
def s_ident(scanner, token): return token
def s_operator(scanner, token): return "op%s" % token
def s_float(scanner, token): return float(token)
def s_int(scanner, token): return int(token)
scanner = re.Scanner([
(r"[a-zA-Z_]\w*", s_ident),
(r"\d+\.\d*", s_float),
(r"\d+", s_int),
(r"=|\+|-|\*|/", s_operator),
(r"\s+", None),
])
# sanity check
test('scanner.scan("sum = 3*foo + 312.50 + bar")',
(['sum', 'op=', 3, 'op*', 'foo', 'op+', 312.5, 'op+', 'bar'], ''))
{code}
In pylexotron this is implemented as:
{code:java}
RuleSpecScanner = SaferScanner([
(r'::=', lambda s, t: t),
(r'\[[a-z0-9_]+\]=', lambda s, t: ('named_collector', t[1:-2])),
(r'[a-z0-9_]+=', lambda s, t: ('named_symbol', t[:-1])),
(r'/(\[\^?.[^]]*\]|[^/]|\\.)*/', lambda s, t: ('regex',
t[1:-1].replace(r'\/', '/'))),
(r'"([^"]|\\.)*"', lambda s, t: ('litstring', t)),
(r'<[^>]*>', lambda s, t: ('reference', t[1:-1])),
(r'\bJUNK\b', lambda s, t: ('junk', t)),
(r'[@()|?*;]', lambda s, t: t),
(r'\s+', None),
(r'#[^\n]*', None),
], re.I | re.S | re.U) {code}
r'\s+' is skipping whitespace
I'm uncertain what r'#[^\n]*' and r'\bJUNK\b' are doing. Adding comments could
be helpful.
The Scanner flags used are re.I | re.S | re.U for IgnoreCase, DotAll and
Unicode, but it doesn't use re.M for Multiline. So, either that could be added
if it doesn't break anything, or the tokenizer would have to tokenize a start
comment and end comment token.
There doesn't seem to be unit tests for pylexotron or SafeScanner, however.
That might be a good thing to add. There could be tests for each type of
token, named_collector, named_symbol, regex, litstring, reference and junk.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of
[jira] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571175#comment-17571175
]
Brad Schoening edited comment on CASSANDRA-17667 at 7/26/22 3:26 AM:
-
[~ahomoki], looking at this a little further, safescanner.py, which inherits
from the python re.Scanner, is tokenizing the input. An example from
[https://mail.python.org/pipermail/python-dev/2003-April/035075.html] shows
input is parsed:
{code:java}
import re
def s_ident(scanner, token): return token
def s_operator(scanner, token): return "op%s" % token
def s_float(scanner, token): return float(token)
def s_int(scanner, token): return int(token)
scanner = re.Scanner([
(r"[a-zA-Z_]\w*", s_ident),
(r"\d+\.\d*", s_float),
(r"\d+", s_int),
(r"=|\+|-|\*|/", s_operator),
(r"\s+", None),
])
# sanity check
test('scanner.scan("sum = 3*foo + 312.50 + bar")',
(['sum', 'op=', 3, 'op*', 'foo', 'op+', 312.5, 'op+', 'bar'], ''))
{code}
In pylexotron this is implemented as:
{code:java}
RuleSpecScanner = SaferScanner([
(r'::=', lambda s, t: t),
(r'\[[a-z0-9_]+\]=', lambda s, t: ('named_collector', t[1:-2])),
(r'[a-z0-9_]+=', lambda s, t: ('named_symbol', t[:-1])),
(r'/(\[\^?.[^]]*\]|[^/]|\\.)*/', lambda s, t: ('regex',
t[1:-1].replace(r'\/', '/'))),
(r'"([^"]|\\.)*"', lambda s, t: ('litstring', t)),
(r'<[^>]*>', lambda s, t: ('reference', t[1:-1])),
(r'\bJUNK\b', lambda s, t: ('junk', t)),
(r'[@()|?*;]', lambda s, t: t),
(r'\s+', None),
(r'#[^\n]*', None),
], re.I | re.S | re.U) {code}
r'\s+' is skipping whitespace
I'm uncertain what r'#[^\n]*' and r'\bJUNK\b' are doing. Adding comments could
be helpful.
The Scanner flags used are re.I | re.S | re.U for IgnoreCase, DotAll and
Unicode, but it doesn't use re.M for Multiline. So, either that could be added
if it doesn't break anything, or the tokenizer would have to tokenize a start
comment and end comment token.
There doesn't seem to be unit tests for pylexotron or SafeScanner, however.
That might be a good thing to add. There could be tests for each type of
token, named_collector, named_symbol, regex, litstring, reference and junk.
was (Author: bschoeni):
[~ahomoki], looking at this a little further, safescanner.py, which inherits
from the python re.Scanner, is tokenizing the input. An example from
[https://mail.python.org/pipermail/python-dev/2003-April/035075.html] shows
input is parsed:
{code:java}
import re
def s_ident(scanner, token): return token
def s_operator(scanner, token): return "op%s" % token
def s_float(scanner, token): return float(token)
def s_int(scanner, token): return int(token)
scanner = re.Scanner([
(r"[a-zA-Z_]\w*", s_ident),
(r"\d+\.\d*", s_float),
(r"\d+", s_int),
(r"=|\+|-|\*|/", s_operator),
(r"\s+", None),
])
# sanity check
test('scanner.scan("sum = 3*foo + 312.50 + bar")',
(['sum', 'op=', 3, 'op*', 'foo', 'op+', 312.5, 'op+', 'bar'], ''))
{code}
In pylexotron this is implemented as:
{code:java}
RuleSpecScanner = SaferScanner([
(r'::=', lambda s, t: t),
(r'\[[a-z0-9_]+\]=', lambda s, t: ('named_collector', t[1:-2])),
(r'[a-z0-9_]+=', lambda s, t: ('named_symbol', t[:-1])),
(r'/(\[\^?.[^]]*\]|[^/]|\\.)*/', lambda s, t: ('regex',
t[1:-1].replace(r'\/', '/'))),
(r'"([^"]|\\.)*"', lambda s, t: ('litstring', t)),
(r'<[^>]*>', lambda s, t: ('reference', t[1:-1])),
(r'\bJUNK\b', lambda s, t: ('junk', t)),
(r'[@()|?*;]', lambda s, t: t),
(r'\s+', None),
(r'#[^\n]*', None),
], re.I | re.S | re.U) {code}
r'\s+' is skipping whitespace
I'm uncertain what r'#[^\n]*' and r'\bJUNK\b' are doing. Adding comments could
be helpful.
There doesn't seem to be a unit test class for pylexotron or SafeScanner,
however. That might be a good thing to add. There could be tests for each
type of token, named_collector, named_symbol, regex, litstring, reference and
junk.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I
[jira] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571175#comment-17571175
]
Brad Schoening edited comment on CASSANDRA-17667 at 7/26/22 3:19 AM:
-
[~ahomoki], looking at this a little further, safescanner.py, which inherits
from the python re.Scanner, is tokenizing the input. An example from
[https://mail.python.org/pipermail/python-dev/2003-April/035075.html] shows
input is parsed:
{code:java}
import re
def s_ident(scanner, token): return token
def s_operator(scanner, token): return "op%s" % token
def s_float(scanner, token): return float(token)
def s_int(scanner, token): return int(token)
scanner = re.Scanner([
(r"[a-zA-Z_]\w*", s_ident),
(r"\d+\.\d*", s_float),
(r"\d+", s_int),
(r"=|\+|-|\*|/", s_operator),
(r"\s+", None),
])
# sanity check
test('scanner.scan("sum = 3*foo + 312.50 + bar")',
(['sum', 'op=', 3, 'op*', 'foo', 'op+', 312.5, 'op+', 'bar'], ''))
{code}
In pylexotron this is implemented as:
{code:java}
RuleSpecScanner = SaferScanner([
(r'::=', lambda s, t: t),
(r'\[[a-z0-9_]+\]=', lambda s, t: ('named_collector', t[1:-2])),
(r'[a-z0-9_]+=', lambda s, t: ('named_symbol', t[:-1])),
(r'/(\[\^?.[^]]*\]|[^/]|\\.)*/', lambda s, t: ('regex',
t[1:-1].replace(r'\/', '/'))),
(r'"([^"]|\\.)*"', lambda s, t: ('litstring', t)),
(r'<[^>]*>', lambda s, t: ('reference', t[1:-1])),
(r'\bJUNK\b', lambda s, t: ('junk', t)),
(r'[@()|?*;]', lambda s, t: t),
(r'\s+', None),
(r'#[^\n]*', None),
], re.I | re.S | re.U) {code}
r'\s+' is skipping whitespace
I'm uncertain what r'#[^\n]*' and r'\bJUNK\b' are doing. Adding comments could
be helpful.
There doesn't seem to be a unit test class for pylexotron or SafeScanner,
however. That might be a good thing to add. There could be tests for each
type of token, named_collector, named_symbol, regex, litstring, reference and
junk.
was (Author: bschoeni):
[~ahomoki], looking at this a little further, safescanner.py, which inherits
from the python re.Scanner, is tokenizing the input. An example from
[https://mail.python.org/pipermail/python-dev/2003-April/035075.html] shows
input is parsed:
{code:java}
import re
def s_ident(scanner, token): return token
def s_operator(scanner, token): return "op%s" % token
def s_float(scanner, token): return float(token)
def s_int(scanner, token): return int(token)
scanner = re.Scanner([
(r"[a-zA-Z_]\w*", s_ident),
(r"\d+\.\d*", s_float),
(r"\d+", s_int),
(r"=|\+|-|\*|/", s_operator),
(r"\s+", None),
])
# sanity check
test('scanner.scan("sum = 3*foo + 312.50 + bar")',
(['sum', 'op=', 3, 'op*', 'foo', 'op+', 312.5, 'op+', 'bar'], ''))
{code}
In pylexotron this is implemented as:
{code:java}
RuleSpecScanner = SaferScanner([
(r'::=', lambda s, t: t),
(r'\[[a-z0-9_]+\]=', lambda s, t: ('named_collector', t[1:-2])),
(r'[a-z0-9_]+=', lambda s, t: ('named_symbol', t[:-1])),
(r'/(\[\^?.[^]]*\]|[^/]|\\.)*/', lambda s, t: ('regex',
t[1:-1].replace(r'\/', '/'))),
(r'"([^"]|\\.)*"', lambda s, t: ('litstring', t)),
(r'<[^>]*>', lambda s, t: ('reference', t[1:-1])),
(r'\bJUNK\b', lambda s, t: ('junk', t)),
(r'[@()|?*;]', lambda s, t: t),
(r'\s+', None),
(r'#[^\n]*', None),
], re.I | re.S | re.U) {code}
r'\s+' is skipping whitespace
I'm uncertain what r'#[^\n]*' and r'\bJUNK\b' are doing. Adding comments could
be helpful.
There doesn't seem to be a unit test class for pylexotron or SafeScanner,
however. That might be a good thing to add.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571175#comment-17571175
]
Brad Schoening commented on CASSANDRA-17667:
[~ahomoki], looking at this a little further, safescanner.py, which inherits
from the python re.Scanner, is tokenizing the input. An example from
[https://mail.python.org/pipermail/python-dev/2003-April/035075.html] shows
input is parsed:
{code:java}
import re
def s_ident(scanner, token): return token
def s_operator(scanner, token): return "op%s" % token
def s_float(scanner, token): return float(token)
def s_int(scanner, token): return int(token)
scanner = re.Scanner([
(r"[a-zA-Z_]\w*", s_ident),
(r"\d+\.\d*", s_float),
(r"\d+", s_int),
(r"=|\+|-|\*|/", s_operator),
(r"\s+", None),
])
# sanity check
test('scanner.scan("sum = 3*foo + 312.50 + bar")',
(['sum', 'op=', 3, 'op*', 'foo', 'op+', 312.5, 'op+', 'bar'], ''))
{code}
In pylexotron this is implemented as:
{code:java}
RuleSpecScanner = SaferScanner([
(r'::=', lambda s, t: t),
(r'\[[a-z0-9_]+\]=', lambda s, t: ('named_collector', t[1:-2])),
(r'[a-z0-9_]+=', lambda s, t: ('named_symbol', t[:-1])),
(r'/(\[\^?.[^]]*\]|[^/]|\\.)*/', lambda s, t: ('regex',
t[1:-1].replace(r'\/', '/'))),
(r'"([^"]|\\.)*"', lambda s, t: ('litstring', t)),
(r'<[^>]*>', lambda s, t: ('reference', t[1:-1])),
(r'\bJUNK\b', lambda s, t: ('junk', t)),
(r'[@()|?*;]', lambda s, t: t),
(r'\s+', None),
(r'#[^\n]*', None),
], re.I | re.S | re.U) {code}
r'\s+' is skipping whitespace
I'm uncertain what r'#[^\n]*' and r'\bJUNK\b' are doing. Adding comments could
be helpful.
There doesn't seem to be a unit test class for pylexotron or SafeScanner,
however. That might be a good thing to add.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17737) Validate that JMX updates properly any properties that were moved to the new config classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571167#comment-17571167 ] Ekaterina Dimitrova commented on CASSANDRA-17737: - Rebased, added your suggestion to the PRs and restarted CI. > Validate that JMX updates properly any properties that were moved to the new > config classes > --- > > Key: CASSANDRA-17737 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17737 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1-beta, 4.1.x, 4.x > > > Check that any properties moved to the new types in 4.1 (Duration, Data > Storage, Data Rate) are always updated by JMX and there are no inconsistent > validations that might cover bugs. Validate proper update in Settings Virtual > Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > *DataRateSpec* - entire_sstable_stream_throughput_outbound, > inter_dc_stream_throughput_outbound, > entire_sstable_inter_dc_stream_throughput_outbound, compaction_throughput, > stream_throughput_outbound - we have setGet* tests and those seem solid, no > issues found. > *DurationSpec* - gc_log_threshold, permissions_validity, denylist_refresh, > request_timeout, hints_flush_period, read_request_timeout, > index_summary_resize_interval, streaming_keep_alive_period, max_hint_window, > roles_update_interval, user_defined_functions_fail_timeout, > write_request_timeout, cdc_free_space_check_interval, roles_validity, > internode_streaming_tcp_user_timeout, gc_warn_threshold, > range_request_timeout, credentials_update_interval, truncate_request_timeout, > cas_contention_timeout, periodic_commitlog_sync_lag_block, > streaming_state_expires, repair_request_timeout, permissions_update_interval, > dynamic_snitch_reset_interval, internode_tcp_connect_timeout, > paxos_purge_grace_period, dynamic_snitch_update_interval, > trace_type_query_ttl, denylist_initial_load_retry, commitlog_sync_period, > native_transport_idle_timeout, credentials_validity, > validation_preview_purge_head_start, repair_state_expires, > internode_tcp_user_timeout, trace_type_repair_ttl, cache_load_timeout, > commitlog_sync_group_window, slow_query_log_timeout, > counter_write_request_timeout, user_defined_functions_warn_timeout > *DataStorageSpec* - > internode_application_send_queue_reserve_endpoint_capacity, cdc_total_space, > networking_cache_size, commitlog_total_space, > internode_application_send_queue_capacity, key_cache_size, > memtable_heap_space, trickle_fsync_interval, max_hints_size_per_host, > internode_application_receive_queue_reserve_endpoint_capacity, > native_transport_max_frame_size, coordinator_read_size_warn_threshold , > internode_application_receive_queue_reserve_global_capacity, > internode_max_message_size, file_cache_size, local_read_size_fail_threshold, > data_disk_usage_max_disk_size, memtable_offheap_space, > coordinator_read_size_fail_threshold, counter_cache_size, > prepared_statements_cache_size, batchlog_replay_throttle, > row_index_read_size_fail_threshold, index_summary_capacity, > repair_session_space, paxos_cache_size, collection_size_fail_threshold, > internode_application_send_queue_reserve_global_capacity, column_index_size, > native_transport_receive_queue_capacity, sstable_preemptive_open_interval, > max_mutation_size, min_free_space_per_drive, batch_size_fail_threshold, > hinted_handoff_throttle, row_index_read_size_warn_threshold, max_value_size, > column_index_cache_size, compaction_large_partition_warning_threshold, > max_hints_file_size, collection_size_warn_threshold, > native_transport_max_request_data_in_flight, > internode_socket_receive_buffer_size, > internode_application_receive_queue_capacity, > internode_socket_send_buffer_size, row_cache_size, > min_tracked_partition_size, local_read_size_warn_threshold, > commitlog_segment_size, batch_size_warn_threshold, streaming_state_size, > native_transport_max_request_data_in_flight_per_ip > NOTE: Some of those were checked/fixed in other tickets but I post the full > lists for completeness -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17776) When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to know when to check the ring but checks that the ring wasn't changed in -Dcassandra.ring_d
[ https://issues.apache.org/jira/browse/CASSANDRA-17776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17776: -- Reviewers: Brandon Williams, Caleb Rackliffe (was: Brandon Williams, Caleb Rackliffe, David Capwell) > When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to > know when to check the ring but checks that the ring wasn't changed in > -Dcassandra.ring_delay_ms, changes to ring delay should not depend on when we > publish load stats > --- > > Key: CASSANDRA-17776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17776 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > In some cases changing the ring delay to be higher is desired (such as when > network is slower), but in order to do a host replacement operators need to > know that there is a relationship with -Dcassandra.broadcast_interval_ms > which is used to publish LOAD via gossip. This relationship should not be > relied on and instead we should sleep based off ring delay rather than delay > when we publish loads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17776) When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to know when to check the ring but checks that the ring wasn't changed in -Dcassandra.ring_d
[ https://issues.apache.org/jira/browse/CASSANDRA-17776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17776: -- Reviewers: Brandon Williams, Caleb Rackliffe, David Capwell Status: Review In Progress (was: Patch Available) > When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to > know when to check the ring but checks that the ring wasn't changed in > -Dcassandra.ring_delay_ms, changes to ring delay should not depend on when we > publish load stats > --- > > Key: CASSANDRA-17776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17776 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > In some cases changing the ring delay to be higher is desired (such as when > network is slower), but in order to do a host replacement operators need to > know that there is a relationship with -Dcassandra.broadcast_interval_ms > which is used to publish LOAD via gossip. This relationship should not be > relied on and instead we should sleep based off ring delay rather than delay > when we publish loads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17776) When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to know when to check the ring but checks that the ring wasn't changed in -Dcassandra.ring
[ https://issues.apache.org/jira/browse/CASSANDRA-17776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571132#comment-17571132 ] Caleb Rackliffe commented on CASSANDRA-17776: - +1 > When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to > know when to check the ring but checks that the ring wasn't changed in > -Dcassandra.ring_delay_ms, changes to ring delay should not depend on when we > publish load stats > --- > > Key: CASSANDRA-17776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17776 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > In some cases changing the ring delay to be higher is desired (such as when > network is slower), but in order to do a host replacement operators need to > know that there is a relationship with -Dcassandra.broadcast_interval_ms > which is used to publish LOAD via gossip. This relationship should not be > relied on and instead we should sleep based off ring delay rather than delay > when we publish loads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17776) When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to know when to check the ring but checks that the ring wasn't changed in -Dcassandra.ring
[ https://issues.apache.org/jira/browse/CASSANDRA-17776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571131#comment-17571131 ] Brandon Williams commented on CASSANDRA-17776: -- Good catch. +1 assuming CI is good. > When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to > know when to check the ring but checks that the ring wasn't changed in > -Dcassandra.ring_delay_ms, changes to ring delay should not depend on when we > publish load stats > --- > > Key: CASSANDRA-17776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17776 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > In some cases changing the ring delay to be higher is desired (such as when > network is slower), but in order to do a host replacement operators need to > know that there is a relationship with -Dcassandra.broadcast_interval_ms > which is used to publish LOAD via gossip. This relationship should not be > relied on and instead we should sleep based off ring delay rather than delay > when we publish loads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17776) When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to know when to check the ring but checks that the ring wasn't changed in -Dcassandra.ring_d
[ https://issues.apache.org/jira/browse/CASSANDRA-17776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17776: -- Test and Documentation Plan: run existing tests Status: Patch Available (was: Open) > When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to > know when to check the ring but checks that the ring wasn't changed in > -Dcassandra.ring_delay_ms, changes to ring delay should not depend on when we > publish load stats > --- > > Key: CASSANDRA-17776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17776 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > In some cases changing the ring delay to be higher is desired (such as when > network is slower), but in order to do a host replacement operators need to > know that there is a relationship with -Dcassandra.broadcast_interval_ms > which is used to publish LOAD via gossip. This relationship should not be > relied on and instead we should sleep based off ring delay rather than delay > when we publish loads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17776) When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to know when to check the ring but checks that the ring wasn't changed in -Dcassandra.ring_d
[ https://issues.apache.org/jira/browse/CASSANDRA-17776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17776: -- Bug Category: Parent values: Correctness(12982)Level 1 values: API / Semantic Implementation(12988) Complexity: Low Hanging Fruit Discovered By: User Report Fix Version/s: 4.x Severity: Normal Assignee: David Capwell Status: Open (was: Triage Needed) > When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to > know when to check the ring but checks that the ring wasn't changed in > -Dcassandra.ring_delay_ms, changes to ring delay should not depend on when we > publish load stats > --- > > Key: CASSANDRA-17776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17776 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > In some cases changing the ring delay to be higher is desired (such as when > network is slower), but in order to do a host replacement operators need to > know that there is a relationship with -Dcassandra.broadcast_interval_ms > which is used to publish LOAD via gossip. This relationship should not be > relied on and instead we should sleep based off ring delay rather than delay > when we publish loads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17776) When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to know when to check the ring but checks that the ring wasn't changed in -Dcassandra.ring_d
David Capwell created CASSANDRA-17776: - Summary: When doing a host replacement, -Dcassandra.broadcast_interval_ms is used to know when to check the ring but checks that the ring wasn't changed in -Dcassandra.ring_delay_ms, changes to ring delay should not depend on when we publish load stats Key: CASSANDRA-17776 URL: https://issues.apache.org/jira/browse/CASSANDRA-17776 Project: Cassandra Issue Type: Bug Components: Consistency/Bootstrap and Decommission Reporter: David Capwell In some cases changing the ring delay to be higher is desired (such as when network is slower), but in order to do a host replacement operators need to know that there is a relationship with -Dcassandra.broadcast_interval_ms which is used to publish LOAD via gossip. This relationship should not be relied on and instead we should sleep based off ring delay rather than delay when we publish loads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[
https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571126#comment-17571126
]
Brad Schoening edited comment on CASSANDRA-15046 at 7/25/22 10:51 PM:
--
CQLSH uses the readline library's history functions, see
[https://docs.python.org/3/library/readline.html#history-file.]
A solution could use the {{{}get_current_history_length{}}}() and
{{get_history_item()}} functions to display a history list.
was (Author: bschoeni):
CQLSH use the readline library's history functions, see
[https://docs.python.org/3/library/readline.html#history-file.]
A solution could use the {{{}get_current_history_length{}}}() and
{{get_history_item()}} functions to display a history list.
> Add a "history" command to cqlsh. Perhaps "show history"?
> --
>
> Key: CASSANDRA-15046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15046
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Wes Peters
>Assignee: Rohit Kumar
>Priority: Low
> Labels: lhf
>
> I was trying to capture some create key space and create table commands from
> a running cqlsh, and found there was no equivalent to the '\s' history
> command in Postgres' psql shell. It's a great tool for figuring out what you
> were doing yesterday.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[
https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571126#comment-17571126
]
Brad Schoening commented on CASSANDRA-15046:
CQLSH use the readline library's history functions, see
[https://docs.python.org/3/library/readline.html#history-file.]
A solution could use the {{{}get_current_history_length{}}}() and
{{get_history_item()}} functions to display a history list.
> Add a "history" command to cqlsh. Perhaps "show history"?
> --
>
> Key: CASSANDRA-15046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15046
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Wes Peters
>Assignee: Rohit Kumar
>Priority: Low
> Labels: lhf
>
> I was trying to capture some create key space and create table commands from
> a running cqlsh, and found there was no equivalent to the '\s' history
> command in Postgres' psql shell. It's a great tool for figuring out what you
> were doing yesterday.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571117#comment-17571117 ] Benedict Elliott Smith commented on CASSANDRA-17768: Thanks for the additional context, Paulo. It sounds like this should be maintained, but perhaps as a netty-layer keep alive, rather than a streaming-specific one. > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17754) When bootstrap fails, CassandraRoleManager may attempt to do read queries that fail with "Cannot read from a bootstrapping node", and increments unavailables counter
[ https://issues.apache.org/jira/browse/CASSANDRA-17754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17754: -- Fix Version/s: 4.2 (was: 4.x) Since Version: 2.0.0 Source Control Link: https://github.com/apache/cassandra/commit/db3a29428df5f4e17791ce8a4e075532abb36667 Resolution: Fixed Status: Resolved (was: Ready to Commit) > When bootstrap fails, CassandraRoleManager may attempt to do read queries > that fail with "Cannot read from a bootstrapping node", and increments > unavailables counters > -- > > Key: CASSANDRA-17754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17754 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, > Feature/Authorization >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.2 > > > If bootstrap fails we stay alive but avoid joining the ring. > CassandraRoleManager attempts to schedule its setup every 10 seconds, but > this will fail due to Bootstrap being pending; the side effect to this is > that readMetrics.unavailables gets incremented. > We should defer attempting to setup only after we know its safe to perform > such as read -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: When bootstrap fails, CassandraRoleManager may attempt to do read queries that fail with "Cannot read from a bootstrapping node", and increments unavailables counters
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new e0a6b83a02 When bootstrap fails, CassandraRoleManager may attempt to
do read queries that fail with "Cannot read from a bootstrapping node", and
increments unavailables counters
e0a6b83a02 is described below
commit e0a6b83a02804bf976fdc43718001f23818ee53d
Author: David Capwell
AuthorDate: Mon Jul 25 12:26:35 2022 -0700
When bootstrap fails, CassandraRoleManager may attempt to do read queries
that fail with "Cannot read from a bootstrapping node", and increments
unavailables counters
patch by David Capwell; reviewed by Sam Tunnicliffe for CASSANDRA-17754
---
CHANGES.txt| 1 +
.../cassandra/auth/CassandraRoleManager.java | 7 ++
.../org/apache/cassandra/service/StorageProxy.java | 19 ++-
.../cassandra/distributed/shared/ClusterUtils.java | 46 +++
.../test/hostreplacement/FailedBootstrapTest.java | 138 +
.../test/hostreplacement/HostReplacementTest.java | 3 +
6 files changed, 212 insertions(+), 2 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 33753cb531..63e8fdd328 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * When bootstrap fails, CassandraRoleManager may attempt to do read queries
that fail with "Cannot read from a bootstrapping node", and increments
unavailables counters (CASSANDRA-17754)
* Add guardrail to disallow DROP KEYSPACE commands (CASSANDRA-17767)
* Remove ephemeral snapshot marker file and introduce a flag to
SnapshotManifest (CASSANDRA-16911)
* Add a virtual table that exposes currently running queries (CASSANDRA-15241)
diff --git a/src/java/org/apache/cassandra/auth/CassandraRoleManager.java
b/src/java/org/apache/cassandra/auth/CassandraRoleManager.java
index 0344de921d..c2272707ec 100644
--- a/src/java/org/apache/cassandra/auth/CassandraRoleManager.java
+++ b/src/java/org/apache/cassandra/auth/CassandraRoleManager.java
@@ -43,6 +43,7 @@ import org.apache.cassandra.db.ConsistencyLevel;
import org.apache.cassandra.db.marshal.UTF8Type;
import org.apache.cassandra.exceptions.*;
import org.apache.cassandra.service.ClientState;
+import org.apache.cassandra.service.StorageProxy;
import org.apache.cassandra.service.StorageService;
import org.apache.cassandra.transport.messages.ResultMessage;
import org.apache.cassandra.utils.ByteBufferUtil;
@@ -386,6 +387,12 @@ public class CassandraRoleManager implements IRoleManager
{
// The delay is to give the node a chance to see its peers before
attempting the operation
ScheduledExecutors.optionalTasks.scheduleSelfRecurring(() -> {
+if (!StorageProxy.isSafeToPerformRead())
+{
+logger.trace("Setup task may not run due to it not being safe
to perform reads... rescheduling");
+scheduleSetupTask(setupTask);
+return;
+}
try
{
setupTask.call();
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index 557382df54..e89bdae717 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -1823,7 +1823,7 @@ public class StorageProxy implements StorageProxyMBean
public static PartitionIterator read(SinglePartitionReadCommand.Group
group, ConsistencyLevel consistencyLevel, long queryStartNanoTime)
throws UnavailableException, IsBootstrappingException,
ReadFailureException, ReadTimeoutException, InvalidRequestException
{
-if (StorageService.instance.isBootstrapMode() &&
!systemKeyspaceQuery(group.queries))
+if (!isSafeToPerformRead(group.queries))
{
readMetrics.unavailables.mark();
readMetricsForLevel(consistencyLevel).unavailables.mark();
@@ -1850,6 +1850,16 @@ public class StorageProxy implements StorageProxyMBean
: readRegular(group, consistencyLevel, queryStartNanoTime);
}
+public static boolean isSafeToPerformRead(List
queries)
+{
+return isSafeToPerformRead() || systemKeyspaceQuery(queries);
+}
+
+public static boolean isSafeToPerformRead()
+{
+return !StorageService.instance.isBootstrapMode();
+}
+
private static PartitionIterator
readWithPaxos(SinglePartitionReadCommand.Group group, ConsistencyLevel
consistencyLevel, long queryStartNanoTime)
throws InvalidRequestException, UnavailableException,
ReadFailureException, ReadTimeoutException
{
@@ -2619,8 +2629,13 @@ public class StorageProxy implements StorageProxyMBean
public static void logRequestException(Exception exception, Collection commands)
{
+//
[cassandra-website] branch asf-staging updated (4ec1bcbf -> 8745e20a)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 4ec1bcbf generate docs for 93aef61a new 8745e20a generate docs for 93aef61a This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (4ec1bcbf) \ N -- N -- N refs/heads/asf-staging (8745e20a) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17775) cassandra-builds defines CASSANDRA_GIT_URL multiple times
[ https://issues.apache.org/jira/browse/CASSANDRA-17775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-17775: Assignee: Brandon Williams > cassandra-builds defines CASSANDRA_GIT_URL multiple times > - > > Key: CASSANDRA-17775 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17775 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > The asf repo is defined for CASSANDRA_GIT_URL in the docker files, > cassandra-artifacts.sh itself, and the packaging scripts also define it if > not set. This make testing artifacts built from your own repository > difficult. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17775) cassandra-builds defines CASSANDRA_GIT_URL multiple times
Brandon Williams created CASSANDRA-17775: Summary: cassandra-builds defines CASSANDRA_GIT_URL multiple times Key: CASSANDRA-17775 URL: https://issues.apache.org/jira/browse/CASSANDRA-17775 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams The asf repo is defined for CASSANDRA_GIT_URL in the docker files, cassandra-artifacts.sh itself, and the packaging scripts also define it if not set. This make testing artifacts built from your own repository difficult. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17774) Implement SSTable count by TWCS bucket
[
https://issues.apache.org/jira/browse/CASSANDRA-17774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571080#comment-17571080
]
Josh McKenzie edited comment on CASSANDRA-17774 at 7/25/22 8:23 PM:
Good call; working on upstreaming some existing code and it predated virtual
tables. Will look at adding this into the patch.
Actually, maybe. [~paulo] - is there a precedent in the virtual table infra for
this kind of data (visualization of int[], metrics across levels)? Looks like
we haven't implemented one for {{getSSTableCountPerLevel}} and from a cursory
inspection of things that extend {{VirtualTable}} I'm not seeing any obvious
candidates to base an implementation off of.
If this represents a visualization of a new pattern of data, I'd advocate for a
follow-up JIRA where we construct that and then apply it to both TWCS buckets
and levels both and expose that data. wdyt?
was (Author: jmckenzie):
Good call; working on upstreaming some existing code and it predated virtual
tables. Will look at adding this into the patch.
> Implement SSTable count by TWCS bucket
> --
>
> Key: CASSANDRA-17774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17774
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction/TWCS
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> It should be possible to report the total number of sstables in buckets by
> using a JMX call {{getSSTableCountPerTWCSBucket()}}, similarly to
> {{getSSTableCountPerLevel()}}. This will help us to assert the compaction
> strategy is able to keep up with major compactions on older time buckets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17769) Fix org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17769: Fix Version/s: 4.1-rc > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > --- > > Key: CASSANDRA-17769 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17769 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-rc, 4.x > > > Fix > org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest > failing on current trunk: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1795/workflows/bc8619bb-7301-4428-9662-bc24e5f38b87/jobs/13335/tests#failed-test-0 > and also in this run > https://app.circleci.com/pipelines/github/driftx/cassandra/551/workflows/ba8cadb9-025f-46f9-b663-69d9e956d30d/jobs/6596/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17774) Implement SSTable count by TWCS bucket
[
https://issues.apache.org/jira/browse/CASSANDRA-17774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571080#comment-17571080
]
Josh McKenzie commented on CASSANDRA-17774:
---
Good call; working on upstreaming some existing code and it predated virtual
tables. Will look at adding this into the patch.
> Implement SSTable count by TWCS bucket
> --
>
> Key: CASSANDRA-17774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17774
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction/TWCS
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> It should be possible to report the total number of sstables in buckets by
> using a JMX call {{getSSTableCountPerTWCSBucket()}}, similarly to
> {{getSSTableCountPerLevel()}}. This will help us to assert the compaction
> strategy is able to keep up with major compactions on older time buckets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17754) When bootstrap fails, CassandraRoleManager may attempt to do read queries that fail with "Cannot read from a bootstrapping node", and increments unavailables count
[ https://issues.apache.org/jira/browse/CASSANDRA-17754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571069#comment-17571069 ] David Capwell commented on CASSANDRA-17754: --- Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17754-trunk-CBB57EA3-BB8C-4FDB-A76C-F1A0F212D4CD]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17754-trunk-CBB57EA3-BB8C-4FDB-A76C-F1A0F212D4CD]|[build|unknown]| > When bootstrap fails, CassandraRoleManager may attempt to do read queries > that fail with "Cannot read from a bootstrapping node", and increments > unavailables counters > -- > > Key: CASSANDRA-17754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17754 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, > Feature/Authorization >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > If bootstrap fails we stay alive but avoid joining the ring. > CassandraRoleManager attempts to schedule its setup every 10 seconds, but > this will fail due to Bootstrap being pending; the side effect to this is > that readMetrics.unavailables gets incremented. > We should defer attempting to setup only after we know its safe to perform > such as read -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (2f338d06 -> 4ec1bcbf)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 2f338d06 generate docs for 93aef61a new 4ec1bcbf generate docs for 93aef61a This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (2f338d06) \ N -- N -- N refs/heads/asf-staging (4ec1bcbf) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../cassandra/configuration/cass_yaml_file.html| 2 +- .../cassandra/configuration/cass_yaml_file.html| 2 +- .../cassandra/configuration/cass_yaml_file.html| 2 +- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078 bytes 5 files changed, 4 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17774) Implement SSTable count by TWCS bucket
[
https://issues.apache.org/jira/browse/CASSANDRA-17774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571057#comment-17571057
]
Paulo Motta commented on CASSANDRA-17774:
-
Nice feature! Can/should we make this a vtable instead of JMX?
Even though we didn't deprecate JMX yet I think we should favor vtables for new
features, unless not practical or fit.
> Implement SSTable count by TWCS bucket
> --
>
> Key: CASSANDRA-17774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17774
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction/TWCS
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> It should be possible to report the total number of sstables in buckets by
> using a JMX call {{getSSTableCountPerTWCSBucket()}}, similarly to
> {{getSSTableCountPerLevel()}}. This will help us to assert the compaction
> strategy is able to keep up with major compactions on older time buckets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17725) Add a flag for throughput in MiB/s for nodetool setstreamthroughput, getstreamthroughput, setinterdcstreamthroughput and getinterdcstreamthroughput
[
https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570985#comment-17570985
]
Caleb Rackliffe commented on CASSANDRA-17725:
-
bq. So I guess what we can do is to add double version of those methods and
deprecate the old ones?
As long as nothing new does any rounding, fine with me. We could also just not
have the old {{nodetool}} commands worry about {{MiB}}, given there are going
to be new methods anyway, where we won't have to round.
> Add a flag for throughput in MiB/s for nodetool setstreamthroughput,
> getstreamthroughput, setinterdcstreamthroughput and
> getinterdcstreamthroughput
>
>
> Key: CASSANDRA-17725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17725
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> As we agreed not to add new JMX methods for the new config on the mailing
> list, we need at least new flags for setstreamthroughput and
> interdcstreamthroughput for the two 4.0 parameters to be set/get also in MiB,
> not only in megabits.
> Thus we will have the option either to use the old version for those 2, or to
> be able to set/get in MiB all 4 streaming parameters. As of 4.1 supported
> units for DataRateSpec are MiB/s, B/s, KiB/s, megabit is only for legacy from
> 4.0 - backward compatibility.
> To be sure we satisfy the requirements around the latest discussions about
> backward compatibility in tools, I will use this ticket also to make a final
> pass on the unit changes done, to ensure the probe output is not affected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17774) Implement SSTable count by TWCS bucket
[
https://issues.apache.org/jira/browse/CASSANDRA-17774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17774:
--
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Implement SSTable count by TWCS bucket
> --
>
> Key: CASSANDRA-17774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17774
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction/TWCS
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> It should be possible to report the total number of sstables in buckets by
> using a JMX call {{getSSTableCountPerTWCSBucket()}}, similarly to
> {{getSSTableCountPerLevel()}}. This will help us to assert the compaction
> strategy is able to keep up with major compactions on older time buckets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17774) Implement SSTable count by TWCS bucket
Josh McKenzie created CASSANDRA-17774:
-
Summary: Implement SSTable count by TWCS bucket
Key: CASSANDRA-17774
URL: https://issues.apache.org/jira/browse/CASSANDRA-17774
Project: Cassandra
Issue Type: Improvement
Components: Local/Compaction/TWCS
Reporter: Josh McKenzie
Assignee: Josh McKenzie
It should be possible to report the total number of sstables in buckets by
using a JMX call {{getSSTableCountPerTWCSBucket()}}, similarly to
{{getSSTableCountPerLevel()}}. This will help us to assert the compaction
strategy is able to keep up with major compactions on older time buckets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570951#comment-17570951 ] Ekaterina Dimitrova edited comment on CASSANDRA-17768 at 7/25/22 3:40 PM: -- (Removing will be breaking change, talking from experience, so please, deprecate only but I agree we need to update NEWS.txt and cassandra.yaml plus clean that logging, at least, if we take the deprecation road :D ) was (Author: e.dimitrova): (Removing will be breaking change, talking from experience, so please, deprecate only but I agree we need to update NEWS.txt and cassandra.yaml at least if we take the deprecation road :D ) > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17773) Incorrect cassandra.logdir on Debian systems
[ https://issues.apache.org/jira/browse/CASSANDRA-17773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570957#comment-17570957 ] Brandon Williams commented on CASSANDRA-17773: -- It looks like CASSANDRA-14306 is what changed this behavior. > Incorrect cassandra.logdir on Debian systems > > > Key: CASSANDRA-17773 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17773 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Eric Evans >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1-rc > > > The Debian packaging patches bin/cassandra to use /var/log/cassandra for > logs, it does so conditionally however, only if CASSANDRA_LOG_DIR is unset. > This occurs _after_ cassandra-env.sh is sourced though, which also sets > CASSANDRA_LOG_DIR if unset (to $CASSANDRA_HOME/logs). The result is that > -Dcassandra.lodir is set to /usr/share/cassandra/logs on Debian systems. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17773) Incorrect cassandra.logdir on Debian systems
[ https://issues.apache.org/jira/browse/CASSANDRA-17773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570957#comment-17570957 ] Brandon Williams edited comment on CASSANDRA-17773 at 7/25/22 3:33 PM: --- It looks like CASSANDRA-14306 is what changed this behavior. /cc [~mck] was (Author: brandon.williams): It looks like CASSANDRA-14306 is what changed this behavior. > Incorrect cassandra.logdir on Debian systems > > > Key: CASSANDRA-17773 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17773 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Eric Evans >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1-rc > > > The Debian packaging patches bin/cassandra to use /var/log/cassandra for > logs, it does so conditionally however, only if CASSANDRA_LOG_DIR is unset. > This occurs _after_ cassandra-env.sh is sourced though, which also sets > CASSANDRA_LOG_DIR if unset (to $CASSANDRA_HOME/logs). The result is that > -Dcassandra.lodir is set to /usr/share/cassandra/logs on Debian systems. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17773) Incorrect cassandra.logdir on Debian systems
[ https://issues.apache.org/jira/browse/CASSANDRA-17773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17773: - Bug Category: Parent values: Packaging(13660)Level 1 values: Package Distribution(13662) Complexity: Normal Discovered By: User Report Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1-rc Severity: Normal Status: Open (was: Triage Needed) > Incorrect cassandra.logdir on Debian systems > > > Key: CASSANDRA-17773 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17773 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Eric Evans >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1-rc > > > The Debian packaging patches bin/cassandra to use /var/log/cassandra for > logs, it does so conditionally however, only if CASSANDRA_LOG_DIR is unset. > This occurs _after_ cassandra-env.sh is sourced though, which also sets > CASSANDRA_LOG_DIR if unset (to $CASSANDRA_HOME/logs). The result is that > -Dcassandra.lodir is set to /usr/share/cassandra/logs on Debian systems. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17773) Incorrect cassandra.logdir on Debian systems
Eric Evans created CASSANDRA-17773: -- Summary: Incorrect cassandra.logdir on Debian systems Key: CASSANDRA-17773 URL: https://issues.apache.org/jira/browse/CASSANDRA-17773 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Eric Evans The Debian packaging patches bin/cassandra to use /var/log/cassandra for logs, it does so conditionally however, only if CASSANDRA_LOG_DIR is unset. This occurs _after_ cassandra-env.sh is sourced though, which also sets CASSANDRA_LOG_DIR if unset (to $CASSANDRA_HOME/logs). The result is that -Dcassandra.lodir is set to /usr/share/cassandra/logs on Debian systems. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17772) Improve documentation around query methods in CQLTester and GuardrailTester
[ https://issues.apache.org/jira/browse/CASSANDRA-17772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17772: -- Fix Version/s: 4.2 Source Control Link: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=a57eae67e5d73f8ab3fd0ab172262380c8dc0280 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Improve documentation around query methods in CQLTester and GuardrailTester > --- > > Key: CASSANDRA-17772 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17772 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.2 > > > Anything that relies on CQLTester.executeFormattedQuery (the > assertInvalidThrowMessage methods for instance) will use internal client > state rather than the client state specified for the query, thus nullifying > any guardrail or systems keyspace permission checks as the > ClientState.isInternal flag overrides all such permission checking. > Reference: > [link|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L385-L388] > > See chain of CQLTester -> ClientState.isInternal here if interested: > [CQLTester|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L1325] > [QueryProcessor|https://github.com/apache/cassandra/blob/8451acc8d8dcfee20d692d1e70ae11b60d2f004e/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L447] > > This is pretty easy to stumble across when testing guardrails as > GuardrailTester adds a variety of assertFails and assertThrows signatures > that _do_ respect the client state and thus apply guardrails > ([example|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java#L271]) > > We should add documentation to the method calls in CQLTester and > GuardrailTester to reflect this discrepancy as it can easily trip someone up > writing tests for guardrails. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17772) Improve documentation around query methods in CQLTester and GuardrailTester
[ https://issues.apache.org/jira/browse/CASSANDRA-17772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17772: -- Status: Ready to Commit (was: Review In Progress) > Improve documentation around query methods in CQLTester and GuardrailTester > --- > > Key: CASSANDRA-17772 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17772 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Anything that relies on CQLTester.executeFormattedQuery (the > assertInvalidThrowMessage methods for instance) will use internal client > state rather than the client state specified for the query, thus nullifying > any guardrail or systems keyspace permission checks as the > ClientState.isInternal flag overrides all such permission checking. > Reference: > [link|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L385-L388] > > See chain of CQLTester -> ClientState.isInternal here if interested: > [CQLTester|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L1325] > [QueryProcessor|https://github.com/apache/cassandra/blob/8451acc8d8dcfee20d692d1e70ae11b60d2f004e/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L447] > > This is pretty easy to stumble across when testing guardrails as > GuardrailTester adds a variety of assertFails and assertThrows signatures > that _do_ respect the client state and thus apply guardrails > ([example|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java#L271]) > > We should add documentation to the method calls in CQLTester and > GuardrailTester to reflect this discrepancy as it can easily trip someone up > writing tests for guardrails. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Improve javadoc on CQLTester and GuardrailTester assertion methods
This is an automated email from the ASF dual-hosted git repository.
jmckenzie pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new a57eae67e5 Improve javadoc on CQLTester and GuardrailTester assertion
methods
a57eae67e5 is described below
commit a57eae67e5d73f8ab3fd0ab172262380c8dc0280
Author: Josh McKenzie
AuthorDate: Fri Jul 22 13:34:41 2022 -0400
Improve javadoc on CQLTester and GuardrailTester assertion methods
Patch by Josh McKenzie; reviewed by Andres de la Pena for CASSANDRA-17772
---
test/unit/org/apache/cassandra/cql3/CQLTester.java | 15 +--
.../cassandra/db/guardrails/GuardrailTester.java | 20
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/test/unit/org/apache/cassandra/cql3/CQLTester.java
b/test/unit/org/apache/cassandra/cql3/CQLTester.java
index eae939b8a9..7c2eebb8c5 100644
--- a/test/unit/org/apache/cassandra/cql3/CQLTester.java
+++ b/test/unit/org/apache/cassandra/cql3/CQLTester.java
@@ -1322,6 +1322,10 @@ public abstract class CQLTester
return executeFormattedQuery(formatViewQuery(KEYSPACE, query), values);
}
+/**
+ * Executes the provided query using the {@link
ClientState#forInternalCalls()} as the expected ClientState. Note:
+ * this means permissions checking will not apply and queries will proceed
regardless of role or guardrails.
+ */
protected UntypedResultSet executeFormattedQuery(String query, Object...
values) throws Throwable
{
UntypedResultSet rs;
@@ -1738,8 +1742,15 @@ public abstract class CQLTester
assertInvalidThrowMessage(Optional.empty(), errorMessage, exception,
query, values);
}
-// if a protocol version > Integer.MIN_VALUE is supplied, executes
-// the query via the java driver, mimicking a real client.
+/**
+ * Asserts that the query provided throws the exceptions provided.
+ *
+ * NOTE: This method uses {@link ClientState#forInternalCalls()} which
sets the {@link ClientState#isInternal} value
+ * to true, nullifying any system keyspace or other permissions checking
for tables.
+ *
+ * If a protocol version > Integer.MIN_VALUE is supplied, executes
+ * the query via the java driver, mimicking a real client.
+ */
protected void assertInvalidThrowMessage(Optional
protocolVersion,
String errorMessage,
Class
exception,
diff --git a/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java
b/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java
index 7c94702a21..54523743b7 100644
--- a/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java
+++ b/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java
@@ -67,6 +67,18 @@ import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertTrue;
import static org.junit.Assert.fail;
+/**
+ * This class provides specific utility methods for testing Guardrails that
should be used instead of the provided
+ * {@link CQLTester} methods. Many of the methods in CQLTester don't respect
the {@link ClientState} provided for a query
+ * and instead use {@link ClientState#forInternalCalls()} which flags as an
internal query and thus bypasses auth and
+ * guardrail checks.
+ *
+ * Some GuardrailTester methods and their usage is as follows:
+ * {@link GuardrailTester#assertValid(String)} to confirm the query as
structured is valid given the state of the db
+ * {@link GuardrailTester#assertWarns(String, String)} to confirm a query
succeeds but warns the text provided
+ * {@link GuardrailTester#assertFails(String, String)} to confirm a query
fails with the message provided
+ * {@link GuardrailTester#testExcludedUsers} to confirm superusers are
excluded from application of the guardrail
+ */
public abstract class GuardrailTester extends CQLTester
{
// Name used when testing CREATE TABLE that should be aborted (we need to
provide it as assertFails, which
@@ -318,6 +330,10 @@ public abstract class GuardrailTester extends CQLTester
assertFails(function, true, messages, redactedMessages);
}
+/**
+ * Unlike {@link CQLTester#assertInvalidThrowMessage}, the chain of
methods ending here in {@link GuardrailTester}
+ * respect the input ClientState so guardrails permissions will be
correctly checked.
+ */
protected void assertFails(CheckedFunction function, boolean thrown,
List messages, List redactedMessages) throws Throwable
{
ClientWarn.instance.captureWarnings();
@@ -478,6 +494,10 @@ public abstract class GuardrailTester extends CQLTester
return execute(state, query, options);
}
+/**
+ * Performs execution of query using the input {@link ClientState} (i.e.
unlike {@link
[jira] [Commented] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570953#comment-17570953
]
Paulo Motta commented on CASSANDRA-17768:
-
It seems like TCP keep-alives are an optional feature, what might explain why
it doesn't work in some cases.
>From [https://www.freesoft.org/CIE/RFC/1122/114.htm:]
{quote}Implementors MAY include "keep-alives" in their TCP implementations,
although this practice is not universally accepted.
{quote}
> streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase
> 1: Refactor Streaming
> --
>
> Key: CASSANDRA-17768
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17768
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10
> Phase 1: Refactor Streaming
> streaming_keep_alive_period is not used anymore, except to print it in error
> message
> [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689]
> If the property should not be used anymore, we need to deprecate it and fix
> the error message as it is misleading.
> [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of
> this one as authors of that patch?
> Thank you in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570950#comment-17570950
]
Paulo Motta edited comment on CASSANDRA-17768 at 7/25/22 3:12 PM:
--
I think the necessity for this is significantly reduced if we use a single
connection for both inbound/outbound streaming traffic, but that was not the
case when the feature was added, so one connection could remain idle for long
periods while the other side was active, what caused connection resets due to
badly configured firewalls/networks.
>From [https://docs.oracle.com/cd/E19787-01/820-2559/using-24/index.html:]
{quote}Where possible, in addition to using the TCP keep-alive mechanism, the
client application also must perform its own periodic keep-alive at its level.
*The TCP keep-alive mechanism is not perfect in all possible boundary cases.*
{quote}
was (Author: paulo):
I think the necessity for this is severely reduced if we use a single
connection for both inbound/outbound streaming traffic, but that was not the
case when the feature was added, so one connection could remain idle for long
periods while the other side was active, what caused connection resets due to
badly configured firewalls/networks.
>From [https://docs.oracle.com/cd/E19787-01/820-2559/using-24/index.html:]
{quote}Where possible, in addition to using the TCP keep-alive mechanism, the
client application also must perform its own periodic keep-alive at its level.
*The TCP keep-alive mechanism is not perfect in all possible boundary cases.*
{quote}
> streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase
> 1: Refactor Streaming
> --
>
> Key: CASSANDRA-17768
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17768
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10
> Phase 1: Refactor Streaming
> streaming_keep_alive_period is not used anymore, except to print it in error
> message
> [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689]
> If the property should not be used anymore, we need to deprecate it and fix
> the error message as it is misleading.
> [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of
> this one as authors of that patch?
> Thank you in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570951#comment-17570951 ] Ekaterina Dimitrova commented on CASSANDRA-17768: - (Removing will be breaking change, talking from experience, so please, deprecate only but I agree we need to update NEWS.txt and cassandra.yaml at least :D ) > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570951#comment-17570951 ] Ekaterina Dimitrova edited comment on CASSANDRA-17768 at 7/25/22 3:12 PM: -- (Removing will be breaking change, talking from experience, so please, deprecate only but I agree we need to update NEWS.txt and cassandra.yaml at least if we take the deprecation road :D ) was (Author: e.dimitrova): (Removing will be breaking change, talking from experience, so please, deprecate only but I agree we need to update NEWS.txt and cassandra.yaml at least :D ) > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570950#comment-17570950
]
Paulo Motta commented on CASSANDRA-17768:
-
I think the necessity for this is severely reduced if we use a single
connection for both inbound/outbound streaming traffic, but that was not the
case when the feature was added, so one connection could remain idle for long
periods while the other side was active, what caused connection resets due to
badly configured firewalls/networks.
>From [https://docs.oracle.com/cd/E19787-01/820-2559/using-24/index.html:]
{quote}Where possible, in addition to using the TCP keep-alive mechanism, the
client application also must perform its own periodic keep-alive at its level.
*The TCP keep-alive mechanism is not perfect in all possible boundary cases.*
{quote}
> streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase
> 1: Refactor Streaming
> --
>
> Key: CASSANDRA-17768
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17768
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10
> Phase 1: Refactor Streaming
> streaming_keep_alive_period is not used anymore, except to print it in error
> message
> [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689]
> If the property should not be used anymore, we need to deprecate it and fix
> the error message as it is misleading.
> [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of
> this one as authors of that patch?
> Thank you in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17772) Improve documentation around query methods in CQLTester and GuardrailTester
[
https://issues.apache.org/jira/browse/CASSANDRA-17772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570947#comment-17570947
]
Josh McKenzie commented on CASSANDRA-17772:
---
{quote}Maybe we could add a brief class-level JavaDoc to {{GuardrailTester}}
saying that the class provides utility methods for testing guardrails that,
differently to {{{}CQLTester{}}}, can use more client states than only the
internal one. wdyt?{quote}
I think that's an excellent idea; will do that on commit.
Thanks for the double-check!
> Improve documentation around query methods in CQLTester and GuardrailTester
> ---
>
> Key: CASSANDRA-17772
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17772
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> Anything that relies on CQLTester.executeFormattedQuery (the
> assertInvalidThrowMessage methods for instance) will use internal client
> state rather than the client state specified for the query, thus nullifying
> any guardrail or systems keyspace permission checks as the
> ClientState.isInternal flag overrides all such permission checking.
> Reference:
> [link|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L385-L388]
>
> See chain of CQLTester -> ClientState.isInternal here if interested:
> [CQLTester|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L1325]
> [QueryProcessor|https://github.com/apache/cassandra/blob/8451acc8d8dcfee20d692d1e70ae11b60d2f004e/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L447]
>
> This is pretty easy to stumble across when testing guardrails as
> GuardrailTester adds a variety of assertFails and assertThrows signatures
> that _do_ respect the client state and thus apply guardrails
> ([example|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java#L271])
>
> We should add documentation to the method calls in CQLTester and
> GuardrailTester to reflect this discrepancy as it can easily trip someone up
> writing tests for guardrails.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570941#comment-17570941 ] Paulo Motta commented on CASSANDRA-17768: - fwiw I don't object removing this if we think this is no longer required, as long as we give proper notice in a NEWS.txt entry. > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570937#comment-17570937 ] Paulo Motta commented on CASSANDRA-17768: - I think the original problem CASSANDRA-11841 was intended to solve is when operators are using networks/firewalls they have little/no control of (ie. cloud/vpn providers), and can't set recommended net.ipv4.tcp_keepalive* settings. The idea is to have an app-layer keep-alive to ensure we don't depend on network settings to keep long-lived cross-datacenter connections alive. This is certainly a niche feature, but I don't know if it's still useful or not. A few pointers to conextualize the use-case being addressed by that setting: - CASSANDRA-12830 - [https://www.mail-archive.com/user@cassandra.apache.org/msg54529.html] - [https://docs.datastax.com/en/archived/cassandra/2.0/cassandra/troubleshooting/trblshootIdleFirewall.html] > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17759) Altering / creating of a keyspace on insufficient number of replicas should filter out gosspping only members
[
https://issues.apache.org/jira/browse/CASSANDRA-17759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570934#comment-17570934
]
Brandon Williams commented on CASSANDRA-17759:
--
Everything looks fine, +1.
I think it's best that we follow the ratified process as much as possible,
since another pair of eyes is never a bad idea (if you can get them!) and,
should something get broken, it's better to have a partner to help shoulder the
blame. :)
> Altering / creating of a keyspace on insufficient number of replicas should
> filter out gosspping only members
> -
>
> Key: CASSANDRA-17759
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17759
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.14, 4.0.6, 4.1-beta, 4.2
>
>
> When there is a CQL CREATE / ALTER KEYSPACE query executed on a
> gossipping-only member of a cluster (-Dcassandra.join_ring=false) where the
> replication factor is bigger than the number of the nodes, there is currently
> a warning emitted, which is ok, but this number also includes the gossipping
> node itself. This is incorrect as such a node is not part of a ring hence it
> does not hold any data.
> This is not happening on "data" nodes (members of the ring) as from data
> nodes perspective, gossipping-only members are not visible.
> We should filter gossipping-only members out of the computation.
> EDIT:
> For the sake of the completeness, I leave here the original description of
> this ticket:
> The original issue for which we refused to do any action:
> Imagine there is a 5-node cluster where two nodes are gossipping-only members
> (-Dcassandra.join_ring=false) - or in other words, 3 data nodes and 2
> "coordinator" nodes.
> Coordinator nodes are capable to speak CQL as well so requests can be
> executed against them. If we create a keyspace against such node, like
> "create keyspace ks1 with replication =
> {class = "NTS", "dc1": 5}
> , this query succeeds but if we set CONSISTENCY to ALL in cqlsh and we try to
> insert some data into a table of such keyspace, it will fail - because it
> does not have enough replicas. It has only 3.
> If this query is executed on data node (a proper member of a ring), this
> should fail too. I think there is a mechanism how to do this, like by
> Guardrails but there is no check which would include gossipping-only members
> into consideration.
> Ideally, we might introduce a check which would check that the replication
> factor is at most as big as the number of members - irrelevant of their
> current status, they just have to be members of the ring.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17738) Validate that JMX updates any new 4.1 properties (which are not moved to the new Config classes; non-duration, non-data rate, non-data storage)
[ https://issues.apache.org/jira/browse/CASSANDRA-17738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17738: Fix Version/s: 4.1 (was: 4.x) (was: 4.1.x) Source Control Link: https://github.com/apache/cassandra/commit/1c70149ef512212d9cf8f57cb703fce92bf3dafa Resolution: Fixed Status: Resolved (was: Ready to Commit) > Validate that JMX updates any new 4.1 properties (which are not moved to the > new Config classes; non-duration, non-data rate, non-data storage) > --- > > Key: CASSANDRA-17738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17738 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1 > > > Check that any properties which are added in 4.1 (non-Duration, non-Data > Storage, non-Data Rate) are always updated by JMX and there are no > inconsistent validations that might cover bugs. Validate proper update in > Settings Virtual Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > _columns_per_table_warn_threshold, partition_keys_in_select_fail_threshold, > group_by_enabled, cdc_block_writes, paxos_variant, > max_top_tombstone_partition_count, data_disk_usage_percentage_fail_threshold, > internode_timeout, compaction_tombstone_warning_threshold, > enable_uuid_sstable_identifiers, user_timestamps_enabled, > paxos_topology_repair_no_dc_checks, scripted_user_defined_functions_enabled, > denylist_max_keys_per_table, auth_cache_warming_enabled, > write_consistency_levels_disallowed, auth_write_consistency_level, > denylist_range_reads_enabled, roles_cache_active_update, > paxos_repair_parallelism, hint_window_persistent_enabled, > paxos_contention_max_wait, table_properties_ignored, > read_before_write_list_operations_enabled, > in_select_cartesian_product_warn_threshold, > paxos_topology_repair_strict_each_quorum, top_partitions_enabled, > secondary_indexes_per_table_fail_threshold, auto_snapshot_ttl, > read_consistency_levels_warned, secondary_indexes_enabled, > internode_error_reporting_exclusions, paxos_contention_min_delta, > default_keyspace_rf, write_consistency_levels_warned, > use_deterministic_table_id, sasi_indexes_enabled, > min_tracked_partition_tombstone_count, > minimum_replication_factor_fail_threshold, table_properties_disallowed, > memtable, keyspaces_warn_threshold, transient_replication_enabled, > user_defined_functions_enabled, user_defined_functions_threads_enabled, > native_transport_max_requests_per_second, > in_select_cartesian_product_fail_threshold, denylist_max_keys_total, > tables_fail_threshold, read_consistency_levels_disallowed, > fields_per_udt_warn_threshold, paxos_on_linearizability_violations, > page_size_warn_threshold, minimum_replication_factor_warn_threshold, > denylist_writes_enabled, traverse_auth_from_root, denylist_consistency_level, > table_properties_warned, materialized_views_enabled, > fields_per_udt_fail_threshold, denylist_reads_enabled, > permissions_cache_active_update, available_processors, > secondary_indexes_per_table_warn_threshold, tables_warn_threshold, > client_error_reporting_exclusions, items_per_collection_warn_threshold, > page_size_fail_threshold, paxos_contention_wait_randomizer, > partition_denylist_enabled, skip_paxos_repair_on_topology_change_keyspaces, > credentials_cache_active_update, failure_detector, > drop_compact_storage_enabled, uncompressed_tables_enabled, > materialized_views_per_table_fail_threshold, keyspaces_fail_threshold, > data_disk_usage_percentage_warn_threshold, repair_state_size, > paxos_contention_min_wait, auth_read_consistency_level, > items_per_collection_fail_threshold, paxos_state_purging, > materialized_views_per_table_warn_threshold, allow_filtering_enabled, > columns_per_table_fail_threshold, paxos_repair_enabled, startup_checks, > compact_tables_enabled, drop_truncate_table_enabled, > max_top_size_partition_count, native_transport_rate_limiting_enabled, > use_statements_enabled, auto_hints_cleanup_enabled, > skip_paxos_repair_on_topology_change, > partition_keys_in_select_warn_threshold, read_thresholds_enabled_ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CASSANDRA-17738) Validate that JMX updates any new 4.1 properties (which are not moved to the new Config classes; non-duration, non-data rate, non-data storage)
[ https://issues.apache.org/jira/browse/CASSANDRA-17738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570932#comment-17570932 ] Ekaterina Dimitrova commented on CASSANDRA-17738: - Committed, thanks! 15b7d678e9..1c70149ef5 cassandra-4.1 -> cassandra-4.1 523424b9ff..d2d6afb8e9 trunk -> trunk > Validate that JMX updates any new 4.1 properties (which are not moved to the > new Config classes; non-duration, non-data rate, non-data storage) > --- > > Key: CASSANDRA-17738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17738 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > Check that any properties which are added in 4.1 (non-Duration, non-Data > Storage, non-Data Rate) are always updated by JMX and there are no > inconsistent validations that might cover bugs. Validate proper update in > Settings Virtual Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > _columns_per_table_warn_threshold, partition_keys_in_select_fail_threshold, > group_by_enabled, cdc_block_writes, paxos_variant, > max_top_tombstone_partition_count, data_disk_usage_percentage_fail_threshold, > internode_timeout, compaction_tombstone_warning_threshold, > enable_uuid_sstable_identifiers, user_timestamps_enabled, > paxos_topology_repair_no_dc_checks, scripted_user_defined_functions_enabled, > denylist_max_keys_per_table, auth_cache_warming_enabled, > write_consistency_levels_disallowed, auth_write_consistency_level, > denylist_range_reads_enabled, roles_cache_active_update, > paxos_repair_parallelism, hint_window_persistent_enabled, > paxos_contention_max_wait, table_properties_ignored, > read_before_write_list_operations_enabled, > in_select_cartesian_product_warn_threshold, > paxos_topology_repair_strict_each_quorum, top_partitions_enabled, > secondary_indexes_per_table_fail_threshold, auto_snapshot_ttl, > read_consistency_levels_warned, secondary_indexes_enabled, > internode_error_reporting_exclusions, paxos_contention_min_delta, > default_keyspace_rf, write_consistency_levels_warned, > use_deterministic_table_id, sasi_indexes_enabled, > min_tracked_partition_tombstone_count, > minimum_replication_factor_fail_threshold, table_properties_disallowed, > memtable, keyspaces_warn_threshold, transient_replication_enabled, > user_defined_functions_enabled, user_defined_functions_threads_enabled, > native_transport_max_requests_per_second, > in_select_cartesian_product_fail_threshold, denylist_max_keys_total, > tables_fail_threshold, read_consistency_levels_disallowed, > fields_per_udt_warn_threshold, paxos_on_linearizability_violations, > page_size_warn_threshold, minimum_replication_factor_warn_threshold, > denylist_writes_enabled, traverse_auth_from_root, denylist_consistency_level, > table_properties_warned, materialized_views_enabled, > fields_per_udt_fail_threshold, denylist_reads_enabled, > permissions_cache_active_update, available_processors, > secondary_indexes_per_table_warn_threshold, tables_warn_threshold, > client_error_reporting_exclusions, items_per_collection_warn_threshold, > page_size_fail_threshold, paxos_contention_wait_randomizer, > partition_denylist_enabled, skip_paxos_repair_on_topology_change_keyspaces, > credentials_cache_active_update, failure_detector, > drop_compact_storage_enabled, uncompressed_tables_enabled, > materialized_views_per_table_fail_threshold, keyspaces_fail_threshold, > data_disk_usage_percentage_warn_threshold, repair_state_size, > paxos_contention_min_wait, auth_read_consistency_level, > items_per_collection_fail_threshold, paxos_state_purging, > materialized_views_per_table_warn_threshold, allow_filtering_enabled, > columns_per_table_fail_threshold, paxos_repair_enabled, startup_checks, > compact_tables_enabled, drop_truncate_table_enabled, > max_top_size_partition_count, native_transport_rate_limiting_enabled, > use_statements_enabled, auto_hints_cleanup_enabled, > skip_paxos_repair_on_topology_change, > partition_keys_in_select_warn_threshold, read_thresholds_enabled_ -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail:
[cassandra] branch cassandra-4.1 updated (15b7d678e9 -> 1c70149ef5)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 15b7d678e9 Merge branch 'cassandra-4.0' into cassandra-4.1 add 1c70149ef5 Fix Settings Virtual Table to update paxos_variant after startup and rename enable_uuid_sstable_identifiers to uuid_sstable_identifiers_enabled as per our config naming conventions patch by Ekaterina Dimitrova; reviewed by Brandon Williams for CASSANDRA-17738 No new revisions were added by this update. Summary of changes: CHANGES.txt| 2 ++ NEWS.txt | 1 + conf/cassandra.yaml| 2 +- src/java/org/apache/cassandra/config/Config.java | 2 +- .../org/apache/cassandra/config/DatabaseDescriptor.java| 2 +- src/java/org/apache/cassandra/service/StartupChecks.java | 2 +- src/java/org/apache/cassandra/service/paxos/Paxos.java | 1 + .../distributed/test/SSTableIdGenerationTest.java | 2 +- .../org/apache/cassandra/service/StorageProxyTest.java | 14 ++ 9 files changed, 23 insertions(+), 5 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d2d6afb8e928755b3ddcb06e0d3b254fa858fec9 Merge: 523424b9ff 1c70149ef5 Author: Ekaterina Dimitrova AuthorDate: Mon Jul 25 10:15:30 2022 -0400 Merge branch 'cassandra-4.1' into trunk CHANGES.txt| 4 NEWS.txt | 1 + conf/cassandra.yaml| 2 +- src/java/org/apache/cassandra/config/Config.java | 2 +- .../org/apache/cassandra/config/DatabaseDescriptor.java| 2 +- src/java/org/apache/cassandra/service/StartupChecks.java | 2 +- src/java/org/apache/cassandra/service/paxos/Paxos.java | 1 + .../distributed/test/SSTableIdGenerationTest.java | 2 +- .../org/apache/cassandra/service/StorageProxyTest.java | 14 ++ 9 files changed, 25 insertions(+), 5 deletions(-) diff --cc CHANGES.txt index d0190865ea,daea0c35ba..33753cb531 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,23 -1,8 +1,27 @@@ -4.1-alpha2 +4.2 + * Add guardrail to disallow DROP KEYSPACE commands (CASSANDRA-17767) + * Remove ephemeral snapshot marker file and introduce a flag to SnapshotManifest (CASSANDRA-16911) + * Add a virtual table that exposes currently running queries (CASSANDRA-15241) + * Allow sstableloader to specify table without relying on path (CASSANDRA-16584) + * Fix TestGossipingPropertyFileSnitch.test_prefer_local_reconnect_on_listen_address (CASSANDRA-17700) + * Add ByteComparable API (CASSANDRA-6936) + * Add guardrail for maximum replication factor (CASSANDRA-17500) + * Increment CQLSH to version 6.2.0 for release 4.2 (CASSANDRA-17646) + * Adding support to perform certificate based internode authentication (CASSANDRA-17661) + * Option to disable CDC writes of repaired data (CASSANDRA-17666) + * When a node is bootstrapping it gets the whole gossip state but applies in random order causing some cases where StorageService will fail causing an instance to not show up in TokenMetadata (CASSANDRA-17676) + * Add CQLSH command SHOW REPLICAS (CASSANDRA-17577) + * Add guardrail to allow disabling of SimpleStrategy (CASSANDRA-17647) + * Change default directory permission to 750 in packaging (CASSANDRA-17470) + * Adding support for TLS client authentication for internode communication (CASSANDRA-17513) + * Add new CQL function maxWritetime (CASSANDRA-17425) + * Add guardrail for ALTER TABLE ADD / DROP / REMOVE column operations (CASSANDRA-17495) + * Rename DisableFlag class to EnableFlag on guardrails (CASSANDRA-17544) +Merged from 4.1: + * Fix Settings Virtual Table to update paxos_variant after startup and rename enable_uuid_sstable_identifiers to +uuid_sstable_identifiers_enabled as per our config naming conventions (CASSANDRA-17738) + * index_summary_resize_interval_in_minutes = -1 is equivalent to index_summary_resize_interval being set to null or +disabled. JMX MBean IndexSummaryManager, setResizeIntervalInMinutes method still takes resizeIntervalInMinutes = -1 for disabled (CASSANDRA-17735) * min_tracked_partition_size_bytes parameter from 4.1 alpha1 was renamed to min_tracked_partition_size (CASSANDRA-17733) * Remove commons-lang dependency during build runtime (CASSANDRA-17724) * Relax synchronization on StreamSession#onError() to avoid deadlock (CASSANDRA-17706) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (523424b9ff -> d2d6afb8e9)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 523424b9ff Merge branch 'cassandra-4.1' into trunk add 1c70149ef5 Fix Settings Virtual Table to update paxos_variant after startup and rename enable_uuid_sstable_identifiers to uuid_sstable_identifiers_enabled as per our config naming conventions patch by Ekaterina Dimitrova; reviewed by Brandon Williams for CASSANDRA-17738 new d2d6afb8e9 Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 4 NEWS.txt | 1 + conf/cassandra.yaml| 2 +- src/java/org/apache/cassandra/config/Config.java | 2 +- .../org/apache/cassandra/config/DatabaseDescriptor.java| 2 +- src/java/org/apache/cassandra/service/StartupChecks.java | 2 +- src/java/org/apache/cassandra/service/paxos/Paxos.java | 1 + .../distributed/test/SSTableIdGenerationTest.java | 2 +- .../org/apache/cassandra/service/StorageProxyTest.java | 14 ++ 9 files changed, 25 insertions(+), 5 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16562) Fix flaky testSkipScrubCorruptedCounterRowWithTool
[
https://issues.apache.org/jira/browse/CASSANDRA-16562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570921#comment-17570921
]
Andres de la Peña edited comment on CASSANDRA-16562 at 7/25/22 2:11 PM:
I think the failures of {{ScrubTest}} on 3.0 are addressed by CASSANDRA-17314.
As for 3.11, it doesn't seem to fail anymore, as it is shown by [repeated runs
on
CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/1953/workflows/dcda4293-58ce-4abf-9ca8-e44f30a47a4f]
and [Butler's
reports|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-3.11/cassandra-3.11].
was (Author: adelapena):
I think the failures of {{ScrubTest}} on 3.0 are addressed by CASSANDRA-17314.
As for 3.11, it doesn't seem to fail anymore, as it is shown by [repeated runs
on
CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/1953/workflows/dcda4293-58ce-4abf-9ca8-e44f30a47a4f]
and
[Butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-3.11/cassandra-3.11].
> Fix flaky testSkipScrubCorruptedCounterRowWithTool
> --
>
> Key: CASSANDRA-16562
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16562
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> See CASSANDRA-16532 where extra flakiness was detected on 3.0 and 3.11
> branches for {{testSkipScrubCorruptedCounterRowWithTool}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16562) Fix flaky testSkipScrubCorruptedCounterRowWithTool
[
https://issues.apache.org/jira/browse/CASSANDRA-16562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570921#comment-17570921
]
Andres de la Peña commented on CASSANDRA-16562:
---
I think the failures of {{ScrubTest}} on 3.0 are addressed by CASSANDRA-17314.
As for 3.11, it doesn't seem to fail anymore, as it is shown by [repeated runs
on
CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/1953/workflows/dcda4293-58ce-4abf-9ca8-e44f30a47a4f]
and
[Butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-3.11/cassandra-3.11].
> Fix flaky testSkipScrubCorruptedCounterRowWithTool
> --
>
> Key: CASSANDRA-16562
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16562
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> See CASSANDRA-16532 where extra flakiness was detected on 3.0 and 3.11
> branches for {{testSkipScrubCorruptedCounterRowWithTool}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17314) Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
[
https://issues.apache.org/jira/browse/CASSANDRA-17314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17314:
--
Status: Needs Committer (was: Patch Available)
> Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
>
>
> Key: CASSANDRA-17314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17314
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x
>
>
> Failed 10 times in the last 14 runs. Flakiness: 61%, Stability: 28%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at jdk.nashorn.internal.scripts.Script$3$\^eval\_.:program(:13)
> at
> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
> at
> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
> at
> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at java.util.Vector.forEach(Vector.java:1277)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17314) Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
[
https://issues.apache.org/jira/browse/CASSANDRA-17314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570920#comment-17570920
]
Andres de la Peña commented on CASSANDRA-17314:
---
I agree, this only affects 3.0. I'm +1 to the changes, now we need the review
of a second committer.
> Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
>
>
> Key: CASSANDRA-17314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17314
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Runtian Liu
>Priority: Normal
> Fix For: 3.0.x
>
>
> Failed 10 times in the last 14 runs. Flakiness: 61%, Stability: 28%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at jdk.nashorn.internal.scripts.Script$3$\^eval\_.:program(:13)
> at
> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
> at
> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
> at
> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at java.util.Vector.forEach(Vector.java:1277)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17754) When bootstrap fails, CassandraRoleManager may attempt to do read queries that fail with "Cannot read from a bootstrapping node", and increments unavailables counter
[ https://issues.apache.org/jira/browse/CASSANDRA-17754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-17754: Status: Ready to Commit (was: Review In Progress) LGTM, the one test failure is unrelated & I see what looks like another flake in the same fixture in Butler. > When bootstrap fails, CassandraRoleManager may attempt to do read queries > that fail with "Cannot read from a bootstrapping node", and increments > unavailables counters > -- > > Key: CASSANDRA-17754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17754 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, > Feature/Authorization >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > If bootstrap fails we stay alive but avoid joining the ring. > CassandraRoleManager attempts to schedule its setup every 10 seconds, but > this will fail due to Bootstrap being pending; the side effect to this is > that readMetrics.unavailables gets incremented. > We should defer attempting to setup only after we know its safe to perform > such as read -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17754) When bootstrap fails, CassandraRoleManager may attempt to do read queries that fail with "Cannot read from a bootstrapping node", and increments unavailables counter
[ https://issues.apache.org/jira/browse/CASSANDRA-17754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-17754: Reviewers: Sam Tunnicliffe, Sam Tunnicliffe Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe) Status: Review In Progress (was: Patch Available) > When bootstrap fails, CassandraRoleManager may attempt to do read queries > that fail with "Cannot read from a bootstrapping node", and increments > unavailables counters > -- > > Key: CASSANDRA-17754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17754 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, > Feature/Authorization >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > If bootstrap fails we stay alive but avoid joining the ring. > CassandraRoleManager attempts to schedule its setup every 10 seconds, but > this will fail due to Bootstrap being pending; the side effect to this is > that readMetrics.unavailables gets incremented. > We should defer attempting to setup only after we know its safe to perform > such as read -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-8959) More efficient frozen UDT, tuple and collection serialization format
[
https://issues.apache.org/jira/browse/CASSANDRA-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570888#comment-17570888
]
Claude Warren edited comment on CASSANDRA-8959 at 7/25/22 1:11 PM:
---
It has been awhile since this was looked at and I am just getting familiar with
the code base. But reading this issue and looking at UserTypeSerializer it
looks like the issue is that the UserType (and other collections?) can have
`null` entries and the issue is that for sparse collections the serialisation
is not efficient.
I think that there are 3 reasonable serialisation techniques:
# The current serialisation for non-sparse values
# A bitmap where each bit represents the presence/absence of a specific
indices.
# A list of integers specifying the presence of specific indices.
The bitmap could be structured as
# int length
# byte[length]
# Standard serialised data elements
The array of integers could be structured as
# int length
# int[length]
# Standard serialised data elements
In the current serialisation the first item is an integer count of the number
of items. Since there can not be a negative count we could set a flag as the
left most bit. so if the number is negative then the first byte (b) is an
encoding descriptor where
{{if (0x80 & b) == 0 then [standard processing]}}
{{if b == 0x80 then [bitmap processing]}}
{{if b == 0xC0 then [array processing]}}
{{If we limit the number of items in the structures to 2^30-1 (1,073,741,823)
then we can calculate the length for the bitmap and array as int length =
access.getInt( value ) & 0x7FFF }}
If n is the number of values in the collection and p is the number of values
that are non-null (populated) then using array encoding is more efficient if
n/32 > p
was (Author: claudenw):
It has been awhile since this was looked at and I am just getting familiar with
the code base. But reading this issue and looking at UserTypeSerializer it
looks like the issue is that the UserType (and other collections?) can have
`null` entries and the issue is that for sparse collections the serialisation
is not efficient.
I think that there are 3 reasonable serialisation techniques:
# The current serialisation for non-sparse values
# A bitmap where each bit represents the presence/absence of a specific
indices.
# A list of integers specifying the presence of specific indices.
The bitmap could be structured as
# int length
# byte[length]
# Standard serialised data elements
The array of integers could be structured as
# int length
# int[length]
# Standard serialised data elements
In the current serialisation the first item is an integer count of the number
of items. Since there can not be a negative count we could set a flag as the
left most bit. so if the number is negative then the first byte (b) is an
encoding descriptor where
{{if (0x80 & b) == 0 then [standard processing]}}
{{if b == 0x80 then [bitmap processing]}}
{{if b == 0xC0 then [array processing]}}
{{If we limit the number of items in the structures to 2^30-1 (1,073,741,823)
then we can calculate the length for the bitmap and array as int length =
access.getInt( value ) & 0x7FFF }}
> More efficient frozen UDT, tuple and collection serialization format
>
>
> Key: CASSANDRA-8959
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8959
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Aleksey Yeschenko
>Priority: Normal
> Labels: performance
> Fix For: 4.x
>
>
> The current serialization format for UDTs has a fixed overhead of 4 bytes per
> defined field (encoding the size of the field).
> It is inefficient for sparse UDTs - ones with many defined fields, but few of
> them present. We could keep a bitset to indicate the missing fields, if any.
> It's sub-optimal for encoding UDTs with all the values present as well. We
> could use varint encoding for the field sizes of blob/text fields and encode
> 'fixed' sized types directly, without the 4-bytes size prologue.
> That or something more brilliant. Any improvement right now is lhf.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8959) More efficient frozen UDT, tuple and collection serialization format
[
https://issues.apache.org/jira/browse/CASSANDRA-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570888#comment-17570888
]
Claude Warren commented on CASSANDRA-8959:
--
It has been awhile since this was looked at and I am just getting familiar with
the code base. But reading this issue and looking at UserTypeSerializer it
looks like the issue is that the UserType (and other collections?) can have
`null` entries and the issue is that for sparse collections the serialisation
is not efficient.
I think that there are 3 reasonable serialisation techniques:
# The current serialisation for non-sparse values
# A bitmap where each bit represents the presence/absence of a specific
indices.
# A list of integers specifying the presence of specific indices.
The bitmap could be structured as
# int length
# byte[length]
# Standard serialised data elements
The array of integers could be structured as
# int length
# int[length]
# Standard serialised data elements
In the current serialisation the first item is an integer count of the number
of items. Since there can not be a negative count we could set a flag as the
left most bit. so if the number is negative then the first byte (b) is an
encoding descriptor where
{{if (0x80 & b) == 0 then [standard processing]}}
{{if b == 0x80 then [bitmap processing]}}
{{if b == 0xC0 then [array processing]}}
{{If we limit the number of items in the structures to 2^30-1 (1,073,741,823)
then we can calculate the length for the bitmap and array as int length =
access.getInt( value ) & 0x7FFF }}
> More efficient frozen UDT, tuple and collection serialization format
>
>
> Key: CASSANDRA-8959
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8959
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Aleksey Yeschenko
>Priority: Normal
> Labels: performance
> Fix For: 4.x
>
>
> The current serialization format for UDTs has a fixed overhead of 4 bytes per
> defined field (encoding the size of the field).
> It is inefficient for sparse UDTs - ones with many defined fields, but few of
> them present. We could keep a bitset to indicate the missing fields, if any.
> It's sub-optimal for encoding UDTs with all the values present as well. We
> could use varint encoding for the field sizes of blob/text fields and encode
> 'fixed' sized types directly, without the 4-bytes size prologue.
> That or something more brilliant. Any improvement right now is lhf.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17748) Move deb/rpm repositories from dist/downloads .a.o to apache.jfrog.io
[ https://issues.apache.org/jira/browse/CASSANDRA-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570871#comment-17570871 ] Michael Semb Wever commented on CASSANDRA-17748: Have created INFRA-23511 to investigate the latter. > Move deb/rpm repositories from dist/downloads .a.o to apache.jfrog.io > - > > Key: CASSANDRA-17748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17748 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Urgent > Labels: pull-request-available > > Move our official debian and redhat repositories from downloads.apache.org to > Apache's JFrog Artifactory server at apache.jfrog.io > That is, the following URLs would be moved from > ``` > https://downloads.apache.org/cassandra/debian/ > https://downloads.apache.org/cassandra/redhat/ > ``` > to > ``` > https://apache.jfrog.io/artifactory/cassandra-deb/ > https://apache.jfrog.io/artifactory/cassandra-rpm/ > ``` > The rationale to do this is to avoid the strict opinionated checksum and > signature requirements on downloads.a.o (dist.a.o), as the debian and redhat > repositories have their own system for integrity and signing (which we > already do). > Furthermore, as these repositories and their binaries are "convenience > binaries" and not the official Cassandra source binaries, they do not need to > be on downloads.a.o and can be served from apache.jfrog.io. This is similar > to maven binaries (and docker images). Apache Arrow is already taking this > approach: https://arrow.apache.org/install/ > An advantage to using apache.frog.io is that these repositories maintain all > past patch versions on each repo series (major/minor). This has been > requested by users a number of times, for the sake of rolling back to a > previous patch version. downloads.a.o can only contain the latest version. > This will BREAK everyone's existing > `/etc/apt/sources.list.d/cassandra.sources.list` and > `/etc/yum.repos.d/cassandra.repo` files. Folk will need to update these files > to point to the new repo URLs. This would require an announcement to both > users@ and dev@. I do not know how we can avoid this breakage. We could put > in a simple README.md in the original URL locations explaining the breakage > and how to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17748) Move deb/rpm repositories from dist/downloads .a.o to apache.jfrog.io
[ https://issues.apache.org/jira/browse/CASSANDRA-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570859#comment-17570859 ] Michael Semb Wever commented on CASSANDRA-17748: In tree patches also required - [3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:cassandra:mck/17748/3.11] - [4.0|https://github.com/apache/cassandra/compare/cassandra-4.0...thelastpickle:cassandra:mck/17748/4.0] - [4.1|https://github.com/apache/cassandra/compare/cassandra-4.1...thelastpickle:cassandra:mck/17748/4.1] - [trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/17748/trunk] Instead of cnames, as deb and rpm systems appear to handle redirects of the repo url, should we host and redirect like: https://debian.cassandra.apache.org --> https://apache.jfrog.io/artifactory/cassandra-deb https://redhat.cassandra.apache.org --> https://apache.jfrog.io/artifactory/cassandra-rpm > Move deb/rpm repositories from dist/downloads .a.o to apache.jfrog.io > - > > Key: CASSANDRA-17748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17748 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Urgent > Labels: pull-request-available > > Move our official debian and redhat repositories from downloads.apache.org to > Apache's JFrog Artifactory server at apache.jfrog.io > That is, the following URLs would be moved from > ``` > https://downloads.apache.org/cassandra/debian/ > https://downloads.apache.org/cassandra/redhat/ > ``` > to > ``` > https://apache.jfrog.io/artifactory/cassandra-deb/ > https://apache.jfrog.io/artifactory/cassandra-rpm/ > ``` > The rationale to do this is to avoid the strict opinionated checksum and > signature requirements on downloads.a.o (dist.a.o), as the debian and redhat > repositories have their own system for integrity and signing (which we > already do). > Furthermore, as these repositories and their binaries are "convenience > binaries" and not the official Cassandra source binaries, they do not need to > be on downloads.a.o and can be served from apache.jfrog.io. This is similar > to maven binaries (and docker images). Apache Arrow is already taking this > approach: https://arrow.apache.org/install/ > An advantage to using apache.frog.io is that these repositories maintain all > past patch versions on each repo series (major/minor). This has been > requested by users a number of times, for the sake of rolling back to a > previous patch version. downloads.a.o can only contain the latest version. > This will BREAK everyone's existing > `/etc/apt/sources.list.d/cassandra.sources.list` and > `/etc/yum.repos.d/cassandra.repo` files. Folk will need to update these files > to point to the new repo URLs. This would require an announcement to both > users@ and dev@. I do not know how we can avoid this breakage. We could put > in a simple README.md in the original URL locations explaining the breakage > and how to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9911) Remove ConcurrentLinkedHashCache
[ https://issues.apache.org/jira/browse/CASSANDRA-9911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-9911: Resolution: Duplicate Status: Resolved (was: Open) This was done in CASSANDRA-10855 > Remove ConcurrentLinkedHashCache > > > Key: CASSANDRA-9911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9911 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Core >Reporter: Robert Stupp >Priority: Low > Fix For: 4.x > > > ... when CASSANDRA-9738 + CASSANDRA-9739 have landed -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17772) Improve documentation around query methods in CQLTester and GuardrailTester
[
https://issues.apache.org/jira/browse/CASSANDRA-17772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570827#comment-17570827
]
Andres de la Peña edited comment on CASSANDRA-17772 at 7/25/22 10:37 AM:
-
Looks good to me, just dropped a couple of nits on [the
commit|https://github.com/josh-mckenzie/cassandra/commit/cc81184461476b558c4440a7cd00f9015f899ca8].
Maybe we could add a brief class-level JavaDoc to {{GuardrailTester}} saying
that the class provides utility methods for testing guardrails that,
differently to {{{}CQLTester{}}}, can use more client states than only the
internal one. wdyt?
was (Author: adelapena):
Looks good to me, just dropped a couple of nits on [the
commit|https://github.com/josh-mckenzie/cassandra/commit/cc81184461476b558c4440a7cd00f9015f899ca8].
> Improve documentation around query methods in CQLTester and GuardrailTester
> ---
>
> Key: CASSANDRA-17772
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17772
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> Anything that relies on CQLTester.executeFormattedQuery (the
> assertInvalidThrowMessage methods for instance) will use internal client
> state rather than the client state specified for the query, thus nullifying
> any guardrail or systems keyspace permission checks as the
> ClientState.isInternal flag overrides all such permission checking.
> Reference:
> [link|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L385-L388]
>
> See chain of CQLTester -> ClientState.isInternal here if interested:
> [CQLTester|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L1325]
> [QueryProcessor|https://github.com/apache/cassandra/blob/8451acc8d8dcfee20d692d1e70ae11b60d2f004e/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L447]
>
> This is pretty easy to stumble across when testing guardrails as
> GuardrailTester adds a variety of assertFails and assertThrows signatures
> that _do_ respect the client state and thus apply guardrails
> ([example|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java#L271])
>
> We should add documentation to the method calls in CQLTester and
> GuardrailTester to reflect this discrepancy as it can easily trip someone up
> writing tests for guardrails.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17738) Validate that JMX updates any new 4.1 properties (which are not moved to the new Config classes; non-duration, non-data rate, non-data storage)
[ https://issues.apache.org/jira/browse/CASSANDRA-17738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17738: - Status: Ready to Commit (was: Review In Progress) > Validate that JMX updates any new 4.1 properties (which are not moved to the > new Config classes; non-duration, non-data rate, non-data storage) > --- > > Key: CASSANDRA-17738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17738 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > Check that any properties which are added in 4.1 (non-Duration, non-Data > Storage, non-Data Rate) are always updated by JMX and there are no > inconsistent validations that might cover bugs. Validate proper update in > Settings Virtual Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > _columns_per_table_warn_threshold, partition_keys_in_select_fail_threshold, > group_by_enabled, cdc_block_writes, paxos_variant, > max_top_tombstone_partition_count, data_disk_usage_percentage_fail_threshold, > internode_timeout, compaction_tombstone_warning_threshold, > enable_uuid_sstable_identifiers, user_timestamps_enabled, > paxos_topology_repair_no_dc_checks, scripted_user_defined_functions_enabled, > denylist_max_keys_per_table, auth_cache_warming_enabled, > write_consistency_levels_disallowed, auth_write_consistency_level, > denylist_range_reads_enabled, roles_cache_active_update, > paxos_repair_parallelism, hint_window_persistent_enabled, > paxos_contention_max_wait, table_properties_ignored, > read_before_write_list_operations_enabled, > in_select_cartesian_product_warn_threshold, > paxos_topology_repair_strict_each_quorum, top_partitions_enabled, > secondary_indexes_per_table_fail_threshold, auto_snapshot_ttl, > read_consistency_levels_warned, secondary_indexes_enabled, > internode_error_reporting_exclusions, paxos_contention_min_delta, > default_keyspace_rf, write_consistency_levels_warned, > use_deterministic_table_id, sasi_indexes_enabled, > min_tracked_partition_tombstone_count, > minimum_replication_factor_fail_threshold, table_properties_disallowed, > memtable, keyspaces_warn_threshold, transient_replication_enabled, > user_defined_functions_enabled, user_defined_functions_threads_enabled, > native_transport_max_requests_per_second, > in_select_cartesian_product_fail_threshold, denylist_max_keys_total, > tables_fail_threshold, read_consistency_levels_disallowed, > fields_per_udt_warn_threshold, paxos_on_linearizability_violations, > page_size_warn_threshold, minimum_replication_factor_warn_threshold, > denylist_writes_enabled, traverse_auth_from_root, denylist_consistency_level, > table_properties_warned, materialized_views_enabled, > fields_per_udt_fail_threshold, denylist_reads_enabled, > permissions_cache_active_update, available_processors, > secondary_indexes_per_table_warn_threshold, tables_warn_threshold, > client_error_reporting_exclusions, items_per_collection_warn_threshold, > page_size_fail_threshold, paxos_contention_wait_randomizer, > partition_denylist_enabled, skip_paxos_repair_on_topology_change_keyspaces, > credentials_cache_active_update, failure_detector, > drop_compact_storage_enabled, uncompressed_tables_enabled, > materialized_views_per_table_fail_threshold, keyspaces_fail_threshold, > data_disk_usage_percentage_warn_threshold, repair_state_size, > paxos_contention_min_wait, auth_read_consistency_level, > items_per_collection_fail_threshold, paxos_state_purging, > materialized_views_per_table_warn_threshold, allow_filtering_enabled, > columns_per_table_fail_threshold, paxos_repair_enabled, startup_checks, > compact_tables_enabled, drop_truncate_table_enabled, > max_top_size_partition_count, native_transport_rate_limiting_enabled, > use_statements_enabled, auto_hints_cleanup_enabled, > skip_paxos_repair_on_topology_change, > partition_keys_in_select_warn_threshold, read_thresholds_enabled_ -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17738) Validate that JMX updates any new 4.1 properties (which are not moved to the new Config classes; non-duration, non-data rate, non-data storage)
[ https://issues.apache.org/jira/browse/CASSANDRA-17738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17738: - Status: Review In Progress (was: Patch Available) > Validate that JMX updates any new 4.1 properties (which are not moved to the > new Config classes; non-duration, non-data rate, non-data storage) > --- > > Key: CASSANDRA-17738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17738 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > Check that any properties which are added in 4.1 (non-Duration, non-Data > Storage, non-Data Rate) are always updated by JMX and there are no > inconsistent validations that might cover bugs. Validate proper update in > Settings Virtual Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > _columns_per_table_warn_threshold, partition_keys_in_select_fail_threshold, > group_by_enabled, cdc_block_writes, paxos_variant, > max_top_tombstone_partition_count, data_disk_usage_percentage_fail_threshold, > internode_timeout, compaction_tombstone_warning_threshold, > enable_uuid_sstable_identifiers, user_timestamps_enabled, > paxos_topology_repair_no_dc_checks, scripted_user_defined_functions_enabled, > denylist_max_keys_per_table, auth_cache_warming_enabled, > write_consistency_levels_disallowed, auth_write_consistency_level, > denylist_range_reads_enabled, roles_cache_active_update, > paxos_repair_parallelism, hint_window_persistent_enabled, > paxos_contention_max_wait, table_properties_ignored, > read_before_write_list_operations_enabled, > in_select_cartesian_product_warn_threshold, > paxos_topology_repair_strict_each_quorum, top_partitions_enabled, > secondary_indexes_per_table_fail_threshold, auto_snapshot_ttl, > read_consistency_levels_warned, secondary_indexes_enabled, > internode_error_reporting_exclusions, paxos_contention_min_delta, > default_keyspace_rf, write_consistency_levels_warned, > use_deterministic_table_id, sasi_indexes_enabled, > min_tracked_partition_tombstone_count, > minimum_replication_factor_fail_threshold, table_properties_disallowed, > memtable, keyspaces_warn_threshold, transient_replication_enabled, > user_defined_functions_enabled, user_defined_functions_threads_enabled, > native_transport_max_requests_per_second, > in_select_cartesian_product_fail_threshold, denylist_max_keys_total, > tables_fail_threshold, read_consistency_levels_disallowed, > fields_per_udt_warn_threshold, paxos_on_linearizability_violations, > page_size_warn_threshold, minimum_replication_factor_warn_threshold, > denylist_writes_enabled, traverse_auth_from_root, denylist_consistency_level, > table_properties_warned, materialized_views_enabled, > fields_per_udt_fail_threshold, denylist_reads_enabled, > permissions_cache_active_update, available_processors, > secondary_indexes_per_table_warn_threshold, tables_warn_threshold, > client_error_reporting_exclusions, items_per_collection_warn_threshold, > page_size_fail_threshold, paxos_contention_wait_randomizer, > partition_denylist_enabled, skip_paxos_repair_on_topology_change_keyspaces, > credentials_cache_active_update, failure_detector, > drop_compact_storage_enabled, uncompressed_tables_enabled, > materialized_views_per_table_fail_threshold, keyspaces_fail_threshold, > data_disk_usage_percentage_warn_threshold, repair_state_size, > paxos_contention_min_wait, auth_read_consistency_level, > items_per_collection_fail_threshold, paxos_state_purging, > materialized_views_per_table_warn_threshold, allow_filtering_enabled, > columns_per_table_fail_threshold, paxos_repair_enabled, startup_checks, > compact_tables_enabled, drop_truncate_table_enabled, > max_top_size_partition_count, native_transport_rate_limiting_enabled, > use_statements_enabled, auto_hints_cleanup_enabled, > skip_paxos_repair_on_topology_change, > partition_keys_in_select_warn_threshold, read_thresholds_enabled_ -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17738) Validate that JMX updates any new 4.1 properties (which are not moved to the new Config classes; non-duration, non-data rate, non-data storage)
[ https://issues.apache.org/jira/browse/CASSANDRA-17738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17738: - Reviewers: Brandon Williams > Validate that JMX updates any new 4.1 properties (which are not moved to the > new Config classes; non-duration, non-data rate, non-data storage) > --- > > Key: CASSANDRA-17738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17738 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > Check that any properties which are added in 4.1 (non-Duration, non-Data > Storage, non-Data Rate) are always updated by JMX and there are no > inconsistent validations that might cover bugs. Validate proper update in > Settings Virtual Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > _columns_per_table_warn_threshold, partition_keys_in_select_fail_threshold, > group_by_enabled, cdc_block_writes, paxos_variant, > max_top_tombstone_partition_count, data_disk_usage_percentage_fail_threshold, > internode_timeout, compaction_tombstone_warning_threshold, > enable_uuid_sstable_identifiers, user_timestamps_enabled, > paxos_topology_repair_no_dc_checks, scripted_user_defined_functions_enabled, > denylist_max_keys_per_table, auth_cache_warming_enabled, > write_consistency_levels_disallowed, auth_write_consistency_level, > denylist_range_reads_enabled, roles_cache_active_update, > paxos_repair_parallelism, hint_window_persistent_enabled, > paxos_contention_max_wait, table_properties_ignored, > read_before_write_list_operations_enabled, > in_select_cartesian_product_warn_threshold, > paxos_topology_repair_strict_each_quorum, top_partitions_enabled, > secondary_indexes_per_table_fail_threshold, auto_snapshot_ttl, > read_consistency_levels_warned, secondary_indexes_enabled, > internode_error_reporting_exclusions, paxos_contention_min_delta, > default_keyspace_rf, write_consistency_levels_warned, > use_deterministic_table_id, sasi_indexes_enabled, > min_tracked_partition_tombstone_count, > minimum_replication_factor_fail_threshold, table_properties_disallowed, > memtable, keyspaces_warn_threshold, transient_replication_enabled, > user_defined_functions_enabled, user_defined_functions_threads_enabled, > native_transport_max_requests_per_second, > in_select_cartesian_product_fail_threshold, denylist_max_keys_total, > tables_fail_threshold, read_consistency_levels_disallowed, > fields_per_udt_warn_threshold, paxos_on_linearizability_violations, > page_size_warn_threshold, minimum_replication_factor_warn_threshold, > denylist_writes_enabled, traverse_auth_from_root, denylist_consistency_level, > table_properties_warned, materialized_views_enabled, > fields_per_udt_fail_threshold, denylist_reads_enabled, > permissions_cache_active_update, available_processors, > secondary_indexes_per_table_warn_threshold, tables_warn_threshold, > client_error_reporting_exclusions, items_per_collection_warn_threshold, > page_size_fail_threshold, paxos_contention_wait_randomizer, > partition_denylist_enabled, skip_paxos_repair_on_topology_change_keyspaces, > credentials_cache_active_update, failure_detector, > drop_compact_storage_enabled, uncompressed_tables_enabled, > materialized_views_per_table_fail_threshold, keyspaces_fail_threshold, > data_disk_usage_percentage_warn_threshold, repair_state_size, > paxos_contention_min_wait, auth_read_consistency_level, > items_per_collection_fail_threshold, paxos_state_purging, > materialized_views_per_table_warn_threshold, allow_filtering_enabled, > columns_per_table_fail_threshold, paxos_repair_enabled, startup_checks, > compact_tables_enabled, drop_truncate_table_enabled, > max_top_size_partition_count, native_transport_rate_limiting_enabled, > use_statements_enabled, auto_hints_cleanup_enabled, > skip_paxos_repair_on_topology_change, > partition_keys_in_select_warn_threshold, read_thresholds_enabled_ -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17738) Validate that JMX updates any new 4.1 properties (which are not moved to the new Config classes; non-duration, non-data rate, non-data storage)
[ https://issues.apache.org/jira/browse/CASSANDRA-17738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570828#comment-17570828 ] Brandon Williams commented on CASSANDRA-17738: -- nodeDownDuringMove looks clearly environmental to me, everything else is good too. +1 > Validate that JMX updates any new 4.1 properties (which are not moved to the > new Config classes; non-duration, non-data rate, non-data storage) > --- > > Key: CASSANDRA-17738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17738 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > Check that any properties which are added in 4.1 (non-Duration, non-Data > Storage, non-Data Rate) are always updated by JMX and there are no > inconsistent validations that might cover bugs. Validate proper update in > Settings Virtual Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > _columns_per_table_warn_threshold, partition_keys_in_select_fail_threshold, > group_by_enabled, cdc_block_writes, paxos_variant, > max_top_tombstone_partition_count, data_disk_usage_percentage_fail_threshold, > internode_timeout, compaction_tombstone_warning_threshold, > enable_uuid_sstable_identifiers, user_timestamps_enabled, > paxos_topology_repair_no_dc_checks, scripted_user_defined_functions_enabled, > denylist_max_keys_per_table, auth_cache_warming_enabled, > write_consistency_levels_disallowed, auth_write_consistency_level, > denylist_range_reads_enabled, roles_cache_active_update, > paxos_repair_parallelism, hint_window_persistent_enabled, > paxos_contention_max_wait, table_properties_ignored, > read_before_write_list_operations_enabled, > in_select_cartesian_product_warn_threshold, > paxos_topology_repair_strict_each_quorum, top_partitions_enabled, > secondary_indexes_per_table_fail_threshold, auto_snapshot_ttl, > read_consistency_levels_warned, secondary_indexes_enabled, > internode_error_reporting_exclusions, paxos_contention_min_delta, > default_keyspace_rf, write_consistency_levels_warned, > use_deterministic_table_id, sasi_indexes_enabled, > min_tracked_partition_tombstone_count, > minimum_replication_factor_fail_threshold, table_properties_disallowed, > memtable, keyspaces_warn_threshold, transient_replication_enabled, > user_defined_functions_enabled, user_defined_functions_threads_enabled, > native_transport_max_requests_per_second, > in_select_cartesian_product_fail_threshold, denylist_max_keys_total, > tables_fail_threshold, read_consistency_levels_disallowed, > fields_per_udt_warn_threshold, paxos_on_linearizability_violations, > page_size_warn_threshold, minimum_replication_factor_warn_threshold, > denylist_writes_enabled, traverse_auth_from_root, denylist_consistency_level, > table_properties_warned, materialized_views_enabled, > fields_per_udt_fail_threshold, denylist_reads_enabled, > permissions_cache_active_update, available_processors, > secondary_indexes_per_table_warn_threshold, tables_warn_threshold, > client_error_reporting_exclusions, items_per_collection_warn_threshold, > page_size_fail_threshold, paxos_contention_wait_randomizer, > partition_denylist_enabled, skip_paxos_repair_on_topology_change_keyspaces, > credentials_cache_active_update, failure_detector, > drop_compact_storage_enabled, uncompressed_tables_enabled, > materialized_views_per_table_fail_threshold, keyspaces_fail_threshold, > data_disk_usage_percentage_warn_threshold, repair_state_size, > paxos_contention_min_wait, auth_read_consistency_level, > items_per_collection_fail_threshold, paxos_state_purging, > materialized_views_per_table_warn_threshold, allow_filtering_enabled, > columns_per_table_fail_threshold, paxos_repair_enabled, startup_checks, > compact_tables_enabled, drop_truncate_table_enabled, > max_top_size_partition_count, native_transport_rate_limiting_enabled, > use_statements_enabled, auto_hints_cleanup_enabled, > skip_paxos_repair_on_topology_change, > partition_keys_in_select_warn_threshold, read_thresholds_enabled_ -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17772) Improve documentation around query methods in CQLTester and GuardrailTester
[ https://issues.apache.org/jira/browse/CASSANDRA-17772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17772: -- Status: Review In Progress (was: Patch Available) > Improve documentation around query methods in CQLTester and GuardrailTester > --- > > Key: CASSANDRA-17772 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17772 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Anything that relies on CQLTester.executeFormattedQuery (the > assertInvalidThrowMessage methods for instance) will use internal client > state rather than the client state specified for the query, thus nullifying > any guardrail or systems keyspace permission checks as the > ClientState.isInternal flag overrides all such permission checking. > Reference: > [link|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L385-L388] > > See chain of CQLTester -> ClientState.isInternal here if interested: > [CQLTester|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L1325] > [QueryProcessor|https://github.com/apache/cassandra/blob/8451acc8d8dcfee20d692d1e70ae11b60d2f004e/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L447] > > This is pretty easy to stumble across when testing guardrails as > GuardrailTester adds a variety of assertFails and assertThrows signatures > that _do_ respect the client state and thus apply guardrails > ([example|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java#L271]) > > We should add documentation to the method calls in CQLTester and > GuardrailTester to reflect this discrepancy as it can easily trip someone up > writing tests for guardrails. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17772) Improve documentation around query methods in CQLTester and GuardrailTester
[ https://issues.apache.org/jira/browse/CASSANDRA-17772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570827#comment-17570827 ] Andres de la Peña commented on CASSANDRA-17772: --- Looks good to me, just dropped a couple of nits on [the commit|https://github.com/josh-mckenzie/cassandra/commit/cc81184461476b558c4440a7cd00f9015f899ca8]. > Improve documentation around query methods in CQLTester and GuardrailTester > --- > > Key: CASSANDRA-17772 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17772 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Anything that relies on CQLTester.executeFormattedQuery (the > assertInvalidThrowMessage methods for instance) will use internal client > state rather than the client state specified for the query, thus nullifying > any guardrail or systems keyspace permission checks as the > ClientState.isInternal flag overrides all such permission checking. > Reference: > [link|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L385-L388] > > See chain of CQLTester -> ClientState.isInternal here if interested: > [CQLTester|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L1325] > [QueryProcessor|https://github.com/apache/cassandra/blob/8451acc8d8dcfee20d692d1e70ae11b60d2f004e/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L447] > > This is pretty easy to stumble across when testing guardrails as > GuardrailTester adds a variety of assertFails and assertThrows signatures > that _do_ respect the client state and thus apply guardrails > ([example|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java#L271]) > > We should add documentation to the method calls in CQLTester and > GuardrailTester to reflect this discrepancy as it can easily trip someone up > writing tests for guardrails. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17772) Improve documentation around query methods in CQLTester and GuardrailTester
[ https://issues.apache.org/jira/browse/CASSANDRA-17772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17772: -- Reviewers: Andres de la Peña > Improve documentation around query methods in CQLTester and GuardrailTester > --- > > Key: CASSANDRA-17772 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17772 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Anything that relies on CQLTester.executeFormattedQuery (the > assertInvalidThrowMessage methods for instance) will use internal client > state rather than the client state specified for the query, thus nullifying > any guardrail or systems keyspace permission checks as the > ClientState.isInternal flag overrides all such permission checking. > Reference: > [link|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L385-L388] > > See chain of CQLTester -> ClientState.isInternal here if interested: > [CQLTester|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L1325] > [QueryProcessor|https://github.com/apache/cassandra/blob/8451acc8d8dcfee20d692d1e70ae11b60d2f004e/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L447] > > This is pretty easy to stumble across when testing guardrails as > GuardrailTester adds a variety of assertFails and assertThrows signatures > that _do_ respect the client state and thus apply guardrails > ([example|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java#L271]) > > We should add documentation to the method calls in CQLTester and > GuardrailTester to reflect this discrepancy as it can easily trip someone up > writing tests for guardrails. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9911) Remove ConcurrentLinkedHashCache
[ https://issues.apache.org/jira/browse/CASSANDRA-9911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570816#comment-17570816 ] Claude Warren commented on CASSANDRA-9911: -- It seems as if this has been removed. I assume ConcurrentLinkedHashCache is a java class, but I can not find it with grep. If I am correct then I think we can close this as completed. > Remove ConcurrentLinkedHashCache > > > Key: CASSANDRA-9911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9911 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Core >Reporter: Robert Stupp >Priority: Low > Fix For: 4.x > > > ... when CASSANDRA-9738 + CASSANDRA-9739 have landed -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17737) Validate that JMX updates properly any properties that were moved to the new config classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570814#comment-17570814 ] Andres de la Peña commented on CASSANDRA-17737: --- Sure, I'll check those commits. > Validate that JMX updates properly any properties that were moved to the new > config classes > --- > > Key: CASSANDRA-17737 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17737 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1-beta, 4.1.x, 4.x > > > Check that any properties moved to the new types in 4.1 (Duration, Data > Storage, Data Rate) are always updated by JMX and there are no inconsistent > validations that might cover bugs. Validate proper update in Settings Virtual > Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > *DataRateSpec* - entire_sstable_stream_throughput_outbound, > inter_dc_stream_throughput_outbound, > entire_sstable_inter_dc_stream_throughput_outbound, compaction_throughput, > stream_throughput_outbound - we have setGet* tests and those seem solid, no > issues found. > *DurationSpec* - gc_log_threshold, permissions_validity, denylist_refresh, > request_timeout, hints_flush_period, read_request_timeout, > index_summary_resize_interval, streaming_keep_alive_period, max_hint_window, > roles_update_interval, user_defined_functions_fail_timeout, > write_request_timeout, cdc_free_space_check_interval, roles_validity, > internode_streaming_tcp_user_timeout, gc_warn_threshold, > range_request_timeout, credentials_update_interval, truncate_request_timeout, > cas_contention_timeout, periodic_commitlog_sync_lag_block, > streaming_state_expires, repair_request_timeout, permissions_update_interval, > dynamic_snitch_reset_interval, internode_tcp_connect_timeout, > paxos_purge_grace_period, dynamic_snitch_update_interval, > trace_type_query_ttl, denylist_initial_load_retry, commitlog_sync_period, > native_transport_idle_timeout, credentials_validity, > validation_preview_purge_head_start, repair_state_expires, > internode_tcp_user_timeout, trace_type_repair_ttl, cache_load_timeout, > commitlog_sync_group_window, slow_query_log_timeout, > counter_write_request_timeout, user_defined_functions_warn_timeout > *DataStorageSpec* - > internode_application_send_queue_reserve_endpoint_capacity, cdc_total_space, > networking_cache_size, commitlog_total_space, > internode_application_send_queue_capacity, key_cache_size, > memtable_heap_space, trickle_fsync_interval, max_hints_size_per_host, > internode_application_receive_queue_reserve_endpoint_capacity, > native_transport_max_frame_size, coordinator_read_size_warn_threshold , > internode_application_receive_queue_reserve_global_capacity, > internode_max_message_size, file_cache_size, local_read_size_fail_threshold, > data_disk_usage_max_disk_size, memtable_offheap_space, > coordinator_read_size_fail_threshold, counter_cache_size, > prepared_statements_cache_size, batchlog_replay_throttle, > row_index_read_size_fail_threshold, index_summary_capacity, > repair_session_space, paxos_cache_size, collection_size_fail_threshold, > internode_application_send_queue_reserve_global_capacity, column_index_size, > native_transport_receive_queue_capacity, sstable_preemptive_open_interval, > max_mutation_size, min_free_space_per_drive, batch_size_fail_threshold, > hinted_handoff_throttle, row_index_read_size_warn_threshold, max_value_size, > column_index_cache_size, compaction_large_partition_warning_threshold, > max_hints_file_size, collection_size_warn_threshold, > native_transport_max_request_data_in_flight, > internode_socket_receive_buffer_size, > internode_application_receive_queue_capacity, > internode_socket_send_buffer_size, row_cache_size, > min_tracked_partition_size, local_read_size_warn_threshold, > commitlog_segment_size, batch_size_warn_threshold, streaming_state_size, > native_transport_max_request_data_in_flight_per_ip > NOTE: Some of those were checked/fixed in other tickets but I post the full > lists for completeness -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17737) Validate that JMX updates properly any properties that were moved to the new config classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17737: -- Reviewers: Andres de la Peña > Validate that JMX updates properly any properties that were moved to the new > config classes > --- > > Key: CASSANDRA-17737 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17737 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1-beta, 4.1.x, 4.x > > > Check that any properties moved to the new types in 4.1 (Duration, Data > Storage, Data Rate) are always updated by JMX and there are no inconsistent > validations that might cover bugs. Validate proper update in Settings Virtual > Table > I branched the configCompatibilityTest in 4.1 in order to get the lists of > properties in this > [commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f2c02861abf0d6c34257d2fac827562437362137] > - the commit won't get into the codebase, just pasting so people know how > the lists were generated: > *DataRateSpec* - entire_sstable_stream_throughput_outbound, > inter_dc_stream_throughput_outbound, > entire_sstable_inter_dc_stream_throughput_outbound, compaction_throughput, > stream_throughput_outbound - we have setGet* tests and those seem solid, no > issues found. > *DurationSpec* - gc_log_threshold, permissions_validity, denylist_refresh, > request_timeout, hints_flush_period, read_request_timeout, > index_summary_resize_interval, streaming_keep_alive_period, max_hint_window, > roles_update_interval, user_defined_functions_fail_timeout, > write_request_timeout, cdc_free_space_check_interval, roles_validity, > internode_streaming_tcp_user_timeout, gc_warn_threshold, > range_request_timeout, credentials_update_interval, truncate_request_timeout, > cas_contention_timeout, periodic_commitlog_sync_lag_block, > streaming_state_expires, repair_request_timeout, permissions_update_interval, > dynamic_snitch_reset_interval, internode_tcp_connect_timeout, > paxos_purge_grace_period, dynamic_snitch_update_interval, > trace_type_query_ttl, denylist_initial_load_retry, commitlog_sync_period, > native_transport_idle_timeout, credentials_validity, > validation_preview_purge_head_start, repair_state_expires, > internode_tcp_user_timeout, trace_type_repair_ttl, cache_load_timeout, > commitlog_sync_group_window, slow_query_log_timeout, > counter_write_request_timeout, user_defined_functions_warn_timeout > *DataStorageSpec* - > internode_application_send_queue_reserve_endpoint_capacity, cdc_total_space, > networking_cache_size, commitlog_total_space, > internode_application_send_queue_capacity, key_cache_size, > memtable_heap_space, trickle_fsync_interval, max_hints_size_per_host, > internode_application_receive_queue_reserve_endpoint_capacity, > native_transport_max_frame_size, coordinator_read_size_warn_threshold , > internode_application_receive_queue_reserve_global_capacity, > internode_max_message_size, file_cache_size, local_read_size_fail_threshold, > data_disk_usage_max_disk_size, memtable_offheap_space, > coordinator_read_size_fail_threshold, counter_cache_size, > prepared_statements_cache_size, batchlog_replay_throttle, > row_index_read_size_fail_threshold, index_summary_capacity, > repair_session_space, paxos_cache_size, collection_size_fail_threshold, > internode_application_send_queue_reserve_global_capacity, column_index_size, > native_transport_receive_queue_capacity, sstable_preemptive_open_interval, > max_mutation_size, min_free_space_per_drive, batch_size_fail_threshold, > hinted_handoff_throttle, row_index_read_size_warn_threshold, max_value_size, > column_index_cache_size, compaction_large_partition_warning_threshold, > max_hints_file_size, collection_size_warn_threshold, > native_transport_max_request_data_in_flight, > internode_socket_receive_buffer_size, > internode_application_receive_queue_capacity, > internode_socket_send_buffer_size, row_cache_size, > min_tracked_partition_size, local_read_size_warn_threshold, > commitlog_segment_size, batch_size_warn_threshold, streaming_state_size, > native_transport_max_request_data_in_flight_per_ip > NOTE: Some of those were checked/fixed in other tickets but I post the full > lists for completeness -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
