[jira] [Commented] (CASSANDRA-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17375228#comment-17375228 ] Berenguer Blasi commented on CASSANDRA-16774: - Hi, I have been bisecting a bit and I think recent 4.0.0 [failures|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/44/] and due to this ticket? Could sbdy familiar with it confirm please? Thx in advance > BinLog does not close chronicle queue leaving this to GC to cleanup > --- > > Key: CASSANDRA-16774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16774 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python, Tool/fql >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.1, 4.1 > > > auditlog_test.py::TestAuditlog::test_archiving_fql and > test_fql_nodetool_options fail from time to time due to the test relying on a > race condition; we do not close chronicle queue so rotation may not happen > before stopping archiver, the tests fail if rotation happens before stopping > archiver (which is done based off GC). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16720) Fix org.apache.cassandra.distributed.test.FqlReplayDDLExclusionTest.test
[
https://issues.apache.org/jira/browse/CASSANDRA-16720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17375013#comment-17375013
]
Stefan Miklosovic commented on CASSANDRA-16720:
---
I think [~dcapwell] has fixed this in CASSANDRA-16774.
> Fix org.apache.cassandra.distributed.test.FqlReplayDDLExclusionTest.test
> -
>
> Key: CASSANDRA-16720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16720
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 4.0-rc, 4.0-rc2
>
> Attachments: fqllogs.tar.bz2
>
>
> It failed a few times in Jenkins lately. Example:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0.0/12/testReport/junit/org.apache.cassandra.distributed.test/FqlReplayDDLExclusionTest/test/]
> {code:java}
> Error Message
> Expected: [[1]] Actual: []
> Stacktrace
> junit.framework.AssertionFailedError: Expected: [[1]] Actual: [] at
> org.apache.cassandra.distributed.shared.AssertUtils.assertRows(AssertUtils.java:58)
> at
> org.apache.cassandra.distributed.test.FqlReplayDDLExclusionTest.test(FqlReplayDDLExclusionTest.java:102)
> {code}
> I was also able to reproduce it locally on the latest 4.0.0 so I believe it
> is worth it to be checked.
> //CC [~stefan.miklosovic] and [~bereng] as I see you two are the only people
> who worked on that test up to now so If you have any thoughts to share, as
> usual, that will be highly appreciated :)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16760) JMXTimer exposes attributes in inconsistent time units
[ https://issues.apache.org/jira/browse/CASSANDRA-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374936#comment-17374936 ] Yifan Cai commented on CASSANDRA-16760: --- Updated the python dtest to assert the length of the RecentValues based on the Cassandra version: https://github.com/apache/cassandra-dtest/pull/149 The CI is all green now. > JMXTimer exposes attributes in inconsistent time units > -- > > Key: CASSANDRA-16760 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16760 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > JMXTimer objects are constructed with a duration time unit, which is fixed to > MICROSECONDS in the codebase. According to that, we should expect the time > values returned from the JXMTimer are in micros. > However, the time unit is inconsistent among the JMXTimer attributes. > Most of the attributes such as percentiles and mean values returned are in > micros, except Values and RecentValues. > Those 2 attributes expose the raw histogram values of the underlying Timer > (CodaHale) and the values are fixed to be based on nanos. > The inconsistency leads to confusion and mis-interpretation of the values, if > the end user is not familiar with the implementation details. One may > consider the Values and RecentValues are also in micros. > Besides the confusion, given the intention is to record the time values in > the micros resolution, we do not need to allocate 165 buckets in the > DecayingEstimatedHistogramReservoir. 165 buckets is necessary for nanos, but > not for micros. We can only allocate 90 buckets and it should reduce ~50% > memory footprint used by the Timers. > I'd like to propose an approach to scale the values being recorded in the > reservoirs used by Timers and reduce the allocation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16510) Make ReadCommand::toCQLString return valid CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-16510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374887#comment-17374887
]
Andres de la Peña commented on CASSANDRA-16510:
---
[~blerer] Thanks for the review. I have rebased the patch and CI is running
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/637/workflows/fcce57eb-db5f-4ece-9f85-6a13e733b70e]
and
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/637/workflows/ec830e8e-97c6-48af-930b-a2ba732ca2e0]),
with a few multiplexer runs for the new {{AbstractReadQueryToCQLStringTest}}.
Do we agree on applying this only to trunk?
> Make ReadCommand::toCQLString return valid CQL
> --
>
> Key: CASSANDRA-16510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16510
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Observability/Logging
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method {{ReadCommand::toCQLString}} doesn't always return queries that
> are valid CQL. For example, queries for a table without clustering columns
> always add the {{WHERE}} keyword even if there isn't a restriction following
> it:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT * FROM t;
> -- toCQLString 3.0:SELECT * FROM k.t WHERE () = () LIMIT 100
> -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE LIMIT 100
> {code}
> Also, case sensitive names and text values are not properly quoted:
> {code:java}
> CREATE TABLE "T" ("K" text, "C" text, "V" text, PRIMARY KEY("K", "C"));
> SELECT * FROM "T" WHERE "K" = 'a' AND "C" = 'b' AND "V" = 'c' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.T WHERE K = a AND V = c AND
> (C) = (b) LIMIT 100
> {code}
> Similar problems can be found on selections of collection items:
> {code:java}
> CREATE TABLE k.t (k int, c int, s set, m map, PRIMARY
> KEY(k, c));
> SELECT s['a'] FROM t;
> -- toCQLString trunk: SELECT s[a] FROM k.t LIMIT 100
> SELECT * FROM t WHERE m['a'] = 'b' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
> {code}
> Some similar problems with more impact than the described above are already
> being addressed in CASSANDRA-16483 and CASSANDRA-16479.
> I think we should add more exhaustive JUnit tests for
> {{ReadCommand::toCQLString}}, making sure that its output is parseable and
> equivalent to the original command. Also, we probably should make sure that
> we have {{toCQLString}} methods in all the query components that are used by
> {{ReadCommand::toCQLString}} (selection, filters, etc.). This way we can use
> them instead of generic {{toString}} methods, making it clear that they are
> supposed to return valid CQL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374817#comment-17374817
]
Benjamin Lerer commented on CASSANDRA-15234:
Changing the status to {{IN PROGRESS}} as the current patch need to update once
we agree on the expected outcome.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15234:
---
Status: In Progress (was: Patch Available)
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374800#comment-17374800
]
Benjamin Lerer commented on CASSANDRA-15241:
[~cnlwsu] CASSANDRA-16510 is ensuring that {{ReadCommand::toCQLString}} is
returning valid CQL strings. I am not sure of how much those changes will
impact your patch but you might need to rebase it once CASSANDRA-16510 has been
committed.
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16510) Make ReadCommand::toCQLString return valid CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-16510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16510:
---
Status: Ready to Commit (was: Review In Progress)
> Make ReadCommand::toCQLString return valid CQL
> --
>
> Key: CASSANDRA-16510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16510
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Observability/Logging
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method {{ReadCommand::toCQLString}} doesn't always return queries that
> are valid CQL. For example, queries for a table without clustering columns
> always add the {{WHERE}} keyword even if there isn't a restriction following
> it:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT * FROM t;
> -- toCQLString 3.0:SELECT * FROM k.t WHERE () = () LIMIT 100
> -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE LIMIT 100
> {code}
> Also, case sensitive names and text values are not properly quoted:
> {code:java}
> CREATE TABLE "T" ("K" text, "C" text, "V" text, PRIMARY KEY("K", "C"));
> SELECT * FROM "T" WHERE "K" = 'a' AND "C" = 'b' AND "V" = 'c' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.T WHERE K = a AND V = c AND
> (C) = (b) LIMIT 100
> {code}
> Similar problems can be found on selections of collection items:
> {code:java}
> CREATE TABLE k.t (k int, c int, s set, m map, PRIMARY
> KEY(k, c));
> SELECT s['a'] FROM t;
> -- toCQLString trunk: SELECT s[a] FROM k.t LIMIT 100
> SELECT * FROM t WHERE m['a'] = 'b' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
> {code}
> Some similar problems with more impact than the described above are already
> being addressed in CASSANDRA-16483 and CASSANDRA-16479.
> I think we should add more exhaustive JUnit tests for
> {{ReadCommand::toCQLString}}, making sure that its output is parseable and
> equivalent to the original command. Also, we probably should make sure that
> we have {{toCQLString}} methods in all the query components that are used by
> {{ReadCommand::toCQLString}} (selection, filters, etc.). This way we can use
> them instead of generic {{toString}} methods, making it clear that they are
> supposed to return valid CQL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16510) Make ReadCommand::toCQLString return valid CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-16510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374797#comment-17374797
]
Benjamin Lerer commented on CASSANDRA-16510:
+1. Thanks for the extensive tests :-)
> Make ReadCommand::toCQLString return valid CQL
> --
>
> Key: CASSANDRA-16510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16510
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Observability/Logging
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method {{ReadCommand::toCQLString}} doesn't always return queries that
> are valid CQL. For example, queries for a table without clustering columns
> always add the {{WHERE}} keyword even if there isn't a restriction following
> it:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT * FROM t;
> -- toCQLString 3.0:SELECT * FROM k.t WHERE () = () LIMIT 100
> -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE LIMIT 100
> {code}
> Also, case sensitive names and text values are not properly quoted:
> {code:java}
> CREATE TABLE "T" ("K" text, "C" text, "V" text, PRIMARY KEY("K", "C"));
> SELECT * FROM "T" WHERE "K" = 'a' AND "C" = 'b' AND "V" = 'c' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.T WHERE K = a AND V = c AND
> (C) = (b) LIMIT 100
> {code}
> Similar problems can be found on selections of collection items:
> {code:java}
> CREATE TABLE k.t (k int, c int, s set, m map, PRIMARY
> KEY(k, c));
> SELECT s['a'] FROM t;
> -- toCQLString trunk: SELECT s[a] FROM k.t LIMIT 100
> SELECT * FROM t WHERE m['a'] = 'b' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
> {code}
> Some similar problems with more impact than the described above are already
> being addressed in CASSANDRA-16483 and CASSANDRA-16479.
> I think we should add more exhaustive JUnit tests for
> {{ReadCommand::toCQLString}}, making sure that its output is parseable and
> equivalent to the original command. Also, we probably should make sure that
> we have {{toCQLString}} methods in all the query components that are used by
> {{ReadCommand::toCQLString}} (selection, filters, etc.). This way we can use
> them instead of generic {{toString}} methods, making it clear that they are
> supposed to return valid CQL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16510) Make ReadCommand::toCQLString return valid CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-16510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16510:
---
Status: Review In Progress (was: Patch Available)
> Make ReadCommand::toCQLString return valid CQL
> --
>
> Key: CASSANDRA-16510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16510
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Observability/Logging
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method {{ReadCommand::toCQLString}} doesn't always return queries that
> are valid CQL. For example, queries for a table without clustering columns
> always add the {{WHERE}} keyword even if there isn't a restriction following
> it:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT * FROM t;
> -- toCQLString 3.0:SELECT * FROM k.t WHERE () = () LIMIT 100
> -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE LIMIT 100
> {code}
> Also, case sensitive names and text values are not properly quoted:
> {code:java}
> CREATE TABLE "T" ("K" text, "C" text, "V" text, PRIMARY KEY("K", "C"));
> SELECT * FROM "T" WHERE "K" = 'a' AND "C" = 'b' AND "V" = 'c' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.T WHERE K = a AND V = c AND
> (C) = (b) LIMIT 100
> {code}
> Similar problems can be found on selections of collection items:
> {code:java}
> CREATE TABLE k.t (k int, c int, s set, m map, PRIMARY
> KEY(k, c));
> SELECT s['a'] FROM t;
> -- toCQLString trunk: SELECT s[a] FROM k.t LIMIT 100
> SELECT * FROM t WHERE m['a'] = 'b' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
> {code}
> Some similar problems with more impact than the described above are already
> being addressed in CASSANDRA-16483 and CASSANDRA-16479.
> I think we should add more exhaustive JUnit tests for
> {{ReadCommand::toCQLString}}, making sure that its output is parseable and
> equivalent to the original command. Also, we probably should make sure that
> we have {{toCQLString}} methods in all the query components that are used by
> {{ReadCommand::toCQLString}} (selection, filters, etc.). This way we can use
> them instead of generic {{toString}} methods, making it clear that they are
> supposed to return valid CQL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16510) Make ReadCommand::toCQLString return valid CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-16510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16510:
---
Reviewers: Benjamin Lerer
> Make ReadCommand::toCQLString return valid CQL
> --
>
> Key: CASSANDRA-16510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16510
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Observability/Logging
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method {{ReadCommand::toCQLString}} doesn't always return queries that
> are valid CQL. For example, queries for a table without clustering columns
> always add the {{WHERE}} keyword even if there isn't a restriction following
> it:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT * FROM t;
> -- toCQLString 3.0:SELECT * FROM k.t WHERE () = () LIMIT 100
> -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE LIMIT 100
> {code}
> Also, case sensitive names and text values are not properly quoted:
> {code:java}
> CREATE TABLE "T" ("K" text, "C" text, "V" text, PRIMARY KEY("K", "C"));
> SELECT * FROM "T" WHERE "K" = 'a' AND "C" = 'b' AND "V" = 'c' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.T WHERE K = a AND V = c AND
> (C) = (b) LIMIT 100
> {code}
> Similar problems can be found on selections of collection items:
> {code:java}
> CREATE TABLE k.t (k int, c int, s set, m map, PRIMARY
> KEY(k, c));
> SELECT s['a'] FROM t;
> -- toCQLString trunk: SELECT s[a] FROM k.t LIMIT 100
> SELECT * FROM t WHERE m['a'] = 'b' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
> {code}
> Some similar problems with more impact than the described above are already
> being addressed in CASSANDRA-16483 and CASSANDRA-16479.
> I think we should add more exhaustive JUnit tests for
> {{ReadCommand::toCQLString}}, making sure that its output is parseable and
> equivalent to the original command. Also, we probably should make sure that
> we have {{toCQLString}} methods in all the query components that are used by
> {{ReadCommand::toCQLString}} (selection, filters, etc.). This way we can use
> them instead of generic {{toString}} methods, making it clear that they are
> supposed to return valid CQL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16787) Copy from csv file with duration type fields fails to import
Brijesh Dungarakoti created CASSANDRA-16787:
---
Summary: Copy from csv file with duration type fields fails to
import
Key: CASSANDRA-16787
URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
Project: Cassandra
Issue Type: Bug
Components: Tool/cqlsh
Reporter: Brijesh Dungarakoti
Assignee: Benjamin Lerer
Attachments: error_cassandra_copy_from_1.JPG,
error_cassandra_copy_from_2.JPG
Getting error:
_cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv' WITH
HEADER = FALSE AND NULL='null';_
_Using 3 child processes_
_Starting copy of users.user_credentials_by_email with columns [email,
la_duration]._
_Failed to make batch statement: Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.)_
_Failed to import 1 rows: TypeError - Received an argument of invalid type for
column "la_duration". Expected: , Got:
; (DurationType arguments must be a Duration.), given up without
retries_
_Failed to process 1 rows; failed rows written to
import_users_user_credentials_by_email.err_
_Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s_
_0 rows imported from 1 files in 0.431 seconds (0 skipped)._
*To Reproduce:*
CREATE KEYSPACE users WITH replication = \{'class': 'NetworkTopologyStrategy',
'datacenter1': '1'} AND durable_writes = true;
CREATE TABLE users.user_credentials_by_email (
email text,
la_duration duration,
PRIMARY KEY(email)
);
create users.csv file with:
l...@la.com,8m26s482ms
Run:
COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
HEADER = FALSE AND NULL='null';
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16777) Flaky ViewTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16777: Since Version: 4.0 Source Control Link: https://github.com/apache/cassandra/commit/6d16a531b1b4b3d63dfa182cd8484fb4d9e93c86 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Flaky ViewTest > -- > > Key: CASSANDRA-16777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16777 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc3, 4.0, 4.0.x > > > ViewTest has been > [failing|https://ci-cassandra.apache.org/job/Cassandra-4.0/113/testReport/junit/org.apache.cassandra.cql3/ViewTest/testFrozenCollectionsWithComplicatedInnerType/] > every now and then on the 4.0 line. Being so close to having 0 faky failures > I want to scratch that itch so I propose we split it like we did with > ViewComplexTest. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (cc3d59a -> f74f5d0)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from cc3d59a Merge branch 'cassandra-4.0' into trunk new 6d16a53 Flaky ViewTest patch by Berenguer Blasi; reviewed by Andres de la Peña for CASSANDRA-16777 new ba0f622 Merge branch 'cassandra-4.0.0' into cassandra-4.0 new f74f5d0 Merge branch 'cassandra-4.0' into trunk The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../apache/cassandra/cql3/ViewAbstractTest.java| 108 +++ .../unit/org/apache/cassandra/cql3/ViewPKTest.java | 461 +++ .../org/apache/cassandra/cql3/ViewRangesTest.java | 197 + test/unit/org/apache/cassandra/cql3/ViewTest.java | 917 + .../org/apache/cassandra/cql3/ViewTimesTest.java | 300 +++ 5 files changed, 1076 insertions(+), 907 deletions(-) create mode 100644 test/unit/org/apache/cassandra/cql3/ViewAbstractTest.java create mode 100644 test/unit/org/apache/cassandra/cql3/ViewPKTest.java create mode 100644 test/unit/org/apache/cassandra/cql3/ViewRangesTest.java create mode 100644 test/unit/org/apache/cassandra/cql3/ViewTimesTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0.0 updated (d13bef9 -> 6d16a53)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-4.0.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d13bef9 Increment version to 4.0-rc3 new 6d16a53 Flaky ViewTest patch by Berenguer Blasi; reviewed by Andres de la Peña for CASSANDRA-16777 The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../apache/cassandra/cql3/ViewAbstractTest.java| 108 +++ .../unit/org/apache/cassandra/cql3/ViewPKTest.java | 461 +++ .../org/apache/cassandra/cql3/ViewRangesTest.java | 197 + test/unit/org/apache/cassandra/cql3/ViewTest.java | 917 + .../org/apache/cassandra/cql3/ViewTimesTest.java | 300 +++ 5 files changed, 1076 insertions(+), 907 deletions(-) create mode 100644 test/unit/org/apache/cassandra/cql3/ViewAbstractTest.java create mode 100644 test/unit/org/apache/cassandra/cql3/ViewPKTest.java create mode 100644 test/unit/org/apache/cassandra/cql3/ViewRangesTest.java create mode 100644 test/unit/org/apache/cassandra/cql3/ViewTimesTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. bereng pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit f74f5d001ef0f3cd502dca6111c018fca3ca12b5 Merge: cc3d59a ba0f622 Author: Bereng AuthorDate: Mon Jul 5 11:11:38 2021 +0200 Merge branch 'cassandra-4.0' into trunk .../apache/cassandra/cql3/ViewAbstractTest.java| 108 +++ .../unit/org/apache/cassandra/cql3/ViewPKTest.java | 461 +++ .../org/apache/cassandra/cql3/ViewRangesTest.java | 197 + test/unit/org/apache/cassandra/cql3/ViewTest.java | 917 + .../org/apache/cassandra/cql3/ViewTimesTest.java | 300 +++ 5 files changed, 1076 insertions(+), 907 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated: Flaky ViewTest patch by Berenguer Blasi; reviewed by Andres de la Peña for CASSANDRA-16777
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-4.0 by this push:
new 6d16a53 Flaky ViewTest patch by Berenguer Blasi; reviewed by Andres
de la Peña for CASSANDRA-16777
new ba0f622 Merge branch 'cassandra-4.0.0' into cassandra-4.0
6d16a53 is described below
commit 6d16a531b1b4b3d63dfa182cd8484fb4d9e93c86
Author: Bereng
AuthorDate: Thu Jul 1 07:52:46 2021 +0200
Flaky ViewTest
patch by Berenguer Blasi; reviewed by Andres de la Peña for CASSANDRA-16777
---
.../apache/cassandra/cql3/ViewAbstractTest.java| 108 +++
.../unit/org/apache/cassandra/cql3/ViewPKTest.java | 461 +++
.../org/apache/cassandra/cql3/ViewRangesTest.java | 197 +
test/unit/org/apache/cassandra/cql3/ViewTest.java | 917 +
.../org/apache/cassandra/cql3/ViewTimesTest.java | 300 +++
5 files changed, 1076 insertions(+), 907 deletions(-)
diff --git a/test/unit/org/apache/cassandra/cql3/ViewAbstractTest.java
b/test/unit/org/apache/cassandra/cql3/ViewAbstractTest.java
new file mode 100644
index 000..bbd21dc
--- /dev/null
+++ b/test/unit/org/apache/cassandra/cql3/ViewAbstractTest.java
@@ -0,0 +1,108 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.cql3;
+
+import java.util.ArrayList;
+import java.util.List;
+import java.util.concurrent.TimeUnit;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.Ignore;
+
+import com.datastax.driver.core.exceptions.OperationTimedOutException;
+import org.apache.cassandra.concurrent.Stage;
+import org.awaitility.Awaitility;
+
+@Ignore
+public abstract class ViewAbstractTest extends CQLTester
+{
+protected final List views = new ArrayList<>();
+
+@BeforeClass
+public static void startup()
+{
+requireNetwork();
+}
+
+@Before
+public void begin()
+{
+begin(views);
+}
+
+private static void begin(List views)
+{
+views.clear();
+}
+
+@After
+public void end() throws Throwable
+{
+end(views, this);
+}
+
+private static void end(List views, CQLTester tester) throws
Throwable
+{
+for (String viewName : views)
+tester.executeNet("DROP MATERIALIZED VIEW " + viewName);
+}
+
+protected void createView(String name, String query) throws Throwable
+{
+createView(name, query, views, this);
+}
+
+private static void createView(String name, String query, List
views, CQLTester tester) throws Throwable
+{
+try
+{
+tester.executeNet(String.format(query, name));
+// If exception is thrown, the view will not be added to the list;
since it shouldn't have been created, this is
+// the desired behavior
+views.add(name);
+}
+catch (OperationTimedOutException ex)
+{
+// ... except for timeout, when we actually do not know whether
the view was created or not
+views.add(name);
+throw ex;
+}
+}
+
+protected void updateView(String query, Object... params) throws Throwable
+{
+updateView(query, this, params);
+}
+
+private static void updateView(String query, CQLTester tester, Object...
params) throws Throwable
+{
+tester.executeNet(query, params);
+waitForViewMutations();
+}
+
+protected static void waitForViewMutations()
+{
+Awaitility.await()
+ .atMost(5, TimeUnit.MINUTES)
+ .until(() ->
Stage.VIEW_MUTATION.executor().getPendingTaskCount() == 0
+ &&
Stage.VIEW_MUTATION.executor().getActiveTaskCount() == 0);
+}
+}
diff --git a/test/unit/org/apache/cassandra/cql3/ViewPKTest.java
b/test/unit/org/apache/cassandra/cql3/ViewPKTest.java
new file mode 100644
index 000..06664cb
--- /dev/null
+++ b/test/unit/org/apache/cassandra/cql3/ViewPKTest.java
@@ -0,0 +1,461 @@
+/*
+ * Licensed to the Apache Software Foundation
[jira] [Commented] (CASSANDRA-11671) Remove check on gossip status from DynamicEndpointSnitch::updateScores
[ https://issues.apache.org/jira/browse/CASSANDRA-11671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374664#comment-17374664 ] Benjamin Lerer commented on CASSANDRA-11671: +1 > Remove check on gossip status from DynamicEndpointSnitch::updateScores > -- > > Key: CASSANDRA-11671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11671 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination >Reporter: Sam Tunnicliffe >Assignee: Artsiom Yudovin >Priority: Low > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > It seems that historically there were initialization ordering issues which > affected DES and StorageService (CASSANDRA-1756) and so a condition was added > to DES::updateScores() to ensure that SS had finished setup. In fact, the > check was actually testing whether gossip was active or not. CASSANDRA-10134 > preserved this behaviour, but it seems likely that the check can be removed > from DES completely now. If not, it can at least be switched to use > SS::isInitialized() which post CASSANDRA-10134 actually reports what it's > name suggests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11671) Remove check on gossip status from DynamicEndpointSnitch::updateScores
[ https://issues.apache.org/jira/browse/CASSANDRA-11671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-11671: --- Status: Ready to Commit (was: Review In Progress) > Remove check on gossip status from DynamicEndpointSnitch::updateScores > -- > > Key: CASSANDRA-11671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11671 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination >Reporter: Sam Tunnicliffe >Assignee: Artsiom Yudovin >Priority: Low > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > It seems that historically there were initialization ordering issues which > affected DES and StorageService (CASSANDRA-1756) and so a condition was added > to DES::updateScores() to ensure that SS had finished setup. In fact, the > check was actually testing whether gossip was active or not. CASSANDRA-10134 > preserved this behaviour, but it seems likely that the check can be removed > from DES completely now. If not, it can at least be switched to use > SS::isInitialized() which post CASSANDRA-10134 actually reports what it's > name suggests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11671) Remove check on gossip status from DynamicEndpointSnitch::updateScores
[ https://issues.apache.org/jira/browse/CASSANDRA-11671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-11671: --- Reviewers: Benjamin Lerer, Brandon Williams (was: Brandon Williams) > Remove check on gossip status from DynamicEndpointSnitch::updateScores > -- > > Key: CASSANDRA-11671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11671 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination >Reporter: Sam Tunnicliffe >Assignee: Artsiom Yudovin >Priority: Low > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > It seems that historically there were initialization ordering issues which > affected DES and StorageService (CASSANDRA-1756) and so a condition was added > to DES::updateScores() to ensure that SS had finished setup. In fact, the > check was actually testing whether gossip was active or not. CASSANDRA-10134 > preserved this behaviour, but it seems likely that the check can be removed > from DES completely now. If not, it can at least be switched to use > SS::isInitialized() which post CASSANDRA-10134 actually reports what it's > name suggests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13720) Clean up repair code
[ https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-13720: --- Status: In Progress (was: Patch Available) > Clean up repair code > > > Key: CASSANDRA-13720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13720 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Simon Zhou >Assignee: Simon Zhou >Priority: Normal > Fix For: 4.x > > > Lots of unused code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13720) Clean up repair code
[
https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374659#comment-17374659
]
Benjamin Lerer edited comment on CASSANDRA-13720 at 7/5/21, 8:22 AM:
-
{quote}wow, it's a long time{quote}
Sorry, for that. :(
We are working on some solutions to try to avoid that kind of problem in the
future. Right now we are going through our backlog of {{Patch Available}}
tickets.
I will just put the ticket {{In Progress}} so that we know you are working on
it.
was (Author: blerer):
{quote}wow, it's a long time{quote}
Sorry, for that. :(
We are working on some solutions to try to avoid that kind of problem in the
future. Right now we are going through out backlog of {{Patch Available}}
tickets.
I will just put the ticket {{In Progress}} so that we know you are working on
it.
> Clean up repair code
>
>
> Key: CASSANDRA-13720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13720
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Normal
> Fix For: 4.x
>
>
> Lots of unused code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13720) Clean up repair code
[
https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374659#comment-17374659
]
Benjamin Lerer edited comment on CASSANDRA-13720 at 7/5/21, 8:21 AM:
-
{quote}wow, it's a long time{quote}
Sorry, for that. :(
We are working on some solutions to try to avoid that kind of problem in the
future. Right now we are going through out backlog of {{Patch Available}}
tickets.
I will just put the ticket {{In Progress}} so that we know you are working on
it.
was (Author: blerer):
{quote}wow, it's a long time{quote}
Sorry, for that. :(
We are working on some solutions to try to avoid that kind of problem in the
future. Right now we are going through out backlog of {{Patch Available}}
tickets.
> Clean up repair code
>
>
> Key: CASSANDRA-13720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13720
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Normal
> Fix For: 4.x
>
>
> Lots of unused code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13720) Clean up repair code
[
https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374659#comment-17374659
]
Benjamin Lerer commented on CASSANDRA-13720:
{quote}wow, it's a long time{quote}
Sorry, for that. :(
We are working on some solutions to try to avoid that kind of problem in the
future. Right now we are going through out backlog of {{Patch Available}}
tickets.
> Clean up repair code
>
>
> Key: CASSANDRA-13720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13720
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Normal
> Fix For: 4.x
>
>
> Lots of unused code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16703: --- Status: Ready to Commit (was: Review In Progress) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374651#comment-17374651 ] Benjamin Lerer commented on CASSANDRA-16703: +1 > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16703: --- Reviewers: Benjamin Lerer, Brandon Williams, Francisco Bento (was: Brandon Williams, Francisco Bento) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
