[3/4] git commit: Merge branch 'cassandra-2.0.0' into cassandra-2.0

2013-08-22 Thread dbrosius
Merge branch 'cassandra-2.0.0' into cassandra-2.0


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

Branch: refs/heads/trunk
Commit: ed79c143995f98f25860e626d13dd8261c1150be
Parents: 05929c0 af9c707
Author: Dave Brosius 
Authored: Thu Aug 22 21:18:53 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:18:53 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--




[4/4] git commit: Merge branch 'cassandra-2.0' into trunk

2013-08-22 Thread dbrosius
Merge branch 'cassandra-2.0' into trunk


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

Branch: refs/heads/trunk
Commit: 239e2d7176531730b8480ba9e912d2f3ce1ada90
Parents: 3f5322f ed79c14
Author: Dave Brosius 
Authored: Thu Aug 22 21:19:45 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:19:45 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--




[2/4] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0.0

2013-08-22 Thread dbrosius
Merge branch 'cassandra-1.2' into cassandra-2.0.0


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

Branch: refs/heads/trunk
Commit: af9c7074ffb443e254e627690c5faa365f08866a
Parents: 624a7a0 ddb501d
Author: Dave Brosius 
Authored: Thu Aug 22 21:16:53 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:16:53 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/af9c7074/bin/nodetool
--



[1/4] git commit: fix nodetool getendpoints when the key has a space in it patch by gdeangelis reviewed by dbrosius for CASSANDRA-4551

2013-08-22 Thread dbrosius
Updated Branches:
  refs/heads/trunk 3f5322f02 -> 239e2d717


fix nodetool getendpoints when the key has a space in it
patch by gdeangelis reviewed by dbrosius for CASSANDRA-4551


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

Branch: refs/heads/trunk
Commit: ddb501df408af59e213380263f3c519d11b89977
Parents: 39066b7
Author: Dave Brosius 
Authored: Thu Aug 22 21:13:24 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:13:24 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddb501df/bin/nodetool
--
diff --git a/bin/nodetool b/bin/nodetool
index c602530..ef79f66 100755
--- a/bin/nodetool
+++ b/bin/nodetool
@@ -59,6 +59,6 @@ esac
   -Xmx32m \
   -Dlog4j.configuration=log4j-tools.properties \
   -Dstorage-config="$CASSANDRA_CONF" \
-  org.apache.cassandra.tools.NodeCmd $@
+  org.apache.cassandra.tools.NodeCmd ${1+"$@"}
 
 # vi:ai sw=4 ts=4 tw=0 et



[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0.0

2013-08-22 Thread dbrosius
Merge branch 'cassandra-1.2' into cassandra-2.0.0


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

Branch: refs/heads/cassandra-2.0
Commit: af9c7074ffb443e254e627690c5faa365f08866a
Parents: 624a7a0 ddb501d
Author: Dave Brosius 
Authored: Thu Aug 22 21:16:53 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:16:53 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/af9c7074/bin/nodetool
--



[1/3] git commit: fix nodetool getendpoints when the key has a space in it patch by gdeangelis reviewed by dbrosius for CASSANDRA-4551

2013-08-22 Thread dbrosius
Updated Branches:
  refs/heads/cassandra-2.0 05929c05c -> ed79c1439


fix nodetool getendpoints when the key has a space in it
patch by gdeangelis reviewed by dbrosius for CASSANDRA-4551


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

Branch: refs/heads/cassandra-2.0
Commit: ddb501df408af59e213380263f3c519d11b89977
Parents: 39066b7
Author: Dave Brosius 
Authored: Thu Aug 22 21:13:24 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:13:24 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddb501df/bin/nodetool
--
diff --git a/bin/nodetool b/bin/nodetool
index c602530..ef79f66 100755
--- a/bin/nodetool
+++ b/bin/nodetool
@@ -59,6 +59,6 @@ esac
   -Xmx32m \
   -Dlog4j.configuration=log4j-tools.properties \
   -Dstorage-config="$CASSANDRA_CONF" \
-  org.apache.cassandra.tools.NodeCmd $@
+  org.apache.cassandra.tools.NodeCmd ${1+"$@"}
 
 # vi:ai sw=4 ts=4 tw=0 et



[3/3] git commit: Merge branch 'cassandra-2.0.0' into cassandra-2.0

2013-08-22 Thread dbrosius
Merge branch 'cassandra-2.0.0' into cassandra-2.0


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

Branch: refs/heads/cassandra-2.0
Commit: ed79c143995f98f25860e626d13dd8261c1150be
Parents: 05929c0 af9c707
Author: Dave Brosius 
Authored: Thu Aug 22 21:18:53 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:18:53 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--




[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0.0

2013-08-22 Thread dbrosius
Merge branch 'cassandra-1.2' into cassandra-2.0.0


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

Branch: refs/heads/cassandra-2.0.0
Commit: af9c7074ffb443e254e627690c5faa365f08866a
Parents: 624a7a0 ddb501d
Author: Dave Brosius 
Authored: Thu Aug 22 21:16:53 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:16:53 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/af9c7074/bin/nodetool
--



[1/2] git commit: fix nodetool getendpoints when the key has a space in it patch by gdeangelis reviewed by dbrosius for CASSANDRA-4551

2013-08-22 Thread dbrosius
Updated Branches:
  refs/heads/cassandra-2.0.0 624a7a02f -> af9c7074f


fix nodetool getendpoints when the key has a space in it
patch by gdeangelis reviewed by dbrosius for CASSANDRA-4551


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

Branch: refs/heads/cassandra-2.0.0
Commit: ddb501df408af59e213380263f3c519d11b89977
Parents: 39066b7
Author: Dave Brosius 
Authored: Thu Aug 22 21:13:24 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:13:24 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddb501df/bin/nodetool
--
diff --git a/bin/nodetool b/bin/nodetool
index c602530..ef79f66 100755
--- a/bin/nodetool
+++ b/bin/nodetool
@@ -59,6 +59,6 @@ esac
   -Xmx32m \
   -Dlog4j.configuration=log4j-tools.properties \
   -Dstorage-config="$CASSANDRA_CONF" \
-  org.apache.cassandra.tools.NodeCmd $@
+  org.apache.cassandra.tools.NodeCmd ${1+"$@"}
 
 # vi:ai sw=4 ts=4 tw=0 et



git commit: fix nodetool getendpoints when the key has a space in it patch by gdeangelis reviewed by dbrosius for CASSANDRA-4551

2013-08-22 Thread dbrosius
Updated Branches:
  refs/heads/cassandra-1.2 39066b722 -> ddb501df4


fix nodetool getendpoints when the key has a space in it
patch by gdeangelis reviewed by dbrosius for CASSANDRA-4551


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

Branch: refs/heads/cassandra-1.2
Commit: ddb501df408af59e213380263f3c519d11b89977
Parents: 39066b7
Author: Dave Brosius 
Authored: Thu Aug 22 21:13:24 2013 -0400
Committer: Dave Brosius 
Committed: Thu Aug 22 21:13:24 2013 -0400

--
 bin/nodetool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddb501df/bin/nodetool
--
diff --git a/bin/nodetool b/bin/nodetool
index c602530..ef79f66 100755
--- a/bin/nodetool
+++ b/bin/nodetool
@@ -59,6 +59,6 @@ esac
   -Xmx32m \
   -Dlog4j.configuration=log4j-tools.properties \
   -Dstorage-config="$CASSANDRA_CONF" \
-  org.apache.cassandra.tools.NodeCmd $@
+  org.apache.cassandra.tools.NodeCmd ${1+"$@"}
 
 # vi:ai sw=4 ts=4 tw=0 et



[jira] [Commented] (CASSANDRA-5337) vnode-aware replacenode command

2013-08-22 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13748170#comment-13748170
 ] 

Brandon Williams commented on CASSANDRA-5337:
-

Those were fixed post-commit.

> vnode-aware replacenode command
> ---
>
> Key: CASSANDRA-5337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5337
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.2.0
>Reporter: Jonathan Ellis
>Assignee: Brandon Williams
>  Labels: vnodes
> Fix For: 1.2.7, 2.0
>
> Attachments: 5337.txt, 5337-v2.txt
>
>
> Currently you have the following options to replace a dead, unrecoverable 
> node:
> - replacetoken.  this requires specifying all 256 or so vnode tokens as a CSL
> - bootstrap new node, decommission old one.  this is inefficient since the 
> new node's vnodes will probably not overlap much with the old one's, so we 
> replicate stream about 2x as much as if we were just replacing the old with 
> the new
> We should add an analogue to replacetoken that takes the address or node ID 
> of the dead node instead.

--
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-5925) Race condition in update lightweight transaction

2013-08-22 Thread Phil Persad (JIRA)
Phil Persad created CASSANDRA-5925:
--

 Summary: Race condition in update lightweight transaction
 Key: CASSANDRA-5925
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5925
 Project: Cassandra
  Issue Type: Bug
 Environment: 3 node Cassandra 2.0.0-rc2 cluster. Java driver 1.0.2.
Reporter: Phil Persad


I'm building some tests for a Cassandra PoC.  One scenario I need to test is 
consumption of 1 time tokens.  These tokens must be consumed exactly once.  The 
cluster involved is a 3 node cluster.  All queries are run with 
ConsistencyLevel.QUORUM. I'm using the following queries:

CREATE KEYSPACE IF NOT EXISTS test WITH replication = { 'class' : 
'SimpleStrategy', 'replication_factor' : 3 };

CREATE TABLE IF NOT EXISTS tkns (tkn blob, consumed boolean, PRIMARY KEY (tkn));

INSERT INTO tkns (tkn, consumed) VALUES (?,FALSE) USING TTL 30;

UPDATE tkns USING TTL 1 SET consumed = TRUE WHERE tkn = ? IF consumed = FALSE;

I use the '[applied]' column in the result set of the update statement to 
determine whether the token has been successfully consumed or if the token is 
being replayed.

My test involves concurrently executing many sets of 1 insert and 2 update 
statements (using Session#execute on BoundStatemnts) then checking to make sure 
that only one of the updates was applied.

When I run this test with relatively few iterations (~100) my results are  what 
I expect (exactly 1 update succeeds).  At ~1000 iterations, I start seeing both 
updates reporting success in 1-2% of cases.  While my test is running, I see 
corresponding error entries in the Cassandra log:

ERROR 15:34:53,583 Exception in thread Thread[MutationStage:522,5,main]
java.lang.NullPointerException
ERROR 15:34:53,584 Exception in thread Thread[MutationStage:474,5,main]
java.lang.NullPointerException
ERROR 15:34:53,584 Exception in thread Thread[MutationStage:536,5,main]
java.lang.NullPointerException
ERROR 15:34:53,729 Exception in thread Thread[MutationStage:480,5,main]
java.lang.NullPointerException
ERROR 15:34:53,729 Exception in thread Thread[MutationStage:534,5,main]
java.lang.NullPointerException


Thanks.

--
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-5337) vnode-aware replacenode command

2013-08-22 Thread Mike Heffner (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13748022#comment-13748022
 ] 

Mike Heffner commented on CASSANDRA-5337:
-

Is it correct that these two conditionals should be updated with the same 
method:

{noformat}
@@ -574,7 +574,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 appStates.put(ApplicationState.NET_VERSION, 
valueFactory.networkVersion());
 appStates.put(ApplicationState.HOST_ID, 
valueFactory.hostId(SystemTable.getLocalHostId()));
 appStates.put(ApplicationState.RPC_ADDRESS, 
valueFactory.rpcaddress(DatabaseDescriptor.getRpcAddress()));
-if (0 != DatabaseDescriptor.getReplaceTokens().size())
+if (DatabaseDescriptor.isReplacing())
{noformat}

and:

{noformat}
@@ -655,7 +655,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 if (logger.isDebugEnabled())
 logger.debug("... got ring + schema info");
 
-if (DatabaseDescriptor.getReplaceTokens().size() == 0)
+if (DatabaseDescriptor.isReplacing())
{noformat}

