date:20110425


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

Jonathan Ellis commented on CASSANDRA-2552:
---

Hard to tell exactly what's going on here w/o knowing where your logging was 
added.

In particular it's important to note that we don't prevent responses from being 
processed after we've already given up and decided to call a timeout (but 
before we've torn down the request callback).

 ReadResponseResolver Race
 -

 Key: CASSANDRA-2552
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2552
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Stu Hood
Assignee: Stu Hood
 Fix For: 0.8.0


 When receiving a response, ReadResponseResolver uses a 3 step process to 
 decide whether to trigger the condition that enough responses have arrived:
 # Add new response
 # Check response set size
 # Check that data is present
 I think that these steps must have been reordered by the compiler in some 
 cases, because I was able to reproduce a case for a QUORUM read where the 
 condition is not properly triggered:
 {noformat}
 INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514 
 ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false 
 in 2 messages
 INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514 
 ReadResponseResolver.java (line 87) post append for 1087367065: hasData=true 
 in 1 messages
 INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623) 
 Read timeout: java.util.concurrent.TimeoutException: 
 ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
 {noformat}
 The last line shows that both results were present, and that one of them was 
 holding data.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-803) remove PropertyConfigurator from CassandraDaemon


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

Jonathan Ellis commented on CASSANDRA-803:
--

It was added back for CASSANDRA-1525

 remove PropertyConfigurator from CassandraDaemon
 

 Key: CASSANDRA-803
 URL: https://issues.apache.org/jira/browse/CASSANDRA-803
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.6
Reporter: Jesse McConnell

 In order for users to make use of the EmbeddedCassandraService for unit 
 testing they need to have a dependency declared on log4j.  
 It would be nice if we could use the log4j-over-slf4j artifact to bridge this 
 requirement for those of us using slf4j.  
 http://www.slf4j.org/legacy.html#log4j-over-slf4j
 Currently it errors with the direct usage of the PropertyConfigurator in 
 o.a.c.thrift.CassandraDaemon.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1096479 - in /cassandra/branches/cassandra-0.8: CHANGES.txt src/java/org/apache/cassandra/tools/NodeCmd.java

Author: jbellis
Date: Mon Apr 25 13:38:11 2011
New Revision: 1096479

URL: http://svn.apache.org/viewvc?rev=1096479view=rev
Log:
fix nodetool setcompactionthroughput
patch by Terje Marthinussen; reviewed by jbellis for CASSANDRA-2550

Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java

Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1096479r1=1096478r2=1096479view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Mon Apr 25 13:38:11 2011
@@ -2,6 +2,7 @@
  * fix NPE compacting index CFs (CASSANDRA-2528)
  * Remove checking all column families on startup for compaction candidates 
(CASSANDRA-2444)
  * validate CQL create keyspace options (CASSANDRA-2525)
+ * fix nodetool setcompactionthroughput (CASSANDRA-2550)
 
 
 0.8.0-beta1

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java?rev=1096479r1=1096478r2=1096479view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java
 Mon Apr 25 13:38:11 2011
@@ -592,8 +592,8 @@ public class NodeCmd
 break;
 
 case SETCOMPACTIONTHROUGHPUT :
-if (arguments.length != 2) { badUse(Missing value 
argument.); }
-probe.setCompactionThroughput(Integer.valueOf(arguments[1]));
+if (arguments.length != 1) { badUse(Missing value 
argument.); }
+probe.setCompactionThroughput(Integer.valueOf(arguments[0]));
 break;
 
 case REMOVETOKEN :

[jira] [Resolved] (CASSANDRA-2550) nodetool setcompactionthroughput requiring wrong number of arguments?


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

Jonathan Ellis resolved CASSANDRA-2550.
---

   Resolution: Fixed
Fix Version/s: 0.8.0
 Reviewer: jbellis
 Assignee: Terje Marthinussen  (was: Stu Hood)

fixed in r1096479, thanks!

 nodetool setcompactionthroughput requiring wrong number of arguments?
 -

 Key: CASSANDRA-2550
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2550
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 0.8 beta 1
Reporter: Terje Marthinussen
Assignee: Terje Marthinussen
Priority: Minor
  Labels: nodetool
 Fix For: 0.8.0


 ---
 case SETCOMPACTIONTHROUGHPUT :
 if (arguments.length != 2) { badUse(Missing value 
 argument.); }
 probe.setCompactionThroughput(Integer.valueOf(arguments[1]));
 break;
 ---
 I would think arguments.length should be just 1?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-2553) Add IN support to CQL SELECT, UPDATE statements

Add IN support to CQL SELECT, UPDATE statements
---

 Key: CASSANDRA-2553
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2553
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
 Fix For: 0.8.1


See CASSANDRA-2538 for example usage.

(Note that UPDATE supporting IN is not very useful; normally you would want to 
use BATCHes instead. Still, unless adding it is more difficult for some reason, 
we might as well do it for consistency.)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2538) CQL: NPE running SELECT with an IN clause


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

Jonathan Ellis commented on CASSANDRA-2538:
---

Okay, created CASSANDRA-2553 for adding IN support to 0.8.1.

