[jira] [Commented] (CASSANDRA-15016) bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793290#comment-16793290
]
Vinay Chella commented on CASSANDRA-15016:
--
Thanks for the review [~aweisberg]
Squashed and committed as
[9c6aa8a76de24df75de73218c917571346cc509c|https://github.com/apache/cassandra-dtest/commit/9c6aa8a76de24df75de73218c917571346cc509c]
to cassandra-dtest
> bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on
> 3.11.4
>
>
> Key: CASSANDRA-15016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15016
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Low
> Labels: dtest, test, upgrade-dtest
>
> {{test_simple_bootstrap_mixed_versions}} is failing due to CASSANDRA-13004,
> which introduced "cassandra.force_3_0_protocol_version" for schema migrations
> during upgrades from 3.0.14 upwards. This flag is missing in
> `test_simple_bootstrap_mixed_versions` while we are adding/bootstrapping
> 3.11.4 node to an existing 3.5 version of C* node, which resulted in {{ks}}
> keyspace schema/data not being bootstrapped to the new node.
> I debugged and confirmed that
> [MigrationManager::is30Compatible|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185]
> is returning false which is forcing
> [MigrationManager::shouldPullSchemaFrom|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177]
> to return false as well.
> *from debug logs:*
> {code:java}
> DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 - Not
> pulling schema because versions match or shouldPullSchemaFrom returned fal
> {code}
> *Failed upgrade tests:
> [https://circleci.com/gh/aweisberg/cassandra/2593#tests/containers/11]*
> *From failed dtest:*
> {code:java}
> self = 0x7f1bec192eb8>
> @pytest.mark.no_vnodes
> @since('3.10', max_version='3.99')
> def test_simple_bootstrap_mixed_versions(self):
> > self._base_bootstrap_test(bootstrap_from_version="3.5")
> upgrade_tests/bootstrap_upgrade_test.py:20:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> bootstrap_test.py:114: in _base_bootstrap_test
> assert_almost_equal(size1, size2, error=0.3)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> args = (429.36, 133.1), kwargs = {'error': 0.3}, error = 0.3, vmax = 429.36
> vmin = 133.1, error_message = ''
> def assert_almost_equal(*args, **kwargs):
> """
> Assert variable number of arguments all fall within a margin of error.
> @params *args variable number of numerical arguments to check
> @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default ''
>
> Examples:
> assert_almost_equal(sizes[2], init_size)
> assert_almost_equal(ttl_session1, ttl_session2[0][0], error=0.005)
> """
> error = kwargs['error'] if 'error' in kwargs else 0.16
> vmax = max(args)
> vmin = min(args)
> error_message = '' if 'error_message' not in kwargs else
> kwargs['error_message']
> assert vmin > vmax * (1.0 - error) or vmin == vmax, \
> > "values not within {:.2f}% of the max: {} ({})".format(error *
> > 100, args, error_message)
> E AssertionError: values not within 30.00% of the max: (429.36, 133.1)
> ()
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15016) bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15016:
-
Fix Version/s: 3.11.4
Since Version: 3.11.0
Status: Resolved (was: Ready to Commit)
> bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on
> 3.11.4
>
>
> Key: CASSANDRA-15016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15016
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Low
> Labels: dtest, test, upgrade-dtest
> Fix For: 3.11.4
>
>
> {{test_simple_bootstrap_mixed_versions}} is failing due to CASSANDRA-13004,
> which introduced "cassandra.force_3_0_protocol_version" for schema migrations
> during upgrades from 3.0.14 upwards. This flag is missing in
> `test_simple_bootstrap_mixed_versions` while we are adding/bootstrapping
> 3.11.4 node to an existing 3.5 version of C* node, which resulted in {{ks}}
> keyspace schema/data not being bootstrapped to the new node.
> I debugged and confirmed that
> [MigrationManager::is30Compatible|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185]
> is returning false which is forcing
> [MigrationManager::shouldPullSchemaFrom|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177]
> to return false as well.
> *from debug logs:*
> {code:java}
> DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 - Not
> pulling schema because versions match or shouldPullSchemaFrom returned fal
> {code}
> *Failed upgrade tests:
> [https://circleci.com/gh/aweisberg/cassandra/2593#tests/containers/11]*
> *From failed dtest:*
> {code:java}
> self = 0x7f1bec192eb8>
> @pytest.mark.no_vnodes
> @since('3.10', max_version='3.99')
> def test_simple_bootstrap_mixed_versions(self):
> > self._base_bootstrap_test(bootstrap_from_version="3.5")
> upgrade_tests/bootstrap_upgrade_test.py:20:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> bootstrap_test.py:114: in _base_bootstrap_test
> assert_almost_equal(size1, size2, error=0.3)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> args = (429.36, 133.1), kwargs = {'error': 0.3}, error = 0.3, vmax = 429.36
> vmin = 133.1, error_message = ''
> def assert_almost_equal(*args, **kwargs):
> """
> Assert variable number of arguments all fall within a margin of error.
> @params *args variable number of numerical arguments to check
> @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default ''
>
> Examples:
> assert_almost_equal(sizes[2], init_size)
> assert_almost_equal(ttl_session1, ttl_session2[0][0], error=0.005)
> """
> error = kwargs['error'] if 'error' in kwargs else 0.16
> vmax = max(args)
> vmin = min(args)
> error_message = '' if 'error_message' not in kwargs else
> kwargs['error_message']
> assert vmin > vmax * (1.0 - error) or vmin == vmax, \
> > "values not within {:.2f}% of the max: {} ({})".format(error *
> > 100, args, error_message)
> E AssertionError: values not within 30.00% of the max: (429.36, 133.1)
> ()
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch master updated: Fix failing upgrade test - test_simple_bootstrap_mixed_versions
This is an automated email from the ASF dual-hosted git repository.
vinaychella pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/master by this push:
new 9c6aa8a Fix failing upgrade test -
test_simple_bootstrap_mixed_versions
9c6aa8a is described below
commit 9c6aa8a76de24df75de73218c917571346cc509c
Author: Vinay Chella
AuthorDate: Wed Feb 6 22:57:53 2019 -0800
Fix failing upgrade test - test_simple_bootstrap_mixed_versions
Adds force_3_0_protocol_version flag to upgrades 3.0.14 upwards which fixes
schema migrations during mixed version bootstrap
Patch by Vinay Chella; reviewed by Ariel Weisberg for CASSANDRA-15016
---
bootstrap_test.py | 34 +++--
dtest.py| 29
upgrade_tests/bootstrap_upgrade_test.py | 5 -
3 files changed, 57 insertions(+), 11 deletions(-)
diff --git a/bootstrap_test.py b/bootstrap_test.py
index e33749e..940bef5 100644
--- a/bootstrap_test.py
+++ b/bootstrap_test.py
@@ -15,7 +15,7 @@ from ccmlib.node import TimeoutError
import pytest
-from dtest import Tester, create_ks, create_cf
+from dtest import Tester, create_ks, create_cf, data_size
from tools.assertions import (assert_almost_equal, assert_bootstrap_state,
assert_not_running,
assert_one, assert_stderr_clean)
from tools.data import query_c1c2
@@ -82,16 +82,16 @@ class TestBootstrap(Tester):
create_cf(session, 'cf', columns={'c1': 'text', 'c2': 'text'})
# record the size before inserting any of our own data
-empty_size = node1.data_size()
-logger.debug("node1 empty size : %s" % float(empty_size))
+empty_size = data_size(node1, 'ks','cf')
+logger.debug("node1 empty size for ks.cf: %s" % float(empty_size))
insert_statement = session.prepare("INSERT INTO ks.cf (key, c1, c2)
VALUES (?, 'value1', 'value2')")
execute_concurrent_with_args(session, insert_statement, [['k%d' % k]
for k in range(keys)])
node1.flush()
node1.compact()
-initial_size = node1.data_size()
-logger.debug("node1 size before bootstrapping node2: %s" %
float(initial_size))
+initial_size = data_size(node1,'ks','cf')
+logger.debug("node1 size for ks.cf before bootstrapping node2: %s" %
float(initial_size))
# Reads inserted data all during the bootstrap process. We shouldn't
# get any error
@@ -103,14 +103,14 @@ class TestBootstrap(Tester):
node2.compact()
node1.cleanup()
-logger.debug("node1 size after cleanup: %s" % float(node1.data_size()))
+logger.debug("node1 size for ks.cf after cleanup: %s" %
float(data_size(node1,'ks','cf')))
node1.compact()
-logger.debug("node1 size after compacting: %s" %
float(node1.data_size()))
+logger.debug("node1 size for ks.cf after compacting: %s" %
float(data_size(node1,'ks','cf')))
-logger.debug("node2 size after compacting: %s" %
float(node2.data_size()))
+logger.debug("node2 size for ks.cf after compacting: %s" %
float(data_size(node2,'ks','cf')))
-size1 = float(node1.data_size())
-size2 = float(node2.data_size())
+size1 = float(data_size(node1,'ks','cf'))
+size2 = float(data_size(node2,'ks','cf'))
assert_almost_equal(size1, size2, error=0.3)
assert_almost_equal(float(initial_size - empty_size), 2 * (size1 -
float(empty_size)))
@@ -140,6 +140,20 @@ class TestBootstrap(Tester):
self._base_bootstrap_test(bootstrap_on_write_survey_and_join)
+def _test_bootstrap_with_compatibility_flag_on(self,
bootstrap_from_version):
+def bootstrap_with_compatibility_flag_on(cluster, token):
+node2 = new_node(cluster)
+node2.set_configuration_options(values={'initial_token': token})
+# cassandra.force_3_0_protocol_version parameter is needed to
allow schema
+# changes during the bootstrapping for upgrades from 3.0.14+ to
anything upwards for 3.0.x or 3.x clusters.
+# @jira_ticket CASSANDRA-13004 for detailed context on
`cassandra.force_3_0_protocol_version` flag
+
node2.start(jvm_args=["-Dcassandra.force_3_0_protocol_version=true"],
+wait_for_binary_proto=True)
+return node2
+
+self._base_bootstrap_test(bootstrap_with_compatibility_flag_on,
+
bootstrap_from_version=bootstrap_from_version)
+
@since('3.10')
@pytest.mark.no_vnodes
def test_simple_bootstrap_small_keepalive_period(self):
diff --git a/dtest.py b/dtest.py
index ec79771..d6aff2d 100644
--- a/dtest.py
+++ b/dtest.py
@@ -384,6 +384,35 @@ def make_auth(user, password):
return private_auth
+def data_size(node, ks, cf):
+"
[jira] [Assigned] (CASSANDRA-15000) Invalidate counter caches on `nodetool import`
[
https://issues.apache.org/jira/browse/CASSANDRA-15000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West reassigned CASSANDRA-15000:
---
Assignee: Jordan West
> Invalidate counter caches on `nodetool import`
> --
>
> Key: CASSANDRA-15000
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15000
> Project: Cassandra
> Issue Type: Bug
>Reporter: Doug Rohrer
>Assignee: Jordan West
>Priority: Normal
>
> {{nodetool import}} currently invalidates row caches on import
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SSTableImporter.java#L291],
> but doesn't invalidate the corresponding counter caches, if they exist. It
> should invalidate both.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793216#comment-16793216
]
Jon Meredith commented on CASSANDRA-15005:
--
That sounds like a very reasonable way to get started if you want to modify the
whitelist.
I've made a bit of progress on loading custom functions instead of extending
the whitelist, here's a branch against 3.0
[https://github.com/jonmeredith/cassandra/tree/CASSANDRA-15005-3.0]
I'm not sure if the convention of exporting an `all()` method will stay, but it
matches the classes that define functions. I'm also not sure what version this
could land in with the current freeze on trunk.
> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Low
>
> I would like to use the UDF system to distribute some simple calculations on
> values. For some use cases, this would require access only to some Java API
> classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access to
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is
> hardcoded in java in
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to
> be extended via some kind of deployment-time configuration. I realize that
> serious security concerns immediately arise for this kind of functionality,
> but I hope that by restricting it (only used during startup, no exposing the
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I
> have sufficient Java skill to do that, but no real familiarity with C*'s
> codebase, yet. :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[ https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15019: Attachment: (was: DistributedReadWritePathTest.java) > Repaired data tracking isn't working for range queries > -- > > Key: CASSANDRA-15019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15019 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination, Consistency/Repair, Test/dtest >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0 > > Attachments: RepairDigestTrackingTest.java > > > CASSANDRA-14145 introduced optional tracking of the repaired dataset used to > construct a read response. If enabled, each replica computes a digest for the > repaired portion of the data, which the coordinator compares in order to > detect divergence between replicas. This isn't working correctly for range > reads, as the ReadCommand instance that the DataResolver is intialized with > does not have the tracking flag set. This has been undetected up until now as > the dtest which should verify it also has a bug in that when the relevant > range query is issued the test expectations are being incorrectly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793030#comment-16793030
]
Jordan West edited comment on CASSANDRA-15019 at 3/14/19 9:29 PM:
--
[~beobal] also shouldn't
[this|https://github.com/beobal/cassandra/commit/c92b9dea14e128f2063dca01526c3afcd5559d51#diff-71f06c193f5b5e270cf8ac695164f43aR2052]
call be to {{DatabaseDescriptor.getRepairedDataTrackingForRangeReadsEnabled}}.
Just noticing this now. It existed before the patch.
EDIT: I've uploaded a test that illustrates the bug (uncomment line 51 to make
the test pass but it shouldn't be necessary). The test also shows how we could
convert the dtest to an in-jvm distributed test.
was (Author: jrwest):
[~beobal] also shouldn't
[this|https://github.com/beobal/cassandra/commit/c92b9dea14e128f2063dca01526c3afcd5559d51#diff-71f06c193f5b5e270cf8ac695164f43aR2052]
call be to {{DatabaseDescriptor.getRepairedDataTrackingForRangeReadsEnabled}}.
Just noticing this now. It existed before the patch.
> Repaired data tracking isn't working for range queries
> --
>
> Key: CASSANDRA-15019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15019
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Consistency/Repair, Test/dtest
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
> Attachments: RepairDigestTrackingTest.java
>
>
> CASSANDRA-14145 introduced optional tracking of the repaired dataset used to
> construct a read response. If enabled, each replica computes a digest for the
> repaired portion of the data, which the coordinator compares in order to
> detect divergence between replicas. This isn't working correctly for range
> reads, as the ReadCommand instance that the DataResolver is intialized with
> does not have the tracking flag set. This has been undetected up until now as
> the dtest which should verify it also has a bug in that when the relevant
> range query is issued the test expectations are being incorrectly set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[ https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15019: Attachment: (was: RepairDigestTrackingTest.java) > Repaired data tracking isn't working for range queries > -- > > Key: CASSANDRA-15019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15019 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination, Consistency/Repair, Test/dtest >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0 > > Attachments: RepairDigestTrackingTest.java > > > CASSANDRA-14145 introduced optional tracking of the repaired dataset used to > construct a read response. If enabled, each replica computes a digest for the > repaired portion of the data, which the coordinator compares in order to > detect divergence between replicas. This isn't working correctly for range > reads, as the ReadCommand instance that the DataResolver is intialized with > does not have the tracking flag set. This has been undetected up until now as > the dtest which should verify it also has a bug in that when the relevant > range query is issued the test expectations are being incorrectly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[ https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15019: Attachment: RepairDigestTrackingTest.java > Repaired data tracking isn't working for range queries > -- > > Key: CASSANDRA-15019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15019 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination, Consistency/Repair, Test/dtest >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0 > > Attachments: RepairDigestTrackingTest.java > > > CASSANDRA-14145 introduced optional tracking of the repaired dataset used to > construct a read response. If enabled, each replica computes a digest for the > repaired portion of the data, which the coordinator compares in order to > detect divergence between replicas. This isn't working correctly for range > reads, as the ReadCommand instance that the DataResolver is intialized with > does not have the tracking flag set. This has been undetected up until now as > the dtest which should verify it also has a bug in that when the relevant > range query is issued the test expectations are being incorrectly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[ https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15019: Attachment: RepairDigestTrackingTest.java > Repaired data tracking isn't working for range queries > -- > > Key: CASSANDRA-15019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15019 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination, Consistency/Repair, Test/dtest >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0 > > Attachments: RepairDigestTrackingTest.java > > > CASSANDRA-14145 introduced optional tracking of the repaired dataset used to > construct a read response. If enabled, each replica computes a digest for the > repaired portion of the data, which the coordinator compares in order to > detect divergence between replicas. This isn't working correctly for range > reads, as the ReadCommand instance that the DataResolver is intialized with > does not have the tracking flag set. This has been undetected up until now as > the dtest which should verify it also has a bug in that when the relevant > range query is issued the test expectations are being incorrectly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[ https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15019: Attachment: DistributedReadWritePathTest.java > Repaired data tracking isn't working for range queries > -- > > Key: CASSANDRA-15019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15019 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination, Consistency/Repair, Test/dtest >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0 > > Attachments: RepairDigestTrackingTest.java > > > CASSANDRA-14145 introduced optional tracking of the repaired dataset used to > construct a read response. If enabled, each replica computes a digest for the > repaired portion of the data, which the coordinator compares in order to > detect divergence between replicas. This isn't working correctly for range > reads, as the ReadCommand instance that the DataResolver is intialized with > does not have the tracking flag set. This has been undetected up until now as > the dtest which should verify it also has a bug in that when the relevant > range query is issued the test expectations are being incorrectly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793044#comment-16793044
]
A. Soroka commented on CASSANDRA-15005:
---
Hello, [~jmeredithco]! I think I might have a bit of time myself in the next
few weeks to look at this. If nothing else, I can get more familiarity with the
C* codebase. Do you have any suggestions or advice (or warnings!)? I was
thinking that we could try something like a list in {{cassandra.yaml}} of Java
types, a la:
{code:yaml}
extraWhitelistedUDFs:
com.my.company.cassandra.functions.myCoolFunc
com.my.company.cassandra.functions.myOtherFunc
{code}
Then I could change {{UDFunction}} to use that list in addition to the
white/blacklists already in {{UDFunction}} to determine whether a {{CREATE
FUNCTION}} is "kosher" or not.
Does that sound like a reasonable way to set off? Thanks!
> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Low
>
> I would like to use the UDF system to distribute some simple calculations on
> values. For some use cases, this would require access only to some Java API
> classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access to
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is
> hardcoded in java in
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to
> be extended via some kind of deployment-time configuration. I realize that
> serious security concerns immediately arise for this kind of functionality,
> but I hope that by restricting it (only used during startup, no exposing the
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I
> have sufficient Java skill to do that, but no real familiarity with C*'s
> codebase, yet. :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793030#comment-16793030
]
Jordan West commented on CASSANDRA-15019:
-
[~beobal] also shouldn't
[this|https://github.com/beobal/cassandra/commit/c92b9dea14e128f2063dca01526c3afcd5559d51#diff-71f06c193f5b5e270cf8ac695164f43aR2052]
call be to {{DatabaseDescriptor.getRepairedDataTrackingForRangeReadsEnabled}}.
Just noticing this now. It existed before the patch.
> Repaired data tracking isn't working for range queries
> --
>
> Key: CASSANDRA-15019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15019
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Consistency/Repair, Test/dtest
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> CASSANDRA-14145 introduced optional tracking of the repaired dataset used to
> construct a read response. If enabled, each replica computes a digest for the
> repaired portion of the data, which the coordinator compares in order to
> detect divergence between replicas. This isn't working correctly for range
> reads, as the ReadCommand instance that the DataResolver is intialized with
> does not have the tracking flag set. This has been undetected up until now as
> the dtest which should verify it also has a bug in that when the relevant
> range query is issued the test expectations are being incorrectly set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r1855545 - in /cassandra/site: publish/download/index.html src/_plugins/release_link.rb
Author: mshuler Date: Thu Mar 14 18:38:30 2019 New Revision: 1855545 URL: http://svn.apache.org/viewvc?rev=1855545&view=rev Log: Fix checksum link generation on download page Checksums for releases are now sha256/sha512, but download page generated links to the old md5/sha1 files Modified: cassandra/site/publish/download/index.html cassandra/site/src/_plugins/release_link.rb Modified: cassandra/site/publish/download/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1855545&r1=1855544&r2=1855545&view=diff == --- cassandra/site/publish/download/index.html (original) +++ cassandra/site/publish/download/index.html Thu Mar 14 18:38:30 2019 @@ -99,17 +99,17 @@ Latest version -Download the latest Apache Cassandra 3.11 release: http://www.apache.org/dyn/closer.lua/cassandra/3.11.4/apache-cassandra-3.11.4-bin.tar.gz";>3.11.4 (http://www.apache.org/dist/cassandra/3.11.4/apache-cassandra-3.11.4-bin.tar.gz.asc";>pgp, http://www.apache.org/dist/cassandra/3.11.4/apache-cassandra-3.11.4-bin.tar.gz.md5";>md5 and http://www.apache.org/dist/cassandra/3.11.4/apache-cassandra-3.11.4-bin.tar.gz.sha1";>sha1), released on 2019-02-11. +Download the latest Apache Cassandra 3.11 release: http://www.apache.org/dyn/closer.lua/cassandra/3.11.4/apache-cassandra-3.11.4-bin.tar.gz";>3.11.4 (http://www.apache.org/dist/cassandra/3.11.4/apache-cassandra-3.11.4-bin.tar.gz.asc";>pgp, http://www.apache.org/dist/cassandra/3.11.4/apache-cassandra-3.11.4-bin.tar.gz.sha256";>sha256 and http://www.apache.org/dist/cassandra/3.11.4/apache-cassandra-3.11.4-bin.tar.gz.sha512";>sha512), released on 2019-02-11. Older supported releases The following older Cassandra releases are still supported: - Apache Cassandra 3.0 is supported until 6 months after 4.0 release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/3.0.18/apache-cassandra-3.0.18-bin.tar.gz";>3.0.18 (http://www.apache.org/dist/cassandra/3.0.18/apache-cassandra-3.0.18-bin.tar.gz.asc";>pgp, http://www.apache.org/dist/cassandra/3.0.18/apache-cassandra-3.0.18-bin.tar.gz.md5";>md5 and http://www.apache.org/dist/cassandra/3.0.18/apache-cassandra-3.0.18-bin.tar.gz.sha1";>sha1), released on 2019-02-11. - Apache Cassandra 2.2 is supported until 4.0 release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/2.2.14/apache-cassandra-2.2.14-bin.tar.gz";>2.2.14 (http://www.apache.org/dist/cassandra/2.2.14/apache-cassandra-2.2.14-bin.tar.gz.asc";>pgp, http://www.apache.org/dist/cassandra/2.2.14/apache-cassandra-2.2.14-bin.tar.gz.md5";>md5 and http://www.apache.org/dist/cassandra/2.2.14/apache-cassandra-2.2.14-bin.tar.gz.sha1";>sha1), released on 2019-02-11. + Apache Cassandra 3.0 is supported until 6 months after 4.0 release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/3.0.18/apache-cassandra-3.0.18-bin.tar.gz";>3.0.18 (http://www.apache.org/dist/cassandra/3.0.18/apache-cassandra-3.0.18-bin.tar.gz.asc";>pgp, http://www.apache.org/dist/cassandra/3.0.18/apache-cassandra-3.0.18-bin.tar.gz.sha256";>sha256 and http://www.apache.org/dist/cassandra/3.0.18/apache-cassandra-3.0.18-bin.tar.gz.sha512";>sha512), released on 2019-02-11. + Apache Cassandra 2.2 is supported until 4.0 release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/2.2.14/apache-cassandra-2.2.14-bin.tar.gz";>2.2.14 (http://www.apache.org/dist/cassandra/2.2.14/apache-cassandra-2.2.14-bin.tar.gz.asc";>pgp, http://www.apache.org/dist/cassandra/2.2.14/apache-cassandra-2.2.14-bin.tar.gz.sha256";>sha256 and http://www.apache.org/dist/cassandra/2.2.14/apache-cassandra-2.2.14-bin.tar.gz.sha512";>sha512), released on 2019-02-11. Apache Cassandra 2.1 is supported until 4.0 release (date TBD) with critical fixes only. The latest release is -http://www.apache.org/dyn/closer.lua/cassandra/2.1.21/apache-cassandra-2.1.21-bin.tar.gz";>2.1.21 (http://www.apache.org/dist/cassandra/2.1.21/apache-cassandra-2.1.21-bin.tar.gz.asc";>pgp, http://www.apache.org/dist/cassandra/2.1.21/apache-cassandra-2.1.21-bin.tar.gz.md5";>md5 and http://www.apache.org/dist/cassandra/2.1.21/apache-cassandra-2.1.21-bin.tar.gz.sha1";>sha1), released on 2019-02-11. +http://www.apache.org/dyn/closer.lua/cassandra/2.1.21/apache-cassandra-2.1.21-bin.tar.gz";>2.1.21 (http://www.apache.org/dist/cassandra/2.1.21/apache-cassandra-2.1.21-bin.tar.gz.asc";>pgp, http://www.apache.org/dist/cassandra/2.1.21/apache-cassandra-2.1.21-bin.tar.gz.sha256";>sha256 and http://www.apache.org/dist/cassandra/2.1.21/apache-cassandra-2.1.21-bin.tar.gz.sha512";>sha512), released on 2019-02-11. Older (unsupported) versions of Cassandra are http://archive.apache.org/dist/cassandra/";>archived here. Modified: cassandra/site/src/_plugins/release_link.rb URL: http://svn.apache.org/viewvc/cassandra/site/
[jira] [Updated] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[ https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15019: Reviewers: Jordan West > Repaired data tracking isn't working for range queries > -- > > Key: CASSANDRA-15019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15019 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination, Consistency/Repair, Test/dtest >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0 > > > CASSANDRA-14145 introduced optional tracking of the repaired dataset used to > construct a read response. If enabled, each replica computes a digest for the > repaired portion of the data, which the coordinator compares in order to > detect divergence between replicas. This isn't working correctly for range > reads, as the ReadCommand instance that the DataResolver is intialized with > does not have the tracking flag set. This has been undetected up until now as > the dtest which should verify it also has a bug in that when the relevant > range query is issued the test expectations are being incorrectly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792936#comment-16792936
]
Jordan West edited comment on CASSANDRA-15019 at 3/14/19 6:19 PM:
--
This looks like the simplest patch to fix this but I wonder if we would be
better served in the future by fixing the functions that copy {{ReadCommand}}
to correctly copy the tracking flag. The patch would be a bit bigger for sure
(needing to modify each function and potentially the constructor) but it would
be more likely prevent this mistake in the future and would clarify the
disabling of the flag for transient replicas.
Happy to +1 it as is but wanted to toss that out there first.
was (Author: jrwest):
This looks like the simplest patch to fix this but I wonder if we would be
better served in the future by fixing the functions that copy `ReadCommand`'s
to correctly copy the tracking flag. The patch would be a bit bigger for sure
(needing to modify each function and potentially the constructor) but it would
be more likely prevent this mistake in the future and would clarify the
disabling of the flag for transient replicas.
Happy to +1 it as is but wanted to toss that out there first.
> Repaired data tracking isn't working for range queries
> --
>
> Key: CASSANDRA-15019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15019
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Consistency/Repair, Test/dtest
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> CASSANDRA-14145 introduced optional tracking of the repaired dataset used to
> construct a read response. If enabled, each replica computes a digest for the
> repaired portion of the data, which the coordinator compares in order to
> detect divergence between replicas. This isn't working correctly for range
> reads, as the ReadCommand instance that the DataResolver is intialized with
> does not have the tracking flag set. This has been undetected up until now as
> the dtest which should verify it also has a bug in that when the relevant
> range query is issued the test expectations are being incorrectly set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15019) Repaired data tracking isn't working for range queries
[ https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792936#comment-16792936 ] Jordan West commented on CASSANDRA-15019: - This looks like the simplest patch to fix this but I wonder if we would be better served in the future by fixing the functions that copy `ReadCommand`'s to correctly copy the tracking flag. The patch would be a bit bigger for sure (needing to modify each function and potentially the constructor) but it would be more likely prevent this mistake in the future and would clarify the disabling of the flag for transient replicas. Happy to +1 it as is but wanted to toss that out there first. > Repaired data tracking isn't working for range queries > -- > > Key: CASSANDRA-15019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15019 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination, Consistency/Repair, Test/dtest >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0 > > > CASSANDRA-14145 introduced optional tracking of the repaired dataset used to > construct a read response. If enabled, each replica computes a digest for the > repaired portion of the data, which the coordinator compares in order to > detect divergence between replicas. This isn't working correctly for range > reads, as the ReadCommand instance that the DataResolver is intialized with > does not have the tracking flag set. This has been undetected up until now as > the dtest which should verify it also has a bug in that when the relevant > range query is issued the test expectations are being incorrectly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14822) Cassandra 4.0 doesn't output DESCRIBE TABLE representations that are valid
[
https://issues.apache.org/jira/browse/CASSANDRA-14822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792912#comment-16792912
]
Jordan West commented on CASSANDRA-14822:
-
[~jolynch] reading CASSANDRA-13910 it looks like the decision to throw an
exception in this case was explicit – to inform the user the feature was
removed vs. silently accepting it but doing nothing. Perhaps the exception
could be better instead?
Separately, it seems like the Python driver needs to be updated as you mention
and upgrading to a newer version is likely a pre-requisite for migrating to
4.0.
> Cassandra 4.0 doesn't output DESCRIBE TABLE representations that are valid
> ---
>
> Key: CASSANDRA-14822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14822
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Low
> Labels: cqlsh
>
> Looks like right now on 4.0 the {{DESCRIBE}} output of a table is no longer
> valid since {{dclocal_read_repair_chance}} was removed:
> {noformat}
> cqlsh> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE test.test (key text, value text, PRIMARY KEY(key));
> cqlsh> DESCRIBE TABLE test.test
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> value text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99p';
> {noformat}
> If you then try to copy and past that output it fails:
> {noformat}
> cqlsh> CREATE TABLE test.test2 (
>... key text PRIMARY KEY,
>... value text
>... ) WITH bloom_filter_fp_chance = 0.01
>... AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
>... AND comment = ''
>... AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
>... AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>... AND crc_check_chance = 1.0
>... AND dclocal_read_repair_chance = 0.0
>... AND default_time_to_live = 0
>... AND gc_grace_seconds = 864000
>... AND max_index_interval = 2048
>... AND memtable_flush_period_in_ms = 0
>... AND min_index_interval = 128
>... AND read_repair_chance = 0.0
>... AND speculative_retry = '99p';
> SyntaxException: Unknown property 'dclocal_read_repair_chance'
> {noformat}
> Currently we leave in {{dclocal_read_repair_chance}} and
> {{read_repair_chance}} for the drivers per the comments left during
> CASSANDRA-13910.
> I think we can just ignore those parameters in the validation/creation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14822) Cassandra 4.0 doesn't output DESCRIBE TABLE representations that are valid
[
https://issues.apache.org/jira/browse/CASSANDRA-14822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West reassigned CASSANDRA-14822:
---
Assignee: Joseph Lynch
Reviewers: Jordan West
> Cassandra 4.0 doesn't output DESCRIBE TABLE representations that are valid
> ---
>
> Key: CASSANDRA-14822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14822
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Low
> Labels: cqlsh
>
> Looks like right now on 4.0 the {{DESCRIBE}} output of a table is no longer
> valid since {{dclocal_read_repair_chance}} was removed:
> {noformat}
> cqlsh> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE test.test (key text, value text, PRIMARY KEY(key));
> cqlsh> DESCRIBE TABLE test.test
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> value text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99p';
> {noformat}
> If you then try to copy and past that output it fails:
> {noformat}
> cqlsh> CREATE TABLE test.test2 (
>... key text PRIMARY KEY,
>... value text
>... ) WITH bloom_filter_fp_chance = 0.01
>... AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
>... AND comment = ''
>... AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
>... AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>... AND crc_check_chance = 1.0
>... AND dclocal_read_repair_chance = 0.0
>... AND default_time_to_live = 0
>... AND gc_grace_seconds = 864000
>... AND max_index_interval = 2048
>... AND memtable_flush_period_in_ms = 0
>... AND min_index_interval = 128
>... AND read_repair_chance = 0.0
>... AND speculative_retry = '99p';
> SyntaxException: Unknown property 'dclocal_read_repair_chance'
> {noformat}
> Currently we leave in {{dclocal_read_repair_chance}} and
> {{read_repair_chance}} for the drivers per the comments left during
> CASSANDRA-13910.
> I think we can just ignore those parameters in the validation/creation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792901#comment-16792901
]
Stefan Podkowinski commented on CASSANDRA-14806:
Looks like your latest builds can be found at:
* [2.2|https://circleci.com/workflow-run/6ac9d6c4-3968-4a6e-8cbe-cad8c7880961]
* [3.0|https://circleci.com/workflow-run/50120c8c-8641-4761-aaa2-64214ed9290a]
* [3.11|https://circleci.com/workflow-run/db5e3bb2-4b8a-456a-8d5b-6dc943fea0fe]
*
[trunk|https://circleci.com/workflow-run/e1eec049-70f1-4a07-b3e9-1c519cb26888]
There seems to be a significant number of 2.2 dtests (see also CASSANDRA-14866)
and the upgrade tests failing, so I did some reference runs against the
unmodified branches. Turns out we see the same kind of failures there as well,
so it shouldn't be related to the patch at all.
* [3.0 - upgrade
tests|https://circleci.com/gh/spodkowinski/cassandra/675#tests/containers/11]
* [3.11 - upgrade
tests|https://circleci.com/gh/spodkowinski/cassandra/673#tests/containers/11]
* [2.2 -
dtests|https://circleci.com/workflow-run/0dae4fa9-7b00-4814-9726-87ad513bb110]
+1, I think we're ready to get this merged now.
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15042) cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
[
https://issues.apache.org/jira/browse/CASSANDRA-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Preston updated CASSANDRA-15042:
Description:
Cassandra 3.11.4
Running a query in cqlsh with TRACING ON
Native Secondary indexes all report cardinalities as *1*.
trace output:
{noformat}
Index mean cardinalities are
country_idx:1,company_idx:1,source_idx:1,domain_idx:1. Scanning with
country_idx.
{noformat}
Cassandra 2.2.x and its' predecessors reported cardinalities > 1 in cqlsh
tracing output:
{noformat}
Candidate index mean cardinalities are
CompositesIndexOnRegular{columnDefs=[ColumnDefinition
{name=country, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
componentIndex=0, indexName=country_idx, indexType=COMPOSITES}
]}:2, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
{name=company, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
componentIndex=0, indexName=company_idx, indexType=COMPOSITES}
]}:1210, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
{name=source, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
componentIndex=0, indexName=source_idx, indexType=COMPOSITES}
]}:501804, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
{name=domain, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
componentIndex=0, indexName=domain, indexType=COMPOSITES}
]}:325801.
Scanning with country_idx.{noformat}
was:
Cassandra 3.11.4
Running a query in cqlsh with TRACING ON
Secondary indexes all report cardinalities as *1*.
trace output:
{noformat}
Index mean cardinalities are
country_idx:1,company_idx:1,source_idx:1,domain_idx:1. Scanning with
country_idx.
{noformat}
Cassandra 2.2.x and its' predecessors reported cardinalities > 1 in cqlsh
tracing output:
{noformat}
Candidate index mean cardinalities are
CompositesIndexOnRegular{columnDefs=[ColumnDefinition
{name=country, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
componentIndex=0, indexName=country_idx, indexType=COMPOSITES}
]}:2, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
{name=company, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
componentIndex=0, indexName=company_idx, indexType=COMPOSITES}
]}:1210, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
{name=source, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
componentIndex=0, indexName=source_idx, indexType=COMPOSITES}
]}:501804, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
{name=domain, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
componentIndex=0, indexName=domain, indexType=COMPOSITES}
]}:325801.
Scanning with country_idx.{noformat}
> cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
> -
>
> Key: CASSANDRA-15042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15042
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI, Legacy/Tools, Observability/Tracing
>Reporter: William Preston
>Priority: Low
>
> Cassandra 3.11.4
> Running a query in cqlsh with TRACING ON
> Native Secondary indexes all report cardinalities as *1*.
> trace output:
> {noformat}
> Index mean cardinalities are
> country_idx:1,company_idx:1,source_idx:1,domain_idx:1. Scanning with
> country_idx.
> {noformat}
> Cassandra 2.2.x and its' predecessors reported cardinalities > 1 in cqlsh
> tracing output:
> {noformat}
> Candidate index mean cardinalities are
> CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=country, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=country_idx, indexType=COMPOSITES}
> ]}:2, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=company, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=company_idx, indexType=COMPOSITES}
> ]}:1210, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=source, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=source_idx, indexType=COMPOSITES}
> ]}:501804, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=domain, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=domain, indexType=COMPOSITES}
> ]}:325801.
> Scanning with country_idx.{noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15042) cqlsh tracing output reports all secondary "Index mean cardinalities" are 1. SASI report as -9223372036854775808
[
https://issues.apache.org/jira/browse/CASSANDRA-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792756#comment-16792756
]
William Preston commented on CASSANDRA-15042:
-
[~benedict] - Please review my new comment regarding SASI cardinality reporting
as -9223372036854775808 in trace. While not high priority this is quite
concerning from a confidence perspective.
Thank you.
> cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
> SASI report as -9223372036854775808
> -
>
> Key: CASSANDRA-15042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15042
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI, Legacy/Tools, Observability/Tracing
>Reporter: William Preston
>Priority: Normal
>
> Cassandra 3.11.4
> Running a query in cqlsh with TRACING ON
> Native Secondary indexes all report cardinalities as *1*.
> trace output:
> {noformat}
> Index mean cardinalities are
> country_idx:1,company_idx:1,source_idx:1,domain_idx:1. Scanning with
> country_idx.
> {noformat}
> Cassandra 2.2.x and its' predecessors reported cardinalities > 1 in cqlsh
> tracing output:
> {noformat}
> Candidate index mean cardinalities are
> CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=country, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=country_idx, indexType=COMPOSITES}
> ]}:2, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=company, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=company_idx, indexType=COMPOSITES}
> ]}:1210, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=source, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=source_idx, indexType=COMPOSITES}
> ]}:501804, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=domain, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=domain, indexType=COMPOSITES}
> ]}:325801.
> Scanning with country_idx.{noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15042) cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
[
https://issues.apache.org/jira/browse/CASSANDRA-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792737#comment-16792737
]
William Preston commented on CASSANDRA-15042:
-
Update:
Similarly, custom SASI indexes all report cardinalities as -9223372036854775808
trace output:
{noformat}
Index mean cardinalities are
country_idx:-9223372036854775808,company_idx:-9223372036854775808,source_idx:-9223372036854775808,domain_idx:-9223372036854775808.
Scanning with country_idx.
{noformat}
> cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
> -
>
> Key: CASSANDRA-15042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15042
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI, Legacy/Tools, Observability/Tracing
>Reporter: William Preston
>Priority: Low
>
> Cassandra 3.11.4
> Running a query in cqlsh with TRACING ON
> Native Secondary indexes all report cardinalities as *1*.
> trace output:
> {noformat}
> Index mean cardinalities are
> country_idx:1,company_idx:1,source_idx:1,domain_idx:1. Scanning with
> country_idx.
> {noformat}
> Cassandra 2.2.x and its' predecessors reported cardinalities > 1 in cqlsh
> tracing output:
> {noformat}
> Candidate index mean cardinalities are
> CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=country, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=country_idx, indexType=COMPOSITES}
> ]}:2, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=company, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=company_idx, indexType=COMPOSITES}
> ]}:1210, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=source, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=source_idx, indexType=COMPOSITES}
> ]}:501804, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=domain, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=domain, indexType=COMPOSITES}
> ]}:325801.
> Scanning with country_idx.{noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15042) cqlsh tracing output reports all secondary "Index mean cardinalities" are 1. SASI report as -9223372036854775808
[
https://issues.apache.org/jira/browse/CASSANDRA-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Preston updated CASSANDRA-15042:
Priority: Normal (was: Low)
> cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
> SASI report as -9223372036854775808
> -
>
> Key: CASSANDRA-15042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15042
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI, Legacy/Tools, Observability/Tracing
>Reporter: William Preston
>Priority: Normal
>
> Cassandra 3.11.4
> Running a query in cqlsh with TRACING ON
> Native Secondary indexes all report cardinalities as *1*.
> trace output:
> {noformat}
> Index mean cardinalities are
> country_idx:1,company_idx:1,source_idx:1,domain_idx:1. Scanning with
> country_idx.
> {noformat}
> Cassandra 2.2.x and its' predecessors reported cardinalities > 1 in cqlsh
> tracing output:
> {noformat}
> Candidate index mean cardinalities are
> CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=country, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=country_idx, indexType=COMPOSITES}
> ]}:2, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=company, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=company_idx, indexType=COMPOSITES}
> ]}:1210, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=source, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=source_idx, indexType=COMPOSITES}
> ]}:501804, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=domain, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=domain, indexType=COMPOSITES}
> ]}:325801.
> Scanning with country_idx.{noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15042) cqlsh tracing output reports all secondary "Index mean cardinalities" are 1. SASI report as -9223372036854775808
[
https://issues.apache.org/jira/browse/CASSANDRA-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Preston updated CASSANDRA-15042:
Summary: cqlsh tracing output reports all secondary "Index mean
cardinalities" are 1. SASI report as -9223372036854775808 (was: cqlsh tracing
output reports all secondary "Index mean cardinalities" are 1. )
> cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
> SASI report as -9223372036854775808
> -
>
> Key: CASSANDRA-15042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15042
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI, Legacy/Tools, Observability/Tracing
>Reporter: William Preston
>Priority: Low
>
> Cassandra 3.11.4
> Running a query in cqlsh with TRACING ON
> Native Secondary indexes all report cardinalities as *1*.
> trace output:
> {noformat}
> Index mean cardinalities are
> country_idx:1,company_idx:1,source_idx:1,domain_idx:1. Scanning with
> country_idx.
> {noformat}
> Cassandra 2.2.x and its' predecessors reported cardinalities > 1 in cqlsh
> tracing output:
> {noformat}
> Candidate index mean cardinalities are
> CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=country, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=country_idx, indexType=COMPOSITES}
> ]}:2, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=company, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=company_idx, indexType=COMPOSITES}
> ]}:1210, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=source, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=source_idx, indexType=COMPOSITES}
> ]}:501804, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=domain, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=domain, indexType=COMPOSITES}
> ]}:325801.
> Scanning with country_idx.{noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15042) cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
[
https://issues.apache.org/jira/browse/CASSANDRA-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Preston updated CASSANDRA-15042:
Component/s: Feature/SASI
> cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
> -
>
> Key: CASSANDRA-15042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15042
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI, Legacy/Tools, Observability/Tracing
>Reporter: William Preston
>Priority: Low
>
> Cassandra 3.11.4
> Running a query in cqlsh with TRACING ON
> Secondary indexes all report cardinalities as *1*.
> trace output:
> {noformat}
> Index mean cardinalities are
> country_idx:1,company_idx:1,source_idx:1,domain_idx:1. Scanning with
> country_idx.
> {noformat}
> Cassandra 2.2.x and its' predecessors reported cardinalities > 1 in cqlsh
> tracing output:
> {noformat}
> Candidate index mean cardinalities are
> CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=country, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=country_idx, indexType=COMPOSITES}
> ]}:2, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=company, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=company_idx, indexType=COMPOSITES}
> ]}:1210, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=source, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=source_idx, indexType=COMPOSITES}
> ]}:501804, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=domain, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=domain, indexType=COMPOSITES}
> ]}:325801.
> Scanning with country_idx.{noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