(another case later in patch)

It would seem like one of those should be {{!DatabaseDescriptor.isReplacing()}}.

Apologies if I'm reading this wrong, just looked wrong on initial read.

> vnode-aware replacenode command
> ---
>
> Key: CASSANDRA-5337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5337
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.2.0
>Reporter: Jonathan Ellis
>Assignee: Brandon Williams
>  Labels: vnodes
> Fix For: 1.2.7, 2.0
>
> Attachments: 5337.txt, 5337-v2.txt
>
>
> Currently you have the following options to replace a dead, unrecoverable 
> node:
> - replacetoken.  this requires specifying all 256 or so vnode tokens as a CSL
> - bootstrap new node, decommission old one.  this is inefficient since the 
> new node's vnodes will probably not overlap much with the old one's, so we 
> replicate stream about 2x as much as if we were just replacing the old with 
> the new
> We should add an analogue to replacetoken that takes the address or node ID 
> of the dead node instead.

--
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-5924) If migration (upgrade) failed mid-way, some data will be "lost" on the upgraded instance

2013-08-22 Thread Jackson Chung (JIRA)
Jackson Chung created CASSANDRA-5924:


 Summary: If migration (upgrade) failed mid-way, some data will be 
"lost" on the upgraded instance
 Key: CASSANDRA-5924
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5924
 Project: Cassandra
  Issue Type: Bug
Reporter: Jackson Chung


When upgrading from 1.0 to 1.1, C* checks from the system keyspace 
(schema_keyspaces) to see if a migration is needed.

When it is needed, it proceeds with migrate migrateSSTables.

But this process does not have any particular order (File.listFiles() has no 
guarantee order), and IOException can be thrown (eg fail to create directory).

In some of our upgrades, system was migrated first, followed by some KSs/CFs, 
but before it finishes all the KSs/CFs, it failed on a custom directory, with 
files in this directory that similar to sstables file convention (contains 
"-"). 

They really shouldn't be there and we are removing them. But this results in C* 
tried to create directory for this file, but it fails, because of 
ownership/permission, with IOException. As a result C* failed to start.

Without knowing why C* failed to start to begin with, C* was restarted. Only 
this time C* does not think it needs to migrate any more (system already 
migrated, so schema_keyspaces exists). This results in the those remaining 
KS/CF failed to be migrated.

Our root cause is because of the custom directory and the ownership/permission 
of it, and again we are removing them to re-upgrade. But the purpose of this 
jira is IOException (or any other exception) can still be thrown for various 
reasons during this process, and can result in the same problem: some CF failed 
to be migrated.

1.2 seems to have some handling codes, but it looks like a RuntimeException 
would still be thrown, and that would still be caught by the 
AbstractCassandraDaemon (or CassandraDaemon if 1.2) :

{code}
catch (Throwable e)
{
logger.error("Exception encountered during startup", e);

// try to warn user on stdout too, if we haven't already detached
e.printStackTrace();
System.out.println("Exception encountered during startup: " + 
e.getMessage());

System.exit(3);
}
{code}

And so I think this problem still exists in 1.2

--
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-5923) Upgrade Apache Thrift to 0.9.1

2013-08-22 Thread Jake Farrell (JIRA)

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

Jake Farrell updated CASSANDRA-5923:


Attachment: cassandra-5923.patch

> Upgrade Apache Thrift to 0.9.1
> --
>
> Key: CASSANDRA-5923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5923
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jake Farrell
>Assignee: Jake Farrell
>Priority: Minor
> Fix For: 2.0
>
> Attachments: cassandra-5923.patch
>
>
> Upgrades the Apache Thrift version from 0.9.0 to 0.9.1 which include over 190 
> bug fixes and additions since the previous release. This will also upgrade 
> commons-lang from 2.6 to 3.1 as it is a dependency for Thrift. 
> All tests passed with initial patch against trunk: 3f5322f

--
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-5923) Upgrade Apache Thrift to 0.9.1

2013-08-22 Thread Jake Farrell (JIRA)
Jake Farrell created CASSANDRA-5923:
---

 Summary: Upgrade Apache Thrift to 0.9.1
 Key: CASSANDRA-5923
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5923
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jake Farrell
Assignee: Jake Farrell
Priority: Minor
 Fix For: 2.0
 Attachments: cassandra-5923.patch

Upgrades the Apache Thrift version from 0.9.0 to 0.9.1 which include over 190 
bug fixes and additions since the previous release. This will also upgrade 
commons-lang from 2.6 to 3.1 as it is a dependency for Thrift. 

All tests passed with initial patch against trunk: 3f5322f

--
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-5867) The Pig CqlStorage/AbstractCassandraStorage classes don't handle collection types

2013-08-22 Thread Alex Liu (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747880#comment-13747880
 ] 

Alex Liu commented on CASSANDRA-5867:
-

The following is the data which will be auto converted to C* type, anything 
else will be bytes.

{code}
if (o == null)
return (ByteBuffer)o;
if (o instanceof java.lang.String)
return ByteBuffer.wrap(new DataByteArray((String)o).get());
if (o instanceof Integer)
return Int32Type.instance.decompose((Integer)o);
if (o instanceof Long)
return LongType.instance.decompose((Long)o);
if (o instanceof Float)
return FloatType.instance.decompose((Float)o);
if (o instanceof Double)
return DoubleType.instance.decompose((Double)o);
if (o instanceof UUID)
return ByteBuffer.wrap(UUIDGen.decompose((UUID) o));

return ByteBuffer.wrap(((DataByteArray) o).get());
{code}

you need prepare the data for write different from read result.

> The Pig CqlStorage/AbstractCassandraStorage classes don't handle collection 
> types
> -
>
> Key: CASSANDRA-5867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5867
> Project: Cassandra
>  Issue Type: Bug
>  Components: Hadoop
>Reporter: Jeremy Hanna
>Assignee: Alex Liu
>  Labels: pig
> Attachments: 5867-1.2-branch.txt, 5867-2-1.2-branch.txt, 
> 5867-3-1.2-branch.txt
>
>
> The CqlStorage class gets the Pig data type for values from the 
> AbstractCassandraStorage class, in the getPigType method.  If it isn't a 
> known data type, it makes the value into a ByteArray.  Currently there aren't 
> any cases there for lists, maps, and sets.
> https://github.com/apache/cassandra/blob/cassandra-1.2.8/src/java/org/apache/cassandra/hadoop/pig/AbstractCassandraStorage.java#L336
> See this describe output from the grunt shell:
> {code}
> grunt> describe listdata ;
> listdata: {id: (name: chararray,value: int),alist: (name: chararray,value: 
> bytearray),amap: (name: chararray,value: bytearray),aset: (name: 
> chararray,value: bytearray)}
> {code}
> where the cql data structures had this schema:
> {code}
> CREATE TABLE alltypes (
>   id int PRIMARY KEY,
>   alist list,
>   amap map,
>   aset set
> {code}
> It turns out that if you cast the map in grunt to a pig map, then it sort of 
> works, but I don't think we should probably use a pig map.  Lists don't 
> appear to work at all, as there is no Pig analogue.  I *think* you could 
> probably just do a UDF to cast these things, but we already have all of the 
> type information, so we just need to change them to tuples or bags or 
> whatever.

--
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-5078) save compaction merge counts in a system table

2013-08-22 Thread lantao yan (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747861#comment-13747861
 ] 

lantao yan commented on CASSANDRA-5078:
---

thanks for all the details. I will update the code this weekend. And I think I 
have found where the problem is. Two of three tests are running well now. I 
will keep reading the existing code base to make sure the change is reasonable.

> save compaction merge counts in a system table
> --
>
> Key: CASSANDRA-5078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5078
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matthew F. Dennis
>Assignee: lantao yan
>Priority: Minor
>  Labels: lhf
> Attachments: patch.patch
>
>
> we should save the compaction merge stats from CASSANDRA-4894 in the system 
> table and probably expose them via JMX (and nodetool)

--
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-5916) gossip and tokenMetadata get hostId out of sync on failed replace_node with the same IP address

2013-08-22 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747853#comment-13747853
 ] 

Brandon Williams edited comment on CASSANDRA-5916 at 8/22/13 8:22 PM:
--

This isn't so much a problem with retrying the replace, as it is with the same 
IP address (which won't work at all currently.) The reason for this is that by 
using the same IP address, the replacing node itself changes the HOST_ID, and 
then can't find the old one.  It's not just as simple as not advertising a new 
HOST_ID either, since by not having one but modifying STATUS we wipe out any 
existing HOST_ID as well.

  was (Author: brandon.williams):
This isn't so much a problem with retrying the replace, as it is with the 
same IP address (which won't at all currently.) The reason for this is that by 
using the same IP address, the replacing node itself changes the HOST_ID, and 
then can't find the old one.  It's not just as simple as not advertising a new 
HOST_ID either, by not having one but modifying STATUS we wipe out any existing 
HOST_ID as well.
  
> gossip and tokenMetadata get hostId out of sync on failed replace_node with 
> the same IP address
> ---
>
> Key: CASSANDRA-5916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5916
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Brandon Williams
>Assignee: Brandon Williams
> Fix For: 1.2.9
>
>
> If you try to replace_node an existing, live hostId, it will error out.  
> However if you're using an existing IP to do this (as in, you chose the wrong 
> uuid to replace on accident) then the newly generated hostId wipes out the 
> old one in TMD, and when you do try to replace it replace_node will complain 
> it does not exist.  Examination of gossipinfo still shows the old hostId, 
> however now you can't replace it either.

--
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-5916) gossip and tokenMetadata get hostId out of sync on failed replace_node

2013-08-22 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747853#comment-13747853
 ] 

Brandon Williams commented on CASSANDRA-5916:
-

This isn't so much a problem with retrying the replace, as it is with the same 
IP address (which won't at all currently.) The reason for this is that by using 
the same IP address, the replacing node itself changes the HOST_ID, and then 
can't find the old one.  It's not just as simple as not advertising a new 
HOST_ID either, by not having one but modifying STATUS we wipe out any existing 
HOST_ID as well.

> gossip and tokenMetadata get hostId out of sync on failed replace_node
> --
>
> Key: CASSANDRA-5916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5916
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Brandon Williams
>Assignee: Brandon Williams
> Fix For: 1.2.9
>
>
> If you try to replace_node an existing, live hostId, it will error out.  
> However if you're using an existing IP to do this (as in, you chose the wrong 
> uuid to replace on accident) then the newly generated hostId wipes out the 
> old one in TMD, and when you do try to replace it replace_node will complain 
> it does not exist.  Examination of gossipinfo still shows the old hostId, 
> however now you can't replace it either.

--
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-5916) gossip and tokenMetadata get hostId out of sync on failed replace_node with the same IP address

2013-08-22 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-5916:


Summary: gossip and tokenMetadata get hostId out of sync on failed 
replace_node with the same IP address  (was: gossip and tokenMetadata get 
hostId out of sync on failed replace_node)

> gossip and tokenMetadata get hostId out of sync on failed replace_node with 
> the same IP address
> ---
>
> Key: CASSANDRA-5916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5916
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Brandon Williams
>Assignee: Brandon Williams
> Fix For: 1.2.9
>
>
> If you try to replace_node an existing, live hostId, it will error out.  
> However if you're using an existing IP to do this (as in, you chose the wrong 
> uuid to replace on accident) then the newly generated hostId wipes out the 
> old one in TMD, and when you do try to replace it replace_node will complain 
> it does not exist.  Examination of gossipinfo still shows the old hostId, 
> however now you can't replace it either.

--
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-5915) node flapping prevents replace_node from succeeding consistently

2013-08-22 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747852#comment-13747852
 ] 

Brandon Williams commented on CASSANDRA-5915:
-

Ok, the same UUID does make sense, as long as the IP was not the same as the 
one being replaced, so I at least understand that part now. Empty STATUS or why 
more ring delay helped is still a mystery.

