date:20110516

nicer error message when endpoint not in topology 
--

 Key: CASSANDRA-2656
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2656
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.0 beta 2, 0.7.5
Reporter: Aaron Morton
Assignee: Aaron Morton
Priority: Trivial


from http://www.mail-archive.com/user@cassandra.apache.org/msg13372.html

currently get a NullPointerException if a node is added to the cluster that is 
not in the topology file. 

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

[jira] [Commented] (CASSANDRA-2655) update wiki with CLI help


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

Aaron Morton commented on CASSANDRA-2655:
-

Create a new page in the wiki with the output 
http://wiki.apache.org/cassandra/CassandraCli08

Will ask on IRC what process would work best for getting this into the release 
process. 

 update wiki with CLI help
 -

 Key: CASSANDRA-2655
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2655
 Project: Cassandra
  Issue Type: Task
  Components: Documentation  website
Affects Versions: 0.8.0
Reporter: Aaron Morton
Assignee: Aaron Morton
Priority: Minor
 Attachments: 0001-add-command-text-to-help-sections.patch, 
 yaml-to-mm.py


 Need a way to update the wiki with the help written for the CLI. 

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

[jira] [Updated] (CASSANDRA-2657) Allow configuration of multiple types of the Trift server

2011-05-16 Thread Vijay (JIRA)


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

Vijay updated CASSANDRA-2657:
-

Assignee: Vijay

 Allow configuration of multiple types of the Trift server
 -

 Key: CASSANDRA-2657
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2657
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.8.1
 Environment: JVM 1.6
Reporter: Vijay
Assignee: Vijay
 Fix For: 0.8.0, 0.8.1


 Thrift server has multiple modes of operations specifically...
  
 1) TNonblockingServer
 2) THsHaServer
 3) TThreadPoolServer
 We should provide a configuration to enable all of the above. The client 
 library can either use Async or the Sync... (independent of the server side)
 This patch also might address the issue (which we where seeing), when there 
 are large number of connections to the server (throughput reduces).

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

[jira] [Commented] (CASSANDRA-1610) Pluggable Compaction

2011-05-16 Thread T Jake Luciani (JIRA)


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

T Jake Luciani commented on CASSANDRA-1610:
---

I'm also for an AbstractCompactionTask, we have specific use-cases (such has 
CassandraFS in brisk) that would greatly benefit from a custom strategy.

 Pluggable Compaction
 

 Key: CASSANDRA-1610
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1610
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Chris Goffinet
Assignee: Alan Liang
Priority: Minor
  Labels: compaction
 Fix For: 1.0

 Attachments: 0001-move-compaction-code-into-own-package.patch, 
 0002-Pluggable-Compaction-and-Expiration.patch


 In CASSANDRA-1608, I proposed some changes on how compaction works. I think 
 it also makes sense to allow the ability to have pluggable compaction per CF. 
 There could be many types of workloads where this makes sense. One example we 
 had at Digg was to completely throw away certain SSTables after N days.
 The goal of this ticket is to make compaction pluggable enough to support 
 compaction based on max timestamp ordering of the sstables while satisfying 
 max sstable size, min and max compaction thresholds. Another goal is to allow 
 expiration of sstables based on a timestamp.

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

[jira] [Updated] (CASSANDRA-2616) Add DROP INDEX command to CLI

2011-05-16 Thread Pavel Yaskevich (JIRA)


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

Pavel Yaskevich updated CASSANDRA-2616:
---

Attachment: CASSANDRA-2616.patch

Command syntax DROP INDEX ON CF.COLUMN

It will drop index definition from CFMetadata and will remove all SSTable files 
related to index.

Help and test are updated. Branch:cassandra-0.8.1

 Add DROP INDEX command to CLI
 ---

 Key: CASSANDRA-2616
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2616
 Project: Cassandra
  Issue Type: New Feature
Reporter: Pavel Yaskevich
Assignee: Pavel Yaskevich
 Fix For: 0.8.1

 Attachments: CASSANDRA-2616.patch




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

svn commit: r1103777 - /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java

Author: jbellis
Date: Mon May 16 15:59:50 2011
New Revision: 1103777

URL: http://svn.apache.org/viewvc?rev=1103777view=rev
Log:
fix formatting

Modified:

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

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java?rev=1103777r1=1103776r2=1103777view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java
 Mon May 16 15:59:50 2011
@@ -845,19 +845,19 @@ public class CompactionManager implement
 totalkeysWritten++;
 }
 else
-   {
-   cfs.invalidateCachedRow(row.getKey());
-   if (!indexedColumns.isEmpty() || isCommutative)
+{
+cfs.invalidateCachedRow(row.getKey());
+if (!indexedColumns.isEmpty() || isCommutative)
 {
 while (row.hasNext())
 {
 IColumn column = row.next();
 if (column instanceof CounterColumn)
-
renewer.maybeRenew((CounterColumn)column);
+renewer.maybeRenew((CounterColumn) 
column);
 if (indexedColumns.contains(column.name()))
 Table.cleanupIndexEntry(cfs, 
row.getKey().key, column);
 }
-   }
+}
 }
 }
 }

[jira] [Commented] (CASSANDRA-2657) Allow configuration of multiple types of the Trift server


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

Jonathan Ellis commented on CASSANDRA-2657:
---

It's not that simple. See CASSANDRA-1405

 Allow configuration of multiple types of the Trift server
 -

 Key: CASSANDRA-2657
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2657
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.8.1
 Environment: JVM 1.6
Reporter: Vijay
Assignee: Vijay
 Fix For: 0.8.0, 0.8.1


 Thrift server has multiple modes of operations specifically...
  
 1) TNonblockingServer
 2) THsHaServer
 3) TThreadPoolServer
 We should provide a configuration to enable all of the above. The client 
 library can either use Async or the Sync... (independent of the server side)
 This patch also might address the issue (which we where seeing), when there 
 are large number of connections to the server (throughput reduces).

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

[jira] [Commented] (CASSANDRA-1608) Redesigned Compaction

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

Jonathan Ellis commented on CASSANDRA-1608:
---

I don't see anything preventing us from recording that information on a
per-sstable basis, the way we do flush point information now (CASSANDRA-2419).

Redesigned Compaction
-

Key: CASSANDRA-1608
URL: https://issues.apache.org/jira/browse/CASSANDRA-1608
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Chris Goffinet

After seeing the I/O issues in CASSANDRA-1470, I've been doing some more
thinking on this subject that I wanted to lay out.
I propose we redo the concept of how compaction works in Cassandra. At the
moment, compaction is kicked off based on a write access pattern, not read
access pattern. In most cases, you want the opposite. You want to be able to
track how well each SSTable is performing in the system. If we were to keep
statistics in-memory of each SSTable, prioritize them based on most accessed,
and bloom filter hit/miss ratios, we could intelligently group sstables that
are being read most often and schedule them for compaction. We could also
schedule lower priority maintenance on SSTable's not often accessed.
I also propose we limit the size of each SSTable to a fix sized, that gives
us the ability to better utilize our bloom filters in a predictable manner.
At the moment after a certain size, the bloom filters become less reliable.
This would also allow us to group data most accessed. Currently the size of
an SSTable can grow to a point where large portions of the data might not
actually be accessed as often.

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

[jira] [Commented] (CASSANDRA-2657) Allow configuration of multiple types of the Trift server

2011-05-16 Thread Vijay (JIRA)


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

Vijay commented on CASSANDRA-2657:
--

aa cool, For now in the current state the Non-Blocking sever works but 
not the THsHa so can we just not implement HsHa in this ticket and borrow 
the functionality from #1405?

 Allow configuration of multiple types of the Trift server
 -

 Key: CASSANDRA-2657
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2657
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.8.1
 Environment: JVM 1.6
Reporter: Vijay
Assignee: Vijay
 Fix For: 0.8.0, 0.8.1


 Thrift server has multiple modes of operations specifically...
  
 1) TNonblockingServer
 2) THsHaServer
 3) TThreadPoolServer
 We should provide a configuration to enable all of the above. The client 
 library can either use Async or the Sync... (independent of the server side)
 This patch also might address the issue (which we where seeing), when there 
 are large number of connections to the server (throughput reduces).

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

[jira] [Created] (CASSANDRA-2658) Pig + CassandraStorage should work when trying to cast data after it's loaded

2011-05-16 Thread Jeremy Hanna (JIRA)

Pig + CassandraStorage should work when trying to cast data after it's loaded
-

 Key: CASSANDRA-2658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2658
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.7.5
Reporter: Jeremy Hanna
Priority: Minor


We currently do a lot with pig + cassandra, but one thing I've found is that 
currently it's very touchy with data that comes from Cassandra for some reason. 
 For example, if I try to a SUM of data that has not been validated as an 
LongType in Cassandra, it borks.  See this schema script for Cassandra - 
https://github.com/jeromatron/pygmalion/blob/master/cassandra/example_data.txt 
- and remove the validation on the num_heads data type and try to SUM that over 
the data and it gives data type errors.  (It breaks with the num_heads 
validation removed and with or without the default_validation class being set.)

We currently do analysis over data that is either just String (UTF8) data or 
that we have validated, so it works for us.  However, I've seen a couple of 
people trying to use Cassandra with Pig that have had issues because of this.  
One of the tenants of pig is that it will eat anything and it kind of goes 
against this if the load/store somehow interferes with that.  So in essence, I 
think this is a big deal for those wanting to use pig with cassandra in the 
ways that pig is normally used.

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

[jira] [Updated] (CASSANDRA-2658) Pig + CassandraStorage should work when trying to cast data after it's loaded

2011-05-16 Thread Jeremy Hanna (JIRA)

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

Jeremy Hanna updated CASSANDRA-2658:

Description:
We currently do a lot with pig + cassandra, but one thing I've found is that
currently it's very touchy with data that comes from Cassandra for some reason.
For example, if I try to a SUM of data that has not been validated as an
LongType in Cassandra, it borks. See this schema script for Cassandra -
https://github.com/jeromatron/pygmalion/blob/master/cassandra/example_data.txt
- and remove the validation on the num_heads data type and try to SUM that over
the data and it gives data type errors. (It breaks with the num_heads
validation removed and with or without the default_validation class being set.)

We currently do analysis over data that is either just String (UTF8) data or
that we have validated, so it works for us. However, I've seen a couple of
people trying to use Cassandra with Pig that have had issues because of this.
One of the tenets of pig is that it will eat anything and it kind of goes
against this if the load/store somehow interferes with that. So in essence, I
think this is a big deal for those wanting to use pig with cassandra in the
ways that pig is normally used.

was:
We currently do a lot with pig + cassandra, but one thing I've found is that
currently it's very touchy with data that comes from Cassandra for some reason.
For example, if I try to a SUM of data that has not been validated as an
LongType in Cassandra, it borks. See this schema script for Cassandra -
https://github.com/jeromatron/pygmalion/blob/master/cassandra/example_data.txt
- and remove the validation on the num_heads data type and try to SUM that over
the data and it gives data type errors. (It breaks with the num_heads
validation removed and with or without the default_validation class being set.)

