date:20120911

Sylvain Lebresne created CASSANDRA-4642:
---

 Summary: Add offline scrub to debian package
 Key: CASSANDRA-4642
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4642
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 1.1.2
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.1.6


When we added the offline scrub in CASSANDRA-4321, we forgot to add the launch 
script to the debian package. We should.

--
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-4642) Add offline scrub to debian package


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-4642:


Attachment: 4642.txt

 Add offline scrub to debian package
 ---

 Key: CASSANDRA-4642
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4642
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 1.1.2
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.1.6

 Attachments: 4642.txt


 When we added the offline scrub in CASSANDRA-4321, we forgot to add the 
 launch script to the debian package. We should.

--
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: Avoid NPE (and cleanups)

Updated Branches:
  refs/heads/trunk c4692a171 - c20b33c93


Avoid NPE (and cleanups)


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c20b33c9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c20b33c9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c20b33c9

Branch: refs/heads/trunk
Commit: c20b33c93775f62a638a8725dc07b00142aae252
Parents: c4692a1
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Sep 11 10:30:36 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Sep 11 10:30:56 2012 +0200

--
 .../cassandra/cql3/statements/BatchStatement.java  |4 ++--
 .../cassandra/cql3/statements/DeleteStatement.java |2 +-
 .../cql3/statements/ModificationStatement.java |   11 ---
 .../cassandra/cql3/statements/UpdateStatement.java |8 
 4 files changed, 15 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c20b33c9/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
index 3a286fc..ac78c89 100644
--- a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
@@ -103,7 +103,7 @@ public class BatchStatement extends ModificationStatement
 for (ModificationStatement statement : statements)
 {
 if (isSetTimestamp())
-statement.timestamp = timestamp;
+statement.setTimestamp(getTimestamp(clientState));
 
 ListIMutation lm = statement.getMutations(clientState, 
variables);
 // Group mutation together, otherwise they won't get applied 
atomically
@@ -164,7 +164,7 @@ public class BatchStatement extends ModificationStatement
 
 public String toString()
 {
-return String.format(BatchStatement(statements=%s, consistency=%s), 
statements, cLevel);
+return String.format(BatchStatement(statements=%s, consistency=%s), 
statements, getConsistencyLevel());
 }
 
 private static class RowAndCounterMutation

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c20b33c9/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
index cd0293a..73f7c0f 100644
--- a/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
@@ -231,7 +231,7 @@ public class DeleteStatement extends ModificationStatement
 return String.format(DeleteStatement(name=%s, columns=%s, 
consistency=%s keys=%s),
  cfName,
  columns,
- cLevel,
+ getConsistencyLevel(),
  whereClause);
 }
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c20b33c9/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
index 00674e9..291ecd9 100644
--- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
@@ -42,9 +42,9 @@ public abstract class ModificationStatement extends 
CFStatement implements CQLSt
 {
 public static final ConsistencyLevel defaultConsistency = 
ConsistencyLevel.ONE;
 
-protected final ConsistencyLevel cLevel;
-protected Long timestamp;
-protected final int timeToLive;
+private final ConsistencyLevel cLevel;
+private Long timestamp;
+private final int timeToLive;
 
 public ModificationStatement(CFName name, Attributes attrs)
 {
@@ -98,6 +98,11 @@ public abstract class ModificationStatement extends 
CFStatement implements CQLSt
 return timestamp == null ? clientState.getTimestamp() : timestamp;
 }
 
+public void setTimestamp(long timestamp)
+{
+this.timestamp = timestamp;
+}
+
 public boolean isSetTimestamp()
 {
 return timestamp != null;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c20b33c9/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java

[jira] [Created] (CASSANDRA-4643) AssertionError: DecoratedKey(-1, ) != DecoratedKey

2012-09-11 Thread Radim Kolar (JIRA)

Radim Kolar created CASSANDRA-4643:
--

 Summary: AssertionError: DecoratedKey(-1, ) != DecoratedKey
 Key: CASSANDRA-4643
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4643
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.5
Reporter: Radim Kolar


i got lot of following errors: decorated key -1 != some number

 INFO [CompactionExecutor:10] 2012-09-11 02:22:13,586 CompactionController.java 
(line 172) Compacting large row 
system/HintsColumnFamily:67fd0f04ca3294558142a5b33a30f6f5 (241502947 bytes) 
incrementally
ERROR [ReadStage:44] 2012-09-11 02:22:13,992 AbstractCassandraDaemon.java (line 
135) Exception in thread Thread[ReadStage:44,5,main]
java.lang.AssertionError: DecoratedKey(-1, ) != 
DecoratedKey(133375303318769338050543368330356089660, ad4f) in 
c:\cassandra\data\test\sipdb\test-sipdb-he-5-Data.db
at 
org.apache.cassandra.db.columniterator.SSTableNamesIterator.init(SSTableNamesIterator.java:72)
at 
org.apache.cassandra.db.filter.NamesQueryFilter.getSSTableColumnIterator(NamesQueryFilter.java:61)
at 
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at 
org.apache.cassandra.db.CollationController.collectTimeOrderedData(CollationController.java:124)
at 
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at 
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)


--
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-4621) AssertionError in StorageProxy.getRestrictedRange


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-4621:


Attachment: 4621.txt

Attaching patch that:
* Don't force positive tokens in Murmur3Partitioner (thus using all the bits of 
the LongToken).
* Exclude Long.MIN_VALUE from the possible tokens of a key (since it's now the 
MINIMUM token).

I note that this means tokens can be negative and that we'll have to update a 
number of documentation relating to computing tokens. Though this was already 
the case before this patch (but maybe to a slightly lesser extend). And 
hopefully vnodes will make (manual) token computations a thing of the past.

 AssertionError in StorageProxy.getRestrictedRange
 -

 Key: CASSANDRA-4621
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4621
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
 Environment: archlinux, openjdk7
Reporter: Pierre-Yves Ritschard
Assignee: Sylvain Lebresne
 Fix For: 1.2.0 beta 1

 Attachments: 4621.txt, 4621.txt


 On a freshly built cassandra from trunk, I can create a column family with a 
 composite row key using the syntax:
 for instance a standard eventlog CF:
  CREATE TABLE events (
facility text,
prio int,
message text,
PRIMARY KEY ( (facility, prio) )
  );
 A simple query will then generate exceptions:
 SELECT * FROM events; will yield:
 ERROR 15:33:40,383 Exception in thread Thread[Thrift:1,5,main]
 java.lang.AssertionError: [min(0),max(-8021625467324731134)]
   at org.apache.cassandra.dht.Bounds.init(Bounds.java:41)
   at org.apache.cassandra.dht.Bounds.split(Bounds.java:59)
   at 
 org.apache.cassandra.service.StorageProxy.getRestrictedRanges(StorageProxy.java:1073)
   at 
 org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:879)
   at 
 org.apache.cassandra.cql3.statements.SelectStatement.multiRangeSlice(SelectStatement.java:209)
   at 
 org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:128)
   at 
 org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
   at 
 org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
   at 
 org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
   at 
 org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
   at 
 org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
   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:184)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)