> node flapping prevents replace_node from succeeding consistently
> 
>
> Key: CASSANDRA-5915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5915
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: 1.2.8
>Reporter: Chris Burroughs
> Attachments: cassandra.log.gz
>
>
> A node was down for a week or two due to hardware disk failure. I tried to 
> use replace_node to bring up a new node on the same physical host with the 
> same IPs. (rbranson suspected that using the same IP may be more issue 
> prone.) This failed due to "unable to find sufficient sources for streaming 
> range"  See CASSANDRA-5913 for a problem with how the failure was handled by 
> gossip.
> All of the other nodes should have been up the entire time, but when this 
> node came up it saw nodes flap up and down for quiet some time.  I was 
> eventually able to get replace_token to work by adding a 60 (!) second sleep 
> to StorageService:bootstrap.  I don't know if the right path is "why are 
> things flapping so much" or "bootstrap should wait until things look stable".
> A few notes about the cluster:
>  * 2 dc cluster (about 20 each), using GossipingPropertyFileSnitch
>  * multi-dc no vpn setup: 
> http://mail-archives.apache.org/mod_mbox/cassandra-user/201306.mbox/%3c51bf5c79.7020...@gmail.com%3E
> Startup log from the successful (with sleep) replace_node attached.

--
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-5867) The Pig CqlStorage/AbstractCassandraStorage classes don't handle collection types

2013-08-22 Thread Alex Holmansky (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747849#comment-13747849
 ] 

Alex Holmansky commented on CASSANDRA-5867:
---

If the key of C* map is converted to string (chararray) in a Pig map on read, 
how will the keys be handled on write?  Will the strings be auto-converted to 
appropriate C* types?  In the past, I've seen issues with that - especially 
with timestamps and UUID values.

> The Pig CqlStorage/AbstractCassandraStorage classes don't handle collection 
> types
> -
>
> Key: CASSANDRA-5867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5867
> Project: Cassandra
>  Issue Type: Bug
>  Components: Hadoop
>Reporter: Jeremy Hanna
>Assignee: Alex Liu
>  Labels: pig
> Attachments: 5867-1.2-branch.txt, 5867-2-1.2-branch.txt, 
> 5867-3-1.2-branch.txt
>
>
> The CqlStorage class gets the Pig data type for values from the 
> AbstractCassandraStorage class, in the getPigType method.  If it isn't a 
> known data type, it makes the value into a ByteArray.  Currently there aren't 
> any cases there for lists, maps, and sets.
> https://github.com/apache/cassandra/blob/cassandra-1.2.8/src/java/org/apache/cassandra/hadoop/pig/AbstractCassandraStorage.java#L336
> See this describe output from the grunt shell:
> {code}
> grunt> describe listdata ;
> listdata: {id: (name: chararray,value: int),alist: (name: chararray,value: 
> bytearray),amap: (name: chararray,value: bytearray),aset: (name: 
> chararray,value: bytearray)}
> {code}
> where the cql data structures had this schema:
> {code}
> CREATE TABLE alltypes (
>   id int PRIMARY KEY,
>   alist list,
>   amap map,
>   aset set
> {code}
> It turns out that if you cast the map in grunt to a pig map, then it sort of 
> works, but I don't think we should probably use a pig map.  Lists don't 
> appear to work at all, as there is no Pig analogue.  I *think* you could 
> probably just do a UDF to cast these things, but we already have all of the 
> type information, so we just need to change them to tuples or bags or 
> whatever.

--
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-5918) Remove CQL2 entirely from Cassandra 2.2

2013-08-22 Thread Robert Coli (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747847#comment-13747847
 ] 

Robert Coli commented on CASSANDRA-5918:


FWIW, this sounds like a reasonable idea to me. It is also encouraging as a 
model for deprecating features which some small set of people might be using 
now but which no one should start using because they're 
unsupported/unmaintained.

> Remove CQL2 entirely from Cassandra 2.2
> ---
>
> Key: CASSANDRA-5918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5918
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
>  Labels: cql
> Fix For: 2.2
>
>
> CQL2 is officially no longer worked on since 1.2. cqlsh no longer supports 
> CQL2 as of Cassandra 2.0.
> It's probably the time to deprecate CQL2 in 2.0 and to remove it entirely in 
> 2.2 - there is nothing in CQL2 now that can't be done via CQL3 and two 
> versions advance warning is plenty of time for those few still using CQL2 to 
> switch to CQL3.

--
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-5078) save compaction merge counts in a system table

2013-08-22 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747803#comment-13747803
 ] 

Jonathan Ellis commented on CASSANDRA-5078:
---

bq. Use CompositeData

Yuki suggests 
http://docs.oracle.com/javase/7/docs/api/javax/management/openmbean/TabularData.html
 may be a better fit.

> save compaction merge counts in a system table
> --
>
> Key: CASSANDRA-5078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5078
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matthew F. Dennis
>Assignee: lantao yan
>Priority: Minor
>  Labels: lhf
> Attachments: patch.patch
>
>
> we should save the compaction merge stats from CASSANDRA-4894 in the system 
> table and probably expose them via JMX (and nodetool)

--
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-5911) Commit logs are not removed after nodetool flush or nodetool drain

2013-08-22 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-5911:
--

 Reviewer: jbellis
Fix Version/s: 2.0.1

> Commit logs are not removed after nodetool flush or nodetool drain
> --
>
> Key: CASSANDRA-5911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5911
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: J.B. Langston
>Assignee: Vijay
>Priority: Minor
> Fix For: 2.0.1
>
>
> Commit logs are not removed after nodetool flush or nodetool drain. This can 
> lead to unnecessary commit log replay during startup.  I've reproduced this 
> on Apache Cassandra 1.2.8.  Usually this isn't much of an issue but on a 
> Solr-indexed column family in DSE, each replayed mutation has to be reindexed 
> which can make startup take a long time (on the order of 20-30 min).
> Reproduction follows:
> {code}
> jblangston:bin jblangston$ ./cassandra > /dev/null
> jblangston:bin jblangston$ ../tools/bin/cassandra-stress -n 2000 > 
> /dev/null
> jblangston:bin jblangston$ du -h ../commitlog
> 576M  ../commitlog
> jblangston:bin jblangston$ nodetool flush
> jblangston:bin jblangston$ du -h ../commitlog
> 576M  ../commitlog
> jblangston:bin jblangston$ nodetool drain
> jblangston:bin jblangston$ du -h ../commitlog
> 576M  ../commitlog
> jblangston:bin jblangston$ pkill java
> jblangston:bin jblangston$ du -h ../commitlog
> 576M  ../commitlog
> jblangston:bin jblangston$ ./cassandra -f | grep Replaying
>  INFO 10:03:42,915 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566761.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566762.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566763.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566764.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566765.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566766.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566767.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566768.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566769.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566770.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566771.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566772.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566773.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566774.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566775.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566776.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566777.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566778.log
>  INFO 10:03:42,922 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566761.log
>  INFO 10:03:43,907 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566762.log
>  INFO 10:03:43,907 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566763.log
>  INFO 10:03:43,907 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566764.log
>  INFO 10:03:43,908 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566765.log
>  INFO 10:03:43,908 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566766.log
>  INFO 10:03:43,908 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566767.log
>  INFO 10:03:43,909 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566768.log
>  INFO 10:03:43,909 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566769.log
>  INFO 10:03:43,909 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566770.log
>  INFO 10:03:43,910 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566771.log
>  INFO 10:03:43,910 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566772.log
>  INFO 10:03:43,911 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566773.log
>  INFO 10:03:43,911 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566774.log
>  INFO 10:03:43,911 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566775.log
>  INFO 10:03:43,912 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566776.log
>  INFO 10:03:43,912 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566777.log
>  INFO 10:03:43,912 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566778.log
> {code}

--
This message is automatically generated by JIRA.
If you think 

[jira] [Assigned] (CASSANDRA-5911) Commit logs are not removed after nodetool flush or nodetool drain

2013-08-22 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis reassigned CASSANDRA-5911:
-

Assignee: Vijay

> Commit logs are not removed after nodetool flush or nodetool drain
> --
>
> Key: CASSANDRA-5911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5911
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: J.B. Langston
>Assignee: Vijay
>Priority: Minor
>
> Commit logs are not removed after nodetool flush or nodetool drain. This can 
> lead to unnecessary commit log replay during startup.  I've reproduced this 
> on Apache Cassandra 1.2.8.  Usually this isn't much of an issue but on a 
> Solr-indexed column family in DSE, each replayed mutation has to be reindexed 
> which can make startup take a long time (on the order of 20-30 min).
> Reproduction follows:
> {code}
> jblangston:bin jblangston$ ./cassandra > /dev/null
> jblangston:bin jblangston$ ../tools/bin/cassandra-stress -n 2000 > 
> /dev/null
> jblangston:bin jblangston$ du -h ../commitlog
> 576M  ../commitlog
> jblangston:bin jblangston$ nodetool flush
> jblangston:bin jblangston$ du -h ../commitlog
> 576M  ../commitlog
> jblangston:bin jblangston$ nodetool drain
> jblangston:bin jblangston$ du -h ../commitlog
> 576M  ../commitlog
> jblangston:bin jblangston$ pkill java
> jblangston:bin jblangston$ du -h ../commitlog
> 576M  ../commitlog
> jblangston:bin jblangston$ ./cassandra -f | grep Replaying
>  INFO 10:03:42,915 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566761.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566762.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566763.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566764.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566765.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566766.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566767.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566768.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566769.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566770.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566771.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566772.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566773.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566774.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566775.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566776.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566777.log, 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566778.log
>  INFO 10:03:42,922 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566761.log
>  INFO 10:03:43,907 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566762.log
>  INFO 10:03:43,907 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566763.log
>  INFO 10:03:43,907 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566764.log
>  INFO 10:03:43,908 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566765.log
>  INFO 10:03:43,908 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566766.log
>  INFO 10:03:43,908 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566767.log
>  INFO 10:03:43,909 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566768.log
>  INFO 10:03:43,909 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566769.log
>  INFO 10:03:43,909 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566770.log
>  INFO 10:03:43,910 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566771.log
>  INFO 10:03:43,910 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566772.log
>  INFO 10:03:43,911 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566773.log
>  INFO 10:03:43,911 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566774.log
>  INFO 10:03:43,911 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566775.log
>  INFO 10:03:43,912 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566776.log
>  INFO 10:03:43,912 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566777.log
>  INFO 10:03:43,912 Replaying 
> /opt/apache-cassandra-1.2.8/commitlog/CommitLog-2-1377096566778.log
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA adminis

[jira] [Commented] (CASSANDRA-5078) save compaction merge counts in a system table

2013-08-22 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747780#comment-13747780
 ] 

Jonathan Ellis commented on CASSANDRA-5078:
---

We should probably exclude compaction_history itself, but including the other 
system tables is a good idea.

Other comments:
- Use CompositeData to expose this to JMX instead of formatted strings 
(https://github.com/apache/cassandra/tree/cassandra-2.0/src/java/org/apache/cassandra/streaming/management)
- Please follow the style guide at http://wiki.apache.org/cassandra/CodeStyle
- In general, don't extract blocks of code that are only called once into 
separate methods

> save compaction merge counts in a system table
> --
>
> Key: CASSANDRA-5078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5078
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matthew F. Dennis
>Priority: Minor
>  Labels: lhf
> Attachments: patch.patch
>
>
> we should save the compaction merge stats from CASSANDRA-4894 in the system 
> table and probably expose them via JMX (and nodetool)

--
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-4551) Nodetool getendpoints keys do not work with spaces, key_validation=ascii value of key => "a test" no delimiter

2013-08-22 Thread Greg DeAngelis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747718#comment-13747718
 ] 

Greg DeAngelis commented on CASSANDRA-4551:
---

I did not see the same issue with nodetool.bat. Seems to work fine.