We currently do analysis over data that is either just String (UTF8) data or
that we have validated, so it works for us. However, I've seen a couple of
people trying to use Cassandra with Pig that have had issues because of this.
One of the tenants of pig is that it will eat anything and it kind of goes
against this if the load/store somehow interferes with that. So in essence, I
think this is a big deal for those wanting to use pig with cassandra in the
ways that pig is normally used.

Pig + CassandraStorage should work when trying to cast data after it's loaded
-

Key: CASSANDRA-2658
URL: https://issues.apache.org/jira/browse/CASSANDRA-2658
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.5
Reporter: Jeremy Hanna
Priority: Minor
Labels: pig

We currently do a lot with pig + cassandra, but one thing I've found is that
currently it's very touchy with data that comes from Cassandra for some
reason. For example, if I try to a SUM of data that has not been validated
as an LongType in Cassandra, it borks. See this schema script for Cassandra
-
https://github.com/jeromatron/pygmalion/blob/master/cassandra/example_data.txt
- and remove the validation on the num_heads data type and try to SUM that
over the data and it gives data type errors. (It breaks with the num_heads
validation removed and with or without the default_validation class being
set.)
We currently do analysis over data that is either just String (UTF8) data or
that we have validated, so it works for us. However, I've seen a couple of
people trying to use Cassandra with Pig that have had issues because of this.
One of the tenets of pig is that it will eat anything and it kind of goes
against this if the load/store somehow interferes with that. So in essence,
I think this is a big deal for those wanting to use pig with cassandra in the
ways that pig is normally used.

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

[jira] [Commented] (CASSANDRA-2654) Work around native heap leak in sun.nio.ch.Util affecting IncomingTcpConnection

2011-05-16 Thread Hannes Schmidt (JIRA)


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

Hannes Schmidt commented on CASSANDRA-2654:
---

Since reading from a socket isn't idempotent, what I called redundant is 
actually harmful. 

 Work around native heap leak in sun.nio.ch.Util affecting 
 IncomingTcpConnection
 ---

 Key: CASSANDRA-2654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2654
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.6.13, 0.7.5, 0.8.0 beta 2
 Environment: OpenJDK Runtime Environment (IcedTea6 1.9.7) 
 (6b20-1.9.7-0ubuntu1~10.04.1)
 OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
 Also observed on Sun/Oracle JDK. Probably platform- and os-independent.
Reporter: Hannes Schmidt
 Fix For: 0.6.12

 Attachments: 2654-v2.txt, chunking.diff


 NIO's leaky, per-thread caching of direct buffers in combination with 
 IncomingTcpConnection's eager buffering of messages leads to leakage of large 
 amounts of native heap. Details in [1]. More on the root cause in [2]. Even 
 though it doesn't fix the leak, attached patch has been found to alleviate 
 the problem by keeping the size of each direct buffer modest.

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

[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations

2011-05-16 Thread Marko Mikulicic (JIRA)


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

Marko Mikulicic commented on CASSANDRA-1391:


is there a way to fix this bad state? I'm not sure if this bug affects me or 
something similar, but my cluster cannot create new keyspaces

Cluster schema does not yet agree

I tried to drop all the nodes but one, but it still complains. Any idea?

 Allow Concurrent Schema Migrations
 --

 Key: CASSANDRA-1391
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Stu Hood

 CASSANDRA-1292 fixed multiple migrations started from the same node to 
 properly queue themselves, but it is still possible for migrations initiated 
 on different nodes to conflict and leave the cluster in a bad state. Since 
 the system_add/drop/rename methods are accessible directly from the client 
 API, they should be completely safe for concurrent use.
 It should be possible to allow for most types of concurrent migrations by 
 converting the UUID schema ID into a VersionVectorClock (as provided by 
 CASSANDRA-580).

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

[jira] [Commented] (CASSANDRA-2647) Cassandra can't find jamm on startup

2011-05-16 Thread paul cannon (JIRA)


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

paul cannon commented on CASSANDRA-2647:


Tested and verified Eric's patch, both via initscript and invocation through 
/usr/sbin/cassandra; the right path to jamm (and all the other lib jars) gets 
set correctly. +1 for the patch.

I think ideally the rest of the initscript would also make use of 
$CASSANDRA_HOME (like when specifying the location of the jars to add to the 
classpath), but since the deb isn't expected to support a change to 
$CASSANDRA_HOME, it's fine as is.

 Cassandra can't find jamm on startup
 

 Key: CASSANDRA-2647
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2647
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Affects Versions: 0.8 beta 1
 Environment: Ubuntu 10.04 Lucid
Reporter: Marcus Bointon
Assignee: paul cannon
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 v1-0001-CASSANDRA-2647-move-jars-under-lib-to-satisfy-hard-cod.txt


 I installed the Debian package (from 
 http://www.apache.org/dist/cassandra/debian unstable) of Cassandra 0.8beta2 
 on Ubuntu 10.04 with the sun jdk over a working copy of 0.7.2. It broke on 
 restart.
 On startup it gives this:
 {code}
 Error occurred during initialization of VM
 agent library failed to init: instrument
 Error opening zip file or JAR manifest missing : /lib/jamm-0.2.2.jar
 {code}
 /etc/cassandra/cassandra-env.sh contains this:
 {code}
 # add the jamm javaagent
 check_openjdk=$(java -version 21 | awk '{if (NR == 2) {print $1}}')
 if [ $check_openjdk != OpenJDK ]
 then
 JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.2.jar
 fi
 {code}
 By default, CASSANDRA_HOME is not set, so it's looking in /lib for this jar. 
 It seems CASSANDRA_HOME should be set to /usr/share/cassandra, since that's 
 where jamm-0.2.2.jar is installed, but that means the path is still wrong.
 I set CASSANDRA_HOME to /usr/share/cassandra and changed the JVM_OPTS line to 
 this:
 {code}
 JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/jamm-0.2.2.jar
 {code}
 and then cassandra started ok.
 Is this a bug or did I miss something?
 I also noticed that this line appears to be the only use of CASSANDRA_HOME.

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

[jira] [Commented] (CASSANDRA-47) SSTable compression


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

Ryan King commented on CASSANDRA-47:


Stu is working on https://issues.apache.org/jira/browse/CASSANDRA-674 which 
will improve the file size dramatically.

 SSTable compression
 ---

 Key: CASSANDRA-47
 URL: https://issues.apache.org/jira/browse/CASSANDRA-47
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Priority: Minor
  Labels: compression
 Fix For: 1.0


 We should be able to do SSTable compression which would trade CPU for I/O 
 (almost always a good trade).

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

[jira] [Updated] (CASSANDRA-2657) Allow configuration of multiple types of the Thrift server


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

Ryan King updated CASSANDRA-2657:
-

Summary: Allow configuration of multiple types of the Thrift server  (was: 
Allow configuration of multiple types of the Trift server)

 Allow configuration of multiple types of the Thrift server
 --

 Key: CASSANDRA-2657
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2657
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.8.1
 Environment: JVM 1.6
Reporter: Vijay
Assignee: Vijay
 Fix For: 0.8.0, 0.8.1


 Thrift server has multiple modes of operations specifically...
  
 1) TNonblockingServer
 2) THsHaServer
 3) TThreadPoolServer
 We should provide a configuration to enable all of the above. The client 
 library can either use Async or the Sync... (independent of the server side)
 This patch also might address the issue (which we where seeing), when there 
 are large number of connections to the server (throughput reduces).

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

[jira] [Updated] (CASSANDRA-2597) inconsistent implementation of 'cumulative distribution function' for Exponential Distribution


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

Ryan King updated CASSANDRA-2597:
-

  Component/s: (was: Core)
   Contrib
  Description: 