+1 on the NPE fix.

 CQL: NPE running SELECT with an IN clause
 -

 Key: CASSANDRA-2538
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2538
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.8 beta 1
Reporter: Cathy Daw
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 0.8.0

 Attachments: 
 v1-0001-CASSANDRA-2538-NPE-running-SELECT-with-an-IN-clause.txt


 *Test Case to Run*
 {noformat}
 cqlsh select * from users where key in ('user2', 'user3');
 Internal application error
 {noformat}
 *Test Setup*
 {noformat}
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar);
 INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
 {noformat}
 *Log Files*
 {noformat}
 ERROR [RequestResponseStage:17] 2011-04-21 23:36:41,600 
 AbstractCassandraDaemon.java (line 112) Fatal exception in thread 
 Thread[RequestResponseStage:17,5,main]
 java.lang.AssertionError
   at 
 org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
   at 
 org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
   at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:636)
 ERROR [RequestResponseStage:17] 2011-04-21 23:36:41,600 
 AbstractCassandraDaemon.java (line 112) Fatal exception in thread 
 Thread[RequestResponseStage:17,5,main]
 java.lang.AssertionError
   at 
 org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
   at 
 org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
   at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:636)
 ERROR [pool-2-thread-5] 2011-04-21 23:37:12,026 Cassandra.java (line 4082) 
 Internal error processing execute_cql_query
 java.lang.NullPointerException
   at org.apache.cassandra.cql.WhereClause.and(WhereClause.java:59)
   at org.apache.cassandra.cql.WhereClause.init(WhereClause.java:44)
   at org.apache.cassandra.cql.CqlParser.whereClause(CqlParser.java:816)
   at 
 org.apache.cassandra.cql.CqlParser.selectStatement(CqlParser.java:502)
   at org.apache.cassandra.cql.CqlParser.query(CqlParser.java:191)
   at 
 org.apache.cassandra.cql.QueryProcessor.getStatement(QueryProcessor.java:834)
   at 
 org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:463)
   at 
 org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1134)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.process(Cassandra.java:4072)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:636)
 {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1096483 - in /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra: service/StorageProxy.java thrift/CassandraServer.java

Author: jbellis
Date: Mon Apr 25 13:53:53 2011
New Revision: 1096483

URL: http://svn.apache.org/viewvc?rev=1096483view=rev
Log:
centralize timeout logging in StorageProxy, and preserve the timeoutexception 
message
patch by Stu Hood; reviewed by jbellis for CASSANDRA-2532

Modified:

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/thrift/CassandraServer.java

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java?rev=1096483r1=1096482r2=1096483view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java
 Mon Apr 25 13:53:53 2011
@@ -160,6 +160,17 @@ public class StorageProxy implements Sto
 responseHandler.get();
 }
 }
+catch (TimeoutException ex)
+{
+if (logger.isDebugEnabled())
+{
+ListString mstrings = new ArrayListString();
+for (IMutation mutation : mutations)
+mstrings.add(mutation.toString(true));
+logger.debug(Write timeout {} for one (or more) of: , 
ex.toString(), mstrings);
+}
+throw ex;
+}
 catch (IOException e)
 {
 assert mostRecentMutation != null;
@@ -568,11 +579,16 @@ public class StorageProxy implements Sto
 if (logger.isDebugEnabled())
 logger.debug(Read:  + (System.currentTimeMillis() - 
startTime2) +  ms.);
 }
+catch (TimeoutException ex)
+{
+if (logger.isDebugEnabled())
+logger.debug(Read timeout: {}, ex.toString());
+throw ex;
+}
 catch (DigestMismatchException ex)
 {
 if (logger.isDebugEnabled())
-logger.debug(Digest mismatch:, ex);
-
+logger.debug(Digest mismatch: {}, ex.toString());
 RowRepairResolver resolver = new 
RowRepairResolver(command.table, command.key);
 RepairCallbackRow repairHandler = new 
RepairCallbackRow(resolver, handler.endpoints);
 for (InetAddress endpoint : handler.endpoints)
@@ -703,6 +719,12 @@ public class StorageProxy implements Sto
 logger.debug(range slices read {}, row.key);
 }
 }
+catch (TimeoutException ex)
+{
+if (logger.isDebugEnabled())
+logger.debug(Range slice timeout: {}, 
ex.toString());
+throw ex;
+}
 catch (DigestMismatchException e)
 {
 throw new AssertionError(e); // no digests in range 
slices yet
@@ -963,6 +985,12 @@ public class StorageProxy implements Sto
 logger.debug(read {}, row);
 }
 }
+catch (TimeoutException ex)
+{
+if (logger.isDebugEnabled())
+logger.debug(Index scan timeout: {}, ex.toString());
+throw ex;
+}
 catch (DigestMismatchException e)
 {
 throw new RuntimeException(e);

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/thrift/CassandraServer.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/thrift/CassandraServer.java?rev=1096483r1=1096482r2=1096483view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/thrift/CassandraServer.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/thrift/CassandraServer.java
 Mon Apr 25 13:53:53 2011
@@ -115,7 +115,6 @@ public class CassandraServer implements 
 }
 catch (TimeoutException e) 
 {
-logger.debug(... timed out);
throw new TimedOutException();
 }
 catch (IOException e)
@@ -552,7 +551,6 @@ public class CassandraServer implements 
 }
 catch (TimeoutException e)
 {
-logger.debug(... timed out);
 throw new TimedOutException();
 }
 }
@@ -620,7 +618,6 @@ public class CassandraServer implements 
 }
 catch (TimeoutException e)
 {
-logger.debug(... timed out);
throw new

[jira] [Commented] (CASSANDRA-2221) 'show create' commands on the CLI to export schema

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

Jonathan Ellis commented on CASSANDRA-2221:
---

It's still valuable to support this from CLI since (a) this gives us an upgrade
path for 0.7 to 0.8 and (b) CQL isn't going to support all the options for
0.8.0 (notably counters).

I'd like to introduce a new command though instead of changing an existing one
in a stable release. show schema maybe?

'show create' commands on the CLI to export schema
--

Key: CASSANDRA-2221
URL: https://issues.apache.org/jira/browse/CASSANDRA-2221
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Jeremy Hanna
Assignee: Aaron Morton
Priority: Minor
Labels: cli
Fix For: 0.8.1

Attachments:
0001-change-show-keyspace-to-create-cli-script-v0.8.patch,
0001-change-show-keyspace-to-create-cli-script.patch

It would be nice to have 'show create' type of commands on the command-line
so that it would generate the DDL for the schema.
A scenario that would make this useful is where a team works out a data model
over time with a dev cluster. They want to use parts of that schema for new
clusters that they create, like a staging/prod cluster. It would be very
handy in this scenario to have some sort of export mechanism.
Another use case is for testing purposes - you want to replicate a problem.
We currently have schematool for import/export but that is deprecated and it
exports into yaml.
This new feature would just be able to 'show' - or export if they want the
entire keyspace - into a script or commands that could be used in a cli
script. It would need to be able to regenerate everything about the keyspace
including indexes and metadata.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-624) maven install does not find libthrift-r808609.jar