> Nodetool getendpoints keys do not work with spaces, key_validation=ascii 
> value of key => "a test"  no delimiter
> ---
>
> Key: CASSANDRA-4551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4551
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.0.9
>Reporter: Mark Valdez
>Assignee: Greg DeAngelis
>Priority: Trivial
>  Labels: datastax_qa, lhf
> Attachments: CASSANDRA-4551.txt
>
>
> Nodetool getendpoints keys do not work with embedded spaces, 
> key_validation=ascii value of key => "a test"  no delimiter tried to escape 
> key => "a test" with double and single quotes. It doesn't work. It just 
> reiterates the format of the tool's command: getendpoints requires ks, cf and 
> key args

--
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-5922) Delete doesn't delete data.

2013-08-22 Thread Chris Eineke (JIRA)

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

Chris Eineke updated CASSANDRA-5922:


Description: 
In a nutshell, I'm running several test cases against my Cassandra JPA 
implementation (astyanax-jpa, see https://github.com/ceineke/astyanax-jpa) and 
sometimes (!) batched deletes seem not to delete all rows specified in the 
batch. 

Here's the sequence of prepared CQL3 statements that is causing the issue to 
appear:

TRUNCATE compositeentity;

(delete all records so we have a clean slate)

INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo, 
compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);
INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo, 
compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);

(insert two unique rows into the table)

SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;
SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;

(load both rows from the table to validate their existence)

SELECT COUNT(1) FROM compositeentity;

(counts rows to validate the number of records in the table)

BEGIN BATCH  DELETE  FROM compositeentity WHERE compositekeypartone = ? AND 
compositekeyparttwo = ? AND compositekeypartthree = ?; DELETE  FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?; APPLY BATCH;

(uses a logged batch to delete the two rows from the table)

SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;
SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;

(tries loads the rows from the table to check that they don't exist anymore)

After the delete, Cassandra has deleted only the first row so that the second 
SELECT here actually returns data. So far, this behaviour occurs randomly.

This happens even if there's a long sleep (1s, 10s) between the batch delete 
and the selects. It is always the second row that isn't deleted, never the 
first.

Thinking it might be timing issue (based on 
http://ria101.wordpress.com/2011/02/08/cassandra-the-importance-of-system-clocks-avoiding-oom-and-how-to-escape-oom-meltdown/),
 I've set up NTP to keep the clocks synchronized across all nodes (one node 
acts as the master which syncs to time.nrc.ca and {0,1,2,3}.ca.pool.ntp.org, 
whereas the remaining ones sync against the master. This hasn't reduced the 
number of times this behaviour crops up.

(I am executing all statements with QUORUM level consistency.)

I'm open to suggestions as to why this occurs and how I can fix it, if this can 
be fixed.

  was:
In a nutcase, I'm running several test cases against my Cassandra JPA 
implementation (astyanax-jpa, see https://github.com/ceineke/astyanax-jpa) and 
sometimes(!) batched deletes seem not to delete all data. 

Here's the sequence of prepared CQL3 statements that is causing the issue to 
appear:

TRUNCATE compositeentity;

(delete all records so we have a clean slate)

INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo, 
compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);
INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo, 
compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);

(insert two unique rows into the table)

SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;
SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;

(load both rows from the table to validate their existence)

SELECT COUNT(1) FROM compositeentity;

(counts rows to validate the number of records in the table)

BEGIN BATCH  DELETE  FROM compositeentity WHERE compositekeypartone = ? AND 
compositekeyparttwo = ? AND compositekeypartthree = ?; DELETE  FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?; APPLY BATCH;

(uses a logged batch to delete the two rows from the table)

SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;
SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypa

[jira] [Commented] (CASSANDRA-5922) Delete doesn't delete data.

2013-08-22 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747687#comment-13747687
 ] 

Sylvain Lebresne commented on CASSANDRA-5922:
-

A simple script that helps reproducing would be good, and if it is in the form 
of a dtest 
(https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py) that 
would be even more awesome as this would eliminate the possibility that it's a 
bug in astyanax-jpa.

> Delete doesn't delete data.
> ---
>
> Key: CASSANDRA-5922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5922
> Project: Cassandra
>  Issue Type: Bug
> Environment: 4-node cluster w/ Cassandra v1.2.8
> Oracle JDK 1.6.0_45
> Netflix Astyanax 1.56.42
> Quorum read and write consistency level
>Reporter: Chris Eineke
>
> In a nutcase, I'm running several test cases against my Cassandra JPA 
> implementation (astyanax-jpa, see https://github.com/ceineke/astyanax-jpa) 
> and sometimes(!) batched deletes seem not to delete all data. 
> Here's the sequence of prepared CQL3 statements that is causing the issue to 
> appear:
> TRUNCATE compositeentity;
> (delete all records so we have a clean slate)
> INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo, 
> compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);
> INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo, 
> compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);
> (insert two unique rows into the table)
> SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
> compositekeypartthree = ?;
> SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
> compositekeypartthree = ?;
> (load both rows from the table to validate their existence)
> SELECT COUNT(1) FROM compositeentity;
> (counts rows to validate the number of records in the table)
> BEGIN BATCH  DELETE  FROM compositeentity WHERE compositekeypartone = ? AND 
> compositekeyparttwo = ? AND compositekeypartthree = ?; DELETE  FROM 
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
> compositekeypartthree = ?; APPLY BATCH;
> (uses a logged batch to delete the two rows from the table)
> SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
> compositekeypartthree = ?;
> SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
> compositekeypartthree = ?;
> (tries loads the rows from the table to check that they don't exist anymore)
> After the delete, Cassandra has deleted only the first row so that the second 
> SELECT here actually returns data. So far, this behaviour occurs randomly.
> This happens even if there's a long sleep (1s, 10s) between the batch delete 
> and the selects. It is always the second row that isn't deleted, never the 
> first.
> Thinking it might be timing issue (based on 
> http://ria101.wordpress.com/2011/02/08/cassandra-the-importance-of-system-clocks-avoiding-oom-and-how-to-escape-oom-meltdown/),
>  I've set up NTP to keep the clocks synchronized across all nodes (one node 
> acts as the master which syncs to time.nrc.ca and {0,1,2,3}.ca.pool.ntp.org, 
> whereas the remaining ones sync against the master. This hasn't reduced the 
> number of times this behaviour crops up.
> (I am executing all statements with QUORUM level consistency.)
> I'm open to suggestions as to why this occurs and how I can fix it, if this 
> can be 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


[jira] [Created] (CASSANDRA-5922) Delete doesn't delete data.

2013-08-22 Thread Chris Eineke (JIRA)
Chris Eineke created CASSANDRA-5922:
---

 Summary: Delete doesn't delete data.
 Key: CASSANDRA-5922
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5922
 Project: Cassandra
  Issue Type: Bug
 Environment: 4-node cluster w/ Cassandra v1.2.8
Oracle JDK 1.6.0_45
Netflix Astyanax 1.56.42
Quorum read and write consistency level
Reporter: Chris Eineke


In a nutcase, I'm running several test cases against my Cassandra JPA 
implementation (astyanax-jpa, see https://github.com/ceineke/astyanax-jpa) and 
sometimes(!) batched deletes seem not to delete all data. 

Here's the sequence of prepared CQL3 statements that is causing the issue to 
appear:

TRUNCATE compositeentity;

(delete all records so we have a clean slate)

INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo, 
compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);
INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo, 
compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);

(insert two unique rows into the table)

SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;
SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;

(load both rows from the table to validate their existence)

SELECT COUNT(1) FROM compositeentity;

(counts rows to validate the number of records in the table)

BEGIN BATCH  DELETE  FROM compositeentity WHERE compositekeypartone = ? AND 
compositekeyparttwo = ? AND compositekeypartthree = ?; DELETE  FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?; APPLY BATCH;

(uses a logged batch to delete the two rows from the table)

SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;
SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM 
compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND 
compositekeypartthree = ?;

(tries loads the rows from the table to check that they don't exist anymore)

After the delete, Cassandra has deleted only the first row so that the second 
SELECT here actually returns data. So far, this behaviour occurs randomly.

This happens even if there's a long sleep (1s, 10s) between the batch delete 
and the selects. It is always the second row that isn't deleted, never the 
first.

Thinking it might be timing issue (based on 
http://ria101.wordpress.com/2011/02/08/cassandra-the-importance-of-system-clocks-avoiding-oom-and-how-to-escape-oom-meltdown/),
 I've set up NTP to keep the clocks synchronized across all nodes (one node 
acts as the master which syncs to time.nrc.ca and {0,1,2,3}.ca.pool.ntp.org, 
whereas the remaining ones sync against the master. This hasn't reduced the 
number of times this behaviour crops up.

(I am executing all statements with QUORUM level consistency.)

I'm open to suggestions as to why this occurs and how I can fix it, if this can 
be 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


[jira] [Comment Edited] (CASSANDRA-5078) save compaction merge counts in a system table

2013-08-22 Thread lantao yan (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747659#comment-13747659
 ] 

lantao yan edited comment on CASSANDRA-5078 at 8/22/13 5:02 PM:


@Jonathan Ellis, do we save the compaction history of column families under 
system keyspace? or just customer keyspaces?

  was (Author: yanlantao):
@Jonathan Ellis, do we save the compaction history of column families under 
system keyspace? or just customer spaces?
  
> save compaction merge counts in a system table
> --
>
> Key: CASSANDRA-5078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5078
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matthew F. Dennis
>Priority: Minor
>  Labels: lhf
> Attachments: patch.patch
>
>
> we should save the compaction merge stats from CASSANDRA-4894 in the system 
> table and probably expose them via JMX (and nodetool)

--
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-5078) save compaction merge counts in a system table

2013-08-22 Thread lantao yan (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747659#comment-13747659
 ] 

lantao yan commented on CASSANDRA-5078:
---

@Jonathan Ellis, do we save the compaction history of column families under 
system keyspace? or just customer spaces?

> save compaction merge counts in a system table
> --
>
> Key: CASSANDRA-5078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5078
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matthew F. Dennis
>Priority: Minor
>  Labels: lhf
> Attachments: patch.patch
>
>
> we should save the compaction merge stats from CASSANDRA-4894 in the system 
> table and probably expose them via JMX (and nodetool)

--
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-5918) Remove CQL2 entirely from Cassandra 2.2

2013-08-22 Thread Patrick McFadin (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747648#comment-13747648
 ] 

Patrick McFadin commented on CASSANDRA-5918:


Your concern for my happiness is heart warming. heh

Whatever it is that isn't "we just took away functionality inside 2.x" will be 
just fine.

> Remove CQL2 entirely from Cassandra 2.2
> ---
>
> Key: CASSANDRA-5918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5918
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
>  Labels: cql
> Fix For: 2.2
>
>
> CQL2 is officially no longer worked on since 1.2. cqlsh no longer supports 
> CQL2 as of Cassandra 2.0.
> It's probably the time to deprecate CQL2 in 2.0 and to remove it entirely in 
> 2.2 - there is nothing in CQL2 now that can't be done via CQL3 and two 
> versions advance warning is plenty of time for those few still using CQL2 to 
> switch to CQL3.

--
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-5918) Remove CQL2 entirely from Cassandra 2.2

2013-08-22 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747627#comment-13747627
 ] 

Jonathan Ellis commented on CASSANDRA-5918:
---

If it takes calling it 3.0 to make you happy, that's doable. :)

> Remove CQL2 entirely from Cassandra 2.2
> ---
>
> Key: CASSANDRA-5918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5918
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
>  Labels: cql
> Fix For: 2.2
>
>
> CQL2 is officially no longer worked on since 1.2. cqlsh no longer supports 
> CQL2 as of Cassandra 2.0.
> It's probably the time to deprecate CQL2 in 2.0 and to remove it entirely in 
> 2.2 - there is nothing in CQL2 now that can't be done via CQL3 and two 
> versions advance warning is plenty of time for those few still using CQL2 to 
> switch to CQL3.

--
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-5918) Remove CQL2 entirely from Cassandra 2.2

2013-08-22 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747619#comment-13747619
 ] 

Brandon Williams commented on CASSANDRA-5918:
-