As reported on the mailing list 
(http://mail-archives.apache.org/mod_mbox/cassandra-dev/201104.mbox/%3CAANLkTimdMSLE8-z0x+0kvzqp7za3AEMLaOFXvd4Z=t...@mail.gmail.com%3E),

{quote}
I just found there are two implementations of 'cumulative distribution
function' for Exponential Distribution and there are inconsistent :

*FailureDetector*
{code:java}
org.apache.cassandra.gms.ArrivalWindow.p(double)
   double p(double t)
   {
   double mean = mean();
   double exponent = (-1)*(t)/mean;
   return *Math.pow(Math.E, exponent)*;
   }
{code}

*DynamicEndpointSnitch*
{code:java}
org.apache.cassandra.locator.AdaptiveLatencyTracker.p(double)
   double p(double t)
   {
   double mean = mean();
   double exponent = (-1) * (t) / mean;
   return *1 - Math.pow( Math.E, exponent);*
   }
{code}

According to the  Exponential Distribution cumulative distribution function
definitionhttp://en.wikipedia.org/wiki/Exponential_distribution#Cumulative_distribution_function,
the later one is correct
{quote}

... however FailureDetector has been working as advertised for some time now.  
Does this mean the Snitch version is actually wrong?

  was:
As reported on the mailing list 
(http://mail-archives.apache.org/mod_mbox/cassandra-dev/201104.mbox/%3CAANLkTimdMSLE8-z0x+0kvzqp7za3AEMLaOFXvd4Z=t...@mail.gmail.com%3E),

{quote}
I just found there are two implementations of 'cumulative distribution
function' for Exponential Distribution and there are inconsistent :

*FailureDetector*
org.apache.cassandra.gms.ArrivalWindow.p(double)
   double p(double t)
   {
   double mean = mean();
   double exponent = (-1)*(t)/mean;
   return *Math.pow(Math.E, exponent)*;
   }

*DynamicEndpointSnitch*
org.apache.cassandra.locator.AdaptiveLatencyTracker.p(double)
   double p(double t)
   {
   double mean = mean();
   double exponent = (-1) * (t) / mean;
   return *1 - Math.pow( Math.E, exponent);*
   }

According to the  Exponential Distribution cumulative distribution function
definitionhttp://en.wikipedia.org/wiki/Exponential_distribution#Cumulative_distribution_function,
the later one is correct
{quote}

... however FailureDetector has been working as advertised for some time now.  
Does this mean the Snitch version is actually wrong?

Fix Version/s: (was: 0.7.7)
   0.7.6

 inconsistent implementation of 'cumulative distribution function' for 
 Exponential Distribution
 --

 Key: CASSANDRA-2597
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2597
 Project: Cassandra
  Issue Type: Bug
  Components: Contrib
Reporter: Jonathan Ellis
Assignee: paul cannon
Priority: Minor
 Fix For: 0.7.6


 As reported on the mailing list 
 (http://mail-archives.apache.org/mod_mbox/cassandra-dev/201104.mbox/%3CAANLkTimdMSLE8-z0x+0kvzqp7za3AEMLaOFXvd4Z=t...@mail.gmail.com%3E),
 {quote}
 I just found there are two implementations of 'cumulative distribution
 function' for Exponential Distribution and there are inconsistent :
 *FailureDetector*
 {code:java}
 org.apache.cassandra.gms.ArrivalWindow.p(double)
double p(double t)
{
double mean = mean();
double exponent = (-1)*(t)/mean;
return *Math.pow(Math.E, exponent)*;
}
 {code}
 *DynamicEndpointSnitch*
 {code:java}
 org.apache.cassandra.locator.AdaptiveLatencyTracker.p(double)
double p(double t)
{
double mean = mean();
double exponent = (-1) * (t) / mean;
return *1 - Math.pow( Math.E, exponent);*
}
 {code}
 According to the  Exponential Distribution cumulative distribution function
 definitionhttp://en.wikipedia.org/wiki/Exponential_distribution#Cumulative_distribution_function,
 the later one is correct
 {quote}
 ... however FailureDetector has been working as advertised for some time now. 
  Does this mean the Snitch version is actually wrong?

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

[jira] [Assigned] (CASSANDRA-2003) get_range_slices test


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

Ryan King reassigned CASSANDRA-2003:


Assignee: Stu Hood  (was: Kelvin Kakugawa)

 get_range_slices test
 -

 Key: CASSANDRA-2003
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2003
 Project: Cassandra
  Issue Type: Test
  Components: Core
 Environment: RandomPartitioner
Reporter: Kelvin Kakugawa
Assignee: Stu Hood
Priority: Minor
 Fix For: 0.8.1

 Attachments: 0002-Assert-that-we-don-t-double-count-any-keys.txt, 
 CASSANDRA-2003-0.7-0001.patch, CASSANDRA-2003-0001.patch


 Test get_range_slices (on an RP cluster) to walk:
 * all keys on each node
 * all keys across cluster

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

[jira] [Updated] (CASSANDRA-2654) Work around native heap leak in sun.nio.ch.Util affecting IncomingTcpConnection

2011-05-16 Thread Hannes Schmidt (JIRA)


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

Hannes Schmidt updated CASSANDRA-2654:
--

Attachment: 2654-v3.txt

Reverted to original logic but kept comment and naming convention for constants.

 Work around native heap leak in sun.nio.ch.Util affecting 
 IncomingTcpConnection
 ---

 Key: CASSANDRA-2654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2654
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.6.13, 0.7.5, 0.8.0 beta 2
 Environment: OpenJDK Runtime Environment (IcedTea6 1.9.7) 
 (6b20-1.9.7-0ubuntu1~10.04.1)
 OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
 Also observed on Sun/Oracle JDK. Probably platform- and os-independent.
Reporter: Hannes Schmidt
 Fix For: 0.6.12

 Attachments: 2654-v2.txt, 2654-v3.txt, chunking.diff


 NIO's leaky, per-thread caching of direct buffers in combination with 
 IncomingTcpConnection's eager buffering of messages leads to leakage of large 
 amounts of native heap. Details in [1]. More on the root cause in [2]. Even 
 though it doesn't fix the leak, attached patch has been found to alleviate 
 the problem by keeping the size of each direct buffer modest.

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

[jira] [Issue Comment Edited] (CASSANDRA-2654) Work around native heap leak in sun.nio.ch.Util affecting IncomingTcpConnection

2011-05-16 Thread Hannes Schmidt (JIRA)

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

Hannes Schmidt edited comment on CASSANDRA-2654 at 5/16/11 6:07 PM:

v3: Reverted to original logic but kept comment and naming convention for
constants.

was (Author: eyealike):
Reverted to original logic but kept comment and naming convention for
constants.

Work around native heap leak in sun.nio.ch.Util affecting
IncomingTcpConnection
---

Key: CASSANDRA-2654
URL: https://issues.apache.org/jira/browse/CASSANDRA-2654
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 0.6.13, 0.7.5, 0.8.0 beta 2
Environment: OpenJDK Runtime Environment (IcedTea6 1.9.7)
(6b20-1.9.7-0ubuntu1~10.04.1)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
Also observed on Sun/Oracle JDK. Probably platform- and os-independent.
Reporter: Hannes Schmidt
Fix For: 0.6.12

Attachments: 2654-v2.txt, 2654-v3.txt, chunking.diff

NIO's leaky, per-thread caching of direct buffers in combination with
IncomingTcpConnection's eager buffering of messages leads to leakage of large
amounts of native heap. Details in [1]. More on the root cause in [2]. Even
though it doesn't fix the leak, attached patch has been found to alleviate
the problem by keeping the size of each direct buffer modest.

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

[jira] [Updated] (CASSANDRA-2597) inconsistent implementation of 'cumulative distribution function' for Exponential Distribution


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

Jonathan Ellis updated CASSANDRA-2597:
--

  Component/s: (was: Contrib)
   Core
Fix Version/s: (was: 0.7.6)
   0.7.7

 inconsistent implementation of 'cumulative distribution function' for 
 Exponential Distribution
 --

 Key: CASSANDRA-2597
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2597
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jonathan Ellis
Assignee: paul cannon
Priority: Minor
 Fix For: 0.7.7


 As reported on the mailing list 
 (http://mail-archives.apache.org/mod_mbox/cassandra-dev/201104.mbox/%3CAANLkTimdMSLE8-z0x+0kvzqp7za3AEMLaOFXvd4Z=t...@mail.gmail.com%3E),
 {quote}
 I just found there are two implementations of 'cumulative distribution
 function' for Exponential Distribution and there are inconsistent :
 *FailureDetector*
 {code:java}
 org.apache.cassandra.gms.ArrivalWindow.p(double)
double p(double t)
{
double mean = mean();
double exponent = (-1)*(t)/mean;
return *Math.pow(Math.E, exponent)*;
}
 {code}
 *DynamicEndpointSnitch*
 {code:java}
 org.apache.cassandra.locator.AdaptiveLatencyTracker.p(double)
double p(double t)
{
double mean = mean();
double exponent = (-1) * (t) / mean;
return *1 - Math.pow( Math.E, exponent);*
}
 {code}
 According to the  Exponential Distribution cumulative distribution function
 definitionhttp://en.wikipedia.org/wiki/Exponential_distribution#Cumulative_distribution_function,
 the later one is correct
 {quote}
 ... however FailureDetector has been working as advertised for some time now. 
  Does this mean the Snitch version is actually wrong?

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

[jira] [Updated] (CASSANDRA-2654) Work around native heap leak in sun.nio.ch.Util affecting IncomingTcpConnection


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

Jonathan Ellis updated CASSANDRA-2654:
--

Attachment: 2654-v4.txt

v4 changes v2 for loop condition to offset  size - remainder.

As you note, doing a readFully with size of zero is harmless.

 Work around native heap leak in sun.nio.ch.Util affecting 
 IncomingTcpConnection
 ---

 Key: CASSANDRA-2654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2654
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.6.13, 0.7.5, 0.8.0 beta 2
 Environment: OpenJDK Runtime Environment (IcedTea6 1.9.7) 
 (6b20-1.9.7-0ubuntu1~10.04.1)
 OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
 Also observed on Sun/Oracle JDK. Probably platform- and os-independent.
Reporter: Hannes Schmidt
 Fix For: 0.6.12

 Attachments: 2654-v2.txt, 2654-v3.txt, 2654-v4.txt, chunking.diff


 NIO's leaky, per-thread caching of direct buffers in combination with 
 IncomingTcpConnection's eager buffering of messages leads to leakage of large 
 amounts of native heap. Details in [1]. More on the root cause in [2]. Even 
 though it doesn't fix the leak, attached patch has been found to alleviate 
 the problem by keeping the size of each direct buffer modest.

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

[jira] [Updated] (CASSANDRA-2653) index scan errors out when zero columns are requested

2011-05-16 Thread Tyler Hobbs (JIRA)


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

Tyler Hobbs updated CASSANDRA-2653:
---

Affects Version/s: 0.8.0 beta 2

 index scan errors out when zero columns are requested
 -

 Key: CASSANDRA-2653
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2653
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.0 beta 2
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 0.7.7


 As reported by Tyler Hobbs as an addendum to CASSANDRA-2401,
 {noformat}
 ERROR 16:13:38,864 Fatal exception in thread Thread[ReadStage:16,5,main]
 java.lang.AssertionError: No data found for 
 SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30], 
 finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false, 
 count=0] in DecoratedKey(81509516161424251288255223397843705139, 
 6b657931):QueryPath(columnFamilyName='cf', superColumnName='null', 
 columnName='null') (original filter 
 SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30], 
 finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false, 
 count=0]) from expression 'cf.626972746864617465 EQ 1'
   at 
 org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1517)
   at 
 org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:42)
   at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 {noformat}

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

[jira] [Reopened] (CASSANDRA-2658) Pig + CassandraStorage should work when trying to cast data after it's loaded


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

Brandon Williams reopened CASSANDRA-2658:
-


 Pig + CassandraStorage should work when trying to cast data after it's loaded
 -

 Key: CASSANDRA-2658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2658
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.7.5
Reporter: Jeremy Hanna
Assignee: Brandon Williams
Priority: Minor
  Labels: pig

 We currently do a lot with pig + cassandra, but one thing I've found is that 
 currently it's very touchy with data that comes from Cassandra for some 
 reason.  For example, if I try to a SUM of data that has not been validated 
 as an LongType in Cassandra, it borks.  See this schema script for Cassandra 
 - 
 https://github.com/jeromatron/pygmalion/blob/master/cassandra/example_data.txt
  - and remove the validation on the num_heads data type and try to SUM that 
 over the data and it gives data type errors.  (It breaks with the num_heads 
 validation removed and with or without the default_validation class being 
 set.)
 We currently do analysis over data that is either just String (UTF8) data or 
 that we have validated, so it works for us.  However, I've seen a couple of 
 people trying to use Cassandra with Pig that have had issues because of this. 
  One of the tenets of pig is that it will eat anything and it kind of goes 
 against this if the load/store somehow interferes with that.  So in essence, 
 I think this is a big deal for those wanting to use pig with cassandra in the 
 ways that pig is normally used.

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

[jira] [Resolved] (CASSANDRA-2658) Pig + CassandraStorage should work when trying to cast data after it's loaded

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

Brandon Williams resolved CASSANDRA-2658.
-

Resolution: Not A Problem

Pig + CassandraStorage should work when trying to cast data after it's loaded
-

Key: CASSANDRA-2658
URL: https://issues.apache.org/jira/browse/CASSANDRA-2658
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.5
Reporter: Jeremy Hanna
Assignee: Brandon Williams
Priority: Minor
Labels: pig

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

[jira] [Resolved] (CASSANDRA-2658) Pig + CassandraStorage should work when trying to cast data after it's loaded


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

Brandon Williams resolved CASSANDRA-2658.
-

Resolution: Won't Fix
  Assignee: Brandon Williams

The source of this problem is that when you remove the validation, the cli 
packs the data with the default validator, in this case UTF8.  Pig's SUM 
function doesn't understand how to sum UTF8, so you would need to explicitly 
cast to an integer first.

When you have the validation class set to LongType, the cli is packing this 
into an 8 byte binary form for you.  When the LoadFunc pulls it out, it 
converts this back into a long and pig's SUM works with those.