2011-04-25 Thread Jake Farrell (JIRA)


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

Jake Farrell commented on CASSANDRA-624:


Libthrift and libfb303 now available in the apache repo 
(http://repo1.maven.org/maven2)

dependency
  groupIdorg.apache.thrift/groupId
  artifactIdlibthrift/artifactId
  version[0.6.1,)/version
/dependency

 maven install does not find libthrift-r808609.jar
 ---

 Key: CASSANDRA-624
 URL: https://issues.apache.org/jira/browse/CASSANDRA-624
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: svn trunk r889436
Reporter: Christophe Pierret
Priority: Minor
 Fix For: 0.5, 0.6

 Attachments: pom.xml.patch


 Do a fresh svn checkout of subversion trunk HEAD (at revision 89436 when 
 error occurred)
 run: maven -e install
 It fails, not finding dependency libthrift.jar
 pom.xml references ${basedir}/lib/libthrift-r808609.jar
 It should be ${basedir}/lib/libthrift-r820831.jar

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts

2011-04-25 Thread Brian Lovett (JIRA)


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

Brian Lovett commented on CASSANDRA-2536:
-

Just bumped into this on a fresh 0.7.4 install on our test cluster. Does this 
only happen in a 2 node ring?

 Schema disagreements when using connections to multiple hosts
 -

 Key: CASSANDRA-2536
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2536
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8 beta 1
 Environment: Two node 0.8-beta1 cluster with one seed and JNA.
Reporter: Tyler Hobbs
Assignee: Gary Dusbabek
 Attachments: schema_disagree.py


 If you have two thrift connections open to different nodes and you create a 
 KS using the first, then a CF in that KS using the second, you wind up with a 
 schema disagreement even if you wait/sleep after creating the KS.
 The attached script reproduces the issue using pycassa (1.0.6 should work 
 fine, although it has the 0.7 thrift-gen code).  It's also reproducible by 
 hand with two cassandra-cli sessions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2537) CQL: Support for batch insert/delete


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

Pavel Yaskevich commented on CASSANDRA-2537:


The question is do we need that? will it be semantically right?

 CQL: Support for batch insert/delete
 

 Key: CASSANDRA-2537
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 0.8 beta 1
 Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: CASSANDRA-2537.patch


 *Test Case To Run*
 {code}
 // Setup
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar);
 //Batch Insert
 BEGIN BATCH USING QUORUM
 INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
 APPLY BATCH
 {code}
 *Actual Behavior*
 {code}
 cqlsh BEGIN BATCH USING QUORUM
... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 Bad Request: line 0:-1 mismatched input 'EOF' expecting K_APPLY
 {code}
 *Documentation Sample*
 {code}
 BEGIN BATCH [USING CONSISTENCY]
 UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
 UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
 UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
 APPLY BATCH
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2537) CQL: Support for batch insert/delete

2011-04-25 Thread Eric Evans (JIRA)


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

Eric Evans commented on CASSANDRA-2537:
---

Pavel,

I don't have time to look over the patch just now, but could you make sure that 
these changes include updated documentation in doc/cql/CQL.textile?

Thanks.

 CQL: Support for batch insert/delete
 

 Key: CASSANDRA-2537
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 0.8 beta 1
 Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: CASSANDRA-2537-v2.patch, CASSANDRA-2537.patch


 *Test Case To Run*
 {code}
 // Setup
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar);
 //Batch Insert
 BEGIN BATCH USING QUORUM
 INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
 APPLY BATCH
 {code}
 *Actual Behavior*
 {code}
 cqlsh BEGIN BATCH USING QUORUM
... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 Bad Request: line 0:-1 mismatched input 'EOF' expecting K_APPLY
 {code}
 *Documentation Sample*
 {code}
 BEGIN BATCH [USING CONSISTENCY]
 UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
 UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
 UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
 APPLY BATCH
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2537) CQL: Support for batch insert/delete


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

Pavel Yaskevich commented on CASSANDRA-2537:


Eric, sorry but I am too scared to touch documentation...
Jonathan, can I you to update doc when you will be reviewing?

 CQL: Support for batch insert/delete
 

 Key: CASSANDRA-2537
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 0.8 beta 1
 Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: CASSANDRA-2537-v2.patch, CASSANDRA-2537.patch


 *Test Case To Run*
 {code}
 // Setup
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar);
 //Batch Insert
 BEGIN BATCH USING QUORUM
 INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
 APPLY BATCH
 {code}
 *Actual Behavior*
 {code}
 cqlsh BEGIN BATCH USING QUORUM
... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 Bad Request: line 0:-1 mismatched input 'EOF' expecting K_APPLY
 {code}
 *Documentation Sample*
 {code}
 BEGIN BATCH [USING CONSISTENCY]
 UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
 UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
 UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
 APPLY BATCH
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2526) Add ant support to generate CQL documentation from textile source

2011-04-25 Thread Nate McCall (JIRA)


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

Nate McCall commented on CASSANDRA-2526:


Looks like they have an issue which leaves out message resource bundles for the 
ant task when they roll their jar files. I have an email with a patch sent out, 
so will wait to hear back. If not, we can just fork and deploy our own cut of 
just the ant task which will play nice with their existing jars. 

