[jira] [Comment Edited] (CASSANDRA-12972) Print stress-tool output header about each 30 secs.
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086891#comment-16086891 ] Vladimir Yudovin edited comment on CASSANDRA-12972 at 7/14/17 6:03 AM: --- Patch attached, actually it can be applied to 3.0 (with path change), 3.11 and trunk as well. was (Author: vovodroid): Patch attached, actually it can be applied to 3.0, 3.11 and trunk as well. > Print stress-tool output header about each 30 secs. > --- > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Stress, Tools >Reporter: Vladimir Yudovin >Assignee: Vladimir Yudovin >Priority: Minor > Labels: lhf > Attachments: 3.11.patch > > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12972) Print stress-tool output header about each 30 secs.
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Yudovin updated CASSANDRA-12972: - Summary: Print stress-tool output header about each 30 secs. (was: Print stress-tool ouput header about each 30 secs.) > Print stress-tool output header about each 30 secs. > --- > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Stress, Tools >Reporter: Vladimir Yudovin >Assignee: Vladimir Yudovin >Priority: Minor > Labels: lhf > Attachments: 3.11.patch > > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12972) Print stress-tool ouput header about each 30 secs.
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Yudovin updated CASSANDRA-12972: - Attachment: 3.11.patch > Print stress-tool ouput header about each 30 secs. > -- > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Stress, Tools >Reporter: Vladimir Yudovin >Assignee: Vladimir Yudovin >Priority: Minor > Labels: lhf > Attachments: 3.11.patch > > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12972) Print stress-tool ouput header about each 30 secs.
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Yudovin updated CASSANDRA-12972: - Attachment: (was: 3.11.patch) > Print stress-tool ouput header about each 30 secs. > -- > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Stress, Tools >Reporter: Vladimir Yudovin >Assignee: Vladimir Yudovin >Priority: Minor > Labels: lhf > Attachments: 3.11.patch > > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12972) Print stress-tool ouput header about each 30 secs.
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Yudovin updated CASSANDRA-12972: - Status: Patch Available (was: Open) > Print stress-tool ouput header about each 30 secs. > -- > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Stress, Tools >Reporter: Vladimir Yudovin >Assignee: Vladimir Yudovin >Priority: Minor > Labels: lhf > Attachments: 3.11.patch > > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12972) Print stress-tool ouput header about each 30 secs.
[ https://issues.apache.org/jira/browse/CASSANDRA-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Yudovin updated CASSANDRA-12972: - Flags: Patch Attachment: 3.11.patch Patch attached, actually it can be applied to 3.0, 3.11 and trunk as well. > Print stress-tool ouput header about each 30 secs. > -- > > Key: CASSANDRA-12972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12972 > Project: Cassandra > Issue Type: Improvement > Components: Stress, Tools >Reporter: Vladimir Yudovin >Assignee: Vladimir Yudovin >Priority: Minor > Labels: lhf > Attachments: 3.11.patch > > > Currently header with columns meaning is printed only on test beginning. If > test is long it's not handy to interpret rows with numbers only. > I propose to repeatably print headers each half-minute or so. > Patch is available, is this improvement needed? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086730#comment-16086730
]
Stefania edited comment on CASSANDRA-11223 at 7/14/17 2:11 AM:
---
bq. So, in practice changing GroupByPrefixReversed.count() has no effect.
Fine to leave it as is then, but let's add a comment explaining this, so that
people don't find it confusing later on.
bq. The limit is only used for limiting the number of rows stored in the cache
for each partition and we will only count the static row if the partition does
not have any row.
Agreed.
bq. ColumnFamily.liveCQL3RowCount() is only used by
ColumnFamilyStore::isFilterFullyCoveredBy to check if the whole partition is
cached. That we count the static row or not, the answer will be correct. We
could argue about ColumnFamily.liveCQL3RowCount() independently of its current
use,
You are right in that {{wholePartitionCached}} will be correct regardless and
we don't need to consider any other use cases that don't exist for 2.2. So it's
fine as is, I was getting mixed up with 3.0.
I've checked the 3.11 patch in depth, and the trunk patch with the GH diff:
* I think we can remove {{selectsFullPartitions}} from {{MultiPartitionPager}}.
* The javadoc of {{ReadQuery.selectsFullPartition()}} still looks wrong, I
think the return is the opposite of what the doc says. This applies to 3.0 as
well.
There is a conflict with CASSANDRA-13482 for 3.0+ so we need to rebase and
rerun CI. Afterwards, if CI is still OK, we should be able to commit.
was (Author: stefania):
bq. So, in practice changing GroupByPrefixReversed.count() has no effect.
Fine to leave it as is then, but let's add a comment explaining this, so that
people don't find it confusing later on.
bq. The limit is only used for limiting the number of rows stored in the cache
for each partition and we will only count the static row if the partition does
not have any row.
Agreed.
bq. ColumnFamily.liveCQL3RowCount() is only used by
ColumnFamilyStore::isFilterFullyCoveredBy to check if the whole partition is
cached. That we count the static row or not, the answer will be correct. We
could argue about ColumnFamily.liveCQL3RowCount() independently of its current
use,
You are right in that {{wholePartitionCached}} will be correct regardless and
we don't need to consider any other use cases that don't exist for 2.2. So it's
fine as is, I was getting mixed up with 3.0.
I've checked the 3.11 patch in depth, and the trunk patch with the GH diff:
* I think we can remove {{selectsFullPartitions}} from {{MultiPartitionPager}}.
* The javadoc of {{ReadQuery.selectsFullPartition()}} looks still wrong, I
think the return is the opposite of what the doc says. This applies to 3.0 as
well.
There is a conflict with CASSANDRA-13482 for 3.0+ so we need to rebase and
rerun CI. Afterwards, if CI is still OK, we should be able to commit.
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // <
[jira] [Commented] (CASSANDRA-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086730#comment-16086730
]
Stefania commented on CASSANDRA-11223:
--
bq. So, in practice changing GroupByPrefixReversed.count() has no effect.
Fine to leave it as is then, but let's add a comment explaining this, so that
people don't find it confusing later on.
bq. The limit is only used for limiting the number of rows stored in the cache
for each partition and we will only count the static row if the partition does
not have any row.
Agreed.
bq. ColumnFamily.liveCQL3RowCount() is only used by
ColumnFamilyStore::isFilterFullyCoveredBy to check if the whole partition is
cached. That we count the static row or not, the answer will be correct. We
could argue about ColumnFamily.liveCQL3RowCount() independently of its current
use,
You are right in that {{wholePartitionCached}} will be correct regardless and
we don't need to consider any other use cases that don't exist for 2.2. So it's
fine as is, I was getting mixed up with 3.0.
I've checked the 3.11 patch in depth, and the trunk patch with the GH diff:
* I think we can remove {{selectsFullPartitions}} from {{MultiPartitionPager}}.
* The javadoc of {{ReadQuery.selectsFullPartition()}} looks still wrong, I
think the return is the opposite of what the doc says. This applies to 3.0 as
well.
There is a conflict with CASSANDRA-13482 for 3.0+ so we need to rebase and
rerun CI. Afterwards, if CI is still OK, we should be able to commit.
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // < FAIL It returns only one
> row because the static row of partition 0 is counted and filtered out in
> SELECT statement
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13691) Fix incorrect [2.1 <— 3.0] serialization of counter cells with pre-2.1 local shards
Aleksey Yeschenko created CASSANDRA-13691:
-
Summary: Fix incorrect [2.1 <— 3.0] serialization of counter cells
with pre-2.1 local shards
Key: CASSANDRA-13691
URL: https://issues.apache.org/jira/browse/CASSANDRA-13691
Project: Cassandra
Issue Type: Bug
Components: Coordination
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Fix For: 3.0.x, 3.11.x
We stopped generating local shards in C* 2.1, after CASSANDRA-6504 (Counters
2.0). But it’s still possible to have counter cell values
around, remaining from 2.0 times, on 2.1, 3.0, 3.11, and even trunk nodes, if
they’ve never been overwritten.
In 2.1, we used two classes for two kinds of counter columns:
{{CounterCell}} class to store counters - internally as collections of
{{CounterContext}} blobs, encoding collections of (host id, count, clock) tuples
{{CounterUpdateCell}} class to represent unapplied increments - essentially a
single long value; this class was never written to commit log, memtables, or
sstables, and was only used inside {{Mutation}} object graph - in memory, and
marshalled over network in cases when counter write coordinator and counter
write leader were different nodes
3.0 got rid of {{CounterCell}} and {{CounterUpdateCell}}, among other {{Cell}}
classes. In order to represent these unapplied increments - equivalents of 2.1
{{CounterUpdateCell}} - in 3.0 we encode them as regular counter columns, with
a ‘special’ {{CounterContext}} value. I.e. a counter context with a single
local shard. We do that so that we can reuse local shard reconcile logic
(summing up) to seamlessly support counters with same names collapsing to
single increments in batches. See {{UpdateParameters.addCounter()}} method
comments
[here|https://github.com/apache/cassandra/blob/cassandra-3.0.14/src/java/org/apache/cassandra/cql3/UpdateParameters.java#L157-L171]
for details. It also assumes that nothing else can generate a counter with
local shards.
It works fine in pure 3.0 clusters, and in mixed 2.1/3.0 clusters, assuming
that there are no counters with legacy local shards remaining from 2.0 era. It
breaks down badly if there are.
{{LegacyLayout.serializeAsLegacyPartition()}} and consequently
{{LegacyCell.isCounterUpdate()}} - classes responsible for serializing and
deserialising in 2.1 format for compatibility - use the following logic to tell
if a cell of {{COUNTER}} kind is a regular final counter or an unapplied
increment:
{code}
private boolean isCounterUpdate()
{
// See UpdateParameters.addCounter() for more details on this
return isCounter() && CounterContext.instance().isLocal(value);
}
{code}
{{CounterContext.isLocal()}} method here looks at the first shard of the
collection of tuples and returns true if it’s a local one.
This method would correctly identify a cell generated by
{{UpdateParameters.addCounter()}} as a counter update and serialize it
correctly as a 2.1 {{CounterUpdateCell}}. However, it would also incorrectly
flag any regular counter cell that just so happens to have a local shard as the
first tuple of the counter context as a counter update. If a 2.1 node as a
coordinator of a read requests fetches such a value from a 3.0 node, during a
rolling upgrade, instead of the expected {{CounterCell}} object it will receive
a {{CounterUpdateCell}}, breaking all the things. In the best case scenario it
will cause an assert in {{AbstractCell.reconcileCounter()}} to be raised.
To fix the problem we must find an unambiguous way, without false positives or
false negatives, to represent and identify unapplied counter updates on 3.0
side.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
cassandra-dtest git commit: Handle index order in describe output on 2.1
Repository: cassandra-dtest
Updated Branches:
refs/heads/master cc355ff25 -> d040629b2
Handle index order in describe output on 2.1
Patch by Joel Knighton; reviewed by Philip Thompson
Project: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/commit/d040629b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/tree/d040629b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/diff/d040629b
Branch: refs/heads/master
Commit: d040629b2a71286105346c3cc637f8d1e16cf0a1
Parents: cc355ff
Author: Joel Knighton
Authored: Wed Jul 12 16:56:08 2017 -0500
Committer: Joel Knighton
Committed: Thu Jul 13 15:17:52 2017 -0500
--
cqlsh_tests/cqlsh_tests.py | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/d040629b/cqlsh_tests/cqlsh_tests.py
--
diff --git a/cqlsh_tests/cqlsh_tests.py b/cqlsh_tests/cqlsh_tests.py
index e7bc11c..418b9f7 100644
--- a/cqlsh_tests/cqlsh_tests.py
+++ b/cqlsh_tests/cqlsh_tests.py
@@ -913,6 +913,9 @@ VALUES (4, blobAsInt(0x), '', blobAsBigint(0x), 0x,
blobAsBoolean(0x), blobAsDec
return ret + "\n" + col_idx_def
def get_users_table_output(self):
+quoted_index_output = self.get_index_output('"QuotedNameIndex"',
'test', 'users', 'firstname')
+myindex_output = self.get_index_output('myindex', 'test', 'users',
'age')
+
if self.cluster.version() >= LooseVersion('3.9'):
return """
CREATE TABLE test.users (
@@ -934,8 +937,7 @@ VALUES (4, blobAsInt(0x), '', blobAsBigint(0x), 0x,
blobAsBoolean(0x), blobAsDec
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
-""" + self.get_index_output('"QuotedNameIndex"', 'test', 'users',
'firstname') \
- + "\n" + self.get_index_output('myindex', 'test', 'users',
'age')
+""" + quoted_index_output + "\n" + myindex_output
elif self.cluster.version() >= LooseVersion('3.0'):
return """
CREATE TABLE test.users (
@@ -957,8 +959,7 @@ VALUES (4, blobAsInt(0x), '', blobAsBigint(0x), 0x,
blobAsBoolean(0x), blobAsDec
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
-""" + self.get_index_output('"QuotedNameIndex"', 'test', 'users',
'firstname') \
- + "\n" + self.get_index_output('myindex', 'test', 'users',
'age')
+""" + quoted_index_output + "\n" + myindex_output
else:
return """
CREATE TABLE test.users (
@@ -979,8 +980,8 @@ VALUES (4, blobAsInt(0x), '', blobAsBigint(0x), 0x,
blobAsBoolean(0x), blobAsDec
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
-""" + self.get_index_output('QuotedNameIndex', 'test', 'users',
'firstname') \
- + "\n" + self.get_index_output('myindex', 'test', 'users',
'age')
+""" + (quoted_index_output + "\n" + myindex_output if
self.cluster.version() >= LooseVersion('2.2') else
+ myindex_output + "\n" + quoted_index_output)
def get_index_output(self, index, ks, table, col):
# a quoted index name (e.g. "FooIndex") is only correctly echoed by
DESCRIBE
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13688) Anticompaction race can leak sstables/txn
[
https://issues.apache.org/jira/browse/CASSANDRA-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086265#comment-16086265
]
Blake Eggleston commented on CASSANDRA-13688:
-
Pushed up fix for that
[here|https://github.com/bdeggleston/cassandra/commit/994f2afe3f42811b1ebf64e3f6de9c14a3b7a28d].
Just for posterity, the problem being fixed here is that {{submitIfRunning}}
will return a cancelled future if the executor is shutdown. However, we weren't
checking the returned future, we were checking the submitted task, which
shouldn't ever be cancelled.
[new utests| https://circleci.com/gh/bdeggleston/cassandra/73]
[dtests|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/125/]
> Anticompaction race can leak sstables/txn
> -
>
> Key: CASSANDRA-13688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13688
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> At the top of {{CompactionManager#performAntiCompaction}}, the parent repair
> session is loaded, if the session can't be found, a RuntimeException is
> thrown. This can happen if a participant is evicted after the IR prepare
> message is received, but before the anticompaction starts. This exception is
> thrown outside of the try/finally block that guards the sstable and lifecycle
> transaction, causing them to leak, and preventing the sstables from ever
> being removed from View.compacting.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13652) Deadlock in AbstractCommitLogSegmentManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086190#comment-16086190
]
Ariel Weisberg commented on CASSANDRA-13652:
OK, how about this?
[3.11
code|https://github.com/apache/cassandra/compare/trunk...aweisberg:13652-3.11?expand=1],
[utests|https://circleci.com/gh/aweisberg/cassandra/335],
[dtests|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/124/]
[~Fuud] are you ok with me rewriting your patch this way?
> Deadlock in AbstractCommitLogSegmentManager
> ---
>
> Key: CASSANDRA-13652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13652
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Fuud
>
> AbstractCommitLogManager uses LockSupport.(un)park incorreclty. It invokes
> unpark without checking if manager thread was parked in approriate place.
> For example, logging frameworks uses queues and queues uses ReadWriteLock's
> that uses LockSupport. Therefore AbstractCommitLogManager.wakeManager can
> wake thread inside Lock and manager thread will sleep forever at park()
> method (because unpark permit was already consumed inside lock).
> For examle stack traces:
> {code}
> "MigrationStage:1" id=412 state=WAITING
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUninterruptibly(WaitQueue.java:279)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.awaitAvailableSegment(AbstractCommitLogSegmentManager.java:263)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.advanceAllocatingFrom(AbstractCommitLogSegmentManager.java:237)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.forceRecycleAll(AbstractCommitLogSegmentManager.java:279)
> at
> org.apache.cassandra.db.commitlog.CommitLog.forceRecycleAllSegments(CommitLog.java:210)
> at org.apache.cassandra.config.Schema.dropView(Schema.java:708)
> at
> org.apache.cassandra.schema.SchemaKeyspace.lambda$updateKeyspace$23(SchemaKeyspace.java:1361)
> at
> org.apache.cassandra.schema.SchemaKeyspace$$Lambda$382/1123232162.accept(Unknown
> Source)
> at java.util.LinkedHashMap$LinkedValues.forEach(LinkedHashMap.java:608)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1080)
> at
> org.apache.cassandra.schema.SchemaKeyspace.updateKeyspace(SchemaKeyspace.java:1361)
> at
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1332)
> at
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1282)
> - locked java.lang.Class@cc38904
> at
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$LocalSessionWrapper.run(DebuggableThreadPoolExecutor.java:322)
> at
> com.ringcentral.concurrent.executors.MonitoredRunnable.run(MonitoredRunnable.java:36)
> at MON_R_MigrationStage.run(NamedRunnableFactory.java:67)
> at
> com.ringcentral.concurrent.executors.MonitoredThreadPoolExecutor$MdcAwareRunnable.run(MonitoredThreadPoolExecutor.java:114)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$61/179045.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
> "COMMIT-LOG-ALLOCATOR:1" id=80 state=WAITING
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1.runMayThrow(AbstractCommitLogSegmentManager.java:128)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$61/179045.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Solution is to use Semaphore instead of low-level LockSupport.
--
This message w
[jira] [Updated] (CASSANDRA-12617) dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-12617:
---
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[cc355ff255f6b44f6b9b77dfd18a586885e2200a|https://github.com/apache/cassandra-dtest/commit/cc355ff255f6b44f6b9b77dfd18a586885e2200a].
Just barely missed commit 5000.
> dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
> ---
>
> Key: CASSANDRA-12617
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12617
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Ariel Weisberg
> Labels: dtest, test-failure
> Fix For: 3.11.x
>
> Attachments: node1_debug.log, node1_gc.log, node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/391/testReport/offline_tools_test/TestOfflineTools/sstableofflinerelevel_test/
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/offline_tools_test.py", line 212, in
> sstableofflinerelevel_test
> self.assertGreater(max(final_levels), 1)
> File "/usr/lib/python2.7/unittest/case.py", line 942, in assertGreater
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "1 not greater than 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
cassandra-dtest git commit: dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
Repository: cassandra-dtest
Updated Branches:
refs/heads/master f1b0ba8a1 -> cc355ff25
dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
Patch by Ariel Weisberg; Reviewed by Philip Thompson for CASSANDRA-12617
Project: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/commit/cc355ff2
Tree: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/tree/cc355ff2
Diff: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/diff/cc355ff2
Branch: refs/heads/master
Commit: cc355ff255f6b44f6b9b77dfd18a586885e2200a
Parents: f1b0ba8
Author: Ariel Weisberg
Authored: Wed Jul 12 18:38:05 2017 -0400
Committer: Ariel Weisberg
Committed: Wed Jul 12 18:38:05 2017 -0400
--
offline_tools_test.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/cc355ff2/offline_tools_test.py
--
diff --git a/offline_tools_test.py b/offline_tools_test.py
index c0a0010..028027d 100644
--- a/offline_tools_test.py
+++ b/offline_tools_test.py
@@ -158,7 +158,7 @@ class TestOfflineTools(Tester):
keys = 8 * cluster.data_dir_count
node1.stress(['write', 'n={0}K'.format(keys), 'no-warmup',
'-schema', 'replication(factor=1)',
- '-col', 'n=FIXED(10)', 'SIZE=FIXED(1024)',
+ '-col', 'n=FIXED(10)', 'SIZE=FIXED(1200)',
'-rate', 'threads=8'])
node1.flush()
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12617) dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-12617:
---
Status: Ready to Commit (was: Patch Available)
> dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
> ---
>
> Key: CASSANDRA-12617
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12617
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Ariel Weisberg
> Labels: dtest, test-failure
> Fix For: 3.11.x
>
> Attachments: node1_debug.log, node1_gc.log, node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/391/testReport/offline_tools_test/TestOfflineTools/sstableofflinerelevel_test/
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/offline_tools_test.py", line 212, in
> sstableofflinerelevel_test
> self.assertGreater(max(final_levels), 1)
> File "/usr/lib/python2.7/unittest/case.py", line 942, in assertGreater
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "1 not greater than 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13688) Anticompaction race can leak sstables/txn
[
https://issues.apache.org/jira/browse/CASSANDRA-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085982#comment-16085982
]
Ariel Weisberg commented on CASSANDRA-13688:
So there is the issue here
https://github.com/apache/cassandra/compare/trunk...bdeggleston:13688?expand=1#diff-d4e3b82e9bebfd2cb466b4a30af07fa4R610
we talked about where it's using the wrong result value to decide whether to
clean up.
Maybe run the dtests, but otherwise it looks good.
> Anticompaction race can leak sstables/txn
> -
>
> Key: CASSANDRA-13688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13688
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> At the top of {{CompactionManager#performAntiCompaction}}, the parent repair
> session is loaded, if the session can't be found, a RuntimeException is
> thrown. This can happen if a participant is evicted after the IR prepare
> message is received, but before the anticompaction starts. This exception is
> thrown outside of the try/finally block that guards the sstable and lifecycle
> transaction, causing them to leak, and preventing the sstables from ever
> being removed from View.compacting.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12958) Cassandra Not Starting NullPointerException at org.apache.cassandra.db.index.SecondaryIndex.createInstance
[
https://issues.apache.org/jira/browse/CASSANDRA-12958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085846#comment-16085846
]
ZhaoYang commented on CASSANDRA-12958:
--
{code}
assert cdef.getIndexOptions() != null;
String class_name =
cdef.getIndexOptions().get(CUSTOM_INDEX_OPTION_NAME);
assert class_name != null;
{code}
{{getIndexOptions()}} is guarded by null-check in previous line. It seems like
there is concurrent modification to reset the map as null..
only place I found suspicious is in {{DropIndexStatement}}, but it shouldn't
happen during server startup before accepting client connections.
{code} //DropIndexStatement.java
CFMetaData cloned = cfm.copy();
ColumnDefinition toChange = cloned.getColumnDefinition(column.name);
assert toChange.getIndexName() != null &&
toChange.getIndexName().equals(indexName);
toChange.setIndexName(null);
toChange.setIndexType(null, null);
return cloned;
{code}
I will check if there is other cases.
> Cassandra Not Starting NullPointerException at
> org.apache.cassandra.db.index.SecondaryIndex.createInstance
> --
>
> Key: CASSANDRA-12958
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12958
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: CentOS
>Reporter: Ashraful Islam
>Assignee: ZhaoYang
> Labels: Bug, not_start, secondary_index
>
> Whole Process of this issue is given below :
> # Dropped secondary index.
> # Run Repair on cluster.
> # After 15 days later of dropping index, below configuration changed in
> Cassandra.yaml :
> index_summary_resize_interval_in_minutes: -1
> (cause While adding nodes it was taking a lot of time to redistribute index)
> # Rolling restart all nodes.
> # While adding fresh node, live nodes were going down.
> After two nodes are down, we stopped node adding process.
> This is the error Cassandra throws while restarting down nodes in System.log:
> {noformat}
> INFO [main] 2016-11-27 00:51:48,220 ColumnFamilyStore.java:382 -
> Initializing ringid.verifiedmobile
> ERROR [main] 2016-11-27 00:51:48,236 CassandraDaemon.java:651 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.db.index.SecondaryIndex.createInstance(SecondaryIndex.java:378)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.index.SecondaryIndexManager.addIndexedColumn(SecondaryIndexManager.java:279)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:407)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:354)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:535)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:511)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:342)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:270)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:93)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:256)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:529)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:638)
> [apache-cassandra-2.2.4.jar:2.2.4]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13613) Import cassandra-dtest project into it's own repository
[
https://issues.apache.org/jira/browse/CASSANDRA-13613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085822#comment-16085822
]
Michael Shuler commented on CASSANDRA-13613:
I've updated the Jenkins Job DSL seed to pull cassandra-dtest from the ASF git
mirror.
https://git1-us-west.apache.org/repos/asf?p=cassandra-builds.git;a=commitdiff;h=b0f3195e4e85b1f7dddb63823a88216cd3a024a4
> Import cassandra-dtest project into it's own repository
>
>
> Key: CASSANDRA-13613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13613
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Nate McCall
>
> Given the completion of CASSANDRA-13584, we can now import
> {{cassandra-dtest}} into ASF infrastructure. This is a top level issue for
> tracking the bits and pieces of this task.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
cassandra-builds git commit: Switch to ASF r/o git mirror for cassandra-dtest
Repository: cassandra-builds
Updated Branches:
refs/heads/master b15c7c055 -> b0f3195e4
Switch to ASF r/o git mirror for cassandra-dtest
Project: http://git-wip-us.apache.org/repos/asf/cassandra-builds/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra-builds/commit/b0f3195e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra-builds/tree/b0f3195e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra-builds/diff/b0f3195e
Branch: refs/heads/master
Commit: b0f3195e4e85b1f7dddb63823a88216cd3a024a4
Parents: b15c7c0
Author: Michael Shuler
Authored: Thu Jul 13 09:59:03 2017 -0500
Committer: Michael Shuler
Committed: Thu Jul 13 09:59:03 2017 -0500
--
jenkins-dsl/cassandra_job_dsl_seed.groovy | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra-builds/blob/b0f3195e/jenkins-dsl/cassandra_job_dsl_seed.groovy
--
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index be1c8ae..d251bf4 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -30,7 +30,7 @@ def buildsBranch = "master"
if(binding.hasVariable("CASSANDRA_BUILDS_BRANCH")) {
buildsBranch = "${CASSANDRA_BUILDS_BRANCH}"
}
-def dtestRepo = "https://github.com/riptano/cassandra-dtest.git";
+def dtestRepo = "https://git.apache.org/cassandra-dtest.git";
if(binding.hasVariable("CASSANDRA_DTEST_GIT_URL")) {
dtestRepo = "${CASSANDRA_DTEST_GIT_URL}"
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085685#comment-16085685
]
Benjamin Lerer commented on CASSANDRA-11223:
{quote}I missed it last time sorry, but we should not count the static row in
{{GroupByPrefixReversed.count()}} when {{countPartitionsWithOnlyStaticData}} is
false.{quote}
I did not change it on purpose.
The problem only affect range queries and multi-partition queries. Range
queries do not accept an {{ORDER BY}} clause. Multi-partition queries only
accept an {{ORDER BY}} clause when paging is off. The limit in this case is
used only when the rows with only static data have already been discarded. So,
in practice changing {{GroupByPrefixReversed.count()}} has no effect.
I will add a test to prove that the behavior is correct.
{quote}Are we sure it's fine to always count the static row in
{{ColumnFamily.liveCQL3RowCount()}}?{quote}
{{ColumnFamily.liveCQL3RowCount()}} is only used by
{{ColumnFamilyStore::isFilterFullyCoveredBy}} to check if the whole partition
is cached. That we count the static row or not, the answer will be correct.
We could argue about {{ColumnFamily.liveCQL3RowCount()}} independently of its
current use, but I am in favor of minimizing the changes on {{2.2}} (taken into
account that everything is different in {{3.0}}). What do you think?
{quote}Should we count static rows for the limits used by
{{RowCacheSerializer.deserialize()}}?{quote}
I think it is fine. The limit is only used for limiting the number of rows
stored in the cache for each partition and we will only count the static row if
the partition does not have any row.
{quote}I haven't checked the 3.11 and trunk patches yet, did they apply or do
they need a full review?{quote}
{{3.11}} is different due to the {{GROUP BY}} functionality.
I pushed the updated branches.
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // < FAIL It returns only one
> row because the static row of partition 0 is counted and filtered out in
> SELECT statement
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12958) Cassandra Not Starting NullPointerException at org.apache.cassandra.db.index.SecondaryIndex.createInstance
[
https://issues.apache.org/jira/browse/CASSANDRA-12958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-12958:
-
Status: Open (was: Patch Available)
> Cassandra Not Starting NullPointerException at
> org.apache.cassandra.db.index.SecondaryIndex.createInstance
> --
>
> Key: CASSANDRA-12958
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12958
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: CentOS
>Reporter: Ashraful Islam
>Assignee: ZhaoYang
> Labels: Bug, not_start, secondary_index
>
> Whole Process of this issue is given below :
> # Dropped secondary index.
> # Run Repair on cluster.
> # After 15 days later of dropping index, below configuration changed in
> Cassandra.yaml :
> index_summary_resize_interval_in_minutes: -1
> (cause While adding nodes it was taking a lot of time to redistribute index)
> # Rolling restart all nodes.
> # While adding fresh node, live nodes were going down.
> After two nodes are down, we stopped node adding process.
> This is the error Cassandra throws while restarting down nodes in System.log:
> {noformat}
> INFO [main] 2016-11-27 00:51:48,220 ColumnFamilyStore.java:382 -
> Initializing ringid.verifiedmobile
> ERROR [main] 2016-11-27 00:51:48,236 CassandraDaemon.java:651 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.db.index.SecondaryIndex.createInstance(SecondaryIndex.java:378)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.index.SecondaryIndexManager.addIndexedColumn(SecondaryIndexManager.java:279)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:407)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:354)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:535)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:511)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:342)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:270)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:93)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:256)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:529)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:638)
> [apache-cassandra-2.2.4.jar:2.2.4]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13148) Systemd support for RPM
[
https://issues.apache.org/jira/browse/CASSANDRA-13148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085526#comment-16085526
]
Murukesh Mohanan commented on CASSANDRA-13148:
--
[~hoall] Carrying over the discussion from CASSANDRA-13436, if you want to
start services when Cassandra starts *listening*, you need a slightly more
complex setup. See [this thread on the systemd-devel mailing
list|https://lists.freedesktop.org/archives/systemd-devel/2015-May/032278.html]
or this [Unix & Linux Stack Exchange
post|https://unix.stackexchange.com/q/241962/70524] (both of which
coincidentally happen to be about Cassandra!), for example. The consensus seems
to be essentially:
1. Use an {{ExecStartPost}} command which waits for the relevant port to start
listening, or
2. Use an additional service which waits for the relevant port to start
listening and depend on it
The latter is more flexible, since you can start services dependent on the
various ports (JMX, CQL, etc.) independently.
> Systemd support for RPM
> ---
>
> Key: CASSANDRA-13148
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13148
> Project: Cassandra
> Issue Type: New Feature
> Components: Packaging
>Reporter: Spiros Ioannou
>
> Since CASSANDRA-12967 will provide an RPM file, it would be greatly
> beneficial if this package included systemd startup unit configuration
> instead of the current traditional init-based, which misbehaves on
> RHEL7/CentOS7.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12996) update slf4j dependency to 1.7.21
[ https://issues.apache.org/jira/browse/CASSANDRA-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085503#comment-16085503 ] Robert Stupp commented on CASSANDRA-12996: -- [~trepik], I don't get the point why C* _bundled_ libs must use the exact same version as some distribution's package for library X and how that would not conflict with other distributions like (to stick RH's ones and not considering other distributions) CentOS or RHEL across _all_ supported versions? Don't get me wrong, but IMO this will lead to a never ending story about patching a self-contained project because some distribution X or Y or Z updated some package and in a not-overseeable list of permutations of library versions. By the way, then you're forcing users to upgrade to other major versions just because the package maintainers decided to upgrade some library. I don't see the value of this - except it may comply with an IMO artificial rule that each individual jar dependency needs to be in a separate RPM. In practice, the opposite is actually true: it causes a lot of confusion and pain to deal with these one-RPM-per-jar thing if you _need_ something from a potentially non-standard repo. > update slf4j dependency to 1.7.21 > - > > Key: CASSANDRA-12996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12996 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Tomas Repik >Assignee: Stefan Podkowinski > Fix For: 4.0 > > Attachments: cassandra-3.11.0-slf4j.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on slf4j 1.7.7, but In Fedora we have the latest upstream version > 1.7.21 It was released some time ago on April 6 2016. I attached a patch > updating Cassandra sources to depend on the newer slf4j sources. The only > actual change is the number of parameters accepted by SubstituteLogger class. > Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12958) Cassandra Not Starting NullPointerException at org.apache.cassandra.db.index.SecondaryIndex.createInstance
[
https://issues.apache.org/jira/browse/CASSANDRA-12958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085485#comment-16085485
]
Andrés de la Peña commented on CASSANDRA-12958:
---
The reported NPE throws at [this
line|https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/db/index/SecondaryIndex.java#L378],
during the instantiation of a custom index. If I'm nothing missing something
obvious, the default empty map set by the patch will avoid the NPE, but the
method will fail anyway because the empty map wouldn't contain the expected
name of the class extending {{SecondaryIndex}} to be instantiated. This makes
me suspect that one of those cases that set the
{{ColumnDefinition.indexOptions}} to {{null}} (or empty) is what is wrong, what
do you think?
Do you know why is it not affecting 2.1? Have you reproduced the problem in
such a way that we could generate a dtest for this?
> Cassandra Not Starting NullPointerException at
> org.apache.cassandra.db.index.SecondaryIndex.createInstance
> --
>
> Key: CASSANDRA-12958
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12958
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: CentOS
>Reporter: Ashraful Islam
>Assignee: ZhaoYang
> Labels: Bug, not_start, secondary_index
>
> Whole Process of this issue is given below :
> # Dropped secondary index.
> # Run Repair on cluster.
> # After 15 days later of dropping index, below configuration changed in
> Cassandra.yaml :
> index_summary_resize_interval_in_minutes: -1
> (cause While adding nodes it was taking a lot of time to redistribute index)
> # Rolling restart all nodes.
> # While adding fresh node, live nodes were going down.
> After two nodes are down, we stopped node adding process.
> This is the error Cassandra throws while restarting down nodes in System.log:
> {noformat}
> INFO [main] 2016-11-27 00:51:48,220 ColumnFamilyStore.java:382 -
> Initializing ringid.verifiedmobile
> ERROR [main] 2016-11-27 00:51:48,236 CassandraDaemon.java:651 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.db.index.SecondaryIndex.createInstance(SecondaryIndex.java:378)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.index.SecondaryIndexManager.addIndexedColumn(SecondaryIndexManager.java:279)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:407)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:354)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:535)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:511)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:342)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:270)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:93)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:256)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:529)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:638)
> [apache-cassandra-2.2.4.jar:2.2.4]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12996) update slf4j dependency to 1.7.21
[ https://issues.apache.org/jira/browse/CASSANDRA-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Repik updated CASSANDRA-12996: Attachment: cassandra-3.11.0-slf4j.patch > update slf4j dependency to 1.7.21 > - > > Key: CASSANDRA-12996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12996 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Tomas Repik >Assignee: Stefan Podkowinski > Fix For: 4.0 > > Attachments: cassandra-3.11.0-slf4j.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on slf4j 1.7.7, but In Fedora we have the latest upstream version > 1.7.21 It was released some time ago on April 6 2016. I attached a patch > updating Cassandra sources to depend on the newer slf4j sources. The only > actual change is the number of parameters accepted by SubstituteLogger class. > Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12996) update slf4j dependency to 1.7.21
[ https://issues.apache.org/jira/browse/CASSANDRA-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Repik updated CASSANDRA-12996: Status: Patch Available (was: Open) > update slf4j dependency to 1.7.21 > - > > Key: CASSANDRA-12996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12996 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Tomas Repik >Assignee: Stefan Podkowinski > Fix For: 4.0 > > Attachments: cassandra-3.11.0-slf4j.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on slf4j 1.7.7, but In Fedora we have the latest upstream version > 1.7.21 It was released some time ago on April 6 2016. I attached a patch > updating Cassandra sources to depend on the newer slf4j sources. The only > actual change is the number of parameters accepted by SubstituteLogger class. > Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12996) update slf4j dependency to 1.7.21
[ https://issues.apache.org/jira/browse/CASSANDRA-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Repik updated CASSANDRA-12996: Description: Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to the sources we need to do in order to successfully build it. Cassandra depends on slf4j 1.7.7, but In Fedora we have the latest upstream version 1.7.21 It was released some time ago on April 6 2016. I attached a patch updating Cassandra sources to depend on the newer slf4j sources. The only actual change is the number of parameters accepted by SubstituteLogger class. Please consider updating. (was: We want to include Cassandra into Fedora, and there are some tweaks to cassandra sources we need to do. The slf4j dependency is one of those tweak we gotta do. Cassandra depends on slf4j 1.7.7, but In Fedora we have the latest upstream version 1.7.21 It was released some time ago on April 6 2016. I attached a patch updating cassandra sources to depend on the newest slf4j sources. The only actual change is the number of parameters accepted by SubstituteLogger class. Please consider updating.) > update slf4j dependency to 1.7.21 > - > > Key: CASSANDRA-12996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12996 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Tomas Repik >Assignee: Stefan Podkowinski > Fix For: 4.0 > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on slf4j 1.7.7, but In Fedora we have the latest upstream version > 1.7.21 It was released some time ago on April 6 2016. I attached a patch > updating Cassandra sources to depend on the newer slf4j sources. The only > actual change is the number of parameters accepted by SubstituteLogger class. > Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12996) update slf4j dependency to 1.7.21
[ https://issues.apache.org/jira/browse/CASSANDRA-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Repik updated CASSANDRA-12996: Attachment: (was: cassandra-3.9-slf4j.patch) > update slf4j dependency to 1.7.21 > - > > Key: CASSANDRA-12996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12996 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Tomas Repik >Assignee: Stefan Podkowinski > Fix For: 4.0 > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on slf4j 1.7.7, but In Fedora we have the latest upstream version > 1.7.21 It was released some time ago on April 6 2016. I attached a patch > updating Cassandra sources to depend on the newer slf4j sources. The only > actual change is the number of parameters accepted by SubstituteLogger class. > Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Repik updated CASSANDRA-12995: Attachment: cassandra-3.11.0-hppc.patch > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement >Reporter: Tomas Repik > Labels: easyfix > Fix For: 4.0 > > Attachments: cassandra-3.11.0-hppc.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Repik updated CASSANDRA-12995: Labels: easyfix (was: ) Fix Version/s: 4.0 Status: Patch Available (was: Reopened) > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement >Reporter: Tomas Repik > Labels: easyfix > Fix For: 4.0 > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Repik updated CASSANDRA-12995: Description: Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to the sources we need to do in order to successfully build it. Cassandra depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream released even newer version 0.7.2. I attached a patch updating cassandra sources to depend on the 0.7.1 hppc sources. It should be also compatible with the newest upstream version. The only actual changes are the removal of Open infix in class names. The issue was discussed in here: https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. (was: We want to include Cassandra into Fedora, and there are some tweaks to cassandra sources we need to do. The com.carrotsearch:hppc dependency is one of those tweak we gotta do. Cassandra depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 However upstream recenlty released even newer version 0.7.2. I attached a patch updating cassandra sources to depend on the 0.7.1 hppc sources. It should be also compatible with the newest upstream version. The only actual changes are the removal of Open infix in class names. The issue was discussed in here: https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating.) > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement >Reporter: Tomas Repik > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Repik updated CASSANDRA-12995: Attachment: (was: cassandra-3.9-hppc.patch) > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement >Reporter: Tomas Repik > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Reopened] (CASSANDRA-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Repik reopened CASSANDRA-12995: - > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement >Reporter: Tomas Repik > Attachments: cassandra-3.9-hppc.patch > > > We want to include Cassandra into Fedora, and there are some tweaks to > cassandra sources we need to do. The com.carrotsearch:hppc dependency is one > of those tweak we gotta do. Cassandra depends on hppc 0.5.4, but In Fedora we > have the newer version 0.7.1 However upstream recenlty released even newer > version 0.7.2. I attached a patch updating cassandra sources to depend on the > 0.7.1 hppc sources. It should be also compatible with the newest upstream > version. The only actual changes are the removal of Open infix in class > names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085389#comment-16085389
]
Andrés de la Peña edited comment on CASSANDRA-10271 at 7/13/17 8:46 AM:
Good point. I have just added tests for descending order:
||[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:10271-3.11]||[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:10271-trunk]||
I am running another CI round just in case.
was (Author: adelapena):
Good point. I have just added test for descending order:
||[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:10271-3.11]||[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:10271-trunk]||
I am running another CI round just in case.
> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Andrés de la Peña
>Priority: Minor
> Fix For: 3.11.x, 4.x
>
> Attachments: 10271-3.x.txt, cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085389#comment-16085389
]
Andrés de la Peña commented on CASSANDRA-10271:
---
Good point. I have just added test for descending order:
||[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:10271-3.11]||[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:10271-trunk]||
I am running another CI round just in case.
> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Andrés de la Peña
>Priority: Minor
> Fix For: 3.11.x, 4.x
>
> Attachments: 10271-3.x.txt, cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13687) Abnormal heap growth and CPU usage during repair.
[ https://issues.apache.org/jira/browse/CASSANDRA-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085351#comment-16085351 ] Stanislav Vishnevskiy commented on CASSANDRA-13687: --- Just adding to this ticket. Today it finished safely again with the 12GB heap, but still used a lot of RAM. The CPU usage is still higher and repairs take about twice as long as they did on 3.0.9. > Abnormal heap growth and CPU usage during repair. > - > > Key: CASSANDRA-13687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13687 > Project: Cassandra > Issue Type: Bug >Reporter: Stanislav Vishnevskiy > Attachments: 3.0.14cpu.png, 3.0.14heap.png, 3.0.14.png, > 3.0.9heap.png, 3.0.9.png > > > We recently upgraded from 3.0.9 to 3.0.14 to get the fix from CASSANDRA-13004 > Sadly 3 out of the last 7 nights we have had to wake up due Cassandra dying > on us. We currently don't have any data to help reproduce this, but maybe > since there aren't many commits between the 2 versions it might be obvious. > Basically we trigger a parallel incremental repair from a single node every > night at 1AM. That node will sometimes start allocating a lot and keeping the > heap maxed and triggering GC. Some of these GC can last up to 2 minutes. This > effectively destroys the whole cluster due to timeouts to this node. > The only solution we currently have is to drain the node and restart the > repair, it has worked fine the second time every time. > I attached heap charts from 3.0.9 and 3.0.14 during repair. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12617) dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085334#comment-16085334
]
Philip Thompson commented on CASSANDRA-12617:
-
The ASF dtest repo was set up today, so you do have commit access now.
> dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
> ---
>
> Key: CASSANDRA-12617
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12617
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Ariel Weisberg
> Labels: dtest, test-failure
> Fix For: 3.11.x
>
> Attachments: node1_debug.log, node1_gc.log, node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/391/testReport/offline_tools_test/TestOfflineTools/sstableofflinerelevel_test/
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/offline_tools_test.py", line 212, in
> sstableofflinerelevel_test
> self.assertGreater(max(final_levels), 1)
> File "/usr/lib/python2.7/unittest/case.py", line 942, in assertGreater
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "1 not greater than 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-13690) Cqlsh not reporting correctly for the columns with same name
[
https://issues.apache.org/jira/browse/CASSANDRA-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski resolved CASSANDRA-13690.
Resolution: Duplicate
> Cqlsh not reporting correctly for the columns with same name
>
>
> Key: CASSANDRA-13690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13690
> Project: Cassandra
> Issue Type: Bug
> Environment: cqlsh 5.0.1 | Cassandra 3.11.0
>Reporter: Scott Shen
>
> cqlsh:test> create table test ( name text, tstamp timestamp, PRIMARY KEY
> (name) );
> cqlsh:test> insert into test(name, tstamp) values('aaa', 123);
> cqlsh:test> insert into test(name, tstamp) values('bbb', 321);
> cqlsh:test> select name, tstamp, name from test;
> name | tstamp | name
> --+-+--
> aaa | 1970-01-01 00:00:00.123000+ | null
> bbb | 1970-01-01 00:00:00.321000+ | null
> (2 rows)
> cqlsh:test> select name, name, tstamp from test;
> name | name| tstamp
> --+-+
> aaa | 1970-01-01 00:00:00.123000+ | null
> bbb | 1970-01-01 00:00:00.321000+ | null
> (2 rows)
> cqlsh:test>
> would expect the name columns to have the same value and the tstamp column
> not misaligned.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085310#comment-16085310
]
Benjamin Lerer commented on CASSANDRA-10271:
Thanks for the patch.
I have only a minor nit.
Could you add some tests to test descending ordering? All the valid queries use
the ascending order which is the default one. If the ordering was broken when
some columns are missing the test will not show it.
> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Andrés de la Peña
>Priority: Minor
> Fix For: 3.11.x, 4.x
>
> Attachments: 10271-3.x.txt, cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085292#comment-16085292
]
Stefania commented on CASSANDRA-11223:
--
2.2 patch:
* I missed it last time sorry, but we should not count the static row in
{{GroupByPrefixReversed.count()}} when {{countPartitionsWithOnlyStaticData}} is
false.
* Are we sure it's fine to always count the static row in
{{ColumnFamily.liveCQL3RowCount()}}?
3.0 patch:
* Should we count static rows for the limits used by
{{RowCacheSerializer.deserialize()}}?
* Nit: we still have a typo in the parameter name
{{countPartitionsWithOnlyStaticData}} for {{DataLimits.newCounter()}}.
* Nit: {{RowFilter.hasExpressionOnClusteringOrRegularColumns()}} javadoc still
has a typo repeated twice: _expressions applies_
I haven't checked the 3.11 and trunk patches yet, did they apply or do they
need a full review?
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // < FAIL It returns only one
> row because the static row of partition 0 is counted and filtered out in
> SELECT statement
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