This isn't a problem with the load/store function, this is a problem with how 
the data is being inserted and not understanding that the cli is masking the 
problem you have a validator by being aware of it and making things easy on 
you.  If you were inserting the data programmatically in the wrong form (ie, a 
string) you would have the same problem, but if you pack()ed it yourself, it 
would work.

 Pig + CassandraStorage should work when trying to cast data after it's loaded
 -

 Key: CASSANDRA-2658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2658
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.7.5
Reporter: Jeremy Hanna
Assignee: Brandon Williams
Priority: Minor
  Labels: pig

 We currently do a lot with pig + cassandra, but one thing I've found is that 
 currently it's very touchy with data that comes from Cassandra for some 
 reason.  For example, if I try to a SUM of data that has not been validated 
 as an LongType in Cassandra, it borks.  See this schema script for Cassandra 
 - 
 https://github.com/jeromatron/pygmalion/blob/master/cassandra/example_data.txt
  - and remove the validation on the num_heads data type and try to SUM that 
 over the data and it gives data type errors.  (It breaks with the num_heads 
 validation removed and with or without the default_validation class being 
 set.)
 We currently do analysis over data that is either just String (UTF8) data or 
 that we have validated, so it works for us.  However, I've seen a couple of 
 people trying to use Cassandra with Pig that have had issues because of this. 
  One of the tenets of pig is that it will eat anything and it kind of goes 
 against this if the load/store somehow interferes with that.  So in essence, 
 I think this is a big deal for those wanting to use pig with cassandra in the 
 ways that pig is normally used.

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

[jira] [Issue Comment Edited] (CASSANDRA-2658) Pig + CassandraStorage should work when trying to cast data after it's loaded


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

Brandon Williams edited comment on CASSANDRA-2658 at 5/16/11 7:04 PM:
--

The source of this problem is that when you remove the validation, the cli 
packs the data with the default validator, in this case UTF8.  Pig's SUM 
function doesn't understand how to sum UTF8, so you would need to explicitly 
cast to an integer first.

When you have the validation class set to LongType, the cli is packing this 
into an 8 byte binary form for you.  When the LoadFunc pulls it out, it 
converts this back into a long and pig's SUM works with those.

This isn't a problem with the load/store function, this is a problem with how 
the data is being inserted and not understanding that the cli is masking the 
problem you have with a validator by being aware of it and making things easy 
on you.  If you were inserting the data programmatically in the wrong form (ie, 
a string) you would have the same problem, but if you pack()ed it yourself, it 
would work.

  was (Author: brandon.williams):
The source of this problem is that when you remove the validation, the cli 
packs the data with the default validator, in this case UTF8.  Pig's SUM 
function doesn't understand how to sum UTF8, so you would need to explicitly 
cast to an integer first.

When you have the validation class set to LongType, the cli is packing this 
into an 8 byte binary form for you.  When the LoadFunc pulls it out, it 
converts this back into a long and pig's SUM works with those.

This isn't a problem with the load/store function, this is a problem with how 
the data is being inserted and not understanding that the cli is masking the 
problem you have a validator by being aware of it and making things easy on 
you.  If you were inserting the data programmatically in the wrong form (ie, a 
string) you would have the same problem, but if you pack()ed it yourself, it 
would work.
  
 Pig + CassandraStorage should work when trying to cast data after it's loaded
 -

 Key: CASSANDRA-2658
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2658
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.7.5
Reporter: Jeremy Hanna
Assignee: Brandon Williams
Priority: Minor
  Labels: pig

 We currently do a lot with pig + cassandra, but one thing I've found is that 
 currently it's very touchy with data that comes from Cassandra for some 
 reason.  For example, if I try to a SUM of data that has not been validated 
 as an LongType in Cassandra, it borks.  See this schema script for Cassandra 
 - 
 https://github.com/jeromatron/pygmalion/blob/master/cassandra/example_data.txt
  - and remove the validation on the num_heads data type and try to SUM that 
 over the data and it gives data type errors.  (It breaks with the num_heads 
 validation removed and with or without the default_validation class being 
 set.)
 We currently do analysis over data that is either just String (UTF8) data or 
 that we have validated, so it works for us.  However, I've seen a couple of 
 people trying to use Cassandra with Pig that have had issues because of this. 
  One of the tenets of pig is that it will eat anything and it kind of goes 
 against this if the load/store somehow interferes with that.  So in essence, 
 I think this is a big deal for those wanting to use pig with cassandra in the 
 ways that pig is normally used.

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

[jira] [Commented] (CASSANDRA-2647) Cassandra can't find jamm on startup

2011-05-16 Thread Joe Travaglini (JIRA)


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

Joe Travaglini commented on CASSANDRA-2647:
---

Forgive the awfully dumb question - I am a new user trying to get Cassandra 
running (for the first time) and ran into this issue as well.

What's the preferred method for applying this patch to the code base?  Running 
Natty x86_64 server.

Thanks in advance.

 Cassandra can't find jamm on startup
 

 Key: CASSANDRA-2647
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2647
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Affects Versions: 0.8 beta 1
 Environment: Ubuntu 10.04 Lucid