Ie. we would end up with two jars instead of one:
wikitext-core.jar (packaged fusesource)
wikitext-ant-task.jar (packaged by DataStax)

The goal would be to get wikitext-ant-task avaialable on maven central as well. 

Ideally I just hear back from fusesource and they will fix + redeploy. 

 Add ant support to generate CQL documentation from textile source
 -

 Key: CASSANDRA-2526
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2526
 Project: Cassandra
  Issue Type: Task
Affects Versions: 0.8 beta 1
Reporter: Jonathan Ellis
Assignee: Nate McCall
Priority: Minor
 Fix For: 0.8.0


 possibly useful links: 
 - 
 http://help.eclipse.org/helios/topic/org.eclipse.mylyn.wikitext.help.ui/help/Markup-Conversion.html#ConversionusingAntbuildscripts
 - 
 http://www.mvnbrowser.com/artifact-details.html?groupId=org.eclipse.mylyn.wikitextartifactId=wikitext

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2404) if out of disk space reclaim compacted SSTables during memtable flush

2011-04-25 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-2404:
-

Minor comments: in the estimation, the index size could be slightly improved by 
adding 10 * nb of keys (2 for the written size of the key + 8 for the recorded 
position). It's  an estimation though so not a huge deal.

But otherwise, +1.

Made me wonder (but not directly related to the ticket), wouldn't it be safer 
when we're out of space to hold on the memtable (and thus block writes fairly 
quickly) instead of dropping the memtable fairly silently (we throw a 
RuntimeException that will be logged, but it still could be some time during 
which the node seems to accept write fine but will throw them out). 

 if out of disk space reclaim compacted SSTables during memtable flush
 -

 Key: CASSANDRA-2404
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2404
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Aaron Morton
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 0.7.6

 Attachments: 2404-0.7.txt, 2404-0.8.txt


 During compaction if there is not enough disk space we invoke GC to reclaim 
 unused space.
 During memtable and binary memtable flush we just error out if there is not 
 enough disk space to flush the table. 
 Can we make cfs.createFlushWriter() use the same logic as 
 Table.getDataFileLocation() to reclaim space if needed?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-2554) Move gossip heartbeats [back] to its own thread

Move gossip heartbeats [back] to its own thread
---

 Key: CASSANDRA-2554
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2554
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.7.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
 Fix For: 0.7.6


Gossip heartbeat *really* needs to run every 1s or other nodes may mark us 
down. But gossip currently shares an executor thread with other tasks.

I see at least two of these could cause blocking: hint cleanup post-delivery 
and flush-expired-memtables, both of which call forceFlush which will block if 
the flush queue + threads are full.

We've run into this before (CASSANDRA-2253); we should move Gossip back to its 
own dedicated executor or it will keep happening whenever someone accidentally 
puts something on the shared executor that can block.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2554) Move gossip heartbeats [back] to its own thread


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

Jonathan Ellis updated CASSANDRA-2554:
--

Attachment: 2554-0.7.txt

 Move gossip heartbeats [back] to its own thread
 ---

 Key: CASSANDRA-2554
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2554
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.7.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
 Fix For: 0.7.6

 Attachments: 2554-0.7.txt


 Gossip heartbeat *really* needs to run every 1s or other nodes may mark us 
 down. But gossip currently shares an executor thread with other tasks.
 I see at least two of these could cause blocking: hint cleanup post-delivery 
 and flush-expired-memtables, both of which call forceFlush which will block 
 if the flush queue + threads are full.
 We've run into this before (CASSANDRA-2253); we should move Gossip back to 
 its own dedicated executor or it will keep happening whenever someone 
 accidentally puts something on the shared executor that can block.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2554) Move gossip heartbeats [back] to its own thread


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

Jonathan Ellis updated CASSANDRA-2554:
--

Attachment: (was: 2554-0.7.txt)

 Move gossip heartbeats [back] to its own thread
 ---

 Key: CASSANDRA-2554
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2554
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.7.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
 Fix For: 0.7.6

 Attachments: 2554-0.7.txt


 Gossip heartbeat *really* needs to run every 1s or other nodes may mark us 
 down. But gossip currently shares an executor thread with other tasks.
 I see at least two of these could cause blocking: hint cleanup post-delivery 
 and flush-expired-memtables, both of which call forceFlush which will block 
 if the flush queue + threads are full.
 We've run into this before (CASSANDRA-2253); we should move Gossip back to 
 its own dedicated executor or it will keep happening whenever someone 
 accidentally puts something on the shared executor that can block.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2554) Move gossip heartbeats [back] to its own thread


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

Jonathan Ellis updated CASSANDRA-2554:
--

Attachment: 2554-0.7.txt

 Move gossip heartbeats [back] to its own thread
 ---

 Key: CASSANDRA-2554
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2554
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.7.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
 Fix For: 0.7.6

 Attachments: 2554-0.7.txt


 Gossip heartbeat *really* needs to run every 1s or other nodes may mark us 
 down. But gossip currently shares an executor thread with other tasks.
 I see at least two of these could cause blocking: hint cleanup post-delivery 
 and flush-expired-memtables, both of which call forceFlush which will block 
 if the flush queue + threads are full.
 We've run into this before (CASSANDRA-2253); we should move Gossip back to 
 its own dedicated executor or it will keep happening whenever someone 
 accidentally puts something on the shared executor that can block.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2537) CQL: Support for batch insert/delete


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

Pavel Yaskevich updated CASSANDRA-2537:
---