--
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: Accept all thrift update on CQL3 cf but don't expose their metadata

Updated Branches:
  refs/heads/trunk c20b33c93 - 73a4b4685


Accept all thrift update on CQL3 cf but don't expose their metadata

patch by slebresne; reviewed by xedin for CASSANDRA-4377


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/73a4b468
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/73a4b468
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/73a4b468

Branch: refs/heads/trunk
Commit: 73a4b4685c61068986e597c1a9adb8641d4de793
Parents: c20b33c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Sep 11 11:02:41 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Sep 11 11:02:41 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/config/CFMetaData.java|   22 +++---
 .../org/apache/cassandra/config/KSMetaData.java|6 +++-
 .../apache/cassandra/thrift/ThriftValidation.java  |   23 ++-
 4 files changed, 45 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/73a4b468/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f5ae4e3..98929cf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -57,6 +57,7 @@
  * Rewrite nodetool help (CASSANDRA-2293)
  * Make CQL3 the default for CQL (CASSANDRA-4640)
  * update stress tool to be able to use CQL3 (CASSANDRA-4406)
+ * Accept all thrift update on CQL3 cf but don't expose their metadata 
(CASSANDRA-4377)
 
 
 1.1.6

http://git-wip-us.apache.org/repos/asf/cassandra/blob/73a4b468/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java 
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 4e29fc7..687b5f3 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -886,12 +886,7 @@ public final class CFMetaData
 def.setKey_alias(keyAliases.get(0));
 Listorg.apache.cassandra.thrift.ColumnDef column_meta = new 
ArrayListorg.apache.cassandra.thrift.ColumnDef(column_metadata.size());
 for (ColumnDefinition cd : column_metadata.values())
-{
-// Non-null componentIndex are only used by CQL (so far) so we 
don't expose
-// them through thrift
-if (cd.componentIndex == null)
 column_meta.add(cd.toThrift());
-}
 def.setColumn_metadata(column_meta);
 def.setCompaction_strategy(compactionStrategyClass.getName());
 def.setCompaction_strategy_options(new HashMapString, 
String(compactionStrategyOptions));
@@ -1425,6 +1420,23 @@ public final class CFMetaData
 return cqlCfDef;
 }
 
+/**
+ * Returns whether this CFMetaData has information non exposed on thrift so
+ * that it cannot be correctly handled automatically by thrift clients.
+ */
+public boolean isThriftIncompatible()
+{
+if (!cqlCfDef.isComposite)
+return false;
+
+for (ColumnDefinition columnDef : column_metadata.values())
+{
+if (columnDef.componentIndex != null)
+return true;
+}
+return false;
+}
+
 @Override
 public String toString()
 {

http://git-wip-us.apache.org/repos/asf/cassandra/blob/73a4b468/src/java/org/apache/cassandra/config/KSMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/KSMetaData.java 
b/src/java/org/apache/cassandra/config/KSMetaData.java
index 50cbb91..e700444 100644
--- a/src/java/org/apache/cassandra/config/KSMetaData.java
+++ b/src/java/org/apache/cassandra/config/KSMetaData.java
@@ -179,7 +179,11 @@ public final class KSMetaData
 {
 ListCfDef cfDefs = new ArrayListCfDef(cfMetaData.size());
 for (CFMetaData cfm : cfMetaData().values())
-cfDefs.add(cfm.toThrift());
+{
+// Don't expose CF that cannot be correctly handle by thrift; see 
CASSANDRA-4377 for further details
+if (!cfm.isThriftIncompatible())
+cfDefs.add(cfm.toThrift());
+}
 KsDef ksdef = new KsDef(name, strategyClass.getName(), cfDefs);
 ksdef.setStrategy_options(strategyOptions);
 ksdef.setDurable_writes(durableWrites);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/73a4b468/src/java/org/apache/cassandra/thrift/ThriftValidation.java
--
diff --git a/src/java/org/apache/cassandra/thrift/ThriftValidation.java 
b/src/java/org/apache/cassandra/thrift/ThriftValidation.java

[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13452835#comment-13452835
 ] 

Piotr Kołaczkowski commented on CASSANDRA-4049:
---

Sorry for late reply, been busy fixing things in dse.

{quote}
{noformat}
catch (Exception e)
{
if (!snapshots.equals(name)  !backups.equals(name)
 !name.contains(.json))
logger.warn(Invalid file '{}' in data directory {}., name, 
dir);
return null;
}
{noformat}
What was the reasoning behind this? Not saying it's wrong to remove it, but I 
want to make sure we understand what it was supposed to do, before deciding we 
don't need it.
{quote}

This check was there before. Actually because this check was firing out 
warnings, we created this ticket ;)

-
 
{noformat}
catch (IOException e)
{
SetComponent components = 
Sets.newHashSetWithExpectedSize(Component.TYPES.size());
for (Component.Type componentType : Component.TYPES)
{
Component component = new Component(componentType);
if (new File(desc.filenameFor(component)).exists())
components.add(component);
}

saveTOC(desc, components);
return components;
}
{noformat}

This one is for backwards compatibility. If we find an SSTable without a TOC 
component (from previous version of C*), we just do what we always did - loop 
through all C* components. 


{quote}
Use FileUtils.closeQuietly{quote}

Oh, yeah. I was looking for IOUtils.closeQuietly, and couldn't find it. Thanks, 
that is what I needed!

{quote}
But probably simpler to just use Guava's Files.readLines{quote}

Ok, I fix it.


{quote}
Do we not know what components are necessary at construction time? Would 
strongly prefer an immutable set. Adding extra parameters to SSTW to do this is 
fine.{quote}

We do, but there is a chicken-and-egg problem here. CompactionStrategy knows. 
But CompactionStrategy needs a set of SSTables to be created. And to create 
SSTable readers you need to know the components. That is why I decided for a 
TOC component, that allows for reading the list of components at SSTable 
construction time.

The workflow of creating a new SSTable is currently as follows:

1. memtable is flushed to disk, with C* only components
2. compaction strategy is notified that a new sstable was created and gets an 
SSTableReader (with only default components)
3. compaction strategy adds its custom components to it; in order to do it, it 
has to read some components of SSTable (e.g. access the index or data file)

In order to make SSTableReader immutable, we had to ask currently installed 
compaction strategy for custom component list somewhere in the middle of this 
process, before creating SSTableReader. That is slightly more complex than what 
we have now (have to change the CS interface), but retaining full immutability 
is probably worth it.

{noformat}
public synchronized void addCustomComponent(Component component){noformat}

You are right that synchronized is wrong here. 

Thanks for great suggestions [~jbellis]. I look into improving my patch as soon 
as I'm done with the tickets I've got in the waiting queue for DSE 3.0.


 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.4.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] [Comment Edited] (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:comment-tabpanelfocusedCommentId=13452835#comment-13452835
 ] 

Piotr Kołaczkowski edited comment on CASSANDRA-4049 at 9/11/12 8:13 PM:


Sorry for late reply, been busy fixing things in dse.

