[jira] [Commented] (CASSANDRA-15266) java internal exception on attempt to UPDATE a row using CONTAINS operator
[
https://issues.apache.org/jira/browse/CASSANDRA-15266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499926#comment-17499926
]
Maciej Sokol commented on CASSANDRA-15266:
--
Sure, here you go:
[3.11|https://github.com/apache/cassandra/pull/1472]
[4.0|https://github.com/apache/cassandra/pull/1473]
[trunk|https://github.com/apache/cassandra/pull/1474]
> java internal exception on attempt to UPDATE a row using CONTAINS operator
> --
>
> Key: CASSANDRA-15266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15266
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Konstantin
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> kostja@atlas ~ % cqlsh -ucassandra -pcassandra
> Connected to My Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE KEYSPACE t1 WITH replication =
> \{'class':'SimpleStrategy', 'replication_factor' : 1};
> cassandra@cqlsh> use t1;
> cassandra@cqlsh:t1> create table t (a int, b frozen>, c int,
> primary key (a, b));
> cassandra@cqlsh:t1> insert into t (a, b, c) values (1, \{1:1, 2:2}, 3);
> cassandra@cqlsh:t1> update t set c=3 where a=1 and b contains 1;
> ServerError: java.lang.UnsupportedOperationException
>
> Server log file:
> ```
> ERROR [Native-Transport-Requests-1] 2019-08-07 17:02:59,283
> QueryMessage.java:129 - Unexpected error during query
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$ContainsRestriction.appendTo(SingleColumnRestriction.java:454)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:109)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770)
> ~[apache-cassan
> dra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.createClustering(ModificationStatement.java:312)
> ~[apache-cassandra-3.
> 11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:677)
> ~[apache-cassandra-3.11.4.j
> ar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:635)
> ~[apache-cassandra-3.11.4
> .jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:437)
> ~[apache-cassa
> ndra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:425)
> ~[apache-cassandra-3.11.4.jar:
> 3.11.4]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44
> ...
> ```
> +Additional information for newcomers:+
> {{CONTAINS}} and {{CONTAINS KEY}} restrictions are not supported for
> {{UPDATE}} or {{DELETE}} operations but they should be properly rejected with
> a proper error message.
> To fix that problem a new check should be added in the
> {{StatementRestrictions}} constructor to thrown an
> {{InvalidRequestException}} if the relation operator is a {{CONTAINS}} or
> {{CONTAINS_KEY}} and the {{StatementType}} an {{UPDATE}} or a {{DELETION}}.
> Some unit tests should be added to {{UpdateTest}} an {{DeleteTest}} to test
> the behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499912#comment-17499912
]
Berenguer Blasi commented on CASSANDRA-16378:
-
Test failures are the early termination known erros. The other only one looks
unrelated to me. +1.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Fix For: 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}} and passed to the
> {{{}ClientState{}}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{{}ConnectedClient{}}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16378:
Fix Version/s: 4.x
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Fix For: 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}} and passed to the
> {{{}ClientState{}}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{{}ConnectedClient{}}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17344: Status: Ready to Commit (was: Review In Progress) > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17344: Reviewers: Berenguer Blasi, Ekaterina Dimitrova (was: Ekaterina Dimitrova) > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499907#comment-17499907 ] Berenguer Blasi commented on CASSANDRA-17344: - LGTM +1 > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17344: Status: Review In Progress (was: Needs Committer) > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17367) sstableloader ignores streaming encryption settings
[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499900#comment-17499900
]
Berenguer Blasi commented on CASSANDRA-17367:
-
SGTM +1
> sstableloader ignores streaming encryption settings
> ---
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Dmitry Potepalov
>Assignee: Dmitry Potepalov
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17367-4.0.txt, 17367-trunk.txt
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17397) cleanup cqlshlib unit test failures and warnings
[ https://issues.apache.org/jira/browse/CASSANDRA-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499871#comment-17499871 ] Brad Schoening commented on CASSANDRA-17397: [~brandon.williams] could you review status here, I can't seem to progress it to patch available > cleanup cqlshlib unit test failures and warnings > > > Key: CASSANDRA-17397 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17397 > Project: Cassandra > Issue Type: Bug >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > > The cqlshlib unit tests have some regular failures and warnings. > # test_copyutil.py fails with too many open files when ulimit is 256 > # cassconnect.py:39: DeprecationWarning: Legacy execution parameters > # sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been > renamed to ConfigParser > # remove unused reference to nosetests.xml in Jenkinsfile > > The cqlshlib test test_copyutil.py fails on MacOS with > *E OSError: [Errno 24] Too many open files* > This happens because the test does not close the file descriptors after use. > The default ulimit on MacOS is small, 256: > % ulimit -n > 256 > The simple fix is to close the pipe after use. Increasing ulimit nofiles > works also, but shouldn't be necessary. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17397) cleanup cqlshlib unit test failures and warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17397:
---
Description:
The cqlshlib unit tests have some regular failures and warnings.
# test_copyutil.py fails with too many open files when ulimit is 256
# cassconnect.py:39: DeprecationWarning: Legacy execution parameters
# sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
renamed to ConfigParser
# remove unused reference to nosetests.xml in Jenkinsfile
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
was:
The cqlshlib unit tests have some regular failures and warnings.
# test_copyutil.py fails with too many open files when ulimit is 256
# cassconnect.py:39: DeprecationWarning: Legacy execution parameters
# sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
renamed to ConfigParser
# remove unused reference to nosetests.xml in Jenkinsfile
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
{*}test/test_copyutil.py{*}:80: in _test_get_ranges_murmur3_base
export_task = ExportTask(shell, self.ks, self.table, self.columns,
self.fname, overridden_opts, self.protocol_version, self.config_file)
{*}copyutil.py{*}:638: in {_}{{_}}init{{_}}{_}
CopyTask.{_}{{_}}init{{_}}{_}(self, shell, ks, table, columns, fname, opts,
protocol_version, config_file, 'to')
{*}copyutil.py{*}:275: in {_}{{_}}init{{_}}{_}
self.inmsg = ReceivingChannels(self.num_processes)
{*}copyutil.py{*}:186: in {_}{{_}}init{{_}}{_}
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:186: in
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:103: in {_}{{_}}init{{_}}{_}
self.reader, self.writer = mp.Pipe(duplex=False)
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py{*}:63:
in Pipe
return Pipe(duplex)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
duplex = False
def Pipe(duplex=True):
'''
Returns pair of connection objects at either end of a pipe
'''
if duplex:
s1, s2 = socket.socketpair()
s1.setblocking(True)
s2.setblocking(True)
c1 = Connection(s1.detach())
c2 = Connection(s2.detach())
else:
> fd1, fd2 = os.pipe()
*E OSError: [Errno 24] Too many open files*
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py{*}:532:
OSError
> cleanup cqlshlib unit test failures and warnings
>
>
> Key: CASSANDRA-17397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17397
> Project: Cassandra
> Issue Type: Bug
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
>
> The cqlshlib unit tests have some regular failures and warnings.
> # test_copyutil.py fails with too many open files when ulimit is 256
> # cassconnect.py:39: DeprecationWarning: Legacy execution parameters
> # sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
> renamed to ConfigParser
> # remove unused reference to nosetests.xml in Jenkinsfile
>
> The cqlshlib test test_copyutil.py fails on MacOS with
> *E OSError: [Errno 24] Too many open files*
> This happens because the test does not close the file descriptors after use.
> The default ulimit on MacOS is small, 256:
> % ulimit -n
> 256
> The simple fix is to close the pipe after use. Increasing ulimit nofiles
> works also, but shouldn't be necessary.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17397) cleanup cqlshlib unit test failures and warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17397:
---
Description:
The cqlshlib unit tests have some regular failures and warnings.
# test_copyutil.py fails with too many open files when ulimit is 256
# cassconnect.py:39: DeprecationWarning: Legacy execution parameters
# sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
renamed to ConfigParser
# remove unused reference to nosetests.xml in Jenkinsfile
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
{*}test/test_copyutil.py{*}:80: in _test_get_ranges_murmur3_base
export_task = ExportTask(shell, self.ks, self.table, self.columns,
self.fname, overridden_opts, self.protocol_version, self.config_file)
{*}copyutil.py{*}:638: in {_}{{_}}init{{_}}{_}
CopyTask.{_}{{_}}init{{_}}{_}(self, shell, ks, table, columns, fname, opts,
protocol_version, config_file, 'to')
{*}copyutil.py{*}:275: in {_}{{_}}init{{_}}{_}
self.inmsg = ReceivingChannels(self.num_processes)
{*}copyutil.py{*}:186: in {_}{{_}}init{{_}}{_}
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:186: in
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:103: in {_}{{_}}init{{_}}{_}
self.reader, self.writer = mp.Pipe(duplex=False)
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py{*}:63:
in Pipe
return Pipe(duplex)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
duplex = False
def Pipe(duplex=True):
'''
Returns pair of connection objects at either end of a pipe
'''
if duplex:
s1, s2 = socket.socketpair()
s1.setblocking(True)
s2.setblocking(True)
c1 = Connection(s1.detach())
c2 = Connection(s2.detach())
else:
> fd1, fd2 = os.pipe()
*E OSError: [Errno 24] Too many open files*
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py{*}:532:
OSError
was:
The cqlshlib unit tests have some regular failures and warnings.
# test_copyutil.py fails with too many open files when ulimit is 256
# cassconnect.py:39: DeprecationWarning: Legacy execution parameters
# sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
renamed to ConfigParser
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
{*}test/test_copyutil.py{*}:80: in _test_get_ranges_murmur3_base
export_task = ExportTask(shell, self.ks, self.table, self.columns,
self.fname, overridden_opts, self.protocol_version, self.config_file)
{*}copyutil.py{*}:638: in {_}{{_}}init{{_}}{_}
CopyTask.{_}{{_}}init{{_}}{_}(self, shell, ks, table, columns, fname, opts,
protocol_version, config_file, 'to')
{*}copyutil.py{*}:275: in {_}{{_}}init{{_}}{_}
self.inmsg = ReceivingChannels(self.num_processes)
{*}copyutil.py{*}:186: in {_}{{_}}init{{_}}{_}
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:186: in
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:103: in {_}{{_}}init{{_}}{_}
self.reader, self.writer = mp.Pipe(duplex=False)
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py{*}:63:
in Pipe
return Pipe(duplex)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
duplex = False
def Pipe(duplex=True):
'''
Returns pair of connection objects at either end of a pipe
'''
if duplex:
s1, s2 = socket.socketpair()
s1.setblocking(True)
s2.setblocking(True)
c1 = Connection(s1.detach())
c2 = Connection(s2.detach())
else:
> fd1, fd2 = os.pipe()
*E
[jira] [Updated] (CASSANDRA-17397) cleanup cqlshlib unit test failures and warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17397:
---
Description:
The cqlshlib unit tests have some regular failures and warnings.
# test_copyutil.py fails with too many open files when ulimit is 256
# cassconnect.py:39: DeprecationWarning: Legacy execution parameters
# sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
renamed to ConfigParser
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
{*}test/test_copyutil.py{*}:80: in _test_get_ranges_murmur3_base
export_task = ExportTask(shell, self.ks, self.table, self.columns,
self.fname, overridden_opts, self.protocol_version, self.config_file)
{*}copyutil.py{*}:638: in {_}{{_}}init{{_}}{_}
CopyTask.{_}{{_}}init{{_}}{_}(self, shell, ks, table, columns, fname, opts,
protocol_version, config_file, 'to')
{*}copyutil.py{*}:275: in {_}{{_}}init{{_}}{_}
self.inmsg = ReceivingChannels(self.num_processes)
{*}copyutil.py{*}:186: in {_}{{_}}init{{_}}{_}
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:186: in
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:103: in {_}{{_}}init{{_}}{_}
self.reader, self.writer = mp.Pipe(duplex=False)
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py{*}:63:
in Pipe
return Pipe(duplex)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
duplex = False
def Pipe(duplex=True):
'''
Returns pair of connection objects at either end of a pipe
'''
if duplex:
s1, s2 = socket.socketpair()
s1.setblocking(True)
s2.setblocking(True)
c1 = Connection(s1.detach())
c2 = Connection(s2.detach())
else:
> fd1, fd2 = os.pipe()
*E OSError: [Errno 24] Too many open files*
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py{*}:532:
OSError
was:
The cqlshlib unit tests have some regular failures and warnings.
# test_copyutil.py fails with too many open files when ulimit is 256
# nose/importer.py:12: DeprecationWarning: the imp module is deprecated in
favour of importlib
# cassconnect.py:39: DeprecationWarning: Legacy execution parameters
# sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
renamed to ConfigParser
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
{*}test/test_copyutil.py{*}:80: in _test_get_ranges_murmur3_base
export_task = ExportTask(shell, self.ks, self.table, self.columns,
self.fname, overridden_opts, self.protocol_version, self.config_file)
{*}copyutil.py{*}:638: in {_}{{_}}init{{_}}{_}
CopyTask.{_}{{_}}init{{_}}{_}(self, shell, ks, table, columns, fname, opts,
protocol_version, config_file, 'to')
{*}copyutil.py{*}:275: in {_}{{_}}init{{_}}{_}
self.inmsg = ReceivingChannels(self.num_processes)
{*}copyutil.py{*}:186: in {_}{{_}}init{{_}}{_}
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:186: in
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:103: in {_}{{_}}init{{_}}{_}
self.reader, self.writer = mp.Pipe(duplex=False)
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py{*}:63:
in Pipe
return Pipe(duplex)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
duplex = False
def Pipe(duplex=True):
'''
Returns pair of connection objects at either end of a pipe
'''
if duplex:
s1, s2 = socket.socketpair()
s1.setblocking(True)
s2.setblocking(True)
c1 = Connection(s1.detach())
c2 = Connection(s2.detach())
else:
>
[jira] [Updated] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17344: Status: Needs Committer (was: Review In Progress) > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
[
https://issues.apache.org/jira/browse/CASSANDRA-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17187:
Reviewers: Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: lhf
> Fix For: 4.x
>
>
> Add a guardrail to limit the number restrictions generated by the cartesian
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)"
> results in
> # cartesian product of 100.
> # The two thresholds default to -1 to disable.
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C*
> instance to its knees even before the query starts executing:
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> {code}
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on cartesian product in the
> guardrails section of cassandra.yaml.
> # Add a {{getInCartesianProduct}} method in {{GuardrailsConfig}} returning a
> {{Threshold.Config}} object
> # Implement that method in {{GuardrailsOptions}}, which is the default
> yaml-based implementation of {{GuardrailsConfig}}
> # Add a Threshold guardrail named {{inCartesianProduct}} in Guardrails, using
> the previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in {{GuardrailsMBean}}
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails#inCartesianProduct guard method. The
> {{MultiCBuilder}} look like good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend {{ThresholdTester}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499812#comment-17499812 ] Ekaterina Dimitrova edited comment on CASSANDRA-17344 at 3/1/22, 11:47 PM: --- Sorry, I missed this ticket earlier when I asked for docs, my bad. I left only one comment with suggestion in GH, thanks! was (Author: e.dimitrova): Sorry, I missed this ticket earlier when I asked for docs, my bad. I left only one comment with suggestion, thanks! > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499812#comment-17499812 ] Ekaterina Dimitrova commented on CASSANDRA-17344: - Sorry, I missed this ticket earlier when I asked for docs, my bad. I left only one comment with suggestion, thanks! > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17344: Reviewers: Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15399:
--
Status: Open (was: Patch Available)
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
> progress_percentage float,
> queue_duration_ms bigint,
> runtime_duration_ms bigint,
> total_duration_ms bigint,
> estimated_partitions bigint,
> partitions_processed bigint,
> estimated_total_bytes bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name )
> )
> {code}
> The main reason for exposing virtual tables rather than exposing through
> durable tables is to make sure what is exposed is accurate. In cases of
> write failures or node failures, the durable tables could become in-accurate
> and could add edge cases where the repair is not running but the tables say
> it is; by relying on repair's internal in-memory bookkeeping, these problems
> go away.
> This jira does not try to solve the following:
> 1) repair resiliency - there are edge cases where repair hits an error and
> runs forever (at least from nodetool's perspective).
> 2) repair stream tracking - I have not learned the streaming side yet and
> what I see is multiple implementations exist, so seems like high scope. My
> hope is to punt from this jira and tackle separately.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15399:
--
Status: Patch Available (was: Review In Progress)
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
> progress_percentage float,
> queue_duration_ms bigint,
> runtime_duration_ms bigint,
> total_duration_ms bigint,
> estimated_partitions bigint,
> partitions_processed bigint,
> estimated_total_bytes bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name )
> )
> {code}
> The main reason for exposing virtual tables rather than exposing through
> durable tables is to make sure what is exposed is accurate. In cases of
> write failures or node failures, the durable tables could become in-accurate
> and could add edge cases where the repair is not running but the tables say
> it is; by relying on repair's internal in-memory bookkeeping, these problems
> go away.
> This jira does not try to solve the following:
> 1) repair resiliency - there are edge cases where repair hits an error and
> runs forever (at least from nodetool's perspective).
> 2) repair stream tracking - I have not learned the streaming side yet and
> what I see is multiple implementations exist, so seems like high scope. My
> hope is to punt from this jira and tackle separately.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499809#comment-17499809
]
Ekaterina Dimitrova commented on CASSANDRA-17221:
-
Hey [~xvade] , I did a quick skim today and left some high level comments on
the commit (around docs, JavaDoc, formatting and testing). Looks like this is
in big part done.
I want to look further at the the new _BigDecimalUtil_ you added and some other
details.
[~blerer] can you also make a review when you have some time, please?
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499797#comment-17499797
]
Tibor Repasi commented on CASSANDRA-16378:
--
Thank you [~e.dimitrova], I've cherry picked your commit
[be699f|https://github.com/apache/cassandra/commit/ab9fcbaf998fb584ae84d584c298af63fcbe699f]
just partly, to not duplicate the entry in CHANGES.txt. Squashed and rebased
onto trunk.
Doc update ticket is open at CASSANDRA-17344.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}} and passed to the
> {{{}ClientState{}}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{{}ConnectedClient{}}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17221:
Test and Documentation Plan: The patch adds new tests (was: The patch add
new tests)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499796#comment-17499796
]
David Capwell commented on CASSANDRA-15399:
---
streaming vtable is now merged. I will be gone until the 21st, but will pick
this up after.
My plan is to extend this in the following way
1) change streaming/repair so each know the others IDs (streaming knows the
repair, and repair can control the id)
2) update streaming table to expose this
3) update the repair state to match the streaming state (cache)
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
> progress_percentage float,
> queue_duration_ms bigint,
> runtime_duration_ms bigint,
> total_duration_ms bigint,
> estimated_partitions bigint,
> partitions_processed bigint,
> estimated_total_bytes bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name )
> )
> {code}
> The main reason for exposing virtual tables rather than exposing through
> durable tables is to make sure what is exposed is accurate. In cases of
> write failures or node failures, the durable tables could become in-accurate
> and could add edge cases where the repair is not running but the tables say
> it is; by relying on repair's internal in-memory bookkeeping, these problems
> go away.
> This jira does not try to solve the following:
> 1) repair resiliency - there are edge cases where repair hits an error and
> runs forever (at least from nodetool's perspective).
> 2) repair stream tracking - I have not learned the streaming side yet and
> what I see is multiple implementations exist, so seems like high scope. My
> hope is to punt from this jira and tackle separately.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17390) Expose streaming as a vtable
[ https://issues.apache.org/jira/browse/CASSANDRA-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17390: -- Fix Version/s: 4.1 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/76d8919062036896835fb7917bb5dd831d4cd43c Resolution: Fixed Status: Resolved (was: Ready to Commit) > Expose streaming as a vtable > > > Key: CASSANDRA-17390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17390 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Streaming, Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1 > > Time Spent: 2.5h > Remaining Estimate: 0h > > CASSANDRA-15399 is exposing repair state as a vtable, but repair relies on > streaming so needs streaming table as well. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Expose streaming as a vtable
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 e87a1e0 Expose streaming as a vtable
e87a1e0 is described below
commit e87a1e0c0a19c64ed2edc2d340c0f8af16776e2c
Author: David Capwell
AuthorDate: Tue Mar 1 13:15:18 2022 -0800
Expose streaming as a vtable
patch by David Capwell; reviewed by Dinesh Joshi, Paulo Motta for
CASSANDRA-17390
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/config/Config.java | 2 +
.../cassandra/config/DatabaseDescriptor.java | 28 ++
.../org/apache/cassandra/config/DurationSpec.java | 24 ++
.../cassandra/db/virtual/AbstractVirtualTable.java | 6 +
.../apache/cassandra/db/virtual/SimpleDataSet.java | 6 +-
.../db/virtual/StreamingVirtualTable.java | 109 ++
.../cassandra/db/virtual/SystemViewsKeyspace.java | 1 +
.../apache/cassandra/service/CassandraDaemon.java | 2 +
.../apache/cassandra/streaming/SessionInfo.java| 11 +-
.../apache/cassandra/streaming/StreamManager.java | 145 ++-
.../cassandra/streaming/StreamResultFuture.java| 13 +-
.../apache/cassandra/streaming/StreamingState.java | 432 +
.../management/StreamEventJMXNotifier.java | 2 +-
.../tools/nodetool/formatter/TableBuilder.java | 20 +
.../cassandra/distributed/impl/Instance.java | 3 +
.../test/streaming/RebuildStreamingTest.java | 96 +
.../distributed/util/QueryResultUtil.java | 70 +++-
test/unit/org/apache/cassandra/cql3/CQLTester.java | 17 +-
.../unit/org/apache/cassandra/db/MmapFileTest.java | 10 +
.../cassandra/db/filter/ColumnFilterTest.java | 2 +
.../db/virtual/StreamingVirtualTableTest.java | 219 +++
.../org/apache/cassandra/io/util/FileTest.java | 4 +
.../AbstractFilesystemOwnershipCheckTest.java | 9 +
.../apache/cassandra/utils/binlog/BinLogTest.java | 9 +
25 files changed, 1214 insertions(+), 27 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 5580102..97ce6c8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Expose streaming as a vtable (CASSANDRA-17390)
* Make startup checks configurable (CASSANDRA-17220)
* Add guardrail for number of partition keys on IN queries (CASSANDRA-17186)
* update Python test framework from nose to pytest (CASSANDRA-17293)
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index 15226cf..964a5e1 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -768,6 +768,8 @@ public class Config
public volatile Set table_properties_disallowed =
Collections.emptySet();
public volatile boolean user_timestamps_enabled = true;
public volatile boolean read_before_write_list_operations_enabled = true;
+public volatile DurationSpec streaming_state_expires =
DurationSpec.inDays(3);
+public volatile DataStorageSpec streaming_state_size =
DataStorageSpec.inMebibytes(40);
/** The configuration of startup checks. */
public volatile Map> startup_checks
= new HashMap<>();
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 9f88ce0..65cb3d6 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -3885,4 +3885,32 @@ public class DatabaseDescriptor
conf.force_new_prepared_statement_behaviour = value;
}
}
+
+public static DurationSpec getStreamingStateExpires()
+{
+return conf.streaming_state_expires;
+}
+
+public static void setStreamingStateExpires(DurationSpec duration)
+{
+if
(!conf.streaming_state_expires.equals(Objects.requireNonNull(duration,
"duration")))
+{
+logger.info("Setting streaming_state_expires to {}", duration);
+conf.streaming_state_expires = duration;
+}
+}
+
+public static DataStorageSpec getStreamingStateSize()
+{
+return conf.streaming_state_size;
+}
+
+public static void setStreamingStateSize(DataStorageSpec duration)
+{
+if (!conf.streaming_state_size.equals(Objects.requireNonNull(duration,
"duration")))
+{
+logger.info("Setting streaming_state_size to {}", duration);
+conf.streaming_state_size = duration;
+}
+}
}
diff --git a/src/java/org/apache/cassandra/config/DurationSpec.java
b/src/java/org/apache/cassandra/config/DurationSpec.java
index f06c247..e5edb35 100644
--- a/src/java/org/apache/cassandra/config/DurationSpec.java
+++ b/src/java/org/apache/cassandra/config/DurationSpec.java
@@
[jira] [Commented] (CASSANDRA-17390) Expose streaming as a vtable
[ https://issues.apache.org/jira/browse/CASSANDRA-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499773#comment-17499773 ] David Capwell commented on CASSANDRA-17390: --- Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17390-trunk-C1379AB9-B4E3-47B9-ACF1-F7124B2B2B3E]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17390-trunk-C1379AB9-B4E3-47B9-ACF1-F7124B2B2B3E]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1465/]| > Expose streaming as a vtable > > > Key: CASSANDRA-17390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17390 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Streaming, Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > CASSANDRA-15399 is exposing repair state as a vtable, but repair relies on > streaming so needs streaming table as well. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17221:
Status: Needs Committer (was: Review In Progress)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17221:
Reviewers: Ekaterina Dimitrova
Status: Review In Progress (was: Needs Committer)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17221:
Status: Needs Committer (was: Patch Available)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499724#comment-17499724
]
Ekaterina Dimitrova commented on CASSANDRA-16378:
-
I added a few comments and addressed them on this
[branch|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-16378]
which is rebased on the latest trunk. Also added NEWS.txt and CHANGES.txt
entry. Do we want to open a separate ticket to update the docs?
Running Circle CI -
[j8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1405/workflows/175baa89-6168-49e0-9e35-31e81ce122b2],
[j11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1405/workflows/9e25aff4-f39e-46ee-931d-d30cb6396c7a]
I can squash and commit tomorrow if no one has objection to the current state
and CI us happy with us.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}} and passed to the
> {{{}ClientState{}}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{{}ConnectedClient{}}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17412) CEP-15: (Accord) Initial Cassandra Integration
[ https://issues.apache.org/jira/browse/CASSANDRA-17412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-17412: Reviewers: Benedict Elliott Smith > CEP-15: (Accord) Initial Cassandra Integration > -- > > Key: CASSANDRA-17412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17412 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Integrate the accord messages into Cassandra and implement a basic Cassandra > to accord topology mapping. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17412) CEP-15: (Accord) Initial Cassandra Integration
[
https://issues.apache.org/jira/browse/CASSANDRA-17412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499719#comment-17499719
]
Blake Eggleston commented on CASSANDRA-17412:
-
I also wanted to point out that this isn’t meant to be merged into C* trunk.
Without having settled on a workflow of publishing accord changes and getting
them into C*, the C* changes should probably be merged into a feature branch
that is periodically rebased against trunk. In the meantime, it’s meant to be
built locally, after you’ve installed the accord library with {{{}./gradlew
install{}}}.
> CEP-15: (Accord) Initial Cassandra Integration
> --
>
> Key: CASSANDRA-17412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17412
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
>
> Integrate the accord messages into Cassandra and implement a basic Cassandra
> to accord topology mapping.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17412) CEP-15: (Accord) Initial Cassandra Integration
[ https://issues.apache.org/jira/browse/CASSANDRA-17412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-17412: Test and Documentation Plan: Accord test suite Status: Patch Available (was: Open) [accord|https://github.com/apache/cassandra-accord/pull/2] [cassandra|https://github.com/bdeggleston/cassandra/tree/accord-integration] The topology mapping is meant to be manually triggered in a dtest, and won’t react to actual topology changes yet. This patch also introduces a very basic accord query builder for testing the integration. > CEP-15: (Accord) Initial Cassandra Integration > -- > > Key: CASSANDRA-17412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17412 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Integrate the accord messages into Cassandra and implement a basic Cassandra > to accord topology mapping. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17412) CEP-15: (Accord) Initial Cassandra Integration
[ https://issues.apache.org/jira/browse/CASSANDRA-17412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-17412: Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > CEP-15: (Accord) Initial Cassandra Integration > -- > > Key: CASSANDRA-17412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17412 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > Integrate the accord messages into Cassandra and implement a basic Cassandra > to accord topology mapping. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17412) CEP-15: (Accord) Initial Cassandra Integration
Blake Eggleston created CASSANDRA-17412: --- Summary: CEP-15: (Accord) Initial Cassandra Integration Key: CASSANDRA-17412 URL: https://issues.apache.org/jira/browse/CASSANDRA-17412 Project: Cassandra Issue Type: New Feature Components: Accord Reporter: Blake Eggleston Assignee: Blake Eggleston Integrate the accord messages into Cassandra and implement a basic Cassandra to accord topology mapping. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14797) CQLSSTableWriter does not support DELETE
[
https://issues.apache.org/jira/browse/CASSANDRA-14797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-14797:
Status: Needs Committer (was: Review In Progress)
Looks good to me. I haven't been able to get a clean CI run yet, but that looks
to be down to unrelated issues. I'll keep on at that, but in the meantime this
could use a second reviewer.
> CQLSSTableWriter does not support DELETE
>
>
> Key: CASSANDRA-14797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14797
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Eric Evans
>Assignee: Doug Rohrer
>Priority: Low
> Fix For: 3.11.x, 4.x
>
> Attachments: cassandra-14797.patch
>
>
> {{CQLSSTableWriter}} doesn't work with {{DELETE}} statements, and ought to.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17094) CEP-15: (Accord) Reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-17094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-17094: Reviewers: Benedict Elliott Smith > CEP-15: (Accord) Reconfiguration > > > Key: CASSANDRA-17094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17094 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Blake Eggleston >Priority: Normal > > Accord presently requires a static topology, and pre-defined fast path > electorates. This ticket covers work to support dynamic topologies and > fast-path electorates, though does not aim to support the full state machine > requirements of Cassandra. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17094) CEP-15: (Accord) Reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-17094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-17094: Test and Documentation Plan: Accord test suite Status: Patch Available (was: Open) PR: https://github.com/apache/cassandra-accord/pull/1 > CEP-15: (Accord) Reconfiguration > > > Key: CASSANDRA-17094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17094 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Blake Eggleston >Priority: Normal > > Accord presently requires a static topology, and pre-defined fast path > electorates. This ticket covers work to support dynamic topologies and > fast-path electorates, though does not aim to support the full state machine > requirements of Cassandra. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17094) CEP-15: (Accord) Reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-17094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-17094: Change Category: Operability Complexity: Challenging Status: Open (was: Triage Needed) > CEP-15: (Accord) Reconfiguration > > > Key: CASSANDRA-17094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17094 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Blake Eggleston >Priority: Normal > > Accord presently requires a static topology, and pre-defined fast path > electorates. This ticket covers work to support dynamic topologies and > fast-path electorates, though does not aim to support the full state machine > requirements of Cassandra. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499664#comment-17499664
]
Stefan Miklosovic edited comment on CASSANDRA-16518 at 3/1/22, 5:25 PM:
I've already tested this as well my colleagues and they are saying it just
works as expected. Given how complex the test is going to be, I am admitting I
am quite hesitant to spend too much time on this. Additioanlly, I am not
completely sure what test I should write, in-jvm dtest or python one? There is
a lot of moving parts here and I am afraid I am going to introduce another
flaky eventually.
Or maybe I could narrow down the scope of the test to test just stuff around
ConfigLimit? What is your opinion on the scope the test should cover here?
was (Author: smiklosovic):
I've already tested this as well my colleagues and they are saying it just
works as expected. Given how complex the test is going to be, I am admitting I
am quite hesitant to spend too much time on this. Additioanlly, I am not
completely sure what test I should write, in-jvm dtest or python one? There is
a lot of moving parts here and I am afraid I am going to introduce another
flaky eventually.
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499664#comment-17499664
]
Stefan Miklosovic commented on CASSANDRA-16518:
---
I've already tested this as well my colleagues and they are saying it just
works as expected. Given how complex the test is going to be, I am admitting I
am quite hesitant to spend too much time on this. Additioanlly, I am not
completely sure what test I should write, in-jvm dtest or python one? There is
a lot of moving parts here and I am afraid I am going to introduce another
flaky eventually.
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17390) Expose streaming as a vtable
[ https://issues.apache.org/jira/browse/CASSANDRA-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17390: -- Status: Ready to Commit (was: Review In Progress) > Expose streaming as a vtable > > > Key: CASSANDRA-17390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17390 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Streaming, Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > CASSANDRA-15399 is exposing repair state as a vtable, but repair relies on > streaming so needs streaming table as well. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17390) Expose streaming as a vtable
[ https://issues.apache.org/jira/browse/CASSANDRA-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17390: -- Status: Review In Progress (was: Patch Available) > Expose streaming as a vtable > > > Key: CASSANDRA-17390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17390 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Streaming, Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > CASSANDRA-15399 is exposing repair state as a vtable, but repair relies on > streaming so needs streaming table as well. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499658#comment-17499658
]
Benjamin Lerer commented on CASSANDRA-10537:
[~e.dimitrova] I wanted to have a deeper look at the patch but forgot about it.
I should have time tomorrow. :-)
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17390) Expose streaming as a vtable
[ https://issues.apache.org/jira/browse/CASSANDRA-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499649#comment-17499649 ] David Capwell commented on CASSANDRA-17390: --- [~paulo] gave a +1 in PR and Slack assuming switching from periodic cleanup to cache; pushed that change and running through CI now > Expose streaming as a vtable > > > Key: CASSANDRA-17390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17390 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Streaming, Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > CASSANDRA-15399 is exposing repair state as a vtable, but repair relies on > streaming so needs streaming table as well. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17390) Expose streaming as a vtable
[ https://issues.apache.org/jira/browse/CASSANDRA-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17390: -- Reviewers: Dinesh Joshi, Paulo Motta (was: Dinesh Joshi) > Expose streaming as a vtable > > > Key: CASSANDRA-17390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17390 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Streaming, Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > CASSANDRA-15399 is exposing repair state as a vtable, but repair relies on > streaming so needs streaming table as well. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499639#comment-17499639
]
Brandon Williams commented on CASSANDRA-16518:
--
I think the real issue here is that we've allowed a null release_version that
never gets resolved, and this patch works around that by ignoring unset
versions. That said, we've released versions that do this, so working around
it seems like the only solution. Can we add a test for this?
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17411) Network partition causes write ONE timeouts when using counters in Cassandra 4
[
https://issues.apache.org/jira/browse/CASSANDRA-17411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17411:
-
Bug Category: Parent values: Availability(12983)
Complexity: Normal
Component/s: Consistency/Coordination
Discovered By: User Report
Fix Version/s: 4.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> Network partition causes write ONE timeouts when using counters in Cassandra 4
> --
>
> Key: CASSANDRA-17411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17411
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Pere Balaguer
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: app.py
>
>
> h5. Affected versions:
> * 4.x
> h5. Observed behavior:
> When executing CL=ONE writes on a table with a counter column, if one of the
> nodes is network partitioned from the others, clients keep sending requests
> to it.
> Even though this may be a "driver" problem, I've been able to reproduce it
> with both java and python datastax drivers using their latest available
> versions and given the behavior only changes depending on the Cassandra
> version, well, here I am.
> h5. Expected behavior:
> In Cassandra 3 after all inflight requests fail (expected), no new requests
> are sent to the partitioned node. The expectation is that Cassandra 4 behaves
> the same way.
> h5. How to reproduce:
> {noformat}
> # Create a cluster with the desired version, will go with 4.x for this example
> ccm create bug-report -v 4.0.3
> ccm populate -n 2:2:2
> ccm start
> # Create schemas and so on
> CQL=$(cat < CONSISTENCY ALL;
> DROP KEYSPACE IF EXISTS demo;
> CREATE KEYSPACE demo WITH REPLICATION = {'class': 'NetworkTopologyStrategy',
> 'dc1': 2, 'dc2': 2, 'dc3': 2};
> CREATE TABLE demo.demo (pk uuid PRIMARY KEY, count counter) WITH compaction =
> {'class': 'LeveledCompactionStrategy'};
> END
> )
> ccm node1 cqlsh --verbose --exec="${CQL}"
> # Launch the attached app.py
> # requires cassandra-driver
> python3 app.py "127.0.0.1" "9042"
> # Wait a bit for the app to settle, proceed to next step once you see 3
> messages in stdout like:
> # 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572
> (0.00) timeouts/total_rqs in the last 1 minute
> # Partition one node with iptables
> iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port 7000 -j
> DROP; iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port
> 9042 -j DROP
> {noformat}
> Some time after executing the iptables command in cassandra-3 the output
> should be similar to:
> {noformat}
> 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:51,576 - target-dc3 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:58,032 - target-dc1 - __main__ - INFO - Got 6/252 (2.380952)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,560 - target-dc2 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,620 - target-dc3 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:58,101 - target-dc1 - __main__ - INFO - Got 2/354 (0.564972)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,602 - target-dc2 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,672 - target-dc3 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:58,153 - target-dc1 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> {noformat}
> as the timeouts/rqs shows, in about 2 minutes the partitioned node stops
> receiving traffic
> while as in cassandra-4
> {noformat}
> 2022-03-01 15:49:39,068 - target-dc3 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:39,107 - target-dc2 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:41,206 - target-dc1 - __main__ - INFO - Got 2/444 (0.450450)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,095 - target-dc3 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,148 - target-dc2 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:42,589 - target-dc1 - __main__ - INFO - Got 7/13 (53.846154)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:51:39,125 - target-dc3 - __main__ - INFO - Got 0/567 (0.00)
> timeouts/total_rqs
[jira] [Commented] (CASSANDRA-17335) Flaky testNoSuchRepairSessionAnticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499630#comment-17499630
]
Bernardo Botella Corbi commented on CASSANDRA-17335:
Thanks [~bereng] ! I just addressed them. Please let me know any thoughts you
may have.
> Flaky testNoSuchRepairSessionAnticompaction
> ---
>
> Key: CASSANDRA-17335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17335
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments:
> 0001-Fix-Flaky-testNoSuchRepairSessionAnticompaction-trunk.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The in-JVM dtest {{RepairErrorsTest#testNoSuchRepairSessionAnticompaction}}
> seems to be flaky, as it's shown by [this repeated
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1280/workflows/8a4e04cb-64cc-46a3-9e1e-c946dfafc7fa/jobs/12114]
> on trunk, which hits 18 failures in 500 iterations. The config for CircleCI
> was generated with:
> {code}
> .circleci/generate.sh -m \
> -e REPEATED_UTEST_TARGET=test-jvm-dtest-some \
> -e REPEATED_UTEST_COUNT=500 \
> -e
> REPEATED_UTEST_CLASS=org.apache.cassandra.distributed.test.RepairErrorsTest
> {code}
> This was discovered while testing CASSANDRA-16878, on [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1268/workflows/aef1c703-c816-40f8-8e07-9055027d6403/jobs/12000].
> The error consists on a failed assertion when grepping the logs in search of
> an error message.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16518:
--
Authors: Stefan Miklosovic (was: Stefan Miklosovic)
Test and Documentation Plan: manual test
Status: Patch Available (was: In Progress)
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499615#comment-17499615
]
Stefan Miklosovic commented on CASSANDRA-16518:
---
PR: [https://github.com/apache/cassandra/pull/1465]
build:
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/769/workflows/c3892242-fe82-449f-85e5-0e6bcdaae5c3]
[~brandon.williams] would you mind to review?
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17411) Network partition causes write ONE timeouts when using counters in Cassandra 4
Pere Balaguer created CASSANDRA-17411:
-
Summary: Network partition causes write ONE timeouts when using
counters in Cassandra 4
Key: CASSANDRA-17411
URL: https://issues.apache.org/jira/browse/CASSANDRA-17411
Project: Cassandra
Issue Type: Bug
Reporter: Pere Balaguer
Attachments: app.py
h5. Affected versions:
* 4.x
h5. Observed behavior:
When executing CL=ONE writes on a table with a counter column, if one of the
nodes is network partitioned from the others, clients keep sending requests to
it.
Even though this may be a "driver" problem, I've been able to reproduce it with
both java and python datastax drivers using their latest available versions and
given the behavior only changes depending on the Cassandra version, well, here
I am.
h5. Expected behavior:
In Cassandra 3 after all inflight requests fail (expected), no new requests are
sent to the partitioned node. The expectation is that Cassandra 4 behaves the
same way.
h5. How to reproduce:
{noformat}
# Create a cluster with the desired version, will go with 4.x for this example
ccm create bug-report -v 4.0.3
ccm populate -n 2:2:2
ccm start
# Create schemas and so on
CQL=$(cat <
[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499607#comment-17499607
]
Ekaterina Dimitrova commented on CASSANDRA-10537:
-
[~bereng] , [~blerer] you still need a committer here or shall we move it to
Review in Progress?
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15266) java internal exception on attempt to UPDATE a row using CONTAINS operator
[
https://issues.apache.org/jira/browse/CASSANDRA-15266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499601#comment-17499601
]
Andres de la Peña commented on CASSANDRA-15266:
---
Thanks, the patch looks good to me. Could you please prepare patches for 3.11,
4.0 and trunk, so I run CI for them? I guess that there won't be any major
conflicts in those branches.
> java internal exception on attempt to UPDATE a row using CONTAINS operator
> --
>
> Key: CASSANDRA-15266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15266
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Konstantin
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> kostja@atlas ~ % cqlsh -ucassandra -pcassandra
> Connected to My Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE KEYSPACE t1 WITH replication =
> \{'class':'SimpleStrategy', 'replication_factor' : 1};
> cassandra@cqlsh> use t1;
> cassandra@cqlsh:t1> create table t (a int, b frozen>, c int,
> primary key (a, b));
> cassandra@cqlsh:t1> insert into t (a, b, c) values (1, \{1:1, 2:2}, 3);
> cassandra@cqlsh:t1> update t set c=3 where a=1 and b contains 1;
> ServerError: java.lang.UnsupportedOperationException
>
> Server log file:
> ```
> ERROR [Native-Transport-Requests-1] 2019-08-07 17:02:59,283
> QueryMessage.java:129 - Unexpected error during query
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$ContainsRestriction.appendTo(SingleColumnRestriction.java:454)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:109)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770)
> ~[apache-cassan
> dra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.createClustering(ModificationStatement.java:312)
> ~[apache-cassandra-3.
> 11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:677)
> ~[apache-cassandra-3.11.4.j
> ar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:635)
> ~[apache-cassandra-3.11.4
> .jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:437)
> ~[apache-cassa
> ndra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:425)
> ~[apache-cassandra-3.11.4.jar:
> 3.11.4]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44
> ...
> ```
> +Additional information for newcomers:+
> {{CONTAINS}} and {{CONTAINS KEY}} restrictions are not supported for
> {{UPDATE}} or {{DELETE}} operations but they should be properly rejected with
> a proper error message.
> To fix that problem a new check should be added in the
> {{StatementRestrictions}} constructor to thrown an
> {{InvalidRequestException}} if the relation operator is a {{CONTAINS}} or
> {{CONTAINS_KEY}} and the {{StatementType}} an {{UPDATE}} or a {{DELETION}}.
> Some unit tests should be added to {{UpdateTest}} an {{DeleteTest}} to test
> the behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17407) Validate existence of DCs when repairing
[ https://issues.apache.org/jira/browse/CASSANDRA-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499519#comment-17499519 ] Brandon Williams commented on CASSANDRA-17407: -- This looks good. Could you add a small test for this? > Validate existence of DCs when repairing > > > Key: CASSANDRA-17407 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17407 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Jan Karlsson >Assignee: Jan Karlsson >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > With the new validation of data centers in the replication factor, it might > be good to give similar treatment to repair. > Currently the behavior of the --in-dc flag only validates that it contains > the local data center. > If a list is given containing nonexistent data centers, the repair will pass > without errors or warning as long as this list also contains the local data > center. > My suggestion would be to validate all the data centers and give an error > when a nonexistent data center is given. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17407) Validate existence of DCs when repairing
[ https://issues.apache.org/jira/browse/CASSANDRA-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17407: - Reviewers: Brandon Williams > Validate existence of DCs when repairing > > > Key: CASSANDRA-17407 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17407 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Jan Karlsson >Assignee: Jan Karlsson >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > With the new validation of data centers in the replication factor, it might > be good to give similar treatment to repair. > Currently the behavior of the --in-dc flag only validates that it contains > the local data center. > If a list is given containing nonexistent data centers, the repair will pass > without errors or warning as long as this list also contains the local data > center. > My suggestion would be to validate all the data centers and give an error > when a nonexistent data center is given. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17180) Implement heartbeat service to know last time Cassandra node was up
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17180: -- Status: Patch Available (was: In Progress) build: https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1463 PR: https://github.com/apache/cassandra/pull/1351 > Implement heartbeat service to know last time Cassandra node was up > --- > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17407) Validate existence of DCs when repairing
[ https://issues.apache.org/jira/browse/CASSANDRA-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499506#comment-17499506 ] Jan Karlsson commented on CASSANDRA-17407: -- You might have a point about this feeling more like a bug than an improvement. It certainly is confusing behavior for users. I was thinking something like this for the patch: ||Patch||Test|| |[3.11\|https://github.com/apache/cassandra/compare/cassandra-3.11...itskarlsson:c17407-3.11?expand=1]|[CircleCi\|https://app.circleci.com/pipelines/github/itskarlsson/cassandra/9/workflows/ca527be8-4145-4c55-bfb4-7cec670e7b4c]| The patch applies cleanly to 4.0/trunk. I can provide patches for the other versions too if needed. > Validate existence of DCs when repairing > > > Key: CASSANDRA-17407 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17407 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Jan Karlsson >Assignee: Jan Karlsson >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > With the new validation of data centers in the replication factor, it might > be good to give similar treatment to repair. > Currently the behavior of the --in-dc flag only validates that it contains > the local data center. > If a list is given containing nonexistent data centers, the repair will pass > without errors or warning as long as this list also contains the local data > center. > My suggestion would be to validate all the data centers and give an error > when a nonexistent data center is given. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17407) Validate existence of DCs when repairing
[ https://issues.apache.org/jira/browse/CASSANDRA-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499506#comment-17499506 ] Jan Karlsson edited comment on CASSANDRA-17407 at 3/1/22, 12:38 PM: You might have a point about this feeling more like a bug than an improvement. It certainly is confusing behavior for users. I was thinking something like this for the patch: ||Patch||Test|| |[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...itskarlsson:c17407-3.11?expand=1]|[CircleCi|https://app.circleci.com/pipelines/github/itskarlsson/cassandra/9/workflows/ca527be8-4145-4c55-bfb4-7cec670e7b4c]| The patch applies cleanly to 4.0/trunk. I can provide patches for the other versions too if needed. was (Author: jan karlsson): You might have a point about this feeling more like a bug than an improvement. It certainly is confusing behavior for users. I was thinking something like this for the patch: ||Patch||Test|| |[3.11\|https://github.com/apache/cassandra/compare/cassandra-3.11...itskarlsson:c17407-3.11?expand=1]|[CircleCi\|https://app.circleci.com/pipelines/github/itskarlsson/cassandra/9/workflows/ca527be8-4145-4c55-bfb4-7cec670e7b4c]| The patch applies cleanly to 4.0/trunk. I can provide patches for the other versions too if needed. > Validate existence of DCs when repairing > > > Key: CASSANDRA-17407 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17407 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Jan Karlsson >Assignee: Jan Karlsson >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > With the new validation of data centers in the replication factor, it might > be good to give similar treatment to repair. > Currently the behavior of the --in-dc flag only validates that it contains > the local data center. > If a list is given containing nonexistent data centers, the repair will pass > without errors or warning as long as this list also contains the local data > center. > My suggestion would be to validate all the data centers and give an error > when a nonexistent data center is given. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index
[ https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499504#comment-17499504 ] Andres de la Peña commented on CASSANDRA-16092: --- [~maedhroz] [~jasonstack] I left multiple review suggestions on the original PR that are yet to be addressed, is the plan to do so in CASSANDRA-16052? Shouldn't we finish the review here before committing to the feature branch? Besides, shouldn't the feature branch be on the Apache repo, if that's possible? > Add Index Group Interface for Storage Attached Index > > > Key: CASSANDRA-16092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16092 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SASI >Reporter: Zhao Yang >Assignee: Zhao Yang >Priority: Normal > Fix For: 5.x > > > [Index > group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634] > interface allows: > * indexes on the same table to receive centralized lifecycle events called > secondary index groups. Sharing of data between multiple column indexes on > the same table allows SAI disk usage to realise significant space savings > over other index implementations. > * index-group to analyze user query and provide a query plan that leverages > all available indexes within the group. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15266) java internal exception on attempt to UPDATE a row using CONTAINS operator
[
https://issues.apache.org/jira/browse/CASSANDRA-15266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499498#comment-17499498
]
Maciej Sokol commented on CASSANDRA-15266:
--
I've addressed all comments posted by you and blerer, let me know if you want
me to squash if that makes reviewing easier.
> java internal exception on attempt to UPDATE a row using CONTAINS operator
> --
>
> Key: CASSANDRA-15266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15266
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Konstantin
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> kostja@atlas ~ % cqlsh -ucassandra -pcassandra
> Connected to My Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE KEYSPACE t1 WITH replication =
> \{'class':'SimpleStrategy', 'replication_factor' : 1};
> cassandra@cqlsh> use t1;
> cassandra@cqlsh:t1> create table t (a int, b frozen>, c int,
> primary key (a, b));
> cassandra@cqlsh:t1> insert into t (a, b, c) values (1, \{1:1, 2:2}, 3);
> cassandra@cqlsh:t1> update t set c=3 where a=1 and b contains 1;
> ServerError: java.lang.UnsupportedOperationException
>
> Server log file:
> ```
> ERROR [Native-Transport-Requests-1] 2019-08-07 17:02:59,283
> QueryMessage.java:129 - Unexpected error during query
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$ContainsRestriction.appendTo(SingleColumnRestriction.java:454)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:109)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770)
> ~[apache-cassan
> dra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.createClustering(ModificationStatement.java:312)
> ~[apache-cassandra-3.
> 11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:677)
> ~[apache-cassandra-3.11.4.j
> ar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:635)
> ~[apache-cassandra-3.11.4
> .jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:437)
> ~[apache-cassa
> ndra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:425)
> ~[apache-cassandra-3.11.4.jar:
> 3.11.4]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44
> ...
> ```
> +Additional information for newcomers:+
> {{CONTAINS}} and {{CONTAINS KEY}} restrictions are not supported for
> {{UPDATE}} or {{DELETE}} operations but they should be properly rejected with
> a proper error message.
> To fix that problem a new check should be added in the
> {{StatementRestrictions}} constructor to thrown an
> {{InvalidRequestException}} if the relation operator is a {{CONTAINS}} or
> {{CONTAINS_KEY}} and the {{StatementType}} an {{UPDATE}} or a {{DELETION}}.
> Some unit tests should be added to {{UpdateTest}} an {{DeleteTest}} to test
> the behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15266) java internal exception on attempt to UPDATE a row using CONTAINS operator
[
https://issues.apache.org/jira/browse/CASSANDRA-15266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499498#comment-17499498
]
Maciej Sokol edited comment on CASSANDRA-15266 at 3/1/22, 12:26 PM:
Thanks, I've addressed all comments posted by you and blerer, let me know if
you want me to squash if that makes reviewing easier.
was (Author: JIRAUSER285315):
I've addressed all comments posted by you and blerer, let me know if you want
me to squash if that makes reviewing easier.
> java internal exception on attempt to UPDATE a row using CONTAINS operator
> --
>
> Key: CASSANDRA-15266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15266
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Konstantin
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> kostja@atlas ~ % cqlsh -ucassandra -pcassandra
> Connected to My Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE KEYSPACE t1 WITH replication =
> \{'class':'SimpleStrategy', 'replication_factor' : 1};
> cassandra@cqlsh> use t1;
> cassandra@cqlsh:t1> create table t (a int, b frozen>, c int,
> primary key (a, b));
> cassandra@cqlsh:t1> insert into t (a, b, c) values (1, \{1:1, 2:2}, 3);
> cassandra@cqlsh:t1> update t set c=3 where a=1 and b contains 1;
> ServerError: java.lang.UnsupportedOperationException
>
> Server log file:
> ```
> ERROR [Native-Transport-Requests-1] 2019-08-07 17:02:59,283
> QueryMessage.java:129 - Unexpected error during query
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$ContainsRestriction.appendTo(SingleColumnRestriction.java:454)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:109)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770)
> ~[apache-cassan
> dra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.createClustering(ModificationStatement.java:312)
> ~[apache-cassandra-3.
> 11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:677)
> ~[apache-cassandra-3.11.4.j
> ar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:635)
> ~[apache-cassandra-3.11.4
> .jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:437)
> ~[apache-cassa
> ndra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:425)
> ~[apache-cassandra-3.11.4.jar:
> 3.11.4]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44
> ...
> ```
> +Additional information for newcomers:+
> {{CONTAINS}} and {{CONTAINS KEY}} restrictions are not supported for
> {{UPDATE}} or {{DELETE}} operations but they should be properly rejected with
> a proper error message.
> To fix that problem a new check should be added in the
> {{StatementRestrictions}} constructor to thrown an
> {{InvalidRequestException}} if the relation operator is a {{CONTAINS}} or
> {{CONTAINS_KEY}} and the {{StatementType}} an {{UPDATE}} or a {{DELETION}}.
> Some unit tests should be added to {{UpdateTest}} an {{DeleteTest}} to test
> the behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail:
[jira] [Updated] (CASSANDRA-15266) java internal exception on attempt to UPDATE a row using CONTAINS operator
[
https://issues.apache.org/jira/browse/CASSANDRA-15266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15266:
---
Reviewers: Andres de la Peña, Benjamin Lerer (was: Andres de la Peña)
> java internal exception on attempt to UPDATE a row using CONTAINS operator
> --
>
> Key: CASSANDRA-15266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15266
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Konstantin
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> kostja@atlas ~ % cqlsh -ucassandra -pcassandra
> Connected to My Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE KEYSPACE t1 WITH replication =
> \{'class':'SimpleStrategy', 'replication_factor' : 1};
> cassandra@cqlsh> use t1;
> cassandra@cqlsh:t1> create table t (a int, b frozen>, c int,
> primary key (a, b));
> cassandra@cqlsh:t1> insert into t (a, b, c) values (1, \{1:1, 2:2}, 3);
> cassandra@cqlsh:t1> update t set c=3 where a=1 and b contains 1;
> ServerError: java.lang.UnsupportedOperationException
>
> Server log file:
> ```
> ERROR [Native-Transport-Requests-1] 2019-08-07 17:02:59,283
> QueryMessage.java:129 - Unexpected error during query
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$ContainsRestriction.appendTo(SingleColumnRestriction.java:454)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:109)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770)
> ~[apache-cassan
> dra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.createClustering(ModificationStatement.java:312)
> ~[apache-cassandra-3.
> 11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:677)
> ~[apache-cassandra-3.11.4.j
> ar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:635)
> ~[apache-cassandra-3.11.4
> .jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:437)
> ~[apache-cassa
> ndra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:425)
> ~[apache-cassandra-3.11.4.jar:
> 3.11.4]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44
> ...
> ```
> +Additional information for newcomers:+
> {{CONTAINS}} and {{CONTAINS KEY}} restrictions are not supported for
> {{UPDATE}} or {{DELETE}} operations but they should be properly rejected with
> a proper error message.
> To fix that problem a new check should be added in the
> {{StatementRestrictions}} constructor to thrown an
> {{InvalidRequestException}} if the relation operator is a {{CONTAINS}} or
> {{CONTAINS_KEY}} and the {{StatementType}} an {{UPDATE}} or a {{DELETION}}.
> Some unit tests should be added to {{UpdateTest}} an {{DeleteTest}} to test
> the behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17367) sstableloader ignores streaming encryption settings
[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499491#comment-17499491
]
Brandon Williams commented on CASSANDRA-17367:
--
Ok, thank you for the deep explanation. I think the test was just broken in
multiple ways before, and I agree there's probably little value in testing
legacy BOP now, especially if we weren't doing it before. That leaves us with
both unencrypted and encrypted transports tested on current sstables, which I
think is good enough and better than we were before, so +1.
> sstableloader ignores streaming encryption settings
> ---
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Dmitry Potepalov
>Assignee: Dmitry Potepalov
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17367-4.0.txt, 17367-trunk.txt
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17402) Unshared heap size excluding data calculation is broken
[ https://issues.apache.org/jira/browse/CASSANDRA-17402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499486#comment-17499486 ] Andres de la Peña commented on CASSANDRA-17402: --- [~jlewandowski] do you have CI results for this? > Unshared heap size excluding data calculation is broken > --- > > Key: CASSANDRA-17402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17402 > Project: Cassandra > Issue Type: Bug > Components: Local/Memtable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > Unshared heap size excluding data calculation is broken. > For example, it does not takes into consideration whether the buffers are > on-heap or off-heap - empty offheap buffer is 64-bytes while empty heap > buffer is 48-bytes. > It matters especially when we have offheap buffers-based memtables. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15266) java internal exception on attempt to UPDATE a row using CONTAINS operator
[
https://issues.apache.org/jira/browse/CASSANDRA-15266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499476#comment-17499476
]
Andres de la Peña edited comment on CASSANDRA-15266 at 3/1/22, 11:52 AM:
-
Thanks for the PR, I think they are not mandatory but I find them very useful.
Overall the changes look good to me, I have left a couple of minor comments. CI
is looking good too.
was (Author: adelapena):
Thanks for the PR, I think they are not mandatory but I found them very useful.
Overall the changes look good to me, I have left a couple of minor comments.
> java internal exception on attempt to UPDATE a row using CONTAINS operator
> --
>
> Key: CASSANDRA-15266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15266
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Konstantin
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> kostja@atlas ~ % cqlsh -ucassandra -pcassandra
> Connected to My Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE KEYSPACE t1 WITH replication =
> \{'class':'SimpleStrategy', 'replication_factor' : 1};
> cassandra@cqlsh> use t1;
> cassandra@cqlsh:t1> create table t (a int, b frozen>, c int,
> primary key (a, b));
> cassandra@cqlsh:t1> insert into t (a, b, c) values (1, \{1:1, 2:2}, 3);
> cassandra@cqlsh:t1> update t set c=3 where a=1 and b contains 1;
> ServerError: java.lang.UnsupportedOperationException
>
> Server log file:
> ```
> ERROR [Native-Transport-Requests-1] 2019-08-07 17:02:59,283
> QueryMessage.java:129 - Unexpected error during query
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$ContainsRestriction.appendTo(SingleColumnRestriction.java:454)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:109)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770)
> ~[apache-cassan
> dra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.createClustering(ModificationStatement.java:312)
> ~[apache-cassandra-3.
> 11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:677)
> ~[apache-cassandra-3.11.4.j
> ar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:635)
> ~[apache-cassandra-3.11.4
> .jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:437)
> ~[apache-cassa
> ndra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:425)
> ~[apache-cassandra-3.11.4.jar:
> 3.11.4]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44
> ...
> ```
> +Additional information for newcomers:+
> {{CONTAINS}} and {{CONTAINS KEY}} restrictions are not supported for
> {{UPDATE}} or {{DELETE}} operations but they should be properly rejected with
> a proper error message.
> To fix that problem a new check should be added in the
> {{StatementRestrictions}} constructor to thrown an
> {{InvalidRequestException}} if the relation operator is a {{CONTAINS}} or
> {{CONTAINS_KEY}} and the {{StatementType}} an {{UPDATE}} or a {{DELETION}}.
> Some unit tests should be added to {{UpdateTest}} an {{DeleteTest}} to test
> the behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CASSANDRA-15266) java internal exception on attempt to UPDATE a row using CONTAINS operator
[
https://issues.apache.org/jira/browse/CASSANDRA-15266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499476#comment-17499476
]
Andres de la Peña commented on CASSANDRA-15266:
---
Thanks for the PR, I think they are not mandatory but I found them very useful.
Overall the changes look good to me, I have left a couple of minor comments.
> java internal exception on attempt to UPDATE a row using CONTAINS operator
> --
>
> Key: CASSANDRA-15266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15266
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Konstantin
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> kostja@atlas ~ % cqlsh -ucassandra -pcassandra
> Connected to My Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE KEYSPACE t1 WITH replication =
> \{'class':'SimpleStrategy', 'replication_factor' : 1};
> cassandra@cqlsh> use t1;
> cassandra@cqlsh:t1> create table t (a int, b frozen>, c int,
> primary key (a, b));
> cassandra@cqlsh:t1> insert into t (a, b, c) values (1, \{1:1, 2:2}, 3);
> cassandra@cqlsh:t1> update t set c=3 where a=1 and b contains 1;
> ServerError: java.lang.UnsupportedOperationException
>
> Server log file:
> ```
> ERROR [Native-Transport-Requests-1] 2019-08-07 17:02:59,283
> QueryMessage.java:129 - Unexpected error during query
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$ContainsRestriction.appendTo(SingleColumnRestriction.java:454)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:109)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770)
> ~[apache-cassan
> dra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.createClustering(ModificationStatement.java:312)
> ~[apache-cassandra-3.
> 11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:677)
> ~[apache-cassandra-3.11.4.j
> ar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:635)
> ~[apache-cassandra-3.11.4
> .jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:437)
> ~[apache-cassa
> ndra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:425)
> ~[apache-cassandra-3.11.4.jar:
> 3.11.4]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44
> ...
> ```
> +Additional information for newcomers:+
> {{CONTAINS}} and {{CONTAINS KEY}} restrictions are not supported for
> {{UPDATE}} or {{DELETE}} operations but they should be properly rejected with
> a proper error message.
> To fix that problem a new check should be added in the
> {{StatementRestrictions}} constructor to thrown an
> {{InvalidRequestException}} if the relation operator is a {{CONTAINS}} or
> {{CONTAINS_KEY}} and the {{StatementType}} an {{UPDATE}} or a {{DELETION}}.
> Some unit tests should be added to {{UpdateTest}} an {{DeleteTest}} to test
> the behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17367) sstableloader ignores streaming encryption settings
[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499462#comment-17499462
]
Dmitry Potepalov commented on CASSANDRA-17367:
--
> we could just go back to legacy here
I tried this first. This test actually did not do any streaming, because the
schema was not created in the target cluster
{noformat}
[junit-timeout] Opening sstables and calculating sections to stream
[junit-timeout] Skipping file na-1-big-Data.db: table
legacy_tables.legacy_na_clust doesn't exist
[junit-timeout] INFO [main] 2022-03-01 11:55:23,639
StreamResultFuture.java:92 - [Stream
#1850f3a0-994e-11ec-b67d-cd751ea3eb05|#1850f3a0-994e-11ec-b67d-cd751ea3eb05]
Executing streaming plan for Bulk Load
[junit-timeout]
[junit-timeout] Summary statistics:
[junit-timeout] Connections per host : 1
[junit-timeout] Total files transferred : 0
{noformat}
So I created necessary keyspaces/tables, started streaming and then got this
error
{noformat}
[junit-timeout] Opening sstables and calculating sections to stream
[junit-timeout] INFO [main] 2022-03-01 12:02:59,470 BufferPools.java:49
- Global buffer pool limit is 247.000MiB for chunk-cache and 61.000MiB for
networking
[junit-timeout] ERROR 11:02:59 Cannot open
/home/dmitry.potepalov/apache_cassandra/test/data/legacy-sstables/na/legacy_tables/legacy_na_clust/na-1-big;
partitioner org.apache.cassandra.dht.ByteOrderedPartitioner does not match
system partitioner org.apache.cassandra.dht.Murmur3Partitioner. Note that the
default partitioner starting with Cassandra 1.2 is Murmur3Partitioner, so you
will need to edit that to match your old partitioner if upgrading.
{noformat}
I verified that the legacy sstables were indeed created with
ByteOrderedPartitioner and decided that using legacy sstables is not
particulary important in the context of the test, so ended up using the
generated ones.
If I was wrong and using legacy sstables is important in this test, could you
please provide some guidance as to how resolve the partitioner error? I don't
know Cassandra very well, I simply assumed that streaming
ByteOrderedPartitioner sstables to a cluster using the Murmur3Partitioner is
not possible - maybe I'm wrong and there's some necessary configuration that
I'm missing? I remember trying to force ByteOrderedPartitioner on the test
cluster, but that failed somehow, don't have the exact error message - should I
try it again?
> sstableloader ignores streaming encryption settings
> ---
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Dmitry Potepalov
>Assignee: Dmitry Potepalov
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17367-4.0.txt, 17367-trunk.txt
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14797) CQLSSTableWriter does not support DELETE
[
https://issues.apache.org/jira/browse/CASSANDRA-14797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe reassigned CASSANDRA-14797:
---
Assignee: Doug Rohrer
> CQLSSTableWriter does not support DELETE
>
>
> Key: CASSANDRA-14797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14797
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Eric Evans
>Assignee: Doug Rohrer
>Priority: Low
> Fix For: 3.11.x, 4.x
>
> Attachments: cassandra-14797.patch
>
>
> {{CQLSSTableWriter}} doesn't work with {{DELETE}} statements, and ought to.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14797) CQLSSTableWriter does not support DELETE
[
https://issues.apache.org/jira/browse/CASSANDRA-14797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-14797:
Reviewers: Sam Tunnicliffe, Sam Tunnicliffe
Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe)
Status: Review In Progress (was: Patch Available)
> CQLSSTableWriter does not support DELETE
>
>
> Key: CASSANDRA-14797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14797
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Eric Evans
>Priority: Low
> Fix For: 3.11.x, 4.x
>
> Attachments: cassandra-14797.patch
>
>
> {{CQLSSTableWriter}} doesn't work with {{DELETE}} statements, and ought to.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499453#comment-17499453
]
Andres de la Peña commented on CASSANDRA-17186:
---
I don't think either that those failures are caused by the patch. The tests
don't seem to use {{IN}} queries and also guardrails are disabled by default.
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Krishna Vadali
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