Reviewer: jbellis  (was: urandom)

 CQL: Support for batch insert/delete
 

 Key: CASSANDRA-2537
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 0.8 beta 1
 Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: CASSANDRA-2537-v2.patch, CASSANDRA-2537.patch


 *Test Case To Run*
 {code}
 // Setup
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar);
 //Batch Insert
 BEGIN BATCH USING QUORUM
 INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
 APPLY BATCH
 {code}
 *Actual Behavior*
 {code}
 cqlsh BEGIN BATCH USING QUORUM
... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 Bad Request: line 0:-1 mismatched input 'EOF' expecting K_APPLY
 {code}
 *Documentation Sample*
 {code}
 BEGIN BATCH [USING CONSISTENCY]
 UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
 UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
 UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
 APPLY BATCH
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1096534 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/utils/

Author: jbellis
Date: Mon Apr 25 17:34:56 2011
New Revision: 1096534

URL: http://svn.apache.org/viewvc?rev=1096534view=rev
Log:
merge from 0.7

Modified:
cassandra/branches/cassandra-0.8/   (props changed)
cassandra/branches/cassandra-0.8/NEWS.txt
cassandra/branches/cassandra-0.8/contrib/   (props changed)

cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
   (props changed)

cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java
   (props changed)

cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java
   (props changed)

cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java
   (props changed)

cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java
   (props changed)

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Memtable.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/utils/BloomFilter.java

Propchange: cassandra/branches/cassandra-0.8/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Apr 25 17:34:56 2011
@@ -1,5 +1,5 @@
 
/cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000
-/cassandra/branches/cassandra-0.7:1026516-1095767,1095916
+/cassandra/branches/cassandra-0.7:1026516-1096531
 /cassandra/branches/cassandra-0.7.0:1053690-1055654
 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689
 /cassandra/trunk:1090978-1090979

Modified: cassandra/branches/cassandra-0.8/NEWS.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/NEWS.txt?rev=1096534r1=1096533r2=1096534view=diff
==
--- cassandra/branches/cassandra-0.8/NEWS.txt (original)
+++ cassandra/branches/cassandra-0.8/NEWS.txt Mon Apr 25 17:34:56 2011
@@ -41,6 +41,26 @@ JMX
 - By default, JMX now listens on port 7199.
 
 
+0.7.5
+=
+
+Upgrading
+-
+- Nothing specific to 0.7.5, but see 0.7.3 Upgrading if upgrading
+  from earlier than 0.7.1.
+
+Changes
+---
+- system_update_column_family no longer snapshots before applying
+  the schema change. (_update_keyspace never did.  _drop_keyspace
+  and _drop_column_family continue to snapshot.)
+- added memtable_flush_queue_size option to cassandra.yaml to
+  avoid blocking writes when multiple column families (or a colum
+  family with indexes) are flushed at the same time.
+- allow overriding initial_token, storage_port and rpc_port using
+  system properties
+
+
 0.7.4
 =
 

Propchange: cassandra/branches/cassandra-0.8/contrib/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Apr 25 17:34:56 2011
@@ -1,5 +1,5 @@
 
/cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009
-/cassandra/branches/cassandra-0.7/contrib:1026516-1095767,1095916
+/cassandra/branches/cassandra-0.7/contrib:1026516-1096531
 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654
 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689
 /cassandra/trunk/contrib:1090978-1090979

Propchange: 
cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Apr 25 17:34:56 2011
@@ -1,5 +1,5 @@
 
/cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000
-/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1095767,1095916
+/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1096531
 
/cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654
 
/cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689
 
/cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090978-1090979

Propchange: 
cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Apr 25 17:34:56 2011
@@ -1,5 +1,5 @@

[jira] [Updated] (CASSANDRA-2554) Move gossip heartbeats [back] to its own thread


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

Jonathan Ellis updated CASSANDRA-2554:
--

Attachment: 2554-0.8.txt

patches against 0.7 and 0.8 to move Gossip to its own executor, and move hint 
deletion + flush expired memtables + cache saving to the long-execution-time 
executor.

 Move gossip heartbeats [back] to its own thread
 ---

 Key: CASSANDRA-2554
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2554
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.7.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
 Fix For: 0.7.6

 Attachments: 2554-0.7.txt, 2554-0.8.txt


 Gossip heartbeat *really* needs to run every 1s or other nodes may mark us 
 down. But gossip currently shares an executor thread with other tasks.
 I see at least two of these could cause blocking: hint cleanup post-delivery 
 and flush-expired-memtables, both of which call forceFlush which will block 
 if the flush queue + threads are full.
 We've run into this before (CASSANDRA-2253); we should move Gossip back to 
 its own dedicated executor or it will keep happening whenever someone 
 accidentally puts something on the shared executor that can block.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2404) if out of disk space reclaim compacted SSTables during memtable flush

2011-04-25 Thread Hudson (JIRA)


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

Hudson commented on CASSANDRA-2404:
---

Integrated in Cassandra-0.7 #457 (See 
[https://builds.apache.org/hudson/job/Cassandra-0.7/457/])
force GC to reclaim disk space on flush, if necessary
patch by jbellis; reviewed by slebresne for CASSANDRA-2404


 if out of disk space reclaim compacted SSTables during memtable flush
 -

 Key: CASSANDRA-2404
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2404
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Aaron Morton
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 0.7.6

 Attachments: 2404-0.7.txt, 2404-0.8.txt


 During compaction if there is not enough disk space we invoke GC to reclaim 
 unused space.
 During memtable and binary memtable flush we just error out if there is not 
 enough disk space to flush the table. 
 Can we make cfs.createFlushWriter() use the same logic as 
 Table.getDataFileLocation() to reclaim space if needed?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2508) missing imports in CQL Python driver


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

Jonathan Ellis updated CASSANDRA-2508:
--