{quote}
{noformat}
catch (Exception e)
{
if (!snapshots.equals(name)  !backups.equals(name)
 !name.contains(.json))
logger.warn(Invalid file '{}' in data directory {}., name, 
dir);
return null;
}
{noformat}
What was the reasoning behind this? Not saying it's wrong to remove it, but I 
want to make sure we understand what it was supposed to do, before deciding we 
don't need it.
{quote}

--This check was there before. Actually because this check was firing out 
warnings, we created this ticket ;)--
Oh, just noticed, you are referring to removed code. I think this one is not 
needed any more - it was to warn against some unknown files in the data 
directory.
I haven't removed the warning completely - just moved it elsewhere. Here it is 
(line 271):

{noformat}
if (!new File(descriptor.filenameFor(component)).exists())
logger.error(Missing component:  + 
descriptor.filenameFor(component));
{noformat}

-
 
{noformat}
catch (IOException e)
{
SetComponent components = 
Sets.newHashSetWithExpectedSize(Component.TYPES.size());
for (Component.Type componentType : Component.TYPES)
{
Component component = new Component(componentType);
if (new File(desc.filenameFor(component)).exists())
components.add(component);
}

saveTOC(desc, components);
return components;
}
{noformat}

This one is for backwards compatibility. If we find an SSTable without a TOC 
component (from previous version of C*), we just do what we always did - loop 
through all C* components. 


{quote}
Use FileUtils.closeQuietly{quote}

Oh, yeah. I was looking for IOUtils.closeQuietly, and couldn't find it. Thanks, 
that is what I needed!

{quote}
But probably simpler to just use Guava's Files.readLines{quote}

Ok, I fix it.


{quote}
Do we not know what components are necessary at construction time? Would 
strongly prefer an immutable set. Adding extra parameters to SSTW to do this is 
fine.{quote}

We do, but there is a chicken-and-egg problem here. CompactionStrategy knows. 
But CompactionStrategy needs a set of SSTables to be created. And to create 
SSTable readers you need to know the components. That is why I decided for a 
TOC component, that allows for reading the list of components at SSTable 
construction time.

The workflow of creating a new SSTable is currently as follows:

1. memtable is flushed to disk, with C* only components
2. compaction strategy is notified that a new sstable was created and gets an 
SSTableReader (with only default components)
3. compaction strategy adds its custom components to it; in order to do it, it 
has to read some components of SSTable (e.g. access the index or data file)

In order to make SSTableReader immutable, we had to ask currently installed 
compaction strategy for custom component list somewhere in the middle of this 
process, before creating SSTableReader. That is slightly more complex than what 
we have now (have to change the CS interface), but retaining full immutability 
is probably worth it.

{noformat}
public synchronized void addCustomComponent(Component component){noformat}

You are right that synchronized is wrong here. 

Thanks for great suggestions [~jbellis]. I look into improving my patch as soon 
as I'm done with the tickets I've got in the waiting queue for DSE 3.0.

  was (Author: pkolaczk):
Sorry for late reply, been busy fixing things in dse.

{quote}
{noformat}
catch (Exception e)
{
if (!snapshots.equals(name)  !backups.equals(name)
 !name.contains(.json))
logger.warn(Invalid file '{}' in data directory {}., name, 
dir);
return null;
}
{noformat}
What was the reasoning behind this? Not saying it's wrong to remove it, but I 
want to make sure we understand what it was supposed to do, before deciding we 
don't need it.
{quote}

This check was there before. Actually because this check was firing out 
warnings, we created this ticket ;)

-
 
{noformat}
catch (IOException e)
{
SetComponent components = 
Sets.newHashSetWithExpectedSize(Component.TYPES.size());
for (Component.Type componentType : Component.TYPES)
{
Component component = new Component(componentType);
if (new File(desc.filenameFor(component)).exists())

[jira] [Comment Edited] (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:comment-tabpanelfocusedCommentId=13452835#comment-13452835
 ] 

Piotr Kołaczkowski edited comment on CASSANDRA-4049 at 9/11/12 8:16 PM:


Sorry for late reply, been busy fixing things in dse.

{quote}
{noformat}
catch (Exception e)
{
if (!snapshots.equals(name)  !backups.equals(name)
 !name.contains(.json))
logger.warn(Invalid file '{}' in data directory {}., name, 
dir);
return null;
}
{noformat}
What was the reasoning behind this? Not saying it's wrong to remove it, but I 
want to make sure we understand what it was supposed to do, before deciding we 
don't need it.
{quote}

--This check was there before. Actually because this check was firing out 
warnings, we created this ticket ;)--
Oh, just noticed, you are referring to removed code. [~slebresne] said he could 
live without them. But if you insist, I can think of bringing them back. Don't 
know how to do it yet, but if it is important, I can try.


{noformat}
if (!new File(descriptor.filenameFor(component)).exists())
logger.error(Missing component:  + 
descriptor.filenameFor(component));
{noformat}

-
 
{noformat}
catch (IOException e)
{
SetComponent components = 
Sets.newHashSetWithExpectedSize(Component.TYPES.size());
for (Component.Type componentType : Component.TYPES)
{
Component component = new Component(componentType);
if (new File(desc.filenameFor(component)).exists())
components.add(component);
}

saveTOC(desc, components);
return components;
}
{noformat}

This one is for backwards compatibility. If we find an SSTable without a TOC 
component (from previous version of C*), we just do what we always did - loop 
through all C* components. 


{quote}
Use FileUtils.closeQuietly{quote}

Oh, yeah. I was looking for IOUtils.closeQuietly, and couldn't find it. Thanks, 
that is what I needed!

{quote}
But probably simpler to just use Guava's Files.readLines{quote}

Ok, I fix it.


{quote}
Do we not know what components are necessary at construction time? Would 
strongly prefer an immutable set. Adding extra parameters to SSTW to do this is 
fine.{quote}

We do, but there is a chicken-and-egg problem here. CompactionStrategy knows. 
But CompactionStrategy needs a set of SSTables to be created. And to create 
SSTable readers you need to know the components. That is why I decided for a 
TOC component, that allows for reading the list of components at SSTable 
construction time.

The workflow of creating a new SSTable is currently as follows:

1. memtable is flushed to disk, with C* only components
2. compaction strategy is notified that a new sstable was created and gets an 
SSTableReader (with only default components)
3. compaction strategy adds its custom components to it; in order to do it, it 
has to read some components of SSTable (e.g. access the index or data file)

In order to make SSTableReader immutable, we had to ask currently installed 
compaction strategy for custom component list somewhere in the middle of this 
process, before creating SSTableReader. That is slightly more complex than what 
we have now (have to change the CS interface), but retaining full immutability 
is probably worth it.

{noformat}
public synchronized void addCustomComponent(Component component){noformat}

You are right that synchronized is wrong here. 

Thanks for great suggestions [~jbellis]. I look into improving my patch as soon 
as I'm done with the tickets I've got in the waiting queue for DSE 3.0.

  was (Author: pkolaczk):
Sorry for late reply, been busy fixing things in dse.

{quote}
{noformat}
catch (Exception e)
{
if (!snapshots.equals(name)  !backups.equals(name)
 !name.contains(.json))
logger.warn(Invalid file '{}' in data directory {}., name, 
dir);
return null;
}
{noformat}
What was the reasoning behind this? Not saying it's wrong to remove it, but I 
want to make sure we understand what it was supposed to do, before deciding we 
don't need it.
{quote}

--This check was there before. Actually because this check was firing out 
warnings, we created this ticket ;)--
Oh, just noticed, you are referring to removed code. I think this one is not 
needed any more - it was to warn against some unknown files in the data 
directory.
I haven't removed the warning completely - just moved it elsewhere. Here it is 
(line 271):

