[jira] [Commented] (CASSANDRA-4670) LeveledCompaction destroys secondary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459463#comment-13459463
]
Roland Gude commented on CASSANDRA-4670:
after restarting the cluster in debug mode the issue seems to have vanished,
but unfortunately i have witnessed the same issue on another cluster using
SizeTieredCompaction (It worked for roughly two days until it showed the issue).
LeveledCompaction destroys secondary indexes
Key: CASSANDRA-4670
URL: https://issues.apache.org/jira/browse/CASSANDRA-4670
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.4, 1.1.5
Reporter: Roland Gude
When LeveledCompactionStrategy is active on a ColumnFamily with an Index
enabled on TTL Columns, the Index is not working correctly, because the
compaction is throwing away index data very aggressively.
Steps to reproduce:
create a cluster with a columnfamily with an indexed column and leveled
compaction:
create column family CorruptIndex
with column_type = 'Standard'
and comparator = 'TimeUUIDType'
and default_validation_class = 'BytesType'
and key_validation_class = 'BytesType'
and read_repair_chance = 0.5
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 4
and max_compaction_threshold = 32
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'NONE'
and column_metadata = [
{column_name : '0003--1000--',
validation_class : BytesType,
index_name : 'idx_corrupt',
index_type : 0}];
in that cf insert expiring data (expiration date should be in the far future
for the sake of this test)
query the data by index:
get CorruptIndex where 0003--1000--=utf8(‘value’)
see results (should be correct for some time)
wait for leveled compaction to compact the index
query the data by index:
get CorruptIndex where 0003--1000--=utf8(‘value’)
see results (are empty)
trigger rebuild index via nodetool
query the data by index:
get CorruptIndex where 0003--1000--=utf8(‘value’)
should be corretc again
wait for leveled compaction to compact the index
query the data by index:
get CorruptIndex where 0003--1000--=utf8(‘value’)
see results (are empty)
repeat until bored
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4689) Log error when using IN together with ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459515#comment-13459515
]
Sylvain Lebresne commented on CASSANDRA-4689:
-
+1
Log error when using IN together with ORDER BY
--
Key: CASSANDRA-4689
URL: https://issues.apache.org/jira/browse/CASSANDRA-4689
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.5
Environment: built from source on cassandra-1.1
(b43cc362aa568a46bc53e545c68518b0bd350b76)
os: ubuntu
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4689.patch
{code}
$ bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.5-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.32.0]
Use HELP for help.
cqlsh use ks;
cqlsh:ks drop TABLE test;
cqlsh:ks CREATE TABLE test (my_id varchar, time_id uuid, value int, PRIMARY
KEY (my_id, time_id));
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key1', 1, 1);
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key2', 2, 2);
cqlsh:ks select * from test where my_id in('key1', 'key2') order by time_id;
TSocket read 0 bytes
{code}
The log shows this:
{code}
ERROR [Thrift:5] 2012-09-19 08:44:59,859 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.IllegalArgumentException: Column time_id wasn't found in select
clause.
at
org.apache.cassandra.cql3.statements.SelectStatement.getColumnPositionInSelect(SelectStatement.java:866)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:836)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:807)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1242)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
NOTE: This issue appears similar to
https://issues.apache.org/jira/browse/CASSANDRA-4612 from the user
perspective, even though 4612 was verified as fixed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: fix error when using ORDER BY with extended selections patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4689
Updated Branches:
refs/heads/cassandra-1.1 c565b64fe - a4c397b49
fix error when using ORDER BY with extended selections
patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4689
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a4c397b4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a4c397b4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a4c397b4
Branch: refs/heads/cassandra-1.1
Commit: a4c397b49c08f543fd42ddc21a6312bce5571947
Parents: c565b64
Author: Pavel Yaskevich xe...@apache.org
Authored: Thu Sep 20 01:11:23 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Thu Sep 20 16:39:22 2012 +0300
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/SelectStatement.java | 15 ---
2 files changed, 9 insertions(+), 7 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4c397b4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0530134..65ba88f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -4,6 +4,7 @@
* fix assumption error in CLI when updating/describing keyspace
(CASSANDRA-4322)
* Adds offline sstablescrub to debian packaging (CASSANDRA-4642)
* Automatic fixing of overlapping leveled sstables (CASSANDRA-4644)
+ * fix error when using ORDER BY with extended selections (CASSANDRA-4689)
1.1.5
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4c397b4/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index a4d64cf..4a013b1 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -804,7 +804,7 @@ public class SelectStatement implements CQLStatement
}
}
-orderResults(cqlRows);
+orderResults(selection, cqlRows);
// Internal calls always return columns in the comparator order, even
when reverse was set
if (isReversed)
@@ -819,7 +819,7 @@ public class SelectStatement implements CQLStatement
/**
* Orders results when multiple keys are selected (using IN)
*/
-private void orderResults(ListCqlRow cqlRows)
+private void orderResults(ListPairCFDefinition.Name, Selector
selection, ListCqlRow cqlRows)
{
// There is nothing to do if
// a. there are no results,
@@ -828,12 +828,13 @@ public class SelectStatement implements CQLStatement
if (cqlRows.isEmpty() || parameters.orderings.isEmpty() ||
keyRestriction == null || keyRestriction.eqValues.size() 2)
return;
+
// optimization when only *one* order condition was given
// because there is no point of using composite comparator if there is
only one order condition
if (parameters.orderings.size() == 1)
{
CFDefinition.Name ordering =
cfDef.get(parameters.orderings.keySet().iterator().next());
-Collections.sort(cqlRows, new
SingleColumnComparator(getColumnPositionInSelect(ordering), ordering.type));
+Collections.sort(cqlRows, new
SingleColumnComparator(getColumnPositionInSelect(selection, ordering),
ordering.type));
return;
}
@@ -848,18 +849,18 @@ public class SelectStatement implements CQLStatement
{
CFDefinition.Name orderingColumn = cfDef.get(identifier);
types.add(orderingColumn.type);
-positions[idx++] = getColumnPositionInSelect(orderingColumn);
+positions[idx++] = getColumnPositionInSelect(selection,
orderingColumn);
}
Collections.sort(cqlRows, new CompositeComparator(types, positions));
}
// determine position of column in the select clause
-private int getColumnPositionInSelect(CFDefinition.Name columnName)
+private int getColumnPositionInSelect(ListPairCFDefinition.Name,
Selector selection, CFDefinition.Name columnName)
{
-for (int i = 0; i selectedNames.size(); i++)
+for (int i = 0; i selection.size(); i++)
{
-if (selectedNames.get(i).left.equals(columnName))
+if (selection.get(i).left.equals(columnName))
return i;
}
[1/2] git commit: merge from 1.1
Updated Branches:
refs/heads/trunk 0ada18462 - ae91d17d3
merge from 1.1
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ae91d17d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ae91d17d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ae91d17d
Branch: refs/heads/trunk
Commit: ae91d17d397ba2b5952c74b4f975dea9c3b72f32
Parents: 0ada184 a4c397b
Author: Pavel Yaskevich xe...@apache.org
Authored: Thu Sep 20 16:57:21 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Thu Sep 20 16:57:21 2012 +0300
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/SelectStatement.java | 15 ---
2 files changed, 9 insertions(+), 7 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae91d17d/CHANGES.txt
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae91d17d/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index 26086ad,4a013b1..4ae9e75
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@@ -804,21 -819,22 +804,22 @@@ public class SelectStatement implement
/**
* Orders results when multiple keys are selected (using IN)
*/
- private void orderResults(ResultSet cqlRows)
-private void orderResults(ListPairCFDefinition.Name, Selector
selection, ListCqlRow cqlRows)
++private void orderResults(ListPairCFDefinition.Name, Selector
selection, ResultSet cqlRows)
{
// There is nothing to do if
// a. there are no results,
// b. no ordering information where given,
-// c. key restriction wasn't given or it's not an IN expression
-if (cqlRows.isEmpty() || parameters.orderings.isEmpty() ||
keyRestriction == null || keyRestriction.eqValues.size() 2)
+// c. key restriction is a Range or not an IN expression
+if (cqlRows.size() == 0 || parameters.orderings.isEmpty() ||
isKeyRange || !keyIsInRelation)
return;
+
// optimization when only *one* order condition was given
// because there is no point of using composite comparator if there
is only one order condition
if (parameters.orderings.size() == 1)
{
CFDefinition.Name ordering =
cfDef.get(parameters.orderings.keySet().iterator().next());
- Collections.sort(cqlRows.rows, new
SingleColumnComparator(getColumnPositionInSelect(ordering), ordering.type));
-Collections.sort(cqlRows, new
SingleColumnComparator(getColumnPositionInSelect(selection, ordering),
ordering.type));
++Collections.sort(cqlRows.rows, new
SingleColumnComparator(getColumnPositionInSelect(selection, ordering),
ordering.type));
return;
}
@@@ -833,10 -849,10 +834,10 @@@
{
CFDefinition.Name orderingColumn = cfDef.get(identifier);
types.add(orderingColumn.type);
- positions[idx++] = getColumnPositionInSelect(orderingColumn);
+ positions[idx++] = getColumnPositionInSelect(selection,
orderingColumn);
}
-Collections.sort(cqlRows, new CompositeComparator(types, positions));
+Collections.sort(cqlRows.rows, new CompositeComparator(types,
positions));
}
// determine position of column in the select clause
[2/2] git commit: fix error when using ORDER BY with extended selections patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4689
fix error when using ORDER BY with extended selections
patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4689
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a4c397b4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a4c397b4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a4c397b4
Branch: refs/heads/trunk
Commit: a4c397b49c08f543fd42ddc21a6312bce5571947
Parents: c565b64
Author: Pavel Yaskevich xe...@apache.org
Authored: Thu Sep 20 01:11:23 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Thu Sep 20 16:39:22 2012 +0300
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/SelectStatement.java | 15 ---
2 files changed, 9 insertions(+), 7 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4c397b4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0530134..65ba88f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -4,6 +4,7 @@
* fix assumption error in CLI when updating/describing keyspace
(CASSANDRA-4322)
* Adds offline sstablescrub to debian packaging (CASSANDRA-4642)
* Automatic fixing of overlapping leveled sstables (CASSANDRA-4644)
+ * fix error when using ORDER BY with extended selections (CASSANDRA-4689)
1.1.5
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4c397b4/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index a4d64cf..4a013b1 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -804,7 +804,7 @@ public class SelectStatement implements CQLStatement
}
}
-orderResults(cqlRows);
+orderResults(selection, cqlRows);
// Internal calls always return columns in the comparator order, even
when reverse was set
if (isReversed)
@@ -819,7 +819,7 @@ public class SelectStatement implements CQLStatement
/**
* Orders results when multiple keys are selected (using IN)
*/
-private void orderResults(ListCqlRow cqlRows)
+private void orderResults(ListPairCFDefinition.Name, Selector
selection, ListCqlRow cqlRows)
{
// There is nothing to do if
// a. there are no results,
@@ -828,12 +828,13 @@ public class SelectStatement implements CQLStatement
if (cqlRows.isEmpty() || parameters.orderings.isEmpty() ||
keyRestriction == null || keyRestriction.eqValues.size() 2)
return;
+
// optimization when only *one* order condition was given
// because there is no point of using composite comparator if there is
only one order condition
if (parameters.orderings.size() == 1)
{
CFDefinition.Name ordering =
cfDef.get(parameters.orderings.keySet().iterator().next());
-Collections.sort(cqlRows, new
SingleColumnComparator(getColumnPositionInSelect(ordering), ordering.type));
+Collections.sort(cqlRows, new
SingleColumnComparator(getColumnPositionInSelect(selection, ordering),
ordering.type));
return;
}
@@ -848,18 +849,18 @@ public class SelectStatement implements CQLStatement
{
CFDefinition.Name orderingColumn = cfDef.get(identifier);
types.add(orderingColumn.type);
-positions[idx++] = getColumnPositionInSelect(orderingColumn);
+positions[idx++] = getColumnPositionInSelect(selection,
orderingColumn);
}
Collections.sort(cqlRows, new CompositeComparator(types, positions));
}
// determine position of column in the select clause
-private int getColumnPositionInSelect(CFDefinition.Name columnName)
+private int getColumnPositionInSelect(ListPairCFDefinition.Name,
Selector selection, CFDefinition.Name columnName)
{
-for (int i = 0; i selectedNames.size(); i++)
+for (int i = 0; i selection.size(); i++)
{
-if (selectedNames.get(i).left.equals(columnName))
+if (selection.get(i).left.equals(columnName))
return i;
}
[jira] [Created] (CASSANDRA-4692) improve error messages: InvalidRequestException(why:Expected 8 or 0 byte long (4))
Michael Krumpholz created CASSANDRA-4692:
Summary: improve error messages:
InvalidRequestException(why:Expected 8 or 0 byte long (4))
Key: CASSANDRA-4692
URL: https://issues.apache.org/jira/browse/CASSANDRA-4692
Project: Cassandra
Issue Type: Improvement
Reporter: Michael Krumpholz
{noformat}
InvalidRequestException(why:Expected 8 or 0 byte long (4))
{noformat}
The error messages could be much more informative and helpful if the column
names would be included in the message. Oh, before this question arises: the
messages are generated within cassandra code even if it may be in the Jdbc*
typed classes (not part of the jdbc project).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4693) CQL Protocol should allow multiple PreparedStatements to be atomically executed
Michaël Figuière created CASSANDRA-4693: --- Summary: CQL Protocol should allow multiple PreparedStatements to be atomically executed Key: CASSANDRA-4693 URL: https://issues.apache.org/jira/browse/CASSANDRA-4693 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Michaël Figuière Currently the only way to insert multiple records on the same partition key, atomically and using PreparedStatements is to use a CQL BATCH command. Unfortunately when doing so the amount of records to be inserted must be known prior to prepare the statement which is rarely the case. Thus the only workaround if one want to keep atomicity is currently to use unprepared statements which send a bulk of CQL strings and is fairly inefficient. Therefore CQL Protocol should allow clients to send multiple PreparedStatements to be executed with similar guarantees and semantic as CQL BATCH command. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[
https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459623#comment-13459623
]
Sylvain Lebresne commented on CASSANDRA-4584:
-
I'm playing devil's advocate here but I wonder if this isn't something that
would be better done at the protocol level. Typically there is two less that
ideal thing if we make it part of the language?
* it's unclear what to do when we prepare a query with a TRACE in it. The
current patch chose to trace both the preparation and all following execution.
But that's 1) largely random and 2) not very flexible. As a user, I want to be
able to trace an execution of a prepared query without having to trace
everyone. And while maybe slightly less useful, being able to trace a prepare
without necessary having all execution being traced would be neat too.
* as remarked by David, it means tracing the parsing of the query become less
natural (to be honest that's not really a big deal, this would still be fairly
to do, but suggests imho that trace don't belong to the language).
None of this is a problem if tracing is a protocol option. Besides, the
protocol is already involved in the tracing in the sense that the trace ID
cannot be returned in the ResultSet, so the protocol has to be involved already
(and I note that for CQL over thrift, we already have the trace_next_query for
that; adding it to the binary protocol will require a bit more work because of
the asynchronous nature of the protocol, but we can leave that to later).
Last minor point in favor of not putting that in the language, we won't have to
torture the parser to disallow writing slightly non-sensical queries like:
{noformat}
TRACE TRACE TRACE TRACE TRACE TRACE INSERT ;
{noformat}
or
{noformat}
BEGIN BATCH INSERT ...; TRACE INSERT ...; INSERT ...; TRACE INSERT ...; APPLY
BATCH;
{noformat}
and similar variation, all of which are allowed by the current patch.
Add CQL syntax to enable request tracing
Key: CASSANDRA-4584
URL: https://issues.apache.org/jira/browse/CASSANDRA-4584
Project: Cassandra
Issue Type: Sub-task
Affects Versions: 1.2.0 beta 1
Reporter: Jonathan Ellis
Assignee: David Alves
Labels: cql3
Fix For: 1.2.0 beta 2
Attachments: 4584.patch, 4584.patch, 4584.patch, 4584.patch,
4584.patch
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4693) CQL Protocol should allow multiple PreparedStatements to be atomically executed
[ https://issues.apache.org/jira/browse/CASSANDRA-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459638#comment-13459638 ] Sylvain Lebresne commented on CASSANDRA-4693: - One way to allow that would be to allow for the executePrepared message of the protocol to take a list of (preparedId, values) instead of just one (we would obviously refuse the query if the list size is 1 and there is something else than a modification statement). Not sure we want to bother with on the CQL-over-thrift side however (I don't). CQL Protocol should allow multiple PreparedStatements to be atomically executed --- Key: CASSANDRA-4693 URL: https://issues.apache.org/jira/browse/CASSANDRA-4693 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Michaël Figuière Labels: cql, protocol Currently the only way to insert multiple records on the same partition key, atomically and using PreparedStatements is to use a CQL BATCH command. Unfortunately when doing so the amount of records to be inserted must be known prior to prepare the statement which is rarely the case. Thus the only workaround if one want to keep atomicity is currently to use unprepared statements which send a bulk of CQL strings and is fairly inefficient. Therefore CQL Protocol should allow clients to send multiple PreparedStatements to be executed with similar guarantees and semantic as CQL BATCH command. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4049) Add generic way of adding SSTable components required custom compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kołaczkowski updated CASSANDRA-4049: -- Attachment: (was: pluggable_custom_components-1.1.4.patch) Add generic way of adding SSTable components required custom compaction strategy Key: CASSANDRA-4049 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Piotr Kołaczkowski Assignee: Piotr Kołaczkowski Priority: Minor Labels: compaction Fix For: 1.1.6 CFS compaction strategy coming up in the next DSE release needs to store some important information in Tombstones.db and RemovedKeys.db files, one per sstable. However, currently Cassandra issues warnings when these files are found in the data directory. Additionally, when switched to SizeTieredCompactionStrategy, the files are left in the data directory after compaction. The attached patch adds new components to the Component class so Cassandra knows about those files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4049) Add generic way of adding SSTable components required custom compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kołaczkowski updated CASSANDRA-4049: -- Attachment: pluggable_custom_components-1.1.5.patch Improved patch: 1. Code style - now uses FileUtils, Guava.readLines 2. Appends TOC instead of overwriting it. 3. Access to TOC file is protected with ReadWriteLock. 4. Components collection is a CopyOnWriteArraySet. 5. No synchronized. I really tried to make components collection immutable first, but that opened unfortunately a whole can of worms related to: 1. SSTable reference counting (two SSTableReader objects sharing data) and deletion 2. Adding custom components from inside of a notifier (e.g. on memtable flush) 3. Rebuilding interval tree (that one was easy to fix, though) Just didn't want to introduce subtle bugs. SSTable and SSTableReader aren't immutable anyway. I performed stress testing with Cassandra FileSystem stress test tool in DSE, and our custom CFS strategy - works fine. Add generic way of adding SSTable components required custom compaction strategy Key: CASSANDRA-4049 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Piotr Kołaczkowski Assignee: Piotr Kołaczkowski Priority: Minor Labels: compaction Fix For: 1.1.6 Attachments: pluggable_custom_components-1.1.5.patch CFS compaction strategy coming up in the next DSE release needs to store some important information in Tombstones.db and RemovedKeys.db files, one per sstable. However, currently Cassandra issues warnings when these files are found in the data directory. Additionally, when switched to SizeTieredCompactionStrategy, the files are left in the data directory after compaction. The attached patch adds new components to the Component class so Cassandra knows about those files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4191) Add `nodetool cfstats ks cf` abilities
[ https://issues.apache.org/jira/browse/CASSANDRA-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459668#comment-13459668 ] Brandon Williams commented on CASSANDRA-4191: - Are you still working on this, Dave? Add `nodetool cfstats ks cf` abilities -- Key: CASSANDRA-4191 URL: https://issues.apache.org/jira/browse/CASSANDRA-4191 Project: Cassandra Issue Type: New Feature Affects Versions: 1.2.0 beta 1 Reporter: Joaquin Casares Assignee: Dave Brosius Priority: Minor Labels: datastax_qa Attachments: 4191_specific_cfstats.diff This way cfstats will only print information per keyspace/column family combinations. Another related proposal as an alternative to this ticket: Allow for `nodetool cfstats` to use --excludes or --includes to accept keyspace and column family arguments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4449) Make prepared statement global rather than connection based
[ https://issues.apache.org/jira/browse/CASSANDRA-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4449: Attachment: 4449.txt Attaching patch that: # make prepared statement global for the binary protocol. I've kept backward compatibility on the thrift side to be conservative. # for the binary protocol, switch the hash used as statement ID to md5, because I don't trust String.hashCode() enough (and I don't think there is guarantees that it cannot change between java versions). I'd *really* like to get that in for 1.2 because I think that having per-connection statement makes it very painful for clients library that want to hide the details of how they perform connection pooling. Make prepared statement global rather than connection based --- Key: CASSANDRA-4449 URL: https://issues.apache.org/jira/browse/CASSANDRA-4449 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Attachments: 4449.txt Currently, prepared statements are connection based. A client can only use a prepared statement on the connection it prepared it on, and if you prepare the same prepared statement on multiple connections, we'll keep multiple times the same prepared statement. This is potentially inefficient but can also be fairly painful for client libraries with pool of connections (a.k.a all reasonable client library ever) as this means you need to make sure you prepare statement on every connection of the pool, including the connection that don't exist yet but might be created later. This ticket suggests making prepared statement global (at least for CQL3), i.e. move them out of ClientState. This will likely reduce the number of stored statement on a given node quite a bit, since it's very likely that all clients to a given node will prepare the same statements (and potentially on all of their connection with the node). And given that prepared statement identifiers are the hashCode() of the string, this should be fairly trivial. I will note that while I think using a hash of the string as identifier is a very good idea, I don't know if the default java hashCode() is good enough. If that's a concern, maybe we should use a safer (bug longer) hash like md5 or sha1. But we'd better do that now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4609) Add thrift transport factory impl to cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459718#comment-13459718 ] Alex Liu commented on CASSANDRA-4609: - Jason, Can you add a ITransportFactory configuration option in cassandra.yaml, so that the cassandra-cli can use any plugin TransportFactory. Add thrift transport factory impl to cassandra-cli -- Key: CASSANDRA-4609 URL: https://issues.apache.org/jira/browse/CASSANDRA-4609 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0003-CASSANDRA-4609-add-thrift-transport-factory-support-.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4649) Cassandra 1.2 should not accept CQL version 3.0.0-beta1
[ https://issues.apache.org/jira/browse/CASSANDRA-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459723#comment-13459723 ] paul cannon commented on CASSANDRA-4649: +1. Cassandra 1.2 should not accept CQL version 3.0.0-beta1 - Key: CASSANDRA-4649 URL: https://issues.apache.org/jira/browse/CASSANDRA-4649 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 Reporter: paul cannon Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Attachments: 4649.txt During Cassandra 1.1's whole lifecycle, the CREATE KEYSPACE syntax was pretty dramatically and incompatibly different from what is there now for 1.2. That's ok, since we explicitly said there could be breaking changes in the syntax before 3.0.0 final, but at least we should make it clear that 3.0.0 is not compatible with the 3.0.0-beta1 syntax we had out for quite a while. If we don't want to reject connections asking for 3.0.0-beta1, we should bump the version number to 3.0.1 or something. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4649) Cassandra 1.2 should not accept CQL version 3.0.0-beta1
[ https://issues.apache.org/jira/browse/CASSANDRA-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4649: --- Reviewer: thepaul Cassandra 1.2 should not accept CQL version 3.0.0-beta1 - Key: CASSANDRA-4649 URL: https://issues.apache.org/jira/browse/CASSANDRA-4649 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 Reporter: paul cannon Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Attachments: 4649.txt During Cassandra 1.1's whole lifecycle, the CREATE KEYSPACE syntax was pretty dramatically and incompatibly different from what is there now for 1.2. That's ok, since we explicitly said there could be breaking changes in the syntax before 3.0.0 final, but at least we should make it clear that 3.0.0 is not compatible with the 3.0.0-beta1 syntax we had out for quite a while. If we don't want to reject connections asking for 3.0.0-beta1, we should bump the version number to 3.0.1 or something. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4310) Multiple independent Level Compactions in Parallel
[ https://issues.apache.org/jira/browse/CASSANDRA-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-4310: -- Attachment: 4310.txt Initial patch attached to get feedback(still writing unit test for this). I introduced _max_concurrent_tasks_ as new compaction option of LeveledCompactionStrategy(default is 1) to specify number of tasks to run in parallel. List of sstables set is chosen by the algorithm similar to above in LeveledManifest#getCompactionCandidates. If there are 2 or more sets to compact, then ParallelLeveledCompactionTask gets created with its own executor, and performs compaction in parallel. I feel I need some unit test for selecting list of sstables, so patch is still in progress. will update if it's done. Multiple independent Level Compactions in Parallel -- Key: CASSANDRA-4310 URL: https://issues.apache.org/jira/browse/CASSANDRA-4310 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: sankalp kohli Assignee: Yuki Morishita Labels: compaction, features, leveled, performance, ssd Fix For: 1.2.1 Attachments: 4310.txt Problem: If you are inserting data into cassandra and level compaction cannot catchup, you will create lot of files in L0. Here is a solution which will help here and also increase the performance of level compaction. We can do many compactions in parallel for unrelated data. 1) For no over lapping levels. Ex: when L0 stable is compacting with L1, we can do compactions in other levels like L2 and L3 if they are eligible. 2) We can also do compactions with files in L1 which are not participating in L0 compactions. This is specially useful if you are using SSD and is not bottlenecked by IO. I am seeing this issue in my cluster. The compactions pending are more than 50k and the disk usage is not that much(I am using SSD). I am doing multithreaded to true and also not throttling the IO by putting the value as 0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4664) Rename permission USE to DESCRIBE.
[ https://issues.apache.org/jira/browse/CASSANDRA-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459752#comment-13459752 ] Yuki Morishita commented on CASSANDRA-4664: --- +1 Rename permission USE to DESCRIBE. -- Key: CASSANDRA-4664 URL: https://issues.apache.org/jira/browse/CASSANDRA-4664 Project: Cassandra Issue Type: Improvement Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Fix For: 1.1.6 Attachments: CASSANDRA-4664.patch We should change USE permission to DESCRIBE as it better reflects it's meaning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3901) write endpoints are not treated correctly, breaking consistency guarantees
[ https://issues.apache.org/jira/browse/CASSANDRA-3901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459764#comment-13459764 ] Jonathan Ellis commented on CASSANDRA-3901: --- Am I misreading this, or is this the same as CASSANDRA-833? See especially https://issues.apache.org/jira/browse/CASSANDRA-833?focusedCommentId=13028232page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13028232 write endpoints are not treated correctly, breaking consistency guarantees -- Key: CASSANDRA-3901 URL: https://issues.apache.org/jira/browse/CASSANDRA-3901 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Peter Schuller Assignee: Peter Schuller I had a nagging feeling this was the case ever since I started wanting CASSANDRA-3833 and thinking about hot to handle the association between nodes in the read set and nodes in the write set. I may be wrong (please point me in the direct direction if so), but I see no code anywhere that tries to (1) apply consistency level to currently normal endpoints only, and (2) connect a given read endpoint with a future write endpoint such that they are tied together for consistency purposes (parts of these concerns probably is covered by CASSANDRA-2434 but that ticket is more general). To be more clear about the problem: Suppose we have a ring of nodes, with a single node bootstrapping. Now, for a given row key suppose reads are served by A, B and C while writes are to go to A, B, C and D. In other words, D is the node bootstrapping. Suppose RF is 3 and A,B,C,D is ring order. There are a few things required for correct behavior: * Writes acked by D must never be treated as sufficient to satisfy consistency level since until it is part of the read set it does not count towards CL on reads. * Writes acked by B must *not* be treated as sufficient to satisfy consistency level *unless* the same write is *also* acked by D, because once D enters the ring, B will no longer be counting towards CL on reads. The only alternative is to make the read succeed and disallow D from entering the ring. We don't seem to be handling this at all (and it becomes more complicated with arbitrary transitions). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-833) fix consistencylevel during bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reopened CASSANDRA-833:
--
Assignee: Jonathan Ellis (was: Sylvain Lebresne)
Well, WTF.
{noformat}
commit 063c8f6cf7b12e976b0d7067037c52c548c6c0db
Author: Jonathan Ellis jbel...@apache.org
Date: Thu Jun 9 00:16:27 2011 +
revert 1133443
git-svn-id:
https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@1133610
13f79535-47bb-0310-9956-ffa450edef68
commit 31f0ee95e927c09183dca77be7739305ba2eeab0
Author: Jonathan Ellis jbel...@apache.org
Date: Wed Jun 8 15:45:54 2011 +
fix inconsistency window duringbootstrap
patch by slebresne; reviewed by jbellis for CASSANDRA-833
git-svn-id:
https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@1133443
13f79535-47bb-0310-9956-ffa450edef68
{noformat}
I have no memory of this. :)
Maybe it caused a regression?
fix consistencylevel during bootstrap
-
Key: CASSANDRA-833
URL: https://issues.apache.org/jira/browse/CASSANDRA-833
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.5
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Fix For: 1.2.0 beta 2
Attachments: 0001-Increase-CL-with-boostrapping-leaving-node.patch,
833-v2.txt
As originally designed, bootstrap nodes should *always* get *all* writes
under any consistencylevel, so when bootstrap finishes the operator can run
cleanup on the old nodes w/o fear that he might lose data.
but if a bootstrap operation fails or is aborted, that means all writes will
fail until the ex-bootstrapping node is decommissioned. so starting in
CASSANDRA-722, we just ignore dead nodes in consistencylevel calculations.
but this breaks the original design. CASSANDRA-822 adds a partial fix for
this (just adding bootstrap targets into the RF targets and hinting
normally), but this is still broken under certain conditions. The real fix
is to consider consistencylevel for two sets of nodes:
1. the RF targets as currently existing (no pending ranges)
2. the RF targets as they will exist after all movement ops are done
If we satisfy CL for both sets then we will always be in good shape.
I'm not sure if we can easily calculate 2. from the current TokenMetadata,
though.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3901) write endpoints are not treated correctly, breaking consistency guarantees
[ https://issues.apache.org/jira/browse/CASSANDRA-3901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459781#comment-13459781 ] Jonathan Ellis commented on CASSANDRA-3901: --- I couldn't find the fix in trunk so I dug a bit deeper and found that I reverted the fix the day after committing it. I don't remember why (this was over a year ago). Reopened 833. write endpoints are not treated correctly, breaking consistency guarantees -- Key: CASSANDRA-3901 URL: https://issues.apache.org/jira/browse/CASSANDRA-3901 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Peter Schuller Assignee: Peter Schuller I had a nagging feeling this was the case ever since I started wanting CASSANDRA-3833 and thinking about hot to handle the association between nodes in the read set and nodes in the write set. I may be wrong (please point me in the direct direction if so), but I see no code anywhere that tries to (1) apply consistency level to currently normal endpoints only, and (2) connect a given read endpoint with a future write endpoint such that they are tied together for consistency purposes (parts of these concerns probably is covered by CASSANDRA-2434 but that ticket is more general). To be more clear about the problem: Suppose we have a ring of nodes, with a single node bootstrapping. Now, for a given row key suppose reads are served by A, B and C while writes are to go to A, B, C and D. In other words, D is the node bootstrapping. Suppose RF is 3 and A,B,C,D is ring order. There are a few things required for correct behavior: * Writes acked by D must never be treated as sufficient to satisfy consistency level since until it is part of the read set it does not count towards CL on reads. * Writes acked by B must *not* be treated as sufficient to satisfy consistency level *unless* the same write is *also* acked by D, because once D enters the ring, B will no longer be counting towards CL on reads. The only alternative is to make the read succeed and disallow D from entering the ring. We don't seem to be handling this at all (and it becomes more complicated with arbitrary transitions). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-833) fix consistencylevel during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-833: - Reviewer: slebresne (was: jbellis) Fix Version/s: (was: 0.8.1) 1.2.0 beta 2 fix consistencylevel during bootstrap - Key: CASSANDRA-833 URL: https://issues.apache.org/jira/browse/CASSANDRA-833 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.5 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 1.2.0 beta 2 Attachments: 0001-Increase-CL-with-boostrapping-leaving-node.patch, 833-v2.txt As originally designed, bootstrap nodes should *always* get *all* writes under any consistencylevel, so when bootstrap finishes the operator can run cleanup on the old nodes w/o fear that he might lose data. but if a bootstrap operation fails or is aborted, that means all writes will fail until the ex-bootstrapping node is decommissioned. so starting in CASSANDRA-722, we just ignore dead nodes in consistencylevel calculations. but this breaks the original design. CASSANDRA-822 adds a partial fix for this (just adding bootstrap targets into the RF targets and hinting normally), but this is still broken under certain conditions. The real fix is to consider consistencylevel for two sets of nodes: 1. the RF targets as currently existing (no pending ranges) 2. the RF targets as they will exist after all movement ops are done If we satisfy CL for both sets then we will always be in good shape. I'm not sure if we can easily calculate 2. from the current TokenMetadata, though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4694) populate_io_cache_on_flush option should be configurable for each column family independently
Alexey Zotov created CASSANDRA-4694: --- Summary: populate_io_cache_on_flush option should be configurable for each column family independently Key: CASSANDRA-4694 URL: https://issues.apache.org/jira/browse/CASSANDRA-4694 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Critical I suggest to configure populate_io_cache_on_flush option for each column family. It should be configurable from cassandra-cli and should be stored in System keyspace. That could be useful if you have a few column families inside single keyspace and you need to fit in memory only one of them. Patch has been attached. I've been testing it on pseudo-cluster using ccm. So I don't have fully confidence about lack of bugs. Please carefully review that code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4694) populate_io_cache_on_flush option should be configurable for each column family independently
[ https://issues.apache.org/jira/browse/CASSANDRA-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zotov updated CASSANDRA-4694: Fix Version/s: (was: 1.1.6) populate_io_cache_on_flush option should be configurable for each column family independently - Key: CASSANDRA-4694 URL: https://issues.apache.org/jira/browse/CASSANDRA-4694 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Critical Labels: cli, core, documentation Attachments: cassandra-1.1-4694-populate_io_cache.txt I suggest to configure populate_io_cache_on_flush option for each column family. It should be configurable from cassandra-cli and should be stored in System keyspace. That could be useful if you have a few column families inside single keyspace and you need to fit in memory only one of them. Patch has been attached. I've been testing it on pseudo-cluster using ccm. So I don't have fully confidence about lack of bugs. Please carefully review that code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4694) populate_io_cache_on_flush option should be configurable for each column family independently
[ https://issues.apache.org/jira/browse/CASSANDRA-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zotov updated CASSANDRA-4694: Attachment: cassandra-1.1-4694-populate_io_cache.txt populate_io_cache_on_flush option should be configurable for each column family independently - Key: CASSANDRA-4694 URL: https://issues.apache.org/jira/browse/CASSANDRA-4694 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Critical Labels: cli, core, documentation Attachments: cassandra-1.1-4694-populate_io_cache.txt I suggest to configure populate_io_cache_on_flush option for each column family. It should be configurable from cassandra-cli and should be stored in System keyspace. That could be useful if you have a few column families inside single keyspace and you need to fit in memory only one of them. Patch has been attached. I've been testing it on pseudo-cluster using ccm. So I don't have fully confidence about lack of bugs. Please carefully review that code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4695) CompactionsTest fails with timeout
Alexey Zotov created CASSANDRA-4695:
---
Summary: CompactionsTest fails with timeout
Key: CASSANDRA-4695
URL: https://issues.apache.org/jira/browse/CASSANDRA-4695
Project: Cassandra
Issue Type: Bug
Components: Tests
Affects Versions: 1.1.5
Environment: Ubuntu 12.04, Java 1.6, Ant 1.8.2, Maven 3.0.4
Ubuntu 11.10, Java 1.6, Ant 1.8.2, Maven 2.2.1
Reporter: Alexey Zotov
Priority: Blocker
{code}
[junit] Testsuite: org.apache.cassandra.db.compaction.CompactionsTest
[junit] Testsuite: org.apache.cassandra.db.compaction.CompactionsTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.db.compaction.CompactionsTest:testStandardColumnCompactions:
Caused an ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please note
the time in the report does not reflect the time until the timeout.
[junit]
[junit]
[junit] Test org.apache.cassandra.db.compaction.CompactionsTest FAILED
(timeout)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4695) CompactionsTest fails with timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4695:
Labels: test-fail (was: )
CompactionsTest fails with timeout
--
Key: CASSANDRA-4695
URL: https://issues.apache.org/jira/browse/CASSANDRA-4695
Project: Cassandra
Issue Type: Bug
Components: Tests
Affects Versions: 1.1.5
Environment: Ubuntu 12.04, Java 1.6, Ant 1.8.2, Maven 3.0.4
Ubuntu 11.10, Java 1.6, Ant 1.8.2, Maven 2.2.1
Reporter: Alexey Zotov
Priority: Blocker
Labels: test-fail
{code}
[junit] Testsuite: org.apache.cassandra.db.compaction.CompactionsTest
[junit] Testsuite: org.apache.cassandra.db.compaction.CompactionsTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.db.compaction.CompactionsTest:testStandardColumnCompactions:
Caused an ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit]
[junit]
[junit] Test org.apache.cassandra.db.compaction.CompactionsTest FAILED
(timeout)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[cassandra-dbapi2] 3 new revisions pushed by pcan...@gmail.com on 2012-09-20 17:59 GMT
3 new revisions:
Revision: 9eb88a2ed7f3
Author: Sylvain Lebresne sylv...@datastax.com
Date: Mon Sep 17 04:34:57 2012
Log: Set initial keyspace after connection has been finalized
http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=9eb88a2ed7f3
Revision: 378ebda45976
Author: paul cannon p...@thepaul.org
Date: Thu Sep 20 10:38:41 2012
Log: tests for specifying keyspace in connect() call
http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=378ebda45976
Revision: a26caaa88cd1
Author: paul cannon p...@thepaul.org
Date: Thu Sep 20 10:58:57 2012
Log: explicitly use cql 2 for test_cql tests
http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=a26caaa88cd1
==
Revision: 9eb88a2ed7f3
Author: Sylvain Lebresne sylv...@datastax.com
Date: Mon Sep 17 04:34:57 2012
Log: Set initial keyspace after connection has been finalized
http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=9eb88a2ed7f3
Modified:
/cql/connection.py
/cql/native.py
/cql/thrifteries.py
===
--- /cql/connection.py Tue Sep 11 17:31:33 2012
+++ /cql/connection.py Mon Sep 17 04:34:57 2012
@@ -46,6 +46,9 @@
self.establish_connection()
self.open_socket = True
+if self.keyspace:
+self.set_initial_keyspace(self.keyspace)
+
def __str__(self):
return (%s(host=%r, port=%r, keyspace=%r, %s)
% (self.__class__.__name__, self.host, self.port,
self.keyspace,
===
--- /cql/native.py Tue Sep 11 18:09:31 2012
+++ /cql/native.py Mon Sep 17 04:34:57 2012
@@ -761,8 +761,6 @@
raise cql.InternalError(Unexpected response %r during
connection setup
% startup_response)
-if self.keyspace:
-self.set_initial_keyspace(self.keyspace)
def set_initial_keyspace(self, keyspace):
c = self.cursor()
===
--- /cql/thrifteries.py Tue Sep 11 17:31:33 2012
+++ /cql/thrifteries.py Mon Sep 17 04:34:57 2012
@@ -134,9 +134,6 @@
if self.cql_version:
self.set_cql_version(self.cql_version)
-if self.keyspace:
-self.set_initial_keyspace(self.keyspace)
-
def set_cql_version(self, cql_version):
self.client.set_cql_version(cql_version)
try:
==
Revision: 378ebda45976
Author: paul cannon p...@thepaul.org
Date: Thu Sep 20 10:38:41 2012
Log: tests for specifying keyspace in connect() call
http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=378ebda45976
Added:
/test/test_connection.py
===
--- /dev/null
+++ /test/test_connection.pyThu Sep 20 10:38:41 2012
@@ -0,0 +1,103 @@
+# 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.
+
+# to configure behavior, define $CQL_TEST_HOST to the destination address
+# for Thrift connections, and $CQL_TEST_PORT to the associated port.
+
+import unittest
+import contextlib
+from thrift.transport import TTransport
+import test_cql
+from test_prepared_queries import MIN_THRIFT_FOR_CQL_3_0_0_FINAL
+
+cql = test_cql.cql
+TEST_HOST = test_cql.TEST_HOST
+TEST_PORT = test_cql.TEST_PORT
+randstring = test_cql.randstring
+del test_cql
+
+class TestConnection(unittest.TestCase):
+def setUp(self):
+self.randstr = randstring()
+
+@contextlib.contextmanager
+def with_keyspace(self, cursor, cqlver):
+ksname = self.randstr + '_conntest_' + cqlver.replace('.', '_')
+if cqlver.startswith('2.'):
+cursor.execute(create keyspace '%s' with
strategy_class='SimpleStrategy'
+and strategy_options:replication_factor=1; %
ksname)
+cursor.execute(use '%s' % ksname)
+yield ksname
+cursor.execute(use system;)
+cursor.execute(drop keyspace '%s' % ksname)
+elif cqlver == '3.0.0-beta1': # for cassandra 1.1
+
[jira] [Updated] (CASSANDRA-4443) shuffle utility for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-4443:
--
Description:
As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to
split up the contiguous ranges.
List discussion: http://thread.gmane.org/gmane.comp.db.cassandra.devel/6799
_Edit0: Linked in mailing list discussion._
_Edit1: Linked in patch information._
_Edit2: Updated patch links._
\\
h3. Patches
||Compare||Raw diff||Description||
|[060_shuffle_utility|https://github.com/acunu/cassandra/compare/top-bases/p/4443/060_shuffle_utility...p/4443/060_shuffle_utility]|[060_shuffle_utility.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/060_shuffle_utility...p/4443/060_shuffle_utility.diff]|{{shuffle}}
util to randomly remap ranges|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files (i.e.
{{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), or remove
them afterward ({{rm .topmsg .topdeps}})._
was:
As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to
split up the contiguous ranges.
List discussion: http://thread.gmane.org/gmane.comp.db.cassandra.devel/6799
_Edit0: Linked in mailing list discussion._
_Edit1: Linked in patch information._
\\
h3. Patches
||Compare||Raw diff||Description||
|[050_process_queued_xfers|https://github.com/acunu/cassandra/compare/top-bases/p/4443/050_process_queued_xfers...p/4443/050_process_queued_xfers]|[050_process_queued_xfers.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/050_process_queued_xfers...p/4443/050_process_queued_xfers.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files (i.e.
{{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), or remove
them afterward ({{rm .topmsg .topdeps}})._
shuffle utility for vnodes
--
Key: CASSANDRA-4443
URL: https://issues.apache.org/jira/browse/CASSANDRA-4443
Project: Cassandra
Issue Type: Sub-task
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0
As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to
split up the contiguous ranges.
List discussion: http://thread.gmane.org/gmane.comp.db.cassandra.devel/6799
_Edit0: Linked in mailing list discussion._
_Edit1: Linked in patch information._
_Edit2: Updated patch links._
\\
h3. Patches
||Compare||Raw diff||Description||
|[060_shuffle_utility|https://github.com/acunu/cassandra/compare/top-bases/p/4443/060_shuffle_utility...p/4443/060_shuffle_utility]|[060_shuffle_utility.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/060_shuffle_utility...p/4443/060_shuffle_utility.diff]|{{shuffle}}
util to randomly remap ranges|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4443) shuffle utility for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-4443:
--
Reviewer: brandon.williams
shuffle utility for vnodes
--
Key: CASSANDRA-4443
URL: https://issues.apache.org/jira/browse/CASSANDRA-4443
Project: Cassandra
Issue Type: Sub-task
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0
As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to
split up the contiguous ranges.
List discussion: http://thread.gmane.org/gmane.comp.db.cassandra.devel/6799
_Edit0: Linked in mailing list discussion._
_Edit1: Linked in patch information._
_Edit2: Updated patch links._
\\
h3. Patches
||Compare||Raw diff||Description||
|[060_shuffle_utility|https://github.com/acunu/cassandra/compare/top-bases/p/4443/060_shuffle_utility...p/4443/060_shuffle_utility]|[060_shuffle_utility.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/060_shuffle_utility...p/4443/060_shuffle_utility.diff]|{{shuffle}}
util to randomly remap ranges|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4609) Add thrift transport factory impl to cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459911#comment-13459911 ] Jason Brown commented on CASSANDRA-4609: Alex, Pavel and I discussed offline, and it seems best to be able to pass the name of transport factory as a command line arg, --transport_factory. Add thrift transport factory impl to cassandra-cli -- Key: CASSANDRA-4609 URL: https://issues.apache.org/jira/browse/CASSANDRA-4609 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0003-CASSANDRA-4609-add-thrift-transport-factory-support-.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4609) Add thrift transport factory impl to cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459933#comment-13459933 ] Alex Liu commented on CASSANDRA-4609: - that works as well. Add thrift transport factory impl to cassandra-cli -- Key: CASSANDRA-4609 URL: https://issues.apache.org/jira/browse/CASSANDRA-4609 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0003-CASSANDRA-4609-add-thrift-transport-factory-support-.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4608) Add thrift server factory to CassandraDaemon
[ https://issues.apache.org/jira/browse/CASSANDRA-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460063#comment-13460063 ] Jason Brown commented on CASSANDRA-4608: Please see additional comments in CASSANDRA-4662. Add thrift server factory to CassandraDaemon Key: CASSANDRA-4608 URL: https://issues.apache.org/jira/browse/CASSANDRA-4608 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0002-CASSANDRA-4608-Add-thrift-server-factory-to-Cassandr.patch Add factory class for CassandraServer Default impl will be the current thrift server types. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-833) fix consistencylevel during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460112#comment-13460112 ] Jonathan Ellis commented on CASSANDRA-833: -- Pushed rebase to https://github.com/jbellis/cassandra/branches/833-3 fix consistencylevel during bootstrap - Key: CASSANDRA-833 URL: https://issues.apache.org/jira/browse/CASSANDRA-833 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.5 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 1.2.0 beta 2 Attachments: 0001-Increase-CL-with-boostrapping-leaving-node.patch, 833-v2.txt As originally designed, bootstrap nodes should *always* get *all* writes under any consistencylevel, so when bootstrap finishes the operator can run cleanup on the old nodes w/o fear that he might lose data. but if a bootstrap operation fails or is aborted, that means all writes will fail until the ex-bootstrapping node is decommissioned. so starting in CASSANDRA-722, we just ignore dead nodes in consistencylevel calculations. but this breaks the original design. CASSANDRA-822 adds a partial fix for this (just adding bootstrap targets into the RF targets and hinting normally), but this is still broken under certain conditions. The real fix is to consider consistencylevel for two sets of nodes: 1. the RF targets as currently existing (no pending ranges) 2. the RF targets as they will exist after all movement ops are done If we satisfy CL for both sets then we will always be in good shape. I'm not sure if we can easily calculate 2. from the current TokenMetadata, though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-833) fix consistencylevel during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460114#comment-13460114 ] Jonathan Ellis commented on CASSANDRA-833: -- (Not exactly a pure rebase since I split out pendingRangesFor instead of cramming everything into getWriteEndpoints.) fix consistencylevel during bootstrap - Key: CASSANDRA-833 URL: https://issues.apache.org/jira/browse/CASSANDRA-833 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.5 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 1.2.0 beta 2 Attachments: 0001-Increase-CL-with-boostrapping-leaving-node.patch, 833-v2.txt As originally designed, bootstrap nodes should *always* get *all* writes under any consistencylevel, so when bootstrap finishes the operator can run cleanup on the old nodes w/o fear that he might lose data. but if a bootstrap operation fails or is aborted, that means all writes will fail until the ex-bootstrapping node is decommissioned. so starting in CASSANDRA-722, we just ignore dead nodes in consistencylevel calculations. but this breaks the original design. CASSANDRA-822 adds a partial fix for this (just adding bootstrap targets into the RF targets and hinting normally), but this is still broken under certain conditions. The real fix is to consider consistencylevel for two sets of nodes: 1. the RF targets as currently existing (no pending ranges) 2. the RF targets as they will exist after all movement ops are done If we satisfy CL for both sets then we will always be in good shape. I'm not sure if we can easily calculate 2. from the current TokenMetadata, though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4191) Add `nodetool cfstats ks cf` abilities
[ https://issues.apache.org/jira/browse/CASSANDRA-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460173#comment-13460173 ] Dave Brosius commented on CASSANDRA-4191: - no, have at it if you like. Add `nodetool cfstats ks cf` abilities -- Key: CASSANDRA-4191 URL: https://issues.apache.org/jira/browse/CASSANDRA-4191 Project: Cassandra Issue Type: New Feature Affects Versions: 1.2.0 beta 1 Reporter: Joaquin Casares Assignee: Dave Brosius Priority: Minor Labels: datastax_qa Attachments: 4191_specific_cfstats.diff This way cfstats will only print information per keyspace/column family combinations. Another related proposal as an alternative to this ticket: Allow for `nodetool cfstats` to use --excludes or --includes to accept keyspace and column family arguments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