Reporter: Marcus Bointon
Assignee: paul cannon
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 v1-0001-CASSANDRA-2647-move-jars-under-lib-to-satisfy-hard-cod.txt


 I installed the Debian package (from 
 http://www.apache.org/dist/cassandra/debian unstable) of Cassandra 0.8beta2 
 on Ubuntu 10.04 with the sun jdk over a working copy of 0.7.2. It broke on 
 restart.
 On startup it gives this:
 {code}
 Error occurred during initialization of VM
 agent library failed to init: instrument
 Error opening zip file or JAR manifest missing : /lib/jamm-0.2.2.jar
 {code}
 /etc/cassandra/cassandra-env.sh contains this:
 {code}
 # add the jamm javaagent
 check_openjdk=$(java -version 21 | awk '{if (NR == 2) {print $1}}')
 if [ $check_openjdk != OpenJDK ]
 then
 JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.2.jar
 fi
 {code}
 By default, CASSANDRA_HOME is not set, so it's looking in /lib for this jar. 
 It seems CASSANDRA_HOME should be set to /usr/share/cassandra, since that's 
 where jamm-0.2.2.jar is installed, but that means the path is still wrong.
 I set CASSANDRA_HOME to /usr/share/cassandra and changed the JVM_OPTS line to 
 this:
 {code}
 JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/jamm-0.2.2.jar
 {code}
 and then cassandra started ok.
 Is this a bug or did I miss something?
 I also noticed that this line appears to be the only use of CASSANDRA_HOME.

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

[jira] [Created] (CASSANDRA-2659) Improve forceDeserialize/getCompactedRow encapsulation

Improve forceDeserialize/getCompactedRow encapsulation
--

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




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

[jira] [Commented] (CASSANDRA-2647) Cassandra can't find jamm on startup

2011-05-16 Thread paul cannon (JIRA)


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

paul cannon commented on CASSANDRA-2647:


bq. What's the preferred method for applying this patch to the code base? 
Running Natty x86_64 server.

Joe- I would say your options are:

1. Apply the patch to a source checkout from the 0.8.0-beta2 tag (using patch 
-p1  patch.txt from the toplevel directory), then build your own custom .debs 
(using, maybe, dpkg-buildpackage -us -uc).

2. Just change this line in /etc/cassandra/cassandra-env.sh:

{code}
JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.2.jar
{code}

to

{code}
JVM_OPTS=$JVM_OPTS -javaagent:/usr/share/cassandra/jamm-0.2.2.jar
{code}

That solves the same problem in a different way. So when you upgrade to an 
official package with the real fix, you will want to change 
/etc/cassandra/cassandra-env.sh back to the way it was.

3. Just wait for 0.8.0 beta3 to be released and use that

 Cassandra can't find jamm on startup
 

 Key: CASSANDRA-2647
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2647
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Affects Versions: 0.8 beta 1
 Environment: Ubuntu 10.04 Lucid
Reporter: Marcus Bointon
Assignee: paul cannon
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 v1-0001-CASSANDRA-2647-move-jars-under-lib-to-satisfy-hard-cod.txt


 I installed the Debian package (from 
 http://www.apache.org/dist/cassandra/debian unstable) of Cassandra 0.8beta2 
 on Ubuntu 10.04 with the sun jdk over a working copy of 0.7.2. It broke on 
 restart.
 On startup it gives this:
 {code}
 Error occurred during initialization of VM
 agent library failed to init: instrument
 Error opening zip file or JAR manifest missing : /lib/jamm-0.2.2.jar
 {code}
 /etc/cassandra/cassandra-env.sh contains this:
 {code}
 # add the jamm javaagent
 check_openjdk=$(java -version 21 | awk '{if (NR == 2) {print $1}}')
 if [ $check_openjdk != OpenJDK ]
 then
 JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.2.jar
 fi
 {code}
 By default, CASSANDRA_HOME is not set, so it's looking in /lib for this jar. 
 It seems CASSANDRA_HOME should be set to /usr/share/cassandra, since that's 
 where jamm-0.2.2.jar is installed, but that means the path is still wrong.
 I set CASSANDRA_HOME to /usr/share/cassandra and changed the JVM_OPTS line to 
 this:
 {code}
 JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/jamm-0.2.2.jar
 {code}
 and then cassandra started ok.
 Is this a bug or did I miss something?
 I also noticed that this line appears to be the only use of CASSANDRA_HOME.

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

[jira] [Updated] (CASSANDRA-2659) Improve forceDeserialize/getCompactedRow encapsulation


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

Jonathan Ellis updated CASSANDRA-2659:
--

Attachment: 2659.txt

Patch centralizes getCompactedRow methods in CompactionController. fake 
controllers (with no CFS) are no longer needed.

 Improve forceDeserialize/getCompactedRow encapsulation
 --

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

 Attachments: 2659.txt




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

[jira] [Commented] (CASSANDRA-2647) Cassandra can't find jamm on startup

2011-05-16 Thread Joe Travaglini (JIRA)


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

Joe Travaglini commented on CASSANDRA-2647:
---

Thanks for the quick response, Paul.  I've taken approach #2 for now, and will 
loop back when I upgrade.  Much appreciated.

 Cassandra can't find jamm on startup
 

 Key: CASSANDRA-2647
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2647
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Affects Versions: 0.8 beta 1
 Environment: Ubuntu 10.04 Lucid
Reporter: Marcus Bointon
Assignee: paul cannon
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 v1-0001-CASSANDRA-2647-move-jars-under-lib-to-satisfy-hard-cod.txt


 I installed the Debian package (from 
 http://www.apache.org/dist/cassandra/debian unstable) of Cassandra 0.8beta2 
 on Ubuntu 10.04 with the sun jdk over a working copy of 0.7.2. It broke on 
 restart.
 On startup it gives this:
 {code}
 Error occurred during initialization of VM
 agent library failed to init: instrument
 Error opening zip file or JAR manifest missing : /lib/jamm-0.2.2.jar
 {code}
 /etc/cassandra/cassandra-env.sh contains this:
 {code}
 # add the jamm javaagent
 check_openjdk=$(java -version 21 | awk '{if (NR == 2) {print $1}}')
 if [ $check_openjdk != OpenJDK ]
 then
 JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.2.jar
 fi
 {code}
 By default, CASSANDRA_HOME is not set, so it's looking in /lib for this jar. 
 It seems CASSANDRA_HOME should be set to /usr/share/cassandra, since that's 
 where jamm-0.2.2.jar is installed, but that means the path is still wrong.
 I set CASSANDRA_HOME to /usr/share/cassandra and changed the JVM_OPTS line to 
 this:
 {code}
 JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/jamm-0.2.2.jar
 {code}
 and then cassandra started ok.
 Is this a bug or did I miss something?
 I also noticed that this line appears to be the only use of CASSANDRA_HOME.

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

svn commit: r1103861 - in /cassandra/branches/cassandra-0.8: build.xml doc/cql/CQL.html

Author: jbellis
Date: Mon May 16 19:57:16 2011
New Revision: 1103861

URL: http://svn.apache.org/viewvc?rev=1103861view=rev
Log:
add ant generate-cql-html
patch by Nate McCall; reviewed by jbellis for CASSANDRA-2526

Removed:
cassandra/branches/cassandra-0.8/doc/cql/CQL.html
Modified:
cassandra/branches/cassandra-0.8/build.xml

Modified: cassandra/branches/cassandra-0.8/build.xml
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/build.xml?rev=1103861r1=1103860r2=1103861view=diff
==
--- cassandra/branches/cassandra-0.8/build.xml (original)
+++ cassandra/branches/cassandra-0.8/build.xml Mon May 16 19:57:16 2011
@@ -221,6 +221,19 @@
  arg value=${build.src.gen-java}/org/apache/cassandra/cql/ /
   /java 
 /target
+   
+   target name=generate-cql-html depends=maven-ant-tasks-init 
description=Generate HTML from textile source
+ artifact:dependencies pathId=wikitext.classpath
+   dependency groupId=com.datastax.wikitext 
artifactId=wikitext-core-ant version=1.3/
+   dependency groupId=org.fusesource.wikitext 
artifactId=textile-core version=1.3/   
+ /artifact:dependencies
+  taskdef classpathref=wikitext.classpath 
resource=wikitexttasks.properties /
+   wikitext-to-html markupLanguage=Textile
+ fileset dir=${basedir}
+   include name=doc/cql/*.textile/
+ /fileset
+   /wikitext-to-html
+   /target
 
 target name=scm-svn-info description=Determines the current Subversion 
URL with peg revision
 if=scm.provider.svn

[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter

2011-05-16 Thread Jon Hermes (JIRA)


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

Jon Hermes commented on CASSANDRA-2500:
---

As a side note, this needs to be rolled into ruby-cassandra to avoid even more 
duplicate work. By the same token, pycassa and the py-cql driver need to be 
mashed up as well.

 Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
 ---

 Key: CASSANDRA-2500
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500
 Project: Cassandra
  Issue Type: Task
Reporter: Jon Hermes
Assignee: Jon Hermes
 Attachments: 2500.txt, genthriftrb.txt


 Create a ruby driver for CQL.
 Lacking something standard (such as py-dbapi), going with something common 
 instead -- RoR ActiveRecord Connection Adapter 
 (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html).

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

[jira] [Updated] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter

2011-05-16 Thread Jon Hermes (JIRA)


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

Jon Hermes updated CASSANDRA-2500:
--

Attachment: 2500.txt
genthriftrb.txt

genthriftrb just adds a gen-thrift-rb target to the build file. Not sure if it 
has general use, but I've written it 1 time now, so including.

The patch adds drivers/rb/cass-dbd/*. It's heavily reliant on ruby DBI (0.4.3), 
so most of the hard work was abstracted out. That being said, it's still a 
rough fit because DBI expects SQL-systems.

It's also Adapter compliant for use in RoR systems.

 Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
 ---

 Key: CASSANDRA-2500
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500
 Project: Cassandra
  Issue Type: Task
Reporter: Jon Hermes
Assignee: Jon Hermes
 Attachments: 2500.txt, genthriftrb.txt


 Create a ruby driver for CQL.
 Lacking something standard (such as py-dbapi), going with something common 
 instead -- RoR ActiveRecord Connection Adapter 
 (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html).

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

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


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

Jonathan Ellis resolved CASSANDRA-2526.
---

Resolution: Fixed
  Reviewer: jbellis

committed (and removed CQL.html from the source tree).

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

 Attachments: 2526.txt, 2526v2.txt


 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-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter


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

Jonathan Ellis commented on CASSANDRA-2500:
---

does this support using KEY in a select clause? That was tricky for java and 
python (CASSANDRA-2622)

 Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
 ---

 Key: CASSANDRA-2500
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500
 Project: Cassandra
  Issue Type: Task
Reporter: Jon Hermes
Assignee: Jon Hermes
 Attachments: 2500.txt, genthriftrb.txt


 Create a ruby driver for CQL.
 Lacking something standard (such as py-dbapi), going with something common 
 instead -- RoR ActiveRecord Connection Adapter 
 (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html).

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

[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter

2011-05-16 Thread Jon Hermes (JIRA)


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

Jon Hermes commented on CASSANDRA-2500:
---

Ah, no. Hadn't seen that ticket yet. Rolling a v2 after some cogitation.

 Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
 ---

 Key: CASSANDRA-2500
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500
 Project: Cassandra
  Issue Type: Task
Reporter: Jon Hermes
Assignee: Jon Hermes
 Attachments: 2500.txt, genthriftrb.txt


 Create a ruby driver for CQL.
 Lacking something standard (such as py-dbapi), going with something common 
 instead -- RoR ActiveRecord Connection Adapter 
 (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html).

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

[jira] [Updated] (CASSANDRA-1709) CQL keyspace and column family management


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

Jonathan Ellis updated CASSANDRA-1709:
--

Fix Version/s: (was: 1.0)
   0.8.1
 Assignee: Pavel Yaskevich

Looks like we also need DROP INDEX.

(We don't allow changing comparator, so one of the ALTER CF examples is 
misleading above.)

 CQL keyspace and column family management
 -

 Key: CASSANDRA-1709
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1709
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Affects Versions: 0.8 beta 1
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: v1-0001-CASSANDRA-1709-CQL-DROP-implementations.txt, 
 v1-0002-system-tests-for-CQL-DROPs.txt, v1-0003-updated-doco-for-CQL-DROPs.txt

   Original Estimate: 0h
  Remaining Estimate: 0h

 CQL specification and implementation for schema management.
 This corresponds to the following RPC methods:
 * system_add_column_family()
 * system_add_keyspace()
 * system_drop_keyspace()
 * system_update_keyspace()
 * system_update_columnfamily()
 *Update: 2011-04-11*
 All that remains for the Cassandra 1.0 timeline is {{ALTER}} (scroll down for 
 the agreed upon specification).  {{CREATE}} and {{DROP}} are complete.

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

[jira] [Resolved] (CASSANDRA-2546) CQL: there is currently no mechanism to specify TTL with insert, update or delete


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

Jonathan Ellis resolved CASSANDRA-2546.
---

Resolution: Duplicate

done in CASSANDRA-2476

 CQL: there is currently no mechanism to specify TTL with insert, update or 
 delete
 -

 Key: CASSANDRA-2546
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2546
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.8 beta 1
Reporter: Cathy Daw
  Labels: cql



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

[jira] [Assigned] (CASSANDRA-2547) CQL: support for create columnfamily option 'row_cache_provider'


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

Jonathan Ellis reassigned CASSANDRA-2547:
-

Assignee: Pavel Yaskevich

 CQL: support for create columnfamily option 'row_cache_provider'
 --

 Key: CASSANDRA-2547
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2547
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 0.8 beta 1
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql



--
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-05-16 Thread Hudson (JIRA)


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

Hudson commented on CASSANDRA-2526:
---

Integrated in Cassandra-0.8 #109 (See 
[https://builds.apache.org/hudson/job/Cassandra-0.8/109/])
add ant generate-cql-html
patch by Nate McCall; reviewed by jbellis for CASSANDRA-2526


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

 Attachments: 2526.txt, 2526v2.txt


 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

svn commit: r1103886 - /cassandra/branches/cassandra-0.8/doc/cql/CQL.textile

Author: jbellis
Date: Mon May 16 20:51:46 2011
New Revision: 1103886

URL: http://svn.apache.org/viewvc?rev=1103886view=rev
Log:
update list of valid consistency levels

Modified:
cassandra/branches/cassandra-0.8/doc/cql/CQL.textile

Modified: cassandra/branches/cassandra-0.8/doc/cql/CQL.textile
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/doc/cql/CQL.textile?rev=1103886r1=1103885r2=1103886view=diff
==
--- cassandra/branches/cassandra-0.8/doc/cql/CQL.textile (original)
+++ cassandra/branches/cassandra-0.8/doc/cql/CQL.textile Mon May 16 20:51:46 
2011
@@ -270,12 +270,12 @@ bc. 
 
 Consistency level specifications are made up the keyword @USING@, followed by 
a consistency level identifier. Valid consistency levels are as follows:
 
-* @CONSISTENCY ZERO@
+* @CONSISTENCY ANY@
 * @CONSISTENCY ONE@ (default)
 * @CONSISTENCY QUORUM@
 * @CONSISTENCY ALL@
-* @CONSISTENCY DCQUORUM@
-* @CONSISTENCY DCQUORUMSYNC@
+* @CONSISTENCY LOCAL_QUORUM@
+* @CONSISTENCY EACH_QUORUM@
 
 h3(#terms). Term specification

[jira] [Assigned] (CASSANDRA-2566) CQL: Batch Updates: some consistency levels not working


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

Jonathan Ellis reassigned CASSANDRA-2566:
-

Assignee: Pavel Yaskevich

 CQL: Batch Updates: some consistency levels not working
 ---

 Key: CASSANDRA-2566
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2566
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.8.1
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
  Labels: cql

 Testing the batch updates, and running into some issues with different 
 consistency levels
 +*Summary*+
 * UNTESTED: CONSISTENCY ANY
 * PASS: CONSISTENCY  ONE
 * PASS: CONSISTENCY  QUORUM
 * PASS: CONSISTENCY  ALL
 * CQL ERROR: CONSISTENCY  LOCAL_QUORUM
 * CQL ERROR: CONSISTENCY  EACH_QUORUM
  
 +*Test Setup*+
 {code}
 CREATE KEYSPACE cqldb with strategy_class =  
 'org.apache.cassandra.locator.SimpleStrategy'  
 and strategy_options:replication_factor=1;
 use cqldb;
 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}
 +*Bug Details*+
 *CONSISTENCY LOCAL_QUORUM*
 {code}
 BEGIN BATCH USING CONSISTENCY  LOCAL_QUORUM
 UPDATE users SET state = 'UT' WHERE KEY = 'user1';
 UPDATE users SET state = 'UT' WHERE KEY = 'user2';
 UPDATE users SET state = 'UT' WHERE KEY = 'user3';
 APPLY BATCH
 cqlsh  Bad Request: line 1:31 mismatched input 'LOCAL_QUORUM' expecting 
 K_LEVEL
 {code}
 *CONSISTENCY EACH_QUORUM*
 {code}
 BEGIN BATCH USING CONSISTENCY  EACH_QUORUM
 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
 cqlsh Bad Request: line 1:31 mismatched input 'EACH_QUORUM' expecting K_LEVEL
 {code}

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

[jira] [Updated] (CASSANDRA-2566) CQL: Batch Updates: some consistency levels not working


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

Jonathan Ellis updated CASSANDRA-2566:
--

Description: 
Testing the batch updates, and running into some issues with different 
consistency levels

+*Summary*+
* UNTESTED: CONSISTENCY ANY
* PASS: CONSISTENCY  ONE
* PASS: CONSISTENCY  QUORUM
* PASS: CONSISTENCY  ALL
* CQL ERROR: CONSISTENCY  LOCAL_QUORUM
* CQL ERROR: CONSISTENCY  EACH_QUORUM

 
+*Test Setup*+
{code}
CREATE KEYSPACE cqldb with strategy_class =  
'org.apache.cassandra.locator.SimpleStrategy'  
and strategy_options:replication_factor=1;

use cqldb;

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}


+*Bug Details*+

*CONSISTENCY LOCAL_QUORUM*
{code}
BEGIN BATCH USING CONSISTENCY  LOCAL_QUORUM
UPDATE users SET state = 'UT' WHERE KEY = 'user1';
UPDATE users SET state = 'UT' WHERE KEY = 'user2';
UPDATE users SET state = 'UT' WHERE KEY = 'user3';
APPLY BATCH

cqlsh  Bad Request: line 1:31 mismatched input 'LOCAL_QUORUM' expecting K_LEVEL
{code}

*CONSISTENCY EACH_QUORUM*
{code}
BEGIN BATCH USING CONSISTENCY  EACH_QUORUM
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

cqlsh Bad Request: line 1:31 mismatched input 'EACH_QUORUM' expecting K_LEVEL
{code}


  was:
Testing the batch updates, and running into some issues with different 
consistency levels

_Note: hopefully not offending anyone by putting multiple bugs in one JIRA, but 
they all seem related, so decided to add them in one.  After triage I can split 
this out, if needed._

+*Summary*+
* PASS: CONSISTENCY  ONE
* PASS: CONSISTENCY  QUORUM
* PASS: CONSISTENCY  ALL
* CQL ERROR: CONSISTENCY ZERO

The following were run on a single node which did not have a DC setup so the 
test isn't fully accurate, but didn't expect exceptions. The following work 
fine for DELETE
* THRIFT ERROR: CONSISTENCY  DCQUORUM
* THRIFT ERROR:CONSISTENCY  DCQUORUMSYNC

The following are not in the CQL Documentation as supported, but I saw a bug 
which says we need to support them for all strategy types.  The following are 
also broken for DELETE.
* CQL ERROR: CONSISTENCY  LOCAL_QUORUM
* CQL ERROR: CONSISTENCY  EACH_QUORUM

 
+*Test Setup*+
{code}
CREATE KEYSPACE cqldb with strategy_class =  
'org.apache.cassandra.locator.SimpleStrategy'  
and strategy_options:replication_factor=1;

use cqldb;

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}


+*Bug Details*+

*CONSISTENCY ZERO*
{code}
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

cqlsh Bad Request: line 1:30 mismatched input 'ZERO' expecting K_LEVEL
{code}

*CONSISTENCY LOCAL_QUORUM*
{code}
BEGIN BATCH USING CONSISTENCY  LOCAL_QUORUM
UPDATE users SET state = 'UT' WHERE KEY = 'user1';
UPDATE users SET state = 'UT' WHERE KEY = 'user2';
UPDATE users SET state = 'UT' WHERE KEY = 'user3';
APPLY BATCH

cqlsh  Bad Request: line 1:31 mismatched input 'LOCAL_QUORUM' expecting K_LEVEL
{code}

*CONSISTENCY EACH_QUORUM*
{code}
BEGIN BATCH USING CONSISTENCY  EACH_QUORUM
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

cqlsh Bad Request: line 1:31 mismatched input 'EACH_QUORUM' expecting K_LEVEL
{code}


*CONSISTENCY DCQUORUM*
{code}
cqlsh DELETE FROM users USING CONSISTENCY DCQUORUM where KEY = 'user2' ; -- 
PASSES
{code}

{code}
BEGIN BATCH USING CONSISTENCY  DCQUORUM
UPDATE users SET state = 'WA' WHERE KEY = 'user1';
UPDATE users SET state = 'WA' WHERE KEY = 'user2';
UPDATE users SET state = 'WA' WHERE KEY = 'user3';
APPLY BATCH 

cqlsh Internal application error


ERROR 19:20:39,087 Internal error processing execute_cql_query
java.lang.IllegalArgumentException: No enum const class 
org.apache.cassandra.thrift.ConsistencyLevel.DCQUORUM
at

[jira] [Updated] (CASSANDRA-2480) Named keys / virtual columns


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

Jonathan Ellis updated CASSANDRA-2480:
--

Assignee: Pavel Yaskevich
  Labels: cql  (was: )

 Named keys / virtual columns
 

 Key: CASSANDRA-2480
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
  Labels: cql
 Fix For: 1.0


 With the completion of CASSANDRA-2396, it is now possible to attach a name to 
 keys (column family-wide).  This could be utilized to introduce the concept 
 of virtual columns in CQL. Here's how that would work:
 Typically you would use the CQL keyword {{KEY}} to specify a row key, for 
 example:
 {code:SQL|title=CQL 1.0}
 INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
 -- or alternately
 UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
 SELECT name1,name2 FROM cf WHERE KEY = key1
 {code}
 For CQL 1.1, that syntax would continue to work, but upon the completion of 
 this issue it should also be possible to assign a name to the key and treat 
 as if it were another column.  For example:
 {code:SQL|title=CQL 1.1}
 INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
 -- or alternately
 UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
 -- Note how the keyname can now be used in the projection
 SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
 -- And, there is no restriction on the order
 SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
 {code}
 The semantics will be such that the existing behavior is maintained (read: 
 when using the {{KEY}} keyword), but if the key is named, and the name is 
 used in a {{SELECT}}, the key's name and value will be returned in the column 
 results, sorted according to the comparator (_Note: we'll need to figure out 
 what that means with respect to differently typed keys_).

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

[jira] [Resolved] (CASSANDRA-2372) JDBC driver will need adjustments post 2311


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

Jonathan Ellis resolved CASSANDRA-2372.
---

Resolution: Duplicate

fixed by CASSANDRA-2622

 JDBC driver will need adjustments post 2311
 ---

 Key: CASSANDRA-2372
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2372
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Gary Dusbabek
Priority: Minor
  Labels: cql

 Right now jdbc just assumes keys are always bytes.  After CASSANDRA-2311 
 we'll need to use a comparator that can be derived from 
 client.describe_keyspaces().

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

[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns


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

Jonathan Ellis updated CASSANDRA-2474:
--

Labels: cql  (was: )

 CQL support for compound columns
 

 Key: CASSANDRA-2474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
  Labels: cql
 Fix For: 1.0


 For the most part, this boils down to supporting the specification of 
 compound column names (the CQL syntax is colon-delimted terms), and then 
 teaching the decoders (drivers) to create structures from the results.

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

[jira] [Updated] (CASSANDRA-2475) Prepared statements


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

Jonathan Ellis updated CASSANDRA-2475:
--

Labels: cql  (was: )

 Prepared statements
 ---

 Key: CASSANDRA-2475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
  Labels: cql
 Fix For: 1.0




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

[jira] [Updated] (CASSANDRA-2477) CQL support for describing keyspaces / column familes


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

Jonathan Ellis updated CASSANDRA-2477:
--

Fix Version/s: (was: 1.0)
   0.8.1
 Assignee: Jonathan Ellis
   Labels: cql  (was: )

Rather than adding new CQL keywords, one alternative would be to take the pgsql 
approach of building this logic into the shell, by querying system CFs.

 CQL support for describing keyspaces / column familes
 -

 Key: CASSANDRA-2477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2477
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Jonathan Ellis
  Labels: cql
 Fix For: 0.8.1




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

[jira] [Commented] (CASSANDRA-2475) Prepared statements


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

Jonathan Ellis commented on CASSANDRA-2475:
---

Traditionally, a prepared statement API would look something like this:

{noformat}
  int prepare_cql_query(1:binary query, 2:Compression compression);
  void execute_prepared_query(1:int query_handle, 2:listbinary parameters, 
3:Compression compression);
{noformat}

... that is, prepare would parse and plan the query, then execute would supply 
the parameters to be bound to query variables.

On the client side, the APIs are well-defined, e.g. JDBC's prepareStatement. 
(Note that we currently fake these APIs on top of the standard 
execute_cql_query.)

 Prepared statements
 ---

 Key: CASSANDRA-2475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
  Labels: cql
 Fix For: 1.0




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

svn commit: r1103894 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/db/HintedHandOffManager.java

Author: jbellis
Date: Mon May 16 21:15:12 2011
New Revision: 1103894

URL: http://svn.apache.org/viewvc?rev=1103894view=rev
Log:
adjust hinted handoff page size to avoid OOM with large columns
patch by jbellis; reviewed by brandonwilliams for CASSANDRA-2652

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

cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/HintedHandOffManager.java

Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1103894r1=1103893r2=1103894view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Mon May 16 21:15:12 2011
@@ -1,3 +1,8 @@
+0.7.7
+ * adjust hinted handoff page size to avoid OOM with large columns 
+   (CASSANDRA-2652)
+
+
 0.7.6
  * force GC to reclaim disk space on flush, if necessary (CASSANDRA-2404)
  * move gossip heartbeat back to its own thread (CASSANDRA-2554)
@@ -24,7 +29,7 @@
  * initialize local ep state prior to gossip startup if needed (CASSANDRA-2638)
  * fix empty Result with secondary index when limit=1 (CASSANDRA-2628)
  * add quote-escaping via backslash to CLI (CASSANDRA-2623)
- * fig pig example script (CASSANDRA-2487)
+ * fix pig example script (CASSANDRA-2487)
  * fix dynamic snitch race in adding latencies (CASSANDRA-2618)
  * Start/stop cassandra after more important services such as mdadm in
debian packaging (CASSANDRA-2481)

Modified: 
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/HintedHandOffManager.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/HintedHandOffManager.java?rev=1103894r1=1103893r2=1103894view=diff
==
--- 
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/HintedHandOffManager.java
 (original)
+++ 
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/HintedHandOffManager.java
 Mon May 16 21:15:12 2011
@@ -116,7 +116,7 @@ public class HintedHandOffManager implem
 logger_.debug(Created HHOM instance, registered MBean.);
 }
 
-private static boolean sendMessage(InetAddress endpoint, String tableName, 
String cfName, ByteBuffer key) throws IOException
+private static boolean sendRow(InetAddress endpoint, String tableName, 
String cfName, ByteBuffer key) throws IOException
 {
 if (!Gossiper.instance.isKnownEndpoint(endpoint))
 {
@@ -131,10 +131,21 @@ public class HintedHandOffManager implem
 Table table = Table.open(tableName);
 DecoratedKey dkey = StorageService.getPartitioner().decorateKey(key);
 ColumnFamilyStore cfs = table.getColumnFamilyStore(cfName);
+
+int pageSize = PAGE_SIZE;
+// send less columns per page if they are very large
+if (cfs.getMeanColumns()  0)
+{
+int averageColumnSize = (int) (cfs.getMeanRowSize() / 
cfs.getMeanColumns());
+pageSize = Math.min(PAGE_SIZE, 
DatabaseDescriptor.getInMemoryCompactionLimit() / averageColumnSize);
+pageSize = Math.max(2, pageSize); // page size of 1 does not allow 
actual paging b/c of = behavior on startColumn
+logger_.debug(average hinted-row column size is {}; using 
pageSize of {}, averageColumnSize, pageSize);
+}
+
 ByteBuffer startColumn = ByteBufferUtil.EMPTY_BYTE_BUFFER;
 while (true)
 {
-QueryFilter filter = QueryFilter.getSliceFilter(dkey, new 
QueryPath(cfs.getColumnFamilyName()), startColumn, 
ByteBufferUtil.EMPTY_BYTE_BUFFER, false, PAGE_SIZE);
+QueryFilter filter = QueryFilter.getSliceFilter(dkey, new 
QueryPath(cfs.getColumnFamilyName()), startColumn, 
ByteBufferUtil.EMPTY_BYTE_BUFFER, false, pageSize);
 ColumnFamily cf = cfs.getColumnFamily(filter);
 if (pagingFinished(cf, startColumn))
 break;
@@ -328,7 +339,7 @@ public class HintedHandOffManager implem
 for (IColumn tableCF : tableCFs)
 {
 String[] parts = getTableAndCFNames(tableCF.name());
-if (sendMessage(endpoint, parts[0], parts[1], 
keyColumn.name()))
+if (sendRow(endpoint, parts[0], parts[1], 
keyColumn.name()))
 {
 deleteHintKey(endpointAsUTF8, keyColumn.name(), 
tableCF.name(), tableCF.timestamp());
 rowsReplayed++;

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

Author: jbellis
Date: Mon May 16 21:16:14 2011
New Revision: 1103895

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

Modified:
cassandra/branches/cassandra-0.8/   (props changed)
cassandra/branches/cassandra-0.8/CHANGES.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/HintedHandOffManager.java

Propchange: cassandra/branches/cassandra-0.8/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon May 16 21:16:14 2011
@@ -1,5 +1,5 @@
 
/cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000
-/cassandra/branches/cassandra-0.7:1026516-1102504
+/cassandra/branches/cassandra-0.7:1026516-1103894
 /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/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1103895r1=1103894r2=1103895view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Mon May 16 21:16:14 2011
@@ -1,3 +1,8 @@
+0.8-?
+ * adjust hinted handoff page size to avoid OOM with large columns 
+   (CASSANDRA-2652)
+
+
 0.8.0-rc1
  * faster flushes and compaction from fixing excessively pessimistic 
rebuffering in BRAF (CASSANDRA-2581)
@@ -25,8 +30,10 @@
  * initialize local ep state prior to gossip startup if needed (CASSANDRA-2638)
  * fix counter increment lost after restart (CASSANDRA-2642)
  * add quote-escaping via backslash to CLI (CASSANDRA-2623)
- * fig pig example script (CASSANDRA-2487)
+ * fix pig example script (CASSANDRA-2487)
  * fix dynamic snitch race in adding latencies (CASSANDRA-2618)
+ * Start/stop cassandra after more important services such as mdadm in
+   debian packaging (CASSANDRA-2481)
 
 
 0.8.0-beta2

Propchange: cassandra/branches/cassandra-0.8/contrib/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon May 16 21:16:14 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-1102504
+/cassandra/branches/cassandra-0.7/contrib:1026516-1103894
 /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 May 16 21:16:14 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-1102504
+/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1103894
 
/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 May 16 21:16:14 2011
@@ -1,5 +1,5 @@
 
/cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000
-/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1102504

[jira] [Commented] (CASSANDRA-1709) CQL keyspace and column family management

2011-05-16 Thread Pavel Yaskevich (JIRA)


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

Pavel Yaskevich commented on CASSANDRA-1709:


I have already created a task for DROP INDEX in CQL - CASSANDRA-2617

 CQL keyspace and column family management
 -

 Key: CASSANDRA-1709
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1709
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Affects Versions: 0.8 beta 1
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: cql
 Fix For: 0.8.1

 Attachments: v1-0001-CASSANDRA-1709-CQL-DROP-implementations.txt, 
 v1-0002-system-tests-for-CQL-DROPs.txt, v1-0003-updated-doco-for-CQL-DROPs.txt

   Original Estimate: 0h
  Remaining Estimate: 0h

 CQL specification and implementation for schema management.
 This corresponds to the following RPC methods:
 * system_add_column_family()
 * system_add_keyspace()
 * system_drop_keyspace()
 * system_update_keyspace()
 * system_update_columnfamily()
 *Update: 2011-04-11*
 All that remains for the Cassandra 1.0 timeline is {{ALTER}} (scroll down for 
 the agreed upon specification).  {{CREATE}} and {{DROP}} are complete.

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

[jira] [Commented] (CASSANDRA-2652) Hinted handoff needs to adjust page size for lage columns to avoid OOM

2011-05-16 Thread Hudson (JIRA)


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

Hudson commented on CASSANDRA-2652:
---

Integrated in Cassandra-0.7 #486 (See 
[https://builds.apache.org/hudson/job/Cassandra-0.7/486/])
adjust hinted handoff page size to avoid OOM with large columns
patch by jbellis; reviewed by brandonwilliams for CASSANDRA-2652


 Hinted handoff needs to adjust page size for lage columns to avoid OOM
 --

 Key: CASSANDRA-2652
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2652
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 0.7.7

 Attachments: 2652.txt


 Example OOM:
 {noformat}
 java.lang.OutOfMemoryError: Java heap space
   at 
 org.apache.cassandra.io.util.BufferedRandomAccessFile.readBytes(BufferedRandomAccessFile.java:269)
   at 
 org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:356)
   at 
 org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:318)
   at 
 org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:99)
   at 
 org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:248)
   at 
 org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:268)
   at 
 org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:227)
   at 
 java.util.concurrent.ConcurrentSkipListMap.buildFromSorted(ConcurrentSkipListMap.java:1493)
   at 
 java.util.concurrent.ConcurrentSkipListMap.init(ConcurrentSkipListMap.java:1443)
   at 
 org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:379)
   at 
 org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:362)
   at 
 org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:322)
   at 
 org.apache.cassandra.db.columniterator.IndexedSliceReader$IndexedBlockFetcher.getNextBlock(IndexedSliceReader.java:179)
   at 
 org.apache.cassandra.db.columniterator.IndexedSliceReader.computeNext(IndexedSliceReader.java:121)
   at 
 org.apache.cassandra.db.columniterator.IndexedSliceReader.computeNext(IndexedSliceReader.java:49)
   at 
 com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136)
   at 
 com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131)
   at 
 org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:108)
   at 
 org.apache.commons.collections.iterators.CollatingIterator.set(CollatingIterator.java:283)
   at 
 org.apache.commons.collections.iterators.CollatingIterator.least(CollatingIterator.java:326)
   at 
 org.apache.commons.collections.iterators.CollatingIterator.next(CollatingIterator.java:230)
   at 
 org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:69)
   at 
 com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136)
   at 
 com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131)
   at 
 org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:116)
   at 
 org.apache.cassandra.db.filter.QueryFilter.collectCollatedColumns(QueryFilter.java:130)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1390)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1267)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1195)
   at 
 org.apache.cassandra.db.HintedHandOffManager.sendMessage(HintedHandOffManager.java:138)
   at 
 org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:331)
   at 
 org.apache.cassandra.db.HintedHandOffManager.access$100(HintedHandOffManager.java:88)
 {noformat}

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

svn commit: r1103916 - /cassandra/branches/cassandra-0.8.1/src/java/org/apache/cassandra/locator/RackInferringSnitch.java

2011-05-16 Thread brandonwilliams

Author: brandonwilliams
Date: Mon May 16 21:43:37 2011
New Revision: 1103916

URL: http://svn.apache.org/viewvc?rev=1103916view=rev
Log:
RIS rack and DC values are interpreted as being unsigned
Patch by Jerr Pisk, reviewed by brandonwilliams for CASSANDRA-2651

Modified:

cassandra/branches/cassandra-0.8.1/src/java/org/apache/cassandra/locator/RackInferringSnitch.java

Modified: 
cassandra/branches/cassandra-0.8.1/src/java/org/apache/cassandra/locator/RackInferringSnitch.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8.1/src/java/org/apache/cassandra/locator/RackInferringSnitch.java?rev=1103916r1=1103915r2=1103916view=diff
==
--- 
cassandra/branches/cassandra-0.8.1/src/java/org/apache/cassandra/locator/RackInferringSnitch.java
 (original)
+++ 
cassandra/branches/cassandra-0.8.1/src/java/org/apache/cassandra/locator/RackInferringSnitch.java
 Mon May 16 21:43:37 2011
@@ -28,11 +28,11 @@ public class RackInferringSnitch extends
 {
 public String getRack(InetAddress endpoint)
 {
-return Byte.toString(endpoint.getAddress()[2]);
+return Integer.toString(endpoint.getAddress()[2]  0xFF, 10);
 }
 
 public String getDatacenter(InetAddress endpoint)
 {
-return Byte.toString(endpoint.getAddress()[1]);
+return Integer.toString(endpoint.getAddress()[1]  0xFF, 10);
 }
 }

[jira] [Updated] (CASSANDRA-2651) Inferred Rack and DC Values Should be Unsigned


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

Brandon Williams updated CASSANDRA-2651:


Fix Version/s: 0.8.1

 Inferred Rack and DC Values Should be Unsigned
 --

 Key: CASSANDRA-2651
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2651
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.7.5
Reporter: Jerry Pisk
Priority: Minor
 Fix For: 0.8.1

 Attachments: trunk-2651.txt


 RackInferringSnitch formats IP address octets as signed byte values when 
 inferring rack and data center values.

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

[jira] [Commented] (CASSANDRA-2477) CQL support for describing keyspaces / column familes

2011-05-16 Thread Rick Shaw (JIRA)


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

Rick Shaw commented on CASSANDRA-2477:
--

Tooling will want to be able to ask the API to describe:

- List all the Keyspace names.
- List all the attributes of the Keyspace
- List all the column families within a Keyspace
- List all of the column names and types of those columns that have been 
declared
- list all of the indexed names and alias names

I think this will need to be returned by the API at the code level not a shell. 

How about just a special set of CFs in the System Keyspace that can be 
treated as RO data that describes Keyspaces and CFs?

 CQL support for describing keyspaces / column familes
 -

 Key: CASSANDRA-2477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2477
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Jonathan Ellis
  Labels: cql
 Fix For: 0.8.1




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

[jira] [Issue Comment Edited] (CASSANDRA-2651) Inferred Rack and DC Values Should be Unsigned


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

Brandon Williams edited comment on CASSANDRA-2651 at 5/16/11 9:44 PM:
--

Committed to 0.8.1 to go along with CASSANDRA-2531

  was (Author: brandon.williams):
Committed to 0.8.1 to go along with CASSANDRA-2351
  
 Inferred Rack and DC Values Should be Unsigned
 --

 Key: CASSANDRA-2651
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2651
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.7.5
Reporter: Jerry Pisk
Priority: Minor
 Fix For: 0.8.1

 Attachments: trunk-2651.txt


 RackInferringSnitch formats IP address octets as signed byte values when 
 inferring rack and data center values.

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

[jira] [Resolved] (CASSANDRA-2651) Inferred Rack and DC Values Should be Unsigned


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

Brandon Williams resolved CASSANDRA-2651.
-

Resolution: Fixed

Committed to 0.8.1 to go along with CASSANDRA-2351

 Inferred Rack and DC Values Should be Unsigned
 --

 Key: CASSANDRA-2651
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2651
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.7.5
Reporter: Jerry Pisk
Priority: Minor
 Fix For: 0.8.1

 Attachments: trunk-2651.txt


 RackInferringSnitch formats IP address octets as signed byte values when 
 inferring rack and data center values.

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

[jira] [Commented] (CASSANDRA-2477) CQL support for describing keyspaces / column familes


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

Jonathan Ellis commented on CASSANDRA-2477:
---

bq. I think this will need to be returned by the API at the code level not a 
shell. 

You misunderstood; I'm not saying that the shell will be the only client able 
to access that, but that the shell can have shortcuts (\d users vs select * 
from pg_class where relname = 'users').

 CQL support for describing keyspaces / column familes
 -

 Key: CASSANDRA-2477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2477
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Jonathan Ellis
  Labels: cql
 Fix For: 0.8.1




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

[jira] [Updated] (CASSANDRA-2566) CQL: Batch Updates: some consistency levels not working

2011-05-16 Thread Pavel Yaskevich (JIRA)


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

Pavel Yaskevich updated CASSANDRA-2566:
---

Attachment: CASSANDRA-2566.patch

Added missing consistency levels to CQL grammar.

 CQL: Batch Updates: some consistency levels not working
 ---

 Key: CASSANDRA-2566
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2566
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.8.1
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
  Labels: cql
 Attachments: CASSANDRA-2566.patch


 Testing the batch updates, and running into some issues with different 
 consistency levels
 +*Summary*+
 * UNTESTED: CONSISTENCY ANY
 * PASS: CONSISTENCY  ONE
 * PASS: CONSISTENCY  QUORUM
 * PASS: CONSISTENCY  ALL
 * CQL ERROR: CONSISTENCY  LOCAL_QUORUM
 * CQL ERROR: CONSISTENCY  EACH_QUORUM
  
 +*Test Setup*+
 {code}
 CREATE KEYSPACE cqldb with strategy_class =  
 'org.apache.cassandra.locator.SimpleStrategy'  
 and strategy_options:replication_factor=1;
 use cqldb;
 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}
 +*Bug Details*+
 *CONSISTENCY LOCAL_QUORUM*
 {code}
 BEGIN BATCH USING CONSISTENCY  LOCAL_QUORUM
 UPDATE users SET state = 'UT' WHERE KEY = 'user1';
 UPDATE users SET state = 'UT' WHERE KEY = 'user2';
 UPDATE users SET state = 'UT' WHERE KEY = 'user3';
 APPLY BATCH
 cqlsh  Bad Request: line 1:31 mismatched input 'LOCAL_QUORUM' expecting 
 K_LEVEL
 {code}
 *CONSISTENCY EACH_QUORUM*
 {code}
 BEGIN BATCH USING CONSISTENCY  EACH_QUORUM
 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
 cqlsh Bad Request: line 1:31 mismatched input 'EACH_QUORUM' expecting K_LEVEL
 {code}

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

svn commit: r1103922 - in /cassandra/branches/cassandra-0.8: CHANGES.txt src/java/org/apache/cassandra/cql/Cql.g

Author: jbellis
Date: Mon May 16 22:01:43 2011
New Revision: 1103922

URL: http://svn.apache.org/viewvc?rev=1103922view=rev
Log:
update cql consistency levels
patch by pyaskevich; reviewed by jbellis for CASSANDRA-2566

Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g

Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1103922r1=1103921r2=1103922view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Mon May 16 22:01:43 2011
@@ -1,6 +1,7 @@
 0.8-?
  * adjust hinted handoff page size to avoid OOM with large columns 
(CASSANDRA-2652)
+ * update CQL consistency levels (CASSANDRA-2566)
 
 
 0.8.0-rc1

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g?rev=1103922r1=1103921r2=1103922view=diff
==
--- cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g 
(original)
+++ cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g 
Mon May 16 22:01:43 2011
@@ -390,9 +390,10 @@ K_USING:   U S I N G;
 K_CONSISTENCY: C O N S I S T E N C Y;
 K_LEVEL:   ( O N E 
| Q U O R U M 
-   | A L L 
-   | D C Q U O R U M 
-   | D C Q U O R U M S Y N C
+   | A L L
+   | A N Y
+   | L O C A L '_' Q U O R U M
+   | E A C H '_' Q U O R U M
)
;
 K_USE: U S E;

[jira] [Commented] (CASSANDRA-2477) CQL support for describing keyspaces / column familes


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

Jonathan Ellis commented on CASSANDRA-2477:
---

Yes, we want cqlsh or a similar tool to be a full replacement for the existing 
cli.

 CQL support for describing keyspaces / column familes
 -

 Key: CASSANDRA-2477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2477
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Jonathan Ellis
  Labels: cql
 Fix For: 0.8.1




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

[jira] [Commented] (CASSANDRA-2477) CQL support for describing keyspaces / column familes

2011-05-16 Thread Eric Evans (JIRA)


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

Eric Evans commented on CASSANDRA-2477:
---

bq. Rather than adding new CQL keywords, one alternative would be to take the 
pgsql approach of building this logic into the shell, by querying system CFs.

How will you actually grok the schema without Avro?

 CQL support for describing keyspaces / column familes
 -

 Key: CASSANDRA-2477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2477
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Jonathan Ellis
  Labels: cql
 Fix For: 0.8.1




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

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-05-16 Thread Eric Evans (JIRA)


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

Eric Evans commented on CASSANDRA-2475:
---

Why {{listbinary}} for parameters, and not {{liststring}}?

 Prepared statements
 ---

 Key: CASSANDRA-2475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
  Labels: cql
 Fix For: 1.0




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

[jira] [Commented] (CASSANDRA-2566) CQL: Batch Updates: some consistency levels not working

2011-05-16 Thread Hudson (JIRA)


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

Hudson commented on CASSANDRA-2566:
---

Integrated in Cassandra-0.8 #111 (See 
[https://builds.apache.org/hudson/job/Cassandra-0.8/111/])
update cql consistency levels
patch by pyaskevich; reviewed by jbellis for CASSANDRA-2566


 CQL: Batch Updates: some consistency levels not working
 ---

 Key: CASSANDRA-2566
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2566
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.8.1
Reporter: Cathy Daw
Assignee: Pavel Yaskevich
  Labels: cql
 Fix For: 0.8.1

 Attachments: CASSANDRA-2566.patch


 Testing the batch updates, and running into some issues with different 
 consistency levels
 +*Summary*+
 * UNTESTED: CONSISTENCY ANY
 * PASS: CONSISTENCY  ONE
 * PASS: CONSISTENCY  QUORUM
 * PASS: CONSISTENCY  ALL
 * CQL ERROR: CONSISTENCY  LOCAL_QUORUM
 * CQL ERROR: CONSISTENCY  EACH_QUORUM
  
 +*Test Setup*+
 {code}
 CREATE KEYSPACE cqldb with strategy_class =  
 'org.apache.cassandra.locator.SimpleStrategy'  
 and strategy_options:replication_factor=1;
 use cqldb;
 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}
 +*Bug Details*+
 *CONSISTENCY LOCAL_QUORUM*
 {code}
 BEGIN BATCH USING CONSISTENCY  LOCAL_QUORUM
 UPDATE users SET state = 'UT' WHERE KEY = 'user1';
 UPDATE users SET state = 'UT' WHERE KEY = 'user2';
 UPDATE users SET state = 'UT' WHERE KEY = 'user3';
 APPLY BATCH
 cqlsh  Bad Request: line 1:31 mismatched input 'LOCAL_QUORUM' expecting 
 K_LEVEL
 {code}
 *CONSISTENCY EACH_QUORUM*
 {code}
 BEGIN BATCH USING CONSISTENCY  EACH_QUORUM
 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
 cqlsh Bad Request: line 1:31 mismatched input 'EACH_QUORUM' expecting K_LEVEL
 {code}

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

[jira] [Commented] (CASSANDRA-2655) update wiki with CLI help


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

Aaron Morton commented on CASSANDRA-2655:
-

From IRC discussion, see CASSANDRA-2526 for example of how the CQL help is 
distributed. 

 update wiki with CLI help
 -

 Key: CASSANDRA-2655
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2655
 Project: Cassandra
  Issue Type: Task
  Components: Documentation  website
Affects Versions: 0.8.0
Reporter: Aaron Morton
Assignee: Aaron Morton
Priority: Minor
 Attachments: 0001-add-command-text-to-help-sections.patch, 
 yaml-to-mm.py


 Need a way to update the wiki with the help written for the CLI. 

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

[jira] [Commented] (CASSANDRA-2475) Prepared statements


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

Jonathan Ellis commented on CASSANDRA-2475:
---

The thinking being that it's easier for a client to encode as string?

That's a reasonable point, but having been up close and personal with both of 
our existing client APIs I'd say that saving a 20-line encode case statement is 
not going to make much difference in pain there.  On the other hand, the 
efficiency wins from receiving the data in native encoded format seem 
substantial (one of the most common data types, numerics, is particularly 
inefficient to decode-from-string).

 Prepared statements
 ---

 Key: CASSANDRA-2475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
  Labels: cql
 Fix For: 1.0




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

[jira] [Assigned] (CASSANDRA-2268) CQL-enabled stress.java


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

Aaron Morton reassigned CASSANDRA-2268:
---

Assignee: Aaron Morton  (was: Pavel Yaskevich)

 CQL-enabled stress.java
 ---

 Key: CASSANDRA-2268
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2268
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Eric Evans
Assignee: Aaron Morton
Priority: Minor
  Labels: cql
 Fix For: 0.8.1


 It would be great if stress.java had a CQL mode.  For making the inevitable 
 RPC-CQL comparisons, but also as a basis for measuring optimizations, and 
 spotting performance regressions.

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

[jira] [Commented] (CASSANDRA-2268) CQL-enabled stress.java