{noformat}
if (!new File(descriptor.filenameFor(component)).exists())
logger.error(Missing component:  + 
descriptor.filenameFor(component));
{noformat}

[jira] [Comment Edited] (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:comment-tabpanelfocusedCommentId=13452835#comment-13452835
 ] 

Piotr Kołaczkowski edited comment on CASSANDRA-4049 at 9/11/12 8:17 PM:


Sorry for late reply, been busy fixing things in dse.

{quote}
{noformat}
catch (Exception e)
{
if (!snapshots.equals(name)  !backups.equals(name)
 !name.contains(.json))
logger.warn(Invalid file '{}' in data directory {}., name, 
dir);
return null;
}
{noformat}
What was the reasoning behind this? Not saying it's wrong to remove it, but I 
want to make sure we understand what it was supposed to do, before deciding we 
don't need it.
{quote}

--This check was there before. Actually because this check was firing out 
warnings, we created this ticket ;)--
Oh, just noticed, you are referring to removed code. [~slebresne] said he could 
live without them. But if you insist, I can think of bringing them back. Don't 
know how to do it yet, but if it is important, I can try.

On the other hand, I left the warning about missing components (which is IMHO 
much more important than some spurious components):
{noformat}
if (!new File(descriptor.filenameFor(component)).exists())
logger.error(Missing component:  + 
descriptor.filenameFor(component));
{noformat}

-
 
{noformat}
catch (IOException e)
{
SetComponent components = 
Sets.newHashSetWithExpectedSize(Component.TYPES.size());
for (Component.Type componentType : Component.TYPES)
{
Component component = new Component(componentType);
if (new File(desc.filenameFor(component)).exists())
components.add(component);
}

saveTOC(desc, components);
return components;
}
{noformat}

This one is for backwards compatibility. If we find an SSTable without a TOC 
component (from previous version of C*), we just do what we always did - loop 
through all C* components. 


{quote}
Use FileUtils.closeQuietly{quote}

Oh, yeah. I was looking for IOUtils.closeQuietly, and couldn't find it. Thanks, 
that is what I needed!

{quote}
But probably simpler to just use Guava's Files.readLines{quote}

Ok, I fix it.


{quote}
Do we not know what components are necessary at construction time? Would 
strongly prefer an immutable set. Adding extra parameters to SSTW to do this is 
fine.{quote}

We do, but there is a chicken-and-egg problem here. CompactionStrategy knows. 
But CompactionStrategy needs a set of SSTables to be created. And to create 
SSTable readers you need to know the components. That is why I decided for a 
TOC component, that allows for reading the list of components at SSTable 
construction time.

The workflow of creating a new SSTable is currently as follows:

1. memtable is flushed to disk, with C* only components
2. compaction strategy is notified that a new sstable was created and gets an 
SSTableReader (with only default components)
3. compaction strategy adds its custom components to it; in order to do it, it 
has to read some components of SSTable (e.g. access the index or data file)

In order to make SSTableReader immutable, we had to ask currently installed 
compaction strategy for custom component list somewhere in the middle of this 
process, before creating SSTableReader. That is slightly more complex than what 
we have now (have to change the CS interface), but retaining full immutability 
is probably worth it.

{noformat}
public synchronized void addCustomComponent(Component component){noformat}

You are right that synchronized is wrong here. 

Thanks for great suggestions [~jbellis]. I look into improving my patch as soon 
as I'm done with the tickets I've got in the waiting queue for DSE 3.0.

  was (Author: pkolaczk):
Sorry for late reply, been busy fixing things in dse.

{quote}
{noformat}
catch (Exception e)
{
if (!snapshots.equals(name)  !backups.equals(name)
 !name.contains(.json))
logger.warn(Invalid file '{}' in data directory {}., name, 
dir);
return null;
}
{noformat}
What was the reasoning behind this? Not saying it's wrong to remove it, but I 
want to make sure we understand what it was supposed to do, before deciding we 
don't need it.
{quote}

--This check was there before. Actually because this check was firing out 
warnings, we created this ticket ;)--
Oh, just noticed, you are referring to removed code. [~slebresne] said he could 
live without them. But if you insist, I can think of bringing them back. Don't 
know how to do it yet, but if it is important, I can try.


{noformat}
if (!new File(descriptor.filenameFor(component)).exists())

[jira] [Commented] (CASSANDRA-4500) cqlsh: understand updated encodings for collections


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452852#comment-13452852
 ] 

Sylvain Lebresne commented on CASSANDRA-4500:
-

This is a detail I suppose, but while updating dtests, I see that the python 
driver deserialize lists as python tuples rather than, well, lists. Was that on 
purpose? (one reason I can see is the fact that tuples are immutable, but it 
seems that maps are deserialized to dict which I believe are mutable, so I 
would think that it's not worth the probably less expected output in the list 
case).

 cqlsh: understand updated encodings for collections
 ---

 Key: CASSANDRA-4500
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4500
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Assignee: paul cannon
  Labels: cqlsh
 Fix For: 1.2.0 beta 1

 Attachments: 4500.patch.txt


 After CASSANDRA-4453, collections will be represented using the binary 
 encoding in thrift CqlResults instead of json. Update cqlsh (and python-cql 
 as necessary) to support.

--
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-1337) parallelize fetching rows for low-cardinality indexes


[ 
https://issues.apache.org/jira/browse/CASSANDRA-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452862#comment-13452862
 ] 

Sylvain Lebresne commented on CASSANDRA-1337:
-

I haven't had the time yet to look at the new patches, but there may be 
something wrong with the revert because the test at 
https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L1736 is 
still broken on trunk, though now it simply doesn't complete. Haven't looked 
yet but the test passes alright in 1.1.

 parallelize fetching rows for low-cardinality indexes
 -

 Key: CASSANDRA-1337
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1337
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jonathan Ellis
Assignee: David Alves
Priority: Minor
 Fix For: 1.2.1

 Attachments: 1137-bugfix.patch, 1337.patch, 1337-v4.patch, 
 ASF.LICENSE.NOT.GRANTED--0001-CASSANDRA-1337-scan-concurrently-depending-on-num-rows.txt,
  CASSANDRA-1337.patch

   Original Estimate: 8h
  Remaining Estimate: 8h

 currently, we read the indexed rows from the first node (in partitioner 
 order); if that does not have enough matching rows, we read the rows from the 
 next, and so forth.
 we should use the statistics fom CASSANDRA-1155 to query multiple nodes in 
 parallel, such that we have a high chance of getting enough rows w/o having 
 to do another round of queries (but, if our estimate is incorrect, we do need 
 to loop and do more rounds until we have enough data or we have fetched from 
 each node).