That's basically what 2.2 is, "not the next major release, but the one after 
that."

> Remove CQL2 entirely from Cassandra 2.2
> ---
>
> Key: CASSANDRA-5918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5918
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
>  Labels: cql
> Fix For: 2.2
>
>
> CQL2 is officially no longer worked on since 1.2. cqlsh no longer supports 
> CQL2 as of Cassandra 2.0.
> It's probably the time to deprecate CQL2 in 2.0 and to remove it entirely in 
> 2.2 - there is nothing in CQL2 now that can't be done via CQL3 and two 
> versions advance warning is plenty of time for those few still using CQL2 to 
> switch to CQL3.

--
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-5918) Remove CQL2 entirely from Cassandra 2.2

2013-08-22 Thread Patrick McFadin (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747615#comment-13747615
 ] 

Patrick McFadin commented on CASSANDRA-5918:


If we are going to remove it as a breaking change, this should be 3.0. There 
are still people in production using CQL2. If 2.x issues a warning, then we can 
give them until 3.x to migrate away. 

> Remove CQL2 entirely from Cassandra 2.2
> ---
>
> Key: CASSANDRA-5918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5918
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
>  Labels: cql
> Fix For: 2.2
>
>
> CQL2 is officially no longer worked on since 1.2. cqlsh no longer supports 
> CQL2 as of Cassandra 2.0.
> It's probably the time to deprecate CQL2 in 2.0 and to remove it entirely in 
> 2.2 - there is nothing in CQL2 now that can't be done via CQL3 and two 
> versions advance warning is plenty of time for those few still using CQL2 to 
> switch to CQL3.

--
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-4191) Add `nodetool cfstats ` abilities

2013-08-22 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-4191:
--

Reviewer: dbrosius  (was: brandon.williams)
Assignee: Lyuben Todorov  (was: Dave Brosius)

Yes.  I'll ask Lyuben to take a look.

> Add `nodetool cfstats  ` 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: Lyuben Todorov
>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] [Commented] (CASSANDRA-4191) Add `nodetool cfstats ` abilities

2013-08-22 Thread Hayato Shimizu (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747578#comment-13747578
 ] 

Hayato Shimizu commented on CASSANDRA-4191:
---

What's the status of this issue? Is it abandoned?


> Add `nodetool cfstats  ` 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] [Commented] (CASSANDRA-5921) Don't return empty list when the L0 compaction candidates could cause overlap in L1

2013-08-22 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747570#comment-13747570
 ] 

Jonathan Ellis commented on CASSANDRA-5921:
---

- You changed {{compactingL0}} to just {{compacting}} which would unfix 5907
- You'll also need to do the L0 difference before the union with L1 overlaps; 
otherwise the difference could remove L1 sstables that need to be included for 
correctness
- Time to address {{TODO try to find a set of L0 sstables that only overlaps 
with non-busy L1 sstables}} ?

> Don't return empty list when the L0 compaction candidates could cause overlap 
> in L1
> ---
>
> Key: CASSANDRA-5921
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5921
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Minor
> Attachments: 
> 0001-instead-of-doing-no-compaction-if-we-have-sstables-t.patch
>
>
> Followup to CASSANDRA-5907 - instead of returning empty list when the 
> compaction candidates could cause overlap in L1, remove sstables that would 
> cause the overlap from the candidates.

--
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 Wiki] Update of "ClientOptions" by JonathanEllis

2013-08-22 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "ClientOptions" page has been changed by JonathanEllis:
https://wiki.apache.org/cassandra/ClientOptions?action=diff&rev1=177&rev2=178

Comment:
add node-cassandra-cql

* [[http://github.com/datastax/java-driver|DataStax Java driver]]
   * Node.js
* Helenus: https://github.com/simplereach/helenus
+   * https://github.com/jorgebay/node-cassandra-cql
   * Clojure
* alia: https://github.com/mpenet/alia (datastax/java-driver wrapper)
* hayt (CQL3 query generation): https://github.com/mpenet/hayt


[jira] [Created] (CASSANDRA-5921) Don't return empty list when the L0 compaction candidates could cause overlap in L1

2013-08-22 Thread Marcus Eriksson (JIRA)
Marcus Eriksson created CASSANDRA-5921:
--

 Summary: Don't return empty list when the L0 compaction candidates 
could cause overlap in L1
 Key: CASSANDRA-5921
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5921
 Project: Cassandra
  Issue Type: Improvement
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
Priority: Minor
 Attachments: 
0001-instead-of-doing-no-compaction-if-we-have-sstables-t.patch

Followup to CASSANDRA-5907 - instead of returning empty list when the 
compaction candidates could cause overlap in L1, remove sstables that would 
cause the overlap from the candidates.

--
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-5921) Don't return empty list when the L0 compaction candidates could cause overlap in L1

2013-08-22 Thread Marcus Eriksson (JIRA)

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

Marcus Eriksson updated CASSANDRA-5921:
---

Attachment: 0001-instead-of-doing-no-compaction-if-we-have-sstables-t.patch

> Don't return empty list when the L0 compaction candidates could cause overlap 
> in L1
> ---
>
> Key: CASSANDRA-5921
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5921
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Minor
> Attachments: 
> 0001-instead-of-doing-no-compaction-if-we-have-sstables-t.patch
>
>
> Followup to CASSANDRA-5907 - instead of returning empty list when the 
> compaction candidates could cause overlap in L1, remove sstables that would 
> cause the overlap from the candidates.

--
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] [Issue Comment Deleted] (CASSANDRA-5078) save compaction merge counts in a system table

2013-08-22 Thread lantao yan (JIRA)

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

lantao yan updated CASSANDRA-5078:
--

Comment: was deleted

(was: is it because of the CompactionManager compacting compaction_history 
itself as well. and During this process, there is some issue?)

> save compaction merge counts in a system table
> --
>
> Key: CASSANDRA-5078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5078
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matthew F. Dennis
>Priority: Minor
>  Labels: lhf
> Attachments: patch.patch
>
>
> we should save the compaction merge stats from CASSANDRA-4894 in the system 
> table and probably expose them via JMX (and nodetool)

--
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 build - log4j is gone

2013-08-22 Thread marcuse
Updated Branches:
  refs/heads/trunk 8bc0f5990 -> 3f5322f02


fix build - log4j is gone


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

Branch: refs/heads/trunk
Commit: 3f5322f02af3ef7e93706cd80ca65c5b127478e0
Parents: 8bc0f59
Author: Marcus Eriksson 
Authored: Thu Aug 22 15:39:16 2013 +0200
Committer: Marcus Eriksson 
Committed: Thu Aug 22 15:39:16 2013 +0200

--
 src/java/org/apache/cassandra/tools/StandaloneSplitter.java | 6 --
 1 file changed, 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f5322f0/src/java/org/apache/cassandra/tools/StandaloneSplitter.java
--
diff --git a/src/java/org/apache/cassandra/tools/StandaloneSplitter.java 
b/src/java/org/apache/cassandra/tools/StandaloneSplitter.java
index 245d824..44cbc33 100644
--- a/src/java/org/apache/cassandra/tools/StandaloneSplitter.java
+++ b/src/java/org/apache/cassandra/tools/StandaloneSplitter.java
@@ -32,7 +32,6 @@ import org.apache.cassandra.db.Keyspace;
 import org.apache.cassandra.db.compaction.LeveledManifest;
 import org.apache.cassandra.db.compaction.SSTableSplitter;
 import org.apache.cassandra.io.sstable.*;
-import org.apache.cassandra.service.CassandraDaemon;
 import org.apache.cassandra.utils.Pair;
 
 import static org.apache.cassandra.tools.BulkLoader.CmdLineOptions;
@@ -41,11 +40,6 @@ public class StandaloneSplitter
 {
 public static final int DEFAULT_SSTABLE_SIZE = 50;
 
-static
-{
-CassandraDaemon.initLog4j();
-}
-
 private static final String TOOL_NAME = "sstablessplit";
 private static final String VERBOSE_OPTION = "verbose";
 private static final String DEBUG_OPTION = "debug";



[jira] [Updated] (CASSANDRA-5920) Allow secondary indexed columns to be used with IN operator

2013-08-22 Thread David Semeria (JIRA)

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

David Semeria updated CASSANDRA-5920:
-

Description: 
Related to https://issues.apache.org/jira/browse/CASSANDRA-4709

Using a secondary indexed column we get: Cannot use IN operator on column not 
part of the PRIMARY KEY
But with any other than the first element of a composite primary key we get: 
PRIMARY KEY part [COLUMN] cannot be restricted by IN relation

This is a pity, because one of the main attractions of CQL over the thrift API 
is the ability to do OR filtering on the node rather than the client

  was:
Related to https://issues.apache.org/jira/browse/CASSANDRA-4709

Using an secondary indexed column we get: Cannot use IN operator on column not 
part of the PRIMARY KEY
But with any other than the first element of a composite primary key we get: 
PRIMARY KEY part [COLUMN] cannot be restricted by IN relation

This is a pity, because one of the main attractions of CQL over the thrift API 
is the ability to do OR filtering on the node rather than the client


> Allow secondary indexed columns to be used with IN operator
> ---
>
> Key: CASSANDRA-5920
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5920
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: David Semeria
>
> Related to https://issues.apache.org/jira/browse/CASSANDRA-4709
> Using a secondary indexed column we get: Cannot use IN operator on column not 
> part of the PRIMARY KEY
> But with any other than the first element of a composite primary key we get: 
> PRIMARY KEY part [COLUMN] cannot be restricted by IN relation
> This is a pity, because one of the main attractions of CQL over the thrift 
> API is the ability to do OR filtering on the node rather than the client

--
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-5920) Allow secondary indexed columns to be used with IN operator

2013-08-22 Thread David Semeria (JIRA)

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

David Semeria updated CASSANDRA-5920:
-

Description: 
Related to https://issues.apache.org/jira/browse/CASSANDRA-4709

Using an secondary indexed column we get: Cannot use IN operator on column not 
part of the PRIMARY KEY
But with any other than the first element of a composite primary key we get: 
PRIMARY KEY part [COLUMN] cannot be restricted by IN relation

This is a pity, because one of the main attractions of CQL over the thrift API 
is the ability to do OR filtering on the node rather than the client

  was:
Related to https://issues.apache.org/jira/browse/CASSANDRA-4709

Currently we get: Cannot use IN operator on column not part of the PRIMARY KEY
But with any other than the first element of a composite primary key we get: 
PRIMARY KEY part [COLUMN] cannot be restricted by IN relation

This is a pity, because one of the main attractions of CQL over the thrift API 
is the ability to do OR filtering on the node rather than the client


> Allow secondary indexed columns to be used with IN operator
> ---
>
> Key: CASSANDRA-5920
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5920
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: David Semeria
>
> Related to https://issues.apache.org/jira/browse/CASSANDRA-4709
> Using an secondary indexed column we get: Cannot use IN operator on column 
> not part of the PRIMARY KEY
> But with any other than the first element of a composite primary key we get: 
> PRIMARY KEY part [COLUMN] cannot be restricted by IN relation
> This is a pity, because one of the main attractions of CQL over the thrift 
> API is the ability to do OR filtering on the node rather than the client

--
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-5920) Allow secondary indexed columns to be used with IN operator

2013-08-22 Thread David Semeria (JIRA)

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

David Semeria updated CASSANDRA-5920:
-

Description: 
Related to https://issues.apache.org/jira/browse/CASSANDRA-4709

Currently we get: Cannot use IN operator on column not part of the PRIMARY KEY
But with any other than the first element of a composite primary key we get: 
PRIMARY KEY part [COLUMN] cannot be restricted by IN relation

This is a pity, because one of the main attractions of CQL over the thrift API 
is the ability to do OR filtering on the node rather than the client

  was:
Related to https://issues.apache.org/jira/browse/CASSANDRA-4709

Currently we get: Cannot use IN operator on column not part of the PRIMARY KEY
But with composite primary keys we get: PRIMARY KEY part [COLUMN] cannot be 
restricted by IN relation