Reviewer: thobbs  (was: urandom)

 missing imports in CQL Python driver
 

 Key: CASSANDRA-2508
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2508
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 0.8 beta 1
Reporter: Eric Evans
Assignee: Jonathan Ellis
  Labels: cql
 Fix For: 0.8.0

 Attachments: 2508.txt


 Try:
 bq. cd drivers/py  python -c 'from cql import DateFromTicks; 
 DateFromTicks(1)'
 Also:
 {{cql.connection}} is missing an import of {{AuthenticationRequest}} from 
 {{ttypes}}, and the exceptions {{NotSupportedError}}, and {{InternalError}}.
 Also:
 {{marshal.unmarshal_long}} has a NameError waiting to happen in the form of 
 unpack

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2444) Remove checkAllColumnFamilies on startup


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

Jonathan Ellis updated CASSANDRA-2444:
--

Fix Version/s: (was: 0.8.1)

 Remove checkAllColumnFamilies on startup
 

 Key: CASSANDRA-2444
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2444
 Project: Cassandra
  Issue Type: Bug
Reporter: Chris Goffinet
Assignee: Chris Goffinet
Priority: Minor
  Labels: compaction
 Fix For: 0.8.0

 Attachments: 
 0001-CASSANDRA-2444-Remove-checking-all-column-families-o.patch


 We've ran into many times where we do not want compaction to run right away 
 against CFs when booting up a node. If the node needs to compact, it will do 
 so at the first flush

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2444) Remove checkAllColumnFamilies on startup


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

Jonathan Ellis updated CASSANDRA-2444:
--

Reviewer: stuhood

 Remove checkAllColumnFamilies on startup
 

 Key: CASSANDRA-2444
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2444
 Project: Cassandra
  Issue Type: Bug
Reporter: Chris Goffinet
Assignee: Chris Goffinet
Priority: Minor
  Labels: compaction
 Fix For: 0.8.0

 Attachments: 
 0001-CASSANDRA-2444-Remove-checking-all-column-families-o.patch


 We've ran into many times where we do not want compaction to run right away 
 against CFs when booting up a node. If the node needs to compact, it will do 
 so at the first flush

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-2555) Explicit timestamp support for CQL

Explicit timestamp support for CQL
--

 Key: CASSANDRA-2555
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2555
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
 Fix For: 0.8.1


To make CQL BATCHes useful for the normal purpose of idempotent retries, we 
need to add  support for client-supplied timestamps.  At a minimum this needs 
to be available for a batch (BEGIN BATCH USING TIMESTAMP 1303743619771318) but 
might also be nice at the statement level (UPDATE ... USING TIMESTAMP ...).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2537) CQL: Support for batch insert/delete


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

Pavel Yaskevich updated CASSANDRA-2537:
---

Attachment: CASSANDRA-2537-v3.patch

v3 only change is new documentation topic - BATCH with a syntax, little 
description and example. (removed old batch section from the UPDATE statement 
doc which was anyway outdated).

 CQL: Support for batch insert/delete
 

 Key: CASSANDRA-2537
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 0.8 beta 1
 Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: CASSANDRA-2537-v2.patch, CASSANDRA-2537-v3.patch, 
 CASSANDRA-2537.patch


 *Test Case To Run*
 {code}
 // Setup
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar);
 //Batch Insert
 BEGIN BATCH USING QUORUM
 INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
 APPLY BATCH
 {code}
 *Actual Behavior*
 {code}
 cqlsh BEGIN BATCH USING QUORUM
... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 Bad Request: line 0:-1 mismatched input 'EOF' expecting K_APPLY
 {code}
 *Documentation Sample*
 {code}
 BEGIN BATCH [USING CONSISTENCY]
 UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
 UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
 UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
 APPLY BATCH
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1096613 - in /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra: cache/AutoSavingCache.java db/HintedHandOffManager.java db/Table.java gms/Gossiper.java service/StorageServic

Author: jbellis
Date: Mon Apr 25 21:38:51 2011
New Revision: 1096613

URL: http://svn.apache.org/viewvc?rev=1096613view=rev
Log:
revert unreviewed code

Modified:

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cache/AutoSavingCache.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/HintedHandOffManager.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/Gossiper.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageService.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cache/AutoSavingCache.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cache/AutoSavingCache.java?rev=1096613r1=1096612r2=1096613view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cache/AutoSavingCache.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cache/AutoSavingCache.java
 Mon Apr 25 21:38:51 2011
@@ -99,10 +99,10 @@ public abstract class AutoSavingCacheK,
 submitWrite();
 }
 };
-saveTask = StorageService.tasks.scheduleWithFixedDelay(runnable,
-   
savePeriodInSeconds,
-   
savePeriodInSeconds,
-   
TimeUnit.SECONDS);
+saveTask = 
StorageService.scheduledTasks.scheduleWithFixedDelay(runnable,
+
savePeriodInSeconds,
+
savePeriodInSeconds,
+
TimeUnit.SECONDS);
 }
 }
 

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/HintedHandOffManager.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/HintedHandOffManager.java?rev=1096613r1=1096612r2=1096613view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/HintedHandOffManager.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/HintedHandOffManager.java
 Mon Apr 25 21:38:51 2011
@@ -216,7 +216,7 @@ public class HintedHandOffManager implem
 }
 }
 };
-StorageService.tasks.execute(runnable);
+StorageService.scheduledTasks.execute(runnable);
 }
 
 private static boolean pagingFinished(ColumnFamily hintColumnFamily, 
ByteBuffer startColumn)

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java?rev=1096613r1=1096612r2=1096613view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java 
(original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java 
Mon Apr 25 21:38:51 2011
@@ -317,7 +317,7 @@ public class Table
 }
 }
 };
-flushTask = StorageService.tasks.scheduleWithFixedDelay(runnable, 10, 
10, TimeUnit.SECONDS);
+flushTask = 
StorageService.scheduledTasks.scheduleWithFixedDelay(runnable, 10, 10, 
TimeUnit.SECONDS);
 }
 
 public void createReplicationStrategy(KSMetaData ksm) throws 