--
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: Add inet support in binary protocol

Updated Branches:
  refs/heads/trunk 73a4b4685 - c6ddbea43


Add inet support in binary protocol

patch by slebresne; reviewed by thepaul for CASSANDRA-4627


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c6ddbea4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c6ddbea4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c6ddbea4

Branch: refs/heads/trunk
Commit: c6ddbea4386d123354b07fb8ad7316abe483c0c5
Parents: 73a4b46
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Sep 11 12:10:27 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Sep 11 12:10:27 2012 +0200

--
 doc/cql3/CQL.textile   |2 ++
 doc/native_protocol.spec   |1 +
 .../org/apache/cassandra/transport/DataType.java   |1 +
 3 files changed, 4 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6ddbea4/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index e0f25da..175bac0 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -652,6 +652,7 @@ bc(syntax)..
 | decimal
 | double
 | float
+| inet
 | int
 | text
 | timestamp
@@ -672,6 +673,7 @@ p. The following table gives additional informations on the 
native data types:
 |@decimal@  |Variable-precision decimal|
 |@double@   |64-bit IEEE-754 floating point|
 |@float@|32-bit IEEE-754 floating point|
+|@inet@ |An IP address. It can be either 4 bytes long (IPv4) or 16 bytes 
long (IPv6)|
 |@int@  |32-bit signed int|
 |@text@ |UTF8 encoded string|
 |@timestamp@|A timestamp. See Working with dates:#usingdates below for more 
information.|

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6ddbea4/doc/native_protocol.spec
--
diff --git a/doc/native_protocol.spec b/doc/native_protocol.spec
index 07d5c69..0dd5c14 100644
--- a/doc/native_protocol.spec
+++ b/doc/native_protocol.spec
@@ -384,6 +384,7 @@ Table of Contents
 0x000DVarchar
 0x000EVarint
 0x000FTimeuuid
+0x0010Inet
 0x0020List: the value is an [option], representing the type
 of the elements of the list.
 0x0021Map: the value is two [option], representing the types 
of the

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6ddbea4/src/java/org/apache/cassandra/transport/DataType.java
--
diff --git a/src/java/org/apache/cassandra/transport/DataType.java 
b/src/java/org/apache/cassandra/transport/DataType.java
index 29d7a93..0cb9d2d 100644
--- a/src/java/org/apache/cassandra/transport/DataType.java
+++ b/src/java/org/apache/cassandra/transport/DataType.java
@@ -48,6 +48,7 @@ public enum DataType implements 
OptionCodec.CodecableDataType
 VARCHAR  (13, UTF8Type.instance),
 VARINT   (14, IntegerType.instance),
 TIMEUUID (15, TimeUUIDType.instance),
+INET (16, InetAddressType.instance),
 LIST (32, null),
 MAP  (33, null),
 SET  (34, null);

[jira] [Commented] (CASSANDRA-4627) support inet data type


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452873#comment-13452873
 ] 

Sylvain Lebresne commented on CASSANDRA-4627:
-

I know that was for cqlsh :)

Anyway, I've committed the patch but leaving that open until the driver is 
updated

 support inet data type
 --

 Key: CASSANDRA-4627
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4627
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Assignee: paul cannon
  Labels: cql, cqlsh
 Fix For: 1.2.0 beta 1

 Attachments: 4627.txt


 CASSANDRA-4018 introduced a new cassandra data type with a cql name inet, 
 which is not yet supported in cqlsh. Add support for decoding and formatting.

--
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 assumption error in CLI when updating/describing keyspace patch by Pavel Yaskevich; reviewed by Dave Brosius for CASSANDRA-4322

2012-09-11 Thread xedin

Updated Branches:
  refs/heads/cassandra-1.1 e172a9b73 - 98708d817


fix assumption error in CLI when updating/describing keyspace
patch by Pavel Yaskevich; reviewed by Dave Brosius for CASSANDRA-4322


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/98708d81
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/98708d81
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/98708d81

Branch: refs/heads/cassandra-1.1
Commit: 98708d817f8df91be4cfcba06c9523027fab881c
Parents: e172a9b
Author: Pavel Yaskevich xe...@apache.org
Authored: Sat Sep 8 21:57:46 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Tue Sep 11 14:11:36 2012 +0300

--
 CHANGES.txt  |1 +
 src/java/org/apache/cassandra/cli/CliClient.java |   38 +++-
 2 files changed, 27 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/98708d81/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 246bc49..b6fe049 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
 1.1.6
  * Improve IAuthority interface by introducing fine-grained
access permissions and grant/revoke commands (CASSANDRA-4490)
+ * fix assumption error in CLI when updating/describing keyspace 
(CASSANDRA-4322)
 
 
 1.1.5

http://git-wip-us.apache.org/repos/asf/cassandra/blob/98708d81/src/java/org/apache/cassandra/cli/CliClient.java
--
diff --git a/src/java/org/apache/cassandra/cli/CliClient.java 
b/src/java/org/apache/cassandra/cli/CliClient.java
index 8296253..d0fb543 100644
--- a/src/java/org/apache/cassandra/cli/CliClient.java
+++ b/src/java/org/apache/cassandra/cli/CliClient.java
@@ -1068,7 +1068,7 @@ public class CliClient
 sessionState.out.println(mySchemaVersion);
 validateSchemaIsSettled(mySchemaVersion);
 keyspacesMap.remove(keyspaceName);