This is a pity, because one of the main attractions of CQL over the thrift API 
is the ability to do OR filtering on the node rather than the client


> Allow secondary indexed columns to be used with IN operator
> ---
>
> Key: CASSANDRA-5920
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5920
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: David Semeria
>
> Related to https://issues.apache.org/jira/browse/CASSANDRA-4709
> Currently we get: Cannot use IN operator on column not part of the PRIMARY KEY
> But with any other than the first element of a composite primary key we get: 
> PRIMARY KEY part [COLUMN] cannot be restricted by IN relation
> This is a pity, because one of the main attractions of CQL over the thrift 
> API is the ability to do OR filtering on the node rather than the client

--
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-5920) Allow secondary indexed columns to be used with IN operator

2013-08-22 Thread David Semeria (JIRA)
David Semeria created CASSANDRA-5920:


 Summary: Allow secondary indexed columns to be used with IN 
operator
 Key: CASSANDRA-5920
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5920
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: David Semeria


Related to https://issues.apache.org/jira/browse/CASSANDRA-4709

Currently we get: Cannot use IN operator on column not part of the PRIMARY KEY
But with composite primary keys we get: PRIMARY KEY part [COLUMN] cannot be 
restricted by IN relation

This is a pity, because one of the main attractions of CQL over the thrift API 
is the ability to do OR filtering on the node rather than the client

--
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


[5/5] git commit: Merge branch 'cassandra-2.0' into trunk

2013-08-22 Thread slebresne
Merge branch 'cassandra-2.0' into trunk


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

Branch: refs/heads/trunk
Commit: 8bc0f59904a25aee72168104a88596419b3e9b2e
Parents: d24e900 05929c0
Author: Sylvain Lebresne 
Authored: Thu Aug 22 10:18:51 2013 +0200
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:18:51 2013 +0200

--
 CHANGES.txt |   2 +
 NEWS.txt|   1 +
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 427 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8bc0f599/CHANGES.txt
--



[1/5] git commit: Fix changelog

2013-08-22 Thread slebresne
Updated Branches:
  refs/heads/trunk d24e90009 -> 8bc0f5990


Fix changelog


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

Branch: refs/heads/trunk
Commit: da55d76d2c15257610959eee43dec197262c0422
Parents: f8be23a
Author: Sylvain Lebresne 
Authored: Thu Aug 22 09:29:55 2013 +0200
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 09:29:55 2013 +0200

--
 CHANGES.txt | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/da55d76d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 14fee1d..0166345 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -7,6 +7,7 @@
  * Cleanup doesn't need to inspect sstables that contain only local data 
(CASSANDRA-5722)
  * Add ability for CQL3 to list partition keys (CASSANDRA-4536)
+ * Improve native protocol serialization (CASSANDRA-5664)
 
 
 2.0.0



[1/3] git commit: Add SSTableSplitter tool to split sstables offline

2013-08-22 Thread slebresne
Updated Branches:
  refs/heads/cassandra-2.0 da55d76d2 -> 05929c05c


Add SSTableSplitter tool to split sstables offline

patch by slebresne; reviewed by krummas for CASSANDRA-4766


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

Branch: refs/heads/cassandra-2.0
Commit: 39066b722607fa88e75d5bc772bd52f1ec8914a0
Parents: 9bb4d93
Author: Sylvain Lebresne 
Authored: Sun Nov 11 14:54:43 2012 +0100
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:08:10 2013 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|   3 +-
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 427 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e1c963c..e887c27 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -26,6 +26,7 @@
  * Fix to support off heap bloom filters size greater than 2 GB 
(CASSANDRA-5903)
  * Properly handle parsing huge map and set literals (CASSANDRA-5893)
  * Fix LCS L0 compaction may overlap in L1 (CASSANDRA-5907)
+ * New sstablesplit tool to split large sstables offline (CASSANDRA-4766)
 Merged from 1.1:
  * Correctly validate sparse composite cells in scrub (CASSANDRA-5855)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 11281ee..491a438 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -18,9 +18,10 @@ using the provided 'sstableupgrade' tool.
 
 Features
 
-- A history of executed nodetool commands is now captured. 
+- A history of executed nodetool commands is now captured.
   It can be found in ~/.cassandra/nodetool.history. Other tools output 
files
   (cli and cqlsh history, .cqlshrc) are now centralized in ~/.cassandra, 
as well.
+- A new sstablesplit utility allows to split large sstables offline.
 
 Defaults
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/bin/sstablesplit
--
diff --git a/bin/sstablesplit b/bin/sstablesplit
new file mode 100755
index 000..933a67d
--- /dev/null
+++ b/bin/sstablesplit
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+# 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.
+
+if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
+for include in /usr/share/cassandra/cassandra.in.sh \
+   /usr/local/share/cassandra/cassandra.in.sh \
+   /opt/cassandra/cassandra.in.sh \
+   ~/.cassandra.in.sh \
+   `dirname $0`/cassandra.in.sh; do
+if [ -r $include ]; then
+. $include
+break
+fi
+done
+elif [ -r $CASSANDRA_INCLUDE ]; then
+. $CASSANDRA_INCLUDE
+fi
+
+# Use JAVA_HOME if set, otherwise look for java in PATH
+if [ -x $JAVA_HOME/bin/java ]; then
+JAVA=$JAVA_HOME/bin/java
+else
+JAVA=`which java`
+fi
+
+if [ -z $CLASSPATH ]; then
+echo "You must set the CLASSPATH var" >&2
+exit 1
+fi
+
+$JAVA -ea -cp $CLASSPATH -Xmx256M \
+-Dlog4j.configuration=log4j-tools.properties \
+org.apache.cassandra.tools.StandaloneSplitter "$@"
+
+# vi:ai sw=4 ts=4 tw=0 et

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/debian/cassandra.install
--
diff --git a/debian/cassandra.install b/debian/cassandra.install
index a504b78..70d4b97 100644
--- a/debian/cassandra.inst

[2/5] git commit: Add SSTableSplitter tool to split sstables offline

2013-08-22 Thread slebresne
Add SSTableSplitter tool to split sstables offline

patch by slebresne; reviewed by krummas for CASSANDRA-4766


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

Branch: refs/heads/trunk
Commit: 39066b722607fa88e75d5bc772bd52f1ec8914a0
Parents: 9bb4d93
Author: Sylvain Lebresne 
Authored: Sun Nov 11 14:54:43 2012 +0100
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:08:10 2013 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|   3 +-
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 427 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e1c963c..e887c27 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -26,6 +26,7 @@
  * Fix to support off heap bloom filters size greater than 2 GB 
(CASSANDRA-5903)
  * Properly handle parsing huge map and set literals (CASSANDRA-5893)
  * Fix LCS L0 compaction may overlap in L1 (CASSANDRA-5907)
+ * New sstablesplit tool to split large sstables offline (CASSANDRA-4766)
 Merged from 1.1:
  * Correctly validate sparse composite cells in scrub (CASSANDRA-5855)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 11281ee..491a438 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -18,9 +18,10 @@ using the provided 'sstableupgrade' tool.
 
 Features
 
-- A history of executed nodetool commands is now captured. 
+- A history of executed nodetool commands is now captured.
   It can be found in ~/.cassandra/nodetool.history. Other tools output 
files
   (cli and cqlsh history, .cqlshrc) are now centralized in ~/.cassandra, 
as well.
+- A new sstablesplit utility allows to split large sstables offline.
 
 Defaults
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/bin/sstablesplit
--
diff --git a/bin/sstablesplit b/bin/sstablesplit
new file mode 100755
index 000..933a67d
--- /dev/null
+++ b/bin/sstablesplit
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+# 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.
+
+if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
+for include in /usr/share/cassandra/cassandra.in.sh \
+   /usr/local/share/cassandra/cassandra.in.sh \
+   /opt/cassandra/cassandra.in.sh \
+   ~/.cassandra.in.sh \
+   `dirname $0`/cassandra.in.sh; do
+if [ -r $include ]; then
+. $include
+break
+fi
+done
+elif [ -r $CASSANDRA_INCLUDE ]; then
+. $CASSANDRA_INCLUDE
+fi
+
+# Use JAVA_HOME if set, otherwise look for java in PATH
+if [ -x $JAVA_HOME/bin/java ]; then
+JAVA=$JAVA_HOME/bin/java
+else
+JAVA=`which java`
+fi
+
+if [ -z $CLASSPATH ]; then
+echo "You must set the CLASSPATH var" >&2
+exit 1
+fi
+
+$JAVA -ea -cp $CLASSPATH -Xmx256M \
+-Dlog4j.configuration=log4j-tools.properties \
+org.apache.cassandra.tools.StandaloneSplitter "$@"
+
+# vi:ai sw=4 ts=4 tw=0 et

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/debian/cassandra.install
--
diff --git a/debian/cassandra.install b/debian/cassandra.install
index a504b78..70d4b97 100644
--- a/debian/cassandra.install
+++ b/debian/cassandra.install
@@ -18,6 +18,7 @@ bin/sstableloader usr/bin

[3/5] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0.0

2013-08-22 Thread slebresne
Merge branch 'cassandra-1.2' into cassandra-2.0.0

Conflicts:
src/java/org/apache/cassandra/db/compaction/CompactionTask.java


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

Branch: refs/heads/trunk
Commit: 624a7a02f8e1240aabdac3117db64d8f3a5da99b
Parents: 5774ecb 39066b7
Author: Sylvain Lebresne 
Authored: Thu Aug 22 10:17:54 2013 +0200
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:17:54 2013 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|   1 +
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 426 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/NEWS.txt
--
diff --cc NEWS.txt
index 717dd4a,491a438..cd8c880
--- a/NEWS.txt
+++ b/NEWS.txt
@@@ -97,7 -21,12 +97,8 @@@ Feature
  - A history of executed nodetool commands is now captured.
It can be found in ~/.cassandra/nodetool.history. Other tools output 
files
(cli and cqlsh history, .cqlshrc) are now centralized in ~/.cassandra, 
as well.
+ - A new sstablesplit utility allows to split large sstables offline.
  
 -Defaults
 -
 -- After performance testing for CASSANDRA-5727, the default LCS filesize
 -  has been changed from 5MB to 160MB.
  
  
  1.2.7

http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/debian/cassandra.install
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/src/java/org/apache/cassandra/db/compaction/CompactionTask.java
--
diff --cc src/java/org/apache/cassandra/db/compaction/CompactionTask.java
index a7b6c64,0fed0a2..c27a020
--- a/src/java/org/apache/cassandra/db/compaction/CompactionTask.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionTask.java
@@@ -102,13 -96,9 +102,13 @@@ public class CompactionTask extends Abs
  
  // sanity check: all sstables must belong to the same cfs
  for (SSTableReader sstable : toCompact)
 -assert sstable.descriptor.cfname.equals(cfs.columnFamily);
 +assert sstable.descriptor.cfname.equals(cfs.name);
 +
 +UUID taskId = SystemKeyspace.startCompaction(cfs, toCompact);
  
- CompactionController controller = new CompactionController(cfs, 
toCompact, gcBefore);
+ CompactionController controller = getCompactionController(toCompact);
 +Set actuallyCompact = Sets.difference(toCompact, 
controller.getFullyExpiredSSTables());
 +
  // new sstables from flush can be added during a compaction, but only 
the compaction can remove them,
  // so in our single-threaded compaction world this is a valid way of 
determining if we're compacting
  // all the sstables (that existed when we started)
@@@ -237,12 -222,18 +237,12 @@@
  {
  throw new RuntimeException(e);
  }
 -
 -if (collector != null)
 -collector.finishCompaction(ci);
  }
  
- cfs.replaceCompactedSSTables(toCompact, sstables, compactionType);
+ replaceCompactedSSTables(toCompact, sstables);
  // TODO: this doesn't belong here, it should be part of the reader to 