ConfigurationException

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/Gossiper.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/Gossiper.java?rev=1096613r1=1096612r2=1096613view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/Gossiper.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/Gossiper.java
 Mon Apr 25 21:38:51 2011
@@ -33,7 +33,6 @@ import org.cliffc.high_scale_lib.NonBloc
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
-import org.apache.cassandra.concurrent.RetryingScheduledThreadPoolExecutor;
 import org.apache.cassandra.utils.FBUtilities;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.net.Message;
@@ -53,8 +52,6 @@ import org.apache.cassandra.service.Stor
 
 public class Gossiper implements IFailureDetectionEventListener
 {

svn commit: r1096614 - /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java

Author: jbellis
Date: Mon Apr 25 21:39:32 2011
New Revision: 1096614

URL: http://svn.apache.org/viewvc?rev=1096614view=rev
Log:
nodetool print compaction percent complete, take 2
patch by Chris Burroughs; reviewed by jbellis for CASSANDRA-2551

Modified:

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java?rev=1096614r1=1096613r2=1096614view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java
 Mon Apr 25 21:39:32 2011
@@ -332,6 +332,10 @@ public class NodeCmd
 outs.println(column family:  + c.getColumnFamily());
 outs.println(bytes compacted:  + c.getBytesComplete());
 outs.println(bytes total:  + c.getTotalBytes());
+String percentComplete = c.getTotalBytes() == 0
+   ? n/a
+   : new DecimalFormat(#.##).format((double) 
c.getBytesComplete() / c.getTotalBytes() * 100) + %;
+outs.println(compaction progress:  + percentComplete);
 outs.println(-);
 }
 outs.println(pending tasks:  + cm.getPendingTasks());

[jira] [Updated] (CASSANDRA-2556) DatacenterReadResolver not triggering repair

2011-04-25 Thread Stu Hood (JIRA)


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

Stu Hood updated CASSANDRA-2556:


Description: DatacenterReadResolver only calls maybeResolveForRepair for 
local reads.  (was: DatacenterReadResolver only calls maybeResolveForRepair for 
messages received locally.)

 DatacenterReadResolver not triggering repair
 

 Key: CASSANDRA-2556
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2556
 Project: Cassandra
  Issue Type: Bug
Reporter: Stu Hood
 Fix For: 0.8.0


 DatacenterReadResolver only calls maybeResolveForRepair for local reads.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-2556) DatacenterReadResolver not triggering repair

2011-04-25 Thread Stu Hood (JIRA)

DatacenterReadResolver not triggering repair


 Key: CASSANDRA-2556
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2556
 Project: Cassandra
  Issue Type: Bug
Reporter: Stu Hood
 Fix For: 0.8.0


DatacenterReadResolver only calls maybeResolveForRepair for messages received 
locally.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-2520) use -z to test for empty variables to make sh and dash happy


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

Jonathan Ellis reassigned CASSANDRA-2520:
-

Assignee: Jackson Chung  (was: Jonathan Ellis)

 use -z to test for empty variables to make sh and dash happy
 

 Key: CASSANDRA-2520
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2520
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Jonathan Ellis
Assignee: Jackson Chung
Priority: Minor
 Fix For: 0.7.6

 Attachments: 2520-0.7.txt




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2537) CQL: Support for batch insert/delete


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

Jonathan Ellis commented on CASSANDRA-2537:
---

why is the default CL change to null (from ONE) in Cql.g?

 CQL: Support for batch insert/delete
 

 Key: CASSANDRA-2537
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 0.8 beta 1
 Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: CASSANDRA-2537-v2.patch, CASSANDRA-2537-v3.patch, 
 CASSANDRA-2537.patch


 *Test Case To Run*
 {code}
 // Setup
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar);
 //Batch Insert
 BEGIN BATCH USING QUORUM
 INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
 APPLY BATCH
 {code}
 *Actual Behavior*
 {code}
 cqlsh BEGIN BATCH USING QUORUM
... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 Bad Request: line 0:-1 mismatched input 'EOF' expecting K_APPLY
 {code}
 *Documentation Sample*
 {code}
 BEGIN BATCH [USING CONSISTENCY]
 UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
 UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
 UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
 APPLY BATCH
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2551) nodetool: Automatically calculate compaction progress

2011-04-25 Thread Hudson (JIRA)


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

Hudson commented on CASSANDRA-2551:
---

Integrated in Cassandra-0.8 #39 (See 
[https://builds.apache.org/hudson/job/Cassandra-0.8/39/])
nodetool print compaction percent complete, take 2
patch by Chris Burroughs; reviewed by jbellis for CASSANDRA-2551
nodetool print compaction percent complete
patch by Chris Burroughs; reviewed by jbellis for CASSANDRA-2551


 nodetool: Automatically calculate compaction progress
 -

 Key: CASSANDRA-2551
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2551
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Chris Burroughs
Assignee: Chris Burroughs
Priority: Minor
 Fix For: 0.8.0

 Attachments: cassandra-0.7-2551.txt, cassandra-0.8-2551.txt


 Every time I run nodetool compaction stats I end up copying bytes compacted 
 and in-progress to a shell and dividing them.  I would like a computer to 
 automatically do this for me.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2537) CQL: Support for batch insert/delete


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

Pavel Yaskevich commented on CASSANDRA-2537:


default we don't need it to be set if the grammar when we don't need it e.g. 
in batch mode, getConsistencyLevel() will always return ONE even if it was not 
set by the grammar. The same method has UPDATE statement.

 CQL: Support for batch insert/delete
 

 Key: CASSANDRA-2537
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 0.8 beta 1
 Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: CASSANDRA-2537-v2.patch, CASSANDRA-2537-v3.patch, 
 CASSANDRA-2537.patch


 *Test Case To Run*
 {code}
 // Setup
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar);
 //Batch Insert
 BEGIN BATCH USING QUORUM
 INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
 APPLY BATCH
 {code}
 *Actual Behavior*
 {code}
 cqlsh BEGIN BATCH USING QUORUM
... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 Bad Request: line 0:-1 mismatched input 'EOF' expecting K_APPLY
 {code}
 *Documentation Sample*
 {code}
 BEGIN BATCH [USING CONSISTENCY]
 UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
 UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
 UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
 APPLY BATCH
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (CASSANDRA-2537) CQL: Support for batch insert/delete


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

Pavel Yaskevich edited comment on CASSANDRA-2537 at 4/25/11 10:37 PM:
--

default we don't need it to be set if the grammar when we don't need it e.g. 
in batch mode, getConsistencyLevel() will return ONE even if it was not set by 
the grammar. The same method has UPDATE statement.

  was (Author: xedin):
default we don't need it to be set if the grammar when we don't need it 
e.g. in batch mode, getConsistencyLevel() will always return ONE even if it was 
not set by the grammar. The same method has UPDATE statement.
  
 CQL: Support for batch insert/delete
 

 Key: CASSANDRA-2537
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 0.8 beta 1
 Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: CASSANDRA-2537-v2.patch, CASSANDRA-2537-v3.patch, 
 CASSANDRA-2537.patch


 *Test Case To Run*
 {code}
 // Setup
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar);
 //Batch Insert
 BEGIN BATCH USING QUORUM
 INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
 APPLY BATCH
 {code}
 *Actual Behavior*
 {code}
 cqlsh BEGIN BATCH USING QUORUM
... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
 Bad Request: line 0:-1 mismatched input 'EOF' expecting K_APPLY
 {code}
 *Documentation Sample*
 {code}
 BEGIN BATCH [USING CONSISTENCY]
 UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
 UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
 UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
 APPLY BATCH
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2545) CQL: cqlsh error running batch update commands

2011-04-25 Thread Cathy Daw (JIRA)


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

Cathy Daw commented on CASSANDRA-2545:
--

*I received the build error when building on my MacOSX and Centos 5.5 builds*
{noformat}
SyntaxError: ('invalid syntax', 
('/usr/lib/python2.6/site-packages/cql/cursor.py', 139, 34, 'except 
TimedOutException::\n'))
{noformat}

*Full build output*
{noformat}
[cassandra@cdaw-qa1 cql-1.0.0]$ sudo python setup.py install
[sudo] password for cassandra: 
running install
running build
running build_py
creating build
creating build/lib
creating build/lib/cql
copying cql/results.py - build/lib/cql
copying cql/marshal.py - build/lib/cql
copying cql/connection.py - build/lib/cql
copying cql/cursor.py - build/lib/cql
copying cql/decoders.py - build/lib/cql
copying cql/__init__.py - build/lib/cql
copying cql/errors.py - build/lib/cql
copying cql/connection_pool.py - build/lib/cql
creating build/lib/cql/cassandra
copying cql/cassandra/__init__.py - build/lib/cql/cassandra
copying cql/cassandra/Cassandra.py - build/lib/cql/cassandra
copying cql/cassandra/constants.py - build/lib/cql/cassandra
copying cql/cassandra/ttypes.py - build/lib/cql/cassandra
running build_scripts
creating build/scripts-2.6
copying and adjusting cqlsh - build/scripts-2.6
changing mode of build/scripts-2.6/cqlsh from 644 to 755
running install_lib
copying build/lib/cql/cursor.py - /usr/lib/python2.6/site-packages/cql
byte-compiling /usr/lib/python2.6/site-packages/cql/cursor.py to cursor.pyc
SyntaxError: ('invalid syntax', 
('/usr/lib/python2.6/site-packages/cql/cursor.py', 139, 34, 'except 
TimedOutException::\n'))

running install_scripts
copying build/scripts-2.6/cqlsh - /usr/bin
changing mode of /usr/bin/cqlsh to 755
running install_egg_info
Removing /usr/lib/python2.6/site-packages/cql-1.0.0-py2.6.egg-info
Writing /usr/lib/python2.6/site-packages/cql-1.0.0-py2.6.egg-info
{noformat}

 CQL: cqlsh error running batch update commands
 --

 Key: CASSANDRA-2545
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2545
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.8 beta 1
Reporter: Cathy Daw
 Attachments: 
 v2-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt


 *CQL Test Case*
 {code}
 //TEST CASE #1
 BEGIN BATCH
 UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
 UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
 UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
 APPLY BATCH   
 //TEST CASE #2
 BEGIN BATCH USING CONSISTENCY ZERO
 UPDATE users SET state = 'TX' WHERE KEY = 'user1';
 UPDATE users SET state = 'TX' WHERE KEY = 'user2';
 UPDATE users SET state = 'TX' WHERE KEY = 'user3';
 APPLY BATCH   
 //ERROR
 Bad Request: line 0:-1 mismatched input 'EOF' expecting K_APPLY
 {code}
 *Test Setup*
 {code}
 CREATE COLUMNFAMILY users (
   KEY varchar PRIMARY KEY,
   password varchar,
   gender varchar,
   session_token varchar,
   state varchar,
   birth_year bigint);
 INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1', 
 'ch@ngem3', 'f', 'CA', '1971');
 INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2', 
 'ch@ngem3', 'f', 'CA', '1972');
 INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3', 
 'ch@ngem3', 'f', 'CA', '1973');
 {code}
 *Documented Syntax*
 {panel}
 BEGIN BATCH [USING CONSISTENCY]
 UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
 UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
 UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
 APPLY BATCH
 {panel}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (CASSANDRA-2537) CQL: Support for batch insert/delete