-getKSMetaData(keySpace);
+getKSMetaData(keyspaceName);
 }
 catch (InvalidRequestException e)
 {
@@ -1879,15 +1879,19 @@ public class CliClient
  * Returns true if this.keySpace is set, false otherwise
  * @return boolean
  */
-private boolean hasKeySpace()
+private boolean hasKeySpace(boolean printError)
 {
-   if (keySpace == null)
-{
-sessionState.out.println(Not authenticated to a working 
keyspace.);
-return false;
-}
+boolean hasKeyspace = keySpace != null;
 
-return true;
+if (!hasKeyspace  printError)
+sessionState.err.println(Not authorized to a working keyspace.);
+
+return hasKeyspace;
+}
+
+private boolean hasKeySpace()
+{
+return hasKeySpace(true);
 }
 
 public String getKeySpace()
@@ -2142,9 +2146,19 @@ public class CliClient
 return;
 
 int argCount = statement.getChildCount();
-
-keyspacesMap.remove(keySpace);
-KsDef currentKeySpace = getKSMetaData(keySpace);
+
+if (keySpace == null  argCount == 0)
+{
+sessionState.out.println(Authenticate to a Keyspace, before using 
`describe` or `describe column_family`);
+return;
+}
+
+KsDef currentKeySpace = null;
+if (keySpace != null)
+{
+keyspacesMap.remove(keySpace);
+currentKeySpace = getKSMetaData(keySpace);
+}
 
 if (argCount  1) // in case somebody changes Cli grammar
 throw new RuntimeException(`describe` command take maximum one 
argument. See `help describe;`);
@@ -2996,7 +3010,7 @@ public class CliClient
 
 public void replayAssumptions(String keyspace)
 {
-if (!CliMain.isConnected() || !hasKeySpace())
+if (!CliMain.isConnected() || !hasKeySpace(false))
 return;
 
 MapString, MapString, String cfAssumes = 
assumptions.get(keyspace);

[2/2] git commit: fix assumption error in CLI when updating/describing keyspace patch by Pavel Yaskevich; reviewed by Dave Brosius for CASSANDRA-4322

2012-09-11 Thread xedin

fix assumption error in CLI when updating/describing keyspace
patch by Pavel Yaskevich; reviewed by Dave Brosius for CASSANDRA-4322


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/98708d81
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/98708d81
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/98708d81

Branch: refs/heads/trunk
Commit: 98708d817f8df91be4cfcba06c9523027fab881c
Parents: e172a9b
Author: Pavel Yaskevich xe...@apache.org
Authored: Sat Sep 8 21:57:46 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Tue Sep 11 14:11:36 2012 +0300

--
 CHANGES.txt  |1 +
 src/java/org/apache/cassandra/cli/CliClient.java |   38 +++-
 2 files changed, 27 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/98708d81/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 246bc49..b6fe049 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
 1.1.6
  * Improve IAuthority interface by introducing fine-grained
access permissions and grant/revoke commands (CASSANDRA-4490)
+ * fix assumption error in CLI when updating/describing keyspace 
(CASSANDRA-4322)
 
 
 1.1.5

http://git-wip-us.apache.org/repos/asf/cassandra/blob/98708d81/src/java/org/apache/cassandra/cli/CliClient.java
--
diff --git a/src/java/org/apache/cassandra/cli/CliClient.java 
b/src/java/org/apache/cassandra/cli/CliClient.java
index 8296253..d0fb543 100644
--- a/src/java/org/apache/cassandra/cli/CliClient.java
+++ b/src/java/org/apache/cassandra/cli/CliClient.java
@@ -1068,7 +1068,7 @@ public class CliClient
 sessionState.out.println(mySchemaVersion);
 validateSchemaIsSettled(mySchemaVersion);
 keyspacesMap.remove(keyspaceName);
-getKSMetaData(keySpace);
+getKSMetaData(keyspaceName);
 }
 catch (InvalidRequestException e)
 {
@@ -1879,15 +1879,19 @@ public class CliClient
  * Returns true if this.keySpace is set, false otherwise
  * @return boolean
  */
-private boolean hasKeySpace()
+private boolean hasKeySpace(boolean printError)
 {
-   if (keySpace == null)
-{
-sessionState.out.println(Not authenticated to a working 
keyspace.);
-return false;
-}
+boolean hasKeyspace = keySpace != null;
 
-return true;
+if (!hasKeyspace  printError)
+sessionState.err.println(Not authorized to a working keyspace.);
+
+return hasKeyspace;
+}
+
+private boolean hasKeySpace()
+{
+return hasKeySpace(true);
 }
 
 public String getKeySpace()
@@ -2142,9 +2146,19 @@ public class CliClient
 return;
 
 int argCount = statement.getChildCount();
-
-keyspacesMap.remove(keySpace);
-KsDef currentKeySpace = getKSMetaData(keySpace);
+
+if (keySpace == null  argCount == 0)
+{
+sessionState.out.println(Authenticate to a Keyspace, before using 
`describe` or `describe column_family`);
+return;
+}
+
+KsDef currentKeySpace = null;
+if (keySpace != null)
+{
+keyspacesMap.remove(keySpace);
+currentKeySpace = getKSMetaData(keySpace);
+}
 
 if (argCount  1) // in case somebody changes Cli grammar
 throw new RuntimeException(`describe` command take maximum one 
argument. See `help describe;`);
@@ -2996,7 +3010,7 @@ public class CliClient
 
 public void replayAssumptions(String keyspace)
 {
-if (!CliMain.isConnected() || !hasKeySpace())
+if (!CliMain.isConnected() || !hasKeySpace(false))
 return;
 
 MapString, MapString, String cfAssumes = 
assumptions.get(keyspace);

[1/2] git commit: merge from 1.1

2012-09-11 Thread xedin

Updated Branches:
  refs/heads/trunk c6ddbea43 - b85c93e0a


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/b85c93e0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b85c93e0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b85c93e0

Branch: refs/heads/trunk
Commit: b85c93e0a89ace02b4a73d49a75976d7fbce6115
Parents: c6ddbea 98708d8
Author: Pavel Yaskevich xe...@apache.org
Authored: Tue Sep 11 14:16:22 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Tue Sep 11 14:16:22 2012 +0300

--
 CHANGES.txt  |9 +---
 src/java/org/apache/cassandra/cli/CliClient.java |   36 +++-
 2 files changed, 28 insertions(+), 17 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b85c93e0/CHANGES.txt
--
diff --cc CHANGES.txt
index 98929cf,b6fe049..00971a5
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,72 -1,7 +1,69 @@@
 +1.2-beta1
 + * add atomic_batch_mutate (CASSANDRA-4542, -4635)
 + * increase default max_hint_window_in_ms to 3h (CASSANDRA-4632)
 + * include message initiation time to replicas so they can more
 +   accurately drop timed-out requests (CASSANDRA-2858)
 + * fix clientutil.jar dependencies (CASSANDRA-4566)
 + * optimize WriteResponse (CASSANDRA-4548)
 + * new metrics (CASSANDRA-4009)
 + * redesign KEYS indexes to avoid read-before-write (CASSANDRA-2897)
 + * debug tracing (CASSANDRA-1123)
 + * parallelize row cache loading (CASSANDRA-4282)
 + * Make compaction, flush JBOD-aware (CASSANDRA-4292)
 + * run local range scans on the read stage (CASSANDRA-3687)
 + * clean up ioexceptions (CASSANDRA-2116)
 + * add disk_failure_policy (CASSANDRA-2118)
 + * Introduce new json format with row level deletion (CASSANDRA-4054)
 + * remove redundant name column from schema_keyspaces (CASSANDRA-4433)
 + * improve nodetool ring handling of multi-dc clusters (CASSANDRA-3047)
 + * update NTS calculateNaturalEndpoints to be O(N log N) (CASSANDRA-3881)
 + * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366)
 + * split up rpc timeout by operation type (CASSANDRA-2819)
 + * rewrite key cache save/load to use only sequential i/o (CASSANDRA-3762)
 + * update MS protocol with a version handshake + broadcast address id
 +   (CASSANDRA-4311)
 + * multithreaded hint replay (CASSANDRA-4189)
 + * add inter-node message compression (CASSANDRA-3127)
 + * remove COPP (CASSANDRA-2479)
 + * Track tombstone expiration and compact when tombstone content is
 +   higher than a configurable threshold, default 20% (CASSANDRA-3442, 4234)
 + * update MurmurHash to version 3 (CASSANDRA-2975)
 + * (CLI) track elapsed time for `delete' operation (CASSANDRA-4060)
 + * (CLI) jline version is bumped to 1.0 to properly  support
 +   'delete' key function (CASSANDRA-4132)
 + * Save IndexSummary into new SSTable 'Summary' component (CASSANDRA-2392, 
4289)
 + * Add support for range tombstones (CASSANDRA-3708)
 + * Improve MessagingService efficiency (CASSANDRA-3617)
 + * Avoid ID conflicts from concurrent schema changes (CASSANDRA-3794)
 + * Set thrift HSHA server thread limit to unlimited by default 
(CASSANDRA-4277)
 + * Avoids double serialization of CF id in RowMutation messages
 +   (CASSANDRA-4293)
 + * stream compressed sstables directly with java nio (CASSANDRA-4297)
 + * Support multiple ranges in SliceQueryFilter (CASSANDRA-3885)
 + * Add column metadata to system column families (CASSANDRA-4018)
 + * (cql3) Always use composite types by default (CASSANDRA-4329)
 + * (cql3) Add support for set, map and list (CASSANDRA-3647)
 + * Validate date type correctly (CASSANDRA-4441)
 + * (cql3) Allow definitions with only a PK (CASSANDRA-4361)
 + * (cql3) Add support for row key composites (CASSANDRA-4179)
 + * improve DynamicEndpointSnitch by using reservoir sampling (CASSANDRA-4038)
 + * (cql3) Add support for 2ndary indexes (CASSANDRA-3680)
 + * (cql3) fix defining more than one PK to be invalid (CASSANDRA-4477)
 + * remove schema agreement checking from all external APIs (Thrift, CQL and 
CQL3) (CASSANDRA-4487)
 + * add Murmur3Partitioner and make it default for new installations 
(CASSANDRA-3772)
 + * (cql3) update pseudo-map syntax to use map syntax (CASSANDRA-4497)
 + * Finer grained exceptions hierarchy and provides error code with exceptions 
(CASSANDRA-3979)
 + * Adds events push to binary protocol (CASSANDRA-4480)
 + * Rewrite nodetool help (CASSANDRA-2293)
 + * Make CQL3 the default for CQL (CASSANDRA-4640)
 + * update stress tool to be able to use CQL3 (CASSANDRA-4406)
 + * Accept all thrift update on CQL3 cf but don't expose their metadata 
(CASSANDRA-4377)
 +
 +
  1.1.6
-   * (cql3) fix potential NPE with both equal and unequal

[jira] [Assigned] (CASSANDRA-4622) corrupted saved caches

2012-09-11 Thread Brandon Williams (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams reassigned CASSANDRA-4622:
---

Assignee: Vijay

 corrupted saved caches
 --

 Key: CASSANDRA-4622
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4622
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams
Assignee: Vijay
 Fix For: 1.2.0


 I'm seeing this fairly frequently on trunk:
 {noformat}
  INFO 05:15:23,805 reading saved cache 
 /var/lib/cassandra/saved_caches/system-schema_columnfamilies-KeyCache-b.db
  WARN 05:15:23,808 error reading saved cache 
 /var/lib/cassandra/saved_caches/system-schema_columnfamilies-KeyCache-b.db
 java.lang.NullPointerException
 at 
 org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:151)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:247)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:362)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:334)
 at org.apache.cassandra.db.Table.initCf(Table.java:333)
 at org.apache.cassandra.db.Table.init(Table.java:271)
 at org.apache.cassandra.db.Table.open(Table.java:101)
 at org.apache.cassandra.db.Table.open(Table.java:79)
 at 
 org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:285)
 at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:201)
 at 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:349)
 at 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:392)
  INFO 05:15:23,858 Opening 
 /var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-ia-5 
 (171 bytes)
  INFO 05:15:23,870 Opening 
 /var/lib/cassandra/data/system/peers/system-peers-ia-1 (7983 bytes)
  INFO 05:15:23,870 Opening 
 /var/lib/cassandra/data/system/peers/system-peers-ia-2 (7876 bytes)
  INFO 05:15:23,884 Opening 
 /var/lib/cassandra/data/system/local/system-local-ia-35 (4910 bytes)
  INFO 05:15:23,885 Opening 
 /var/lib/cassandra/data/system/local/system-local-ia-33 (75 bytes)
  INFO 05:15:23,885 Opening 
 /var/lib/cassandra/data/system/local/system-local-ia-34 (4676 bytes)
  INFO 05:15:23,912 reading saved cache 
 /var/lib/cassandra/saved_caches/system-local-KeyCache-b.db
  WARN 05:15:23,912 error reading saved cache 
 /var/lib/cassandra/saved_caches/system-local-KeyCache-b.db
 java.lang.NullPointerException
 at 
 org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:151)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:247)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:362)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:334)
 at org.apache.cassandra.db.Table.initCf(Table.java:333)
 at org.apache.cassandra.db.Table.init(Table.java:271)
 at org.apache.cassandra.db.Table.open(Table.java:101)
 at org.apache.cassandra.db.Table.open(Table.java:79)
 at 
 org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:285)
 at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:201)
 at 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:349)
 at 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:392)
 {noformat}

--
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-4417) invalid counter shard detected

[
https://issues.apache.org/jira/browse/CASSANDRA-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453058#comment-13453058
]

Sylvain Lebresne commented on CASSANDRA-4417:
-

That's a very good point. Counters do rely on the fact that nodes do not lose
the increments they are leader for (or that they don't reuse the same nodeId
if they do), but unless the commit log uses batch mode, this can happen. And
that will lead to exactly the exception seen here, so I'd say there's a very
good chance this is the problem.

I'll note that if that is indeed a problem, it's very possible that the error
logged happens only much later (after the unclean shutdown) and on some other
node than the one having died. So not being able to correlate the error to an
unclean shutdown doesn't really indicate that it's not related.

The consequence of this happening is that the increments that have been lost
with un-synced commit log are lost. Meaning that with the default
configuration, one could lose up to 10 seconds of the increments (for which the
dying node is leader). However, I think it is also possible to have results
from read to miss slightly more than that, though that last part should fix
itself if the counter is incremented again.

As for the error message logged, it's possible that lots of them are logged
even though only a small number of counters are affected since it's print
during column reconciliation and thus could be logged many time for the same
counter.

A simple workaround is to use batch commit log, but that has a potentially
important performance impact.

Another solution I've though of would be to try to detect unclean shutdown (by
marking something during clean shutdown and checking for that at startup) and
if we detect one, to renew the nodeId. The problem with that is that this
potentially mean renewing the nodeId pretty often. And each time we do that,
the internal representation of counter grow and I'm really afraid it will be a
problem in that case. And while we have some mechanism to shrink back counter
by merging sub-counts when the nodeId is renewed too often, that mechanism
assumes that the node owning the nodeId has the more up-to-date value for this
sub-count, which is exactly the problem here. So overall I don't have any good
idea to fix this. Other ideas?

invalid counter shard detected
---

Key: CASSANDRA-4417
URL: https://issues.apache.org/jira/browse/CASSANDRA-4417
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.1
Environment: Amazon Linux
Reporter: Senthilvel Rangaswamy

Seeing errors like these:
2012-07-06_07:00:27.22662 ERROR 07:00:27,226 invalid counter shard detected;
(17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 13) and
(17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 1) differ only in count; will pick
highest to self-heal; this indicates a bug or corruption generated a bad
counter shard
What does it mean ?

--
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-3515) track tombstones skipped on read path

2012-09-11 Thread Pavel Yaskevich (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453062#comment-13453062
 ] 

Pavel Yaskevich commented on CASSANDRA-3515:


+1

 track tombstones skipped on read path
 -

 Key: CASSANDRA-3515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3515
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jackson Chung
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 1.2.0

 Attachments: 3515.txt


 i think summary says it all, but see further:
 {noformat}
  driftx x: I guess we could add a histogram of how many tombstones we 
 filtered on a read
  driftx x: @action: go for it in that context
  action jackson: thx!
  mdennis x: +1 on histogram of filtered tombstones
  driftx x: definitely useful for diagnosing the queue-like case
  driftx x: the histogram I mea
 {noformat}

--
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-4639) Incorrect counter values

2012-09-11 Thread Omid Aladini (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453065#comment-13453065
]

Omid Aladini commented on CASSANDRA-4639:
-

This looks the same as CASSANDRA-4417 which is currently in progress.

Incorrect counter values

Key: CASSANDRA-4639
URL: https://issues.apache.org/jira/browse/CASSANDRA-4639
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: We've got a production 21 node cluster with 3 virtual
data centers. Keyspace that contains counter column families has a
replication 3 on DC1 and 1 on DC3. DC1 is using SSD drives, DC3 spinning hard
drives. We are using Ubuntu Server as an OS. Machines have 24GB of RAM.
Reporter: Bartłomiej Romański
Priority: Critical

Since yesterday almost all counters are incorrect. Usually about 4-5 times
higher than expected. In logs we've got this message:
ERROR [MutationStage:15] 2012-09-10 13:47:13,280 CounterContext.java (line
381) invalid counter shard detected; (6de8e940-dd23-11e1--5233df6faaff,
7, 242) and (6de8e940-dd23-11e1--5233df6faaff, 7, 392) differ only in
count; will pick highest to self-heal; this indicates a bug or corruption
generated a bad counter shard
every couple of seconds.
This cluster was running without any serious problems for at least 2 months.
Any ideas?

[jira] [Created] (CASSANDRA-4644) Compaction error with Cassandra 1.1.4 and LCS

2012-09-11 Thread Rudolf VanderLeeden (JIRA)

Rudolf VanderLeeden created CASSANDRA-4644:
--

 Summary: Compaction error with Cassandra 1.1.4 and LCS 
 Key: CASSANDRA-4644
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4644
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.4
 Environment: Cassandra 1.1.4, Ubuntu Lucid (2.6.32-346), Amazon EC2 
m1.xlarge
Reporter: Rudolf VanderLeeden


In our 1.1.4 testcluster of 3 nodes with RF=3, KS=1, and CF=5, we are getting 
an asserting error when running 'nodetool compact highscores leaderboard'. This 
stops compactions on the 'leaderboard' CF summing up to 11835 pending 
compactions. This error is seen only one one node. 

The SSTables have originally been created on a 1.1.2 cluster with STCS and then 
copied to the testcluster also with 1.1.2. Repair, cleanup, compact were OK 
with STCS. Next, we changed to LCS and did again repair, cleanup, compact with 
success. 

Then we started to use this LCS-based testcluster intensively and created lots 
of data and also large keys with millions of columns. 

The assertion error in system.log :
 INFO [CompactionExecutor:8] 2012-09-11 14:20:45,043 CompactionController.java 
(line 172) Compacting large row 
highscores/leaderboard:4c422d64626331353166372d363464612d343235342d396130322d6535616365343337373532332d676c6f62616c2d30
 (72589650 bytes) incrementally
ERROR [CompactionExecutor:8] 2012-09-11 14:20:50,336 
AbstractCassandraDaemon.java (line 135) Exception in thread 
Thread[CompactionExecutor:8,1,RMI Runtime]
java.lang.AssertionError
at 
org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214)
at 
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158)
at 
org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:531)
at 
org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:254)
at 
org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:992)
at 
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:200)
at 
org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:50)
at 
org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:288)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)



--
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-4611) Add AlterKeyspace statement

2012-09-11 Thread Pavel Yaskevich (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453076#comment-13453076
 ] 

Pavel Yaskevich commented on CASSANDRA-4611:


Sylvain, can you please rebase?

 Add AlterKeyspace statement
 ---

 Key: CASSANDRA-4611
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4611
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
  Labels: cql3
 Fix For: 1.2.0 beta 1

 Attachments: 4611.txt


 Somehow we never added an ALTER KEYSPACE statement. We should.

--
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-4645) (CQL3) Re-allow order by on non-selected columns

Sylvain Lebresne created CASSANDRA-4645:
---

 Summary: (CQL3) Re-allow order by on non-selected columns
 Key: CASSANDRA-4645
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4645
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Sylvain Lebresne
Priority: Minor
 Fix For: 1.2.0


CASSANDRA-4612 added a limitation to ORDER BY query in that it requires the 
columns part of the ORDER BY to be in the select clause, while this wasn't the 
case previously.

The reason for that is that for ORDER BY with IN queries, the sorting is done 
post-query, and by the time we do the ordering, we've already cut down the 
result set to the select clause, so if the column are not in the select clause 
we cannot sort on them.

We should remove that that limitation however as this is a regression from what 
we had before. As far as 1.2.0 is concerned, at the very least we should lift 
the limitation for EQ queries since we don't do any post-query sorting in that 
case and that was working correctly pre-CASSANDRA-4612. But we should also 
remove that limitation for IN query, even if it's in a second time.

--
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: Remove merge markers in changelog

Updated Branches:
  refs/heads/trunk b85c93e0a - 208d77b7a


Remove merge markers in changelog


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/208d77b7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/208d77b7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/208d77b7

Branch: refs/heads/trunk
Commit: 208d77b7a3ed06980f0077bdd3ffc91572a24c1e
Parents: b85c93e
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Sep 11 17:22:24 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Sep 11 17:22:24 2012 +0200

--
 CHANGES.txt |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/208d77b7/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 00971a5..c06554f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -100,10 +100,7 @@ Merged from 1.0:
  * (Hadoop) fix setting key length for old-style mapred api (CASSANDRA-4534)
  * (Hadoop) fix iterating through a resultset consisting entirely
of tombstoned rows (CASSANDRA-4466)
- HEAD
  * Fix multiple values for CurrentLocal NodeID (CASSANDRA-4626)
-===
- cassandra-1.1
 
 
  * munmap commitlog segments before rename (CASSANDRA-4337)

[jira] [Updated] (CASSANDRA-4611) Add AlterKeyspace statement


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-4611:


Attachment: (was: 4611.txt)

 Add AlterKeyspace statement
 ---

 Key: CASSANDRA-4611
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4611
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
  Labels: cql3
 Fix For: 1.2.0 beta 1

 Attachments: 4611.txt


 Somehow we never added an ALTER KEYSPACE statement. We should.

--
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-4611) Add AlterKeyspace statement