load when the tracker is wired up
  for (SSTableReader sstable : sstables)
 -{
 -for (Map.Entry entry : 
cachedKeyMap.get(sstable.descriptor).entrySet())
 -   sstable.cacheKey(entry.getKey(), entry.getValue());
 -}
 +sstable.preheat(cachedKeyMap.get(sstable.descriptor));
  
  if (logger.isInfoEnabled())
  {
@@@ -274,20 -265,16 +274,30 @@@
  }
  }
  
 +private SSTableWriter createCompactionWriter(File sstableDirectory, long 
keysPerSSTable)
 +{
 +return new SSTableWriter(cfs.getTempSSTablePath(sstableDirectory),
 + keysPerSSTable,
 + cfs.metadata,
 + cfs.partitioner,
 + SSTableMetadata.createCollect

[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0.0

2013-08-22 Thread slebresne
Merge branch 'cassandra-1.2' into cassandra-2.0.0

Conflicts:
src/java/org/apache/cassandra/db/compaction/CompactionTask.java


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

Branch: refs/heads/cassandra-2.0
Commit: 624a7a02f8e1240aabdac3117db64d8f3a5da99b
Parents: 5774ecb 39066b7
Author: Sylvain Lebresne 
Authored: Thu Aug 22 10:17:54 2013 +0200
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:17:54 2013 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|   1 +
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 426 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/NEWS.txt
--
diff --cc NEWS.txt
index 717dd4a,491a438..cd8c880
--- a/NEWS.txt
+++ b/NEWS.txt
@@@ -97,7 -21,12 +97,8 @@@ Feature
  - A history of executed nodetool commands is now captured.
It can be found in ~/.cassandra/nodetool.history. Other tools output 
files
(cli and cqlsh history, .cqlshrc) are now centralized in ~/.cassandra, 
as well.
+ - A new sstablesplit utility allows to split large sstables offline.
  
 -Defaults
 -
 -- After performance testing for CASSANDRA-5727, the default LCS filesize
 -  has been changed from 5MB to 160MB.
  
  
  1.2.7

http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/debian/cassandra.install
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/src/java/org/apache/cassandra/db/compaction/CompactionTask.java
--
diff --cc src/java/org/apache/cassandra/db/compaction/CompactionTask.java
index a7b6c64,0fed0a2..c27a020
--- a/src/java/org/apache/cassandra/db/compaction/CompactionTask.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionTask.java
@@@ -102,13 -96,9 +102,13 @@@ public class CompactionTask extends Abs
  
  // sanity check: all sstables must belong to the same cfs
  for (SSTableReader sstable : toCompact)
 -assert sstable.descriptor.cfname.equals(cfs.columnFamily);
 +assert sstable.descriptor.cfname.equals(cfs.name);
 +
 +UUID taskId = SystemKeyspace.startCompaction(cfs, toCompact);
  
- CompactionController controller = new CompactionController(cfs, 
toCompact, gcBefore);
+ CompactionController controller = getCompactionController(toCompact);
 +Set actuallyCompact = Sets.difference(toCompact, 
controller.getFullyExpiredSSTables());
 +
  // new sstables from flush can be added during a compaction, but only 
the compaction can remove them,
  // so in our single-threaded compaction world this is a valid way of 
determining if we're compacting
  // all the sstables (that existed when we started)
@@@ -237,12 -222,18 +237,12 @@@
  {
  throw new RuntimeException(e);
  }
 -
 -if (collector != null)
 -collector.finishCompaction(ci);
  }
  
- cfs.replaceCompactedSSTables(toCompact, sstables, compactionType);
+ replaceCompactedSSTables(toCompact, sstables);
  // TODO: this doesn't belong here, it should be part of the reader to 
load when the tracker is wired up
  for (SSTableReader sstable : sstables)
 -{
 -for (Map.Entry entry : 
cachedKeyMap.get(sstable.descriptor).entrySet())
 -   sstable.cacheKey(entry.getKey(), entry.getValue());
 -}
 +sstable.preheat(cachedKeyMap.get(sstable.descriptor));
  
  if (logger.isInfoEnabled())
  {
@@@ -274,20 -265,16 +274,30 @@@
  }
  }
  
 +private SSTableWriter createCompactionWriter(File sstableDirectory, long 
keysPerSSTable)
 +{
 +return new SSTableWriter(cfs.getTempSSTablePath(sstableDirectory),
 + keysPerSSTable,
 + cfs.metadata,
 + cfs.partitioner,
 + SSTableMetadata.creat

[3/3] git commit: Merge branch 'cassandra-2.0.0' into cassandra-2.0

2013-08-22 Thread slebresne
Merge branch 'cassandra-2.0.0' into cassandra-2.0


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

Branch: refs/heads/cassandra-2.0
Commit: 05929c05cd06b29917fdaada7d39284ceff8d720
Parents: da55d76 624a7a0
Author: Sylvain Lebresne 
Authored: Thu Aug 22 10:18:36 2013 +0200
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:18:36 2013 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|   1 +
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 426 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/05929c05/CHANGES.txt
--



[4/5] git commit: Merge branch 'cassandra-2.0.0' into cassandra-2.0

2013-08-22 Thread slebresne
Merge branch 'cassandra-2.0.0' into cassandra-2.0


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

Branch: refs/heads/trunk
Commit: 05929c05cd06b29917fdaada7d39284ceff8d720
Parents: da55d76 624a7a0
Author: Sylvain Lebresne 
Authored: Thu Aug 22 10:18:36 2013 +0200
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:18:36 2013 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|   1 +
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 426 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/05929c05/CHANGES.txt
--



[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0.0

2013-08-22 Thread slebresne
Merge branch 'cassandra-1.2' into cassandra-2.0.0

Conflicts:
src/java/org/apache/cassandra/db/compaction/CompactionTask.java


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

Branch: refs/heads/cassandra-2.0.0
Commit: 624a7a02f8e1240aabdac3117db64d8f3a5da99b
Parents: 5774ecb 39066b7
Author: Sylvain Lebresne 
Authored: Thu Aug 22 10:17:54 2013 +0200
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:17:54 2013 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|   1 +
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 426 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/NEWS.txt
--
diff --cc NEWS.txt
index 717dd4a,491a438..cd8c880
--- a/NEWS.txt
+++ b/NEWS.txt
@@@ -97,7 -21,12 +97,8 @@@ Feature
  - A history of executed nodetool commands is now captured.
It can be found in ~/.cassandra/nodetool.history. Other tools output 
files
(cli and cqlsh history, .cqlshrc) are now centralized in ~/.cassandra, 
as well.
+ - A new sstablesplit utility allows to split large sstables offline.
  
 -Defaults
 -
 -- After performance testing for CASSANDRA-5727, the default LCS filesize
 -  has been changed from 5MB to 160MB.
  
  
  1.2.7

http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/debian/cassandra.install
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/624a7a02/src/java/org/apache/cassandra/db/compaction/CompactionTask.java
--
diff --cc src/java/org/apache/cassandra/db/compaction/CompactionTask.java
index a7b6c64,0fed0a2..c27a020
--- a/src/java/org/apache/cassandra/db/compaction/CompactionTask.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionTask.java
@@@ -102,13 -96,9 +102,13 @@@ public class CompactionTask extends Abs
  
  // sanity check: all sstables must belong to the same cfs
  for (SSTableReader sstable : toCompact)
 -assert sstable.descriptor.cfname.equals(cfs.columnFamily);
 +assert sstable.descriptor.cfname.equals(cfs.name);
 +
 +UUID taskId = SystemKeyspace.startCompaction(cfs, toCompact);
  
- CompactionController controller = new CompactionController(cfs, 
toCompact, gcBefore);
+ CompactionController controller = getCompactionController(toCompact);
 +Set actuallyCompact = Sets.difference(toCompact, 
controller.getFullyExpiredSSTables());
 +
  // new sstables from flush can be added during a compaction, but only 
the compaction can remove them,
  // so in our single-threaded compaction world this is a valid way of 
determining if we're compacting
  // all the sstables (that existed when we started)
@@@ -237,12 -222,18 +237,12 @@@
  {
  throw new RuntimeException(e);
  }
 -
 -if (collector != null)
 -collector.finishCompaction(ci);
  }
  
- cfs.replaceCompactedSSTables(toCompact, sstables, compactionType);
+ replaceCompactedSSTables(toCompact, sstables);
  // TODO: this doesn't belong here, it should be part of the reader to 
load when the tracker is wired up
  for (SSTableReader sstable : sstables)
 -{
 -for (Map.Entry entry : 
cachedKeyMap.get(sstable.descriptor).entrySet())
 -   sstable.cacheKey(entry.getKey(), entry.getValue());
 -}
 +sstable.preheat(cachedKeyMap.get(sstable.descriptor));
  
  if (logger.isInfoEnabled())
  {
@@@ -274,20 -265,16 +274,30 @@@
  }
  }
  
 +private SSTableWriter createCompactionWriter(File sstableDirectory, long 
keysPerSSTable)
 +{
 +return new SSTableWriter(cfs.getTempSSTablePath(sstableDirectory),
 + keysPerSSTable,
 + cfs.metadata,
 + cfs.partitioner,
 + SSTableMetadata.cre

[1/2] git commit: Add SSTableSplitter tool to split sstables offline

2013-08-22 Thread slebresne
Updated Branches:
  refs/heads/cassandra-2.0.0 5774ecb40 -> 624a7a02f


Add SSTableSplitter tool to split sstables offline

patch by slebresne; reviewed by krummas for CASSANDRA-4766


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

Branch: refs/heads/cassandra-2.0.0
Commit: 39066b722607fa88e75d5bc772bd52f1ec8914a0
Parents: 9bb4d93
Author: Sylvain Lebresne 
Authored: Sun Nov 11 14:54:43 2012 +0100
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:08:10 2013 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|   3 +-
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 427 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e1c963c..e887c27 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -26,6 +26,7 @@
  * Fix to support off heap bloom filters size greater than 2 GB 
(CASSANDRA-5903)
  * Properly handle parsing huge map and set literals (CASSANDRA-5893)
  * Fix LCS L0 compaction may overlap in L1 (CASSANDRA-5907)
+ * New sstablesplit tool to split large sstables offline (CASSANDRA-4766)
 Merged from 1.1:
  * Correctly validate sparse composite cells in scrub (CASSANDRA-5855)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 11281ee..491a438 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -18,9 +18,10 @@ using the provided 'sstableupgrade' tool.
 
 Features
 
-- A history of executed nodetool commands is now captured. 
+- A history of executed nodetool commands is now captured.
   It can be found in ~/.cassandra/nodetool.history. Other tools output 
files
   (cli and cqlsh history, .cqlshrc) are now centralized in ~/.cassandra, 
as well.
+- A new sstablesplit utility allows to split large sstables offline.
 
 Defaults
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/bin/sstablesplit
--
diff --git a/bin/sstablesplit b/bin/sstablesplit
new file mode 100755
index 000..933a67d
--- /dev/null
+++ b/bin/sstablesplit
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+# 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.
+
+if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
+for include in /usr/share/cassandra/cassandra.in.sh \
+   /usr/local/share/cassandra/cassandra.in.sh \
+   /opt/cassandra/cassandra.in.sh \
+   ~/.cassandra.in.sh \
+   `dirname $0`/cassandra.in.sh; do
+if [ -r $include ]; then
+. $include
+break
+fi
+done
+elif [ -r $CASSANDRA_INCLUDE ]; then
+. $CASSANDRA_INCLUDE
+fi
+
+# Use JAVA_HOME if set, otherwise look for java in PATH
+if [ -x $JAVA_HOME/bin/java ]; then
+JAVA=$JAVA_HOME/bin/java
+else
+JAVA=`which java`
+fi
+
+if [ -z $CLASSPATH ]; then
+echo "You must set the CLASSPATH var" >&2
+exit 1
+fi
+
+$JAVA -ea -cp $CLASSPATH -Xmx256M \
+-Dlog4j.configuration=log4j-tools.properties \
+org.apache.cassandra.tools.StandaloneSplitter "$@"
+
+# vi:ai sw=4 ts=4 tw=0 et

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/debian/cassandra.install
--
diff --git a/debian/cassandra.install b/debian/cassandra.install
index a504b78..70d4b97 100644
--- a/debian/cassandra.

[jira] [Resolved] (CASSANDRA-4766) ReverseCompaction

2013-08-22 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne resolved CASSANDRA-4766.
-

Resolution: Fixed

Alright, committed then, thanks

> ReverseCompaction
> -
>
> Key: CASSANDRA-4766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4766
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 1.2.9
>
> Attachments: 4766.txt
>
>
> Sometimes you run into a situation where your sized tiered SSTables get to be 
> a funky size. Maybe a repair starts this or you were forced into a 
> compaction. In any case we should be able to anti-compact a table, since 
> anti-compact is a bad word lets call this reverse compact. This could be done 
> online or offline. Closely related is SSTables cound have a max size. Leveled 
> is not right for everyone.

--
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 SSTableSplitter tool to split sstables offline

2013-08-22 Thread slebresne
Updated Branches:
  refs/heads/cassandra-1.2 9bb4d93e3 -> 39066b722


Add SSTableSplitter tool to split sstables offline

patch by slebresne; reviewed by krummas for CASSANDRA-4766


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

Branch: refs/heads/cassandra-1.2
Commit: 39066b722607fa88e75d5bc772bd52f1ec8914a0
Parents: 9bb4d93
Author: Sylvain Lebresne 
Authored: Sun Nov 11 14:54:43 2012 +0100
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 10:08:10 2013 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|   3 +-
 bin/sstablesplit|  50 
 debian/cassandra.install|   1 +
 .../cassandra/db/compaction/CompactionTask.java |  14 +-
 .../db/compaction/SSTableSplitter.java  | 105 
 .../cassandra/tools/StandaloneSplitter.java | 256 +++
 7 files changed, 427 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e1c963c..e887c27 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -26,6 +26,7 @@
  * Fix to support off heap bloom filters size greater than 2 GB 
(CASSANDRA-5903)
  * Properly handle parsing huge map and set literals (CASSANDRA-5893)
  * Fix LCS L0 compaction may overlap in L1 (CASSANDRA-5907)
+ * New sstablesplit tool to split large sstables offline (CASSANDRA-4766)
 Merged from 1.1:
  * Correctly validate sparse composite cells in scrub (CASSANDRA-5855)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 11281ee..491a438 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -18,9 +18,10 @@ using the provided 'sstableupgrade' tool.
 
 Features
 
-- A history of executed nodetool commands is now captured. 
+- A history of executed nodetool commands is now captured.
   It can be found in ~/.cassandra/nodetool.history. Other tools output 
files
   (cli and cqlsh history, .cqlshrc) are now centralized in ~/.cassandra, 
as well.
+- A new sstablesplit utility allows to split large sstables offline.
 
 Defaults
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/bin/sstablesplit
--
diff --git a/bin/sstablesplit b/bin/sstablesplit
new file mode 100755
index 000..933a67d
--- /dev/null
+++ b/bin/sstablesplit
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+# 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.
+
+if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
+for include in /usr/share/cassandra/cassandra.in.sh \
+   /usr/local/share/cassandra/cassandra.in.sh \
+   /opt/cassandra/cassandra.in.sh \
+   ~/.cassandra.in.sh \
+   `dirname $0`/cassandra.in.sh; do
+if [ -r $include ]; then
+. $include
+break
+fi
+done
+elif [ -r $CASSANDRA_INCLUDE ]; then
+. $CASSANDRA_INCLUDE
+fi
+
+# Use JAVA_HOME if set, otherwise look for java in PATH
+if [ -x $JAVA_HOME/bin/java ]; then
+JAVA=$JAVA_HOME/bin/java
+else
+JAVA=`which java`
+fi
+
+if [ -z $CLASSPATH ]; then
+echo "You must set the CLASSPATH var" >&2
+exit 1
+fi
+
+$JAVA -ea -cp $CLASSPATH -Xmx256M \
+-Dlog4j.configuration=log4j-tools.properties \
+org.apache.cassandra.tools.StandaloneSplitter "$@"
+
+# vi:ai sw=4 ts=4 tw=0 et

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39066b72/debian/cassandra.install
--
diff --git a/debian/cassandra.install b/debian/cassandra.install
index a504b78..70d4b97 100644
--- a/debian/cassandra.inst

[jira] [Commented] (CASSANDRA-5799) Column can expire while lazy compacting it...

2013-08-22 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747345#comment-13747345
 ] 

Sylvain Lebresne commented on CASSANDRA-5799:
-

bq. Does it matter that my SSTables are mostly on version ic?

I shouldn't matter, no.

bq. but I fear it's still an issue. Here is a stack I just saw in my freshly 
upgraded 1.2.7 cluster

It could be that there is still a problem. But I'm confident that we did fixed 
one issue with this ticket, so that would be a separate problem. Let's track 
that new problem in CASSANDRA-5720 then maybe. Can you indicate in that latter 
issue that you can reproduce on 1.2.7 btw (so we don't close it as a duplicate 
of something fixed).

bq. I've been unable to compact this CF since we went to C* 1.2.

If you have some sstables that always fail to compact with that error on 1.2.7, 
then would you be allowed to provide that set of sstables privately so I can 
check what's going on on my side?

> Column can expire while lazy compacting it...
> -
>
> Key: CASSANDRA-5799
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5799
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.2.6
>Reporter: Fabien Rousseau
>Assignee: Sylvain Lebresne
> Fix For: 1.2.7
>
> Attachments: 5799.txt
>
>
> Using TTL + range tombstones can lead to failure while lazy compacting rows.
> Scenario to reproduce :
>  - create an SSTable with one row and some columns and a TTL of 8 seconds
>  - wait one second
>  - create a second SSTable with the same rowkey as above, and add a range 
> tombstone
>  - start the first pass of the lazy compaction before the columns with TTL 
> are expired
>  - wait 10 seconds (enough for columns with TTL to expire)
>  - continue lazy expiration
>  - the following assertion will fail :
> [junit] junit.framework.AssertionFailedError: originally calculated 
> column size of 1379 but now it is 1082
> [junit]   at 
> org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:150)

--
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 changelog

2013-08-22 Thread slebresne
Updated Branches:
  refs/heads/cassandra-2.0 f8be23a81 -> da55d76d2


Fix changelog


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

Branch: refs/heads/cassandra-2.0
Commit: da55d76d2c15257610959eee43dec197262c0422
Parents: f8be23a
Author: Sylvain Lebresne 
Authored: Thu Aug 22 09:29:55 2013 +0200
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 09:29:55 2013 +0200

--
 CHANGES.txt | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/da55d76d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 14fee1d..0166345 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -7,6 +7,7 @@
  * Cleanup doesn't need to inspect sstables that contain only local data 
(CASSANDRA-5722)
  * Add ability for CQL3 to list partition keys (CASSANDRA-4536)
+ * Improve native protocol serialization (CASSANDRA-5664)
 
 
 2.0.0



[1/3] git commit: reduce Map allocations in hinted handoff delivery patch by dbrosius reviewed by jbellis for cassandra-5919

2013-08-22 Thread slebresne
Updated Branches:
  refs/heads/trunk d60ead8ee -> d24e90009


reduce Map allocations in hinted handoff delivery
patch by dbrosius reviewed by jbellis for cassandra-5919


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

Branch: refs/heads/trunk
Commit: 647e0678db7c4a112a605754459e3d67973275c3
Parents: 1af59e3
Author: Dave Brosius 
Authored: Wed Aug 21 23:32:37 2013 -0400
Committer: Dave Brosius 
Committed: Wed Aug 21 23:32:37 2013 -0400

--
 src/java/org/apache/cassandra/db/HintedHandOffManager.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/647e0678/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--
diff --git a/src/java/org/apache/cassandra/db/HintedHandOffManager.java 
b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
index 014a4cc..406f62d 100644
--- a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
+++ b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
@@ -356,7 +356,7 @@ public class HintedHandOffManager implements 
HintedHandOffManagerMBean
 }
 
 List responseHandlers = Lists.newArrayList();
-
+Map truncationTimesCache = new HashMap();
 for (final Column hint : hintsPage)
 {
 // check if hints delivery has been paused during the process
@@ -395,7 +395,7 @@ public class HintedHandOffManager implements 
HintedHandOffManagerMBean
 throw new AssertionError(e);
 }
 
-Map truncationTimesCache = new HashMap();
+truncationTimesCache.clear();
 for (UUID cfId : 
ImmutableSet.copyOf((rm.getColumnFamilyIds(
 {
 Long truncatedAt = truncationTimesCache.get(cfId);



[3/3] git commit: Merge branch 'cassandra-2.0' into trunk

2013-08-22 Thread slebresne
Merge branch 'cassandra-2.0' into trunk


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

Branch: refs/heads/trunk
Commit: d24e900095e3f938a3c12631d182e8b0f0657fa4
Parents: d60ead8 f8be23a
Author: Sylvain Lebresne 
Authored: Thu Aug 22 09:23:33 2013 +0200
Committer: Sylvain Lebresne 
Committed: Thu Aug 22 09:23:33 2013 +0200

--
 .../org/apache/cassandra/cql3/QueryOptions.java |  82 +++---
 .../org/apache/cassandra/cql3/ResultSet.java|  77 +++--
 .../org/apache/cassandra/transport/CBCodec.java |   3 +-
 .../org/apache/cassandra/transport/CBUtil.java  | 281 ---
 .../apache/cassandra/transport/DataType.java|  10 +-
 .../org/apache/cassandra/transport/Event.java   |  54 +++-
 .../cassandra/transport/FrameCompressor.java|  12 +-
 .../org/apache/cassandra/transport/Message.java |  18 +-
 .../apache/cassandra/transport/OptionCodec.java |  10 +-
 .../transport/messages/AuthChallenge.java   |  16 +-
 .../transport/messages/AuthResponse.java|  16 +-
 .../transport/messages/AuthSuccess.java |  17 +-
 .../transport/messages/AuthenticateMessage.java |  14 +-
 .../transport/messages/BatchMessage.java|  70 ++---
 .../transport/messages/CredentialsMessage.java  |  35 +--
 .../transport/messages/ErrorMessage.java|  79 +++---
 .../transport/messages/EventMessage.java|  14 +-
 .../transport/messages/ExecuteMessage.java  |  45 ++-
 .../transport/messages/OptionsMessage.java  |  13 +-
 .../transport/messages/PrepareMessage.java  |  14 +-
 .../transport/messages/QueryMessage.java|  30 +-
 .../transport/messages/ReadyMessage.java|  13 +-
 .../transport/messages/RegisterMessage.java |  21 +-
 .../transport/messages/ResultMessage.java   | 128 -
 .../transport/messages/StartupMessage.java  |  16 +-
 .../transport/messages/SupportedMessage.java|  16 +-
 26 files changed, 611 insertions(+), 493 deletions(-)
--




[jira] [Commented] (CASSANDRA-5708) Add DELETE ... IF EXISTS to CQL3

2013-08-22 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747327#comment-13747327
 ] 

Sylvain Lebresne commented on CASSANDRA-5708:
-

Right, we can't fully rely on the row marker anymore. That being said, we can 
still do a simple slice query with a limit of 1 to check for existence (we 
already do it for IF NOT EXISTS in fact). We just probably require a flag in 
SP.cas() to say "apply the cas if the result fetch is *not* null".

> Add DELETE ... IF EXISTS to CQL3
> 
>
> Key: CASSANDRA-5708
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5708
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Priority: Minor
> Fix For: 2.0.1
>
>
> I've been slightly lazy in CASSANDRA-5443 and didn't added a {{DELETE .. IF 
> EXISTS}} syntax to CQL because it wasn't immediately clear what was the 
> correct condition to use for the "IF EXISTS". But at least for CQL3 tables, 
> this is in fact pretty easy to do using the row marker so we should probably 
> add it.

--
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