svn commit: r1083130 - in /cassandra/trunk/doc/cql: CQL.html CQL.textile

[eevans]

Author: eevans
Date: Sat Mar 19 02:14:54 2011
New Revision: 1083130

URL: http://svn.apache.org/viewvc?rev=1083130&view=rev
Log:
update CQL docs to reflect utf8 comparator/validator default

Patch by eevans

Modified:
cassandra/trunk/doc/cql/CQL.html
cassandra/trunk/doc/cql/CQL.textile

Modified: cassandra/trunk/doc/cql/CQL.html
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.html?rev=1083130&r1=1083129&r2=1083130&view=diff
==
--- cassandra/trunk/doc/cql/CQL.html (original)
+++ cassandra/trunk/doc/cql/CQL.html Sat Mar 19 02:14:54 2011
@@ -26,13 +26,13 @@ DELETE [COLUMNS] FROM 
-Accepts a single argument for the column family name, and 
permanently removes all data from said column family.CREATE 
KEYSPACESynopsis:CREATE KEYSPACE  
WITH replication_factor =  AND strategy_class = ""
+Accepts a single argument for the column family name, and 
permanently removes all data from said column family.CREATE 
KEYSPACESynopsis:CREATE KEYSPACE  
WITH replication_factor =  AND strategy_class = 
 [AND strategy_options. =  [AND 
strategy_options. = ]];
-The CREATE KEYSPACE statement creates a new 
top-level namespace (aka “keyspace”). Valid names are any string 
constructed of alphanumeric characters and underscores, but must begin with a 
letter.  Properties such as replication strategy and count are specified during 
creation using the following accepted keyword 
arguments:keywordrequireddescriptionreplication_factoryesNumeric
 argument that specifies the number of replicas for this 
keyspace.strategy_classyesClass name to use 
for managing replica placement.  Any of the shipped strategies can be used by 
specifying the class name relative to org.apache.cassandra.locator, others will 
need to be fully-qualified and located on the 
classpath.strategy_optionsnoSome strategies 
require additional arguments which can be supplied by appending the option na
 me to the strategy_options keyword, separated by a colon 
(:).  For example, a strategy option of “DC1” with a 
value of “1” would be specified as strategy_options:DC1 = 
"1".CREATE 
COLUMNFAMILYSynopsis:CREATE COLUMNFAMILY 
 [(name1 type, name2 type, ...)] [WITH keyword1 = arg1
+The CREATE KEYSPACE statement creates a new 
top-level namespace (aka “keyspace”). Valid names are any string 
constructed of alphanumeric characters and underscores, but must begin with a 
letter.  Properties such as replication strategy and count are specified during 
creation using the following accepted keyword 
arguments:keywordrequireddescriptionreplication_factoryesNumeric
 argument that specifies the number of replicas for this 
keyspace.strategy_classyesClass name to use 
for managing replica placement.  Any of the shipped strategies can be used by 
specifying the class name relative to org.apache.cassandra.locator, others will 
need to be fully-qualified and located on the 
classpath.strategy_optionsnoSome strategies 
require additional arguments which can be supplied by appending the option na
 me to the strategy_options keyword, separated by a colon 
(:).  For example, a strategy option of “DC1” with a 
value of “1” would be specified as strategy_options:DC1 = 
1.CREATE 
COLUMNFAMILYSynopsis:CREATE COLUMNFAMILY 
 [(name1 type, name2 type, ...)] [WITH keyword1 = arg1
 [AND keyword2 = arg2 [AND ...]]];
 CREATE COLUMNFAMILY statements create new column 
family namespaces under the current keyspace. Valid column family names are 
strings of alphanumeric characters and underscores, which begin with a 
letter.Specifying Column Type 
(optional)CREATE COLUMNFAMILY  (name1 
type, name2 type) ...;
 It is possible to assign columns a type during column family 
creation.  Columns configured with a type are validated accordingly when a 
write occurs. Column types are specified as a parenthesized, comma-separated 
list of column term and type pairs.  The list of recognized types 
are:typedescriptionbytesArbitrary
 bytes (no validation)asciiASCII character 
stringutf8UTF8 encoded 
stringtimeuuidType 1 
UUIDuuidType 4 
UUIDint4-byte 
integerlong8-byte longNote: 
In addition to the recognized types listed above, it is also possible to supply 
a string containing the name of a class (a sub-class of 
AbstractType), either fully qua

svn commit: r1083128 - /cassandra/trunk/test/system/test_cql.py

[eevans]

Author: eevans
Date: Sat Mar 19 02:09:44 2011
New Revision: 1083128

URL: http://svn.apache.org/viewvc?rev=1083128&view=rev
Log:
better utf8 CQL system tests

Patch by eevans

Modified:
cassandra/trunk/test/system/test_cql.py

Modified: cassandra/trunk/test/system/test_cql.py
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/test/system/test_cql.py?rev=1083128&r1=1083127&r2=1083128&view=diff
==
--- cassandra/trunk/test/system/test_cql.py (original)
+++ cassandra/trunk/test/system/test_cql.py Sat Mar 19 02:09:44 2011
@@ -1,3 +1,4 @@
+# -*- coding: utf-8 -*-
 # Licensed to the Apache Software Foundation (ASF) under one
 # or more contributor license agreements.  See the NOTICE file
 # distributed with this work for additional information
@@ -24,8 +25,8 @@ sys.path.append(join(abspath(dirname(__f
 
 from cql import Connection
 from cql.errors import CQLException
-from . import ThriftTester
-from . import thrift_client # TODO: temporary
+from __init__ import ThriftTester
+from __init__ import thrift_client # TODO: temporary
 
 def assert_raises(exception, method, *args):
 try:
@@ -79,13 +80,6 @@ def load_sample(dbconn):
 dbconn.execute(query, "cd1", "vd1", "col", "val", "kd")
 
 dbconn.execute("""
-UPDATE StandardUtf82 SET '%s' = 've1', 'col' = 'val' WHERE KEY = 'kd'
-""" % u'\xa9'.encode('utf8'))
-dbconn.execute("""
-UPDATE StandardUtf82 SET 'cf1' = 'vf1', 'col' = 'val' WHERE KEY = 'kd'
-""")
-
-dbconn.execute("""
 BEGIN BATCH USING CONSISTENCY ONE
  UPDATE StandardLongA SET 1='1', 2='2', 3='3', 4='4' WHERE KEY='aa';
  UPDATE StandardLongA SET 5='5', 6='6', 7='8', 9='9' WHERE KEY='ab';
@@ -525,4 +519,28 @@ class TestCql(ThriftTester):
 assert r[0].columns[0].name == uid.bytes
 
 # TODO: slices of uuids from cf w/ LexicalUUIDType comparator
+
+def test_utf8_read_write(self):
+"reading and writing utf8 values"
+conn = init()
+# Sorting: ¢ (u00a2) < © (u00a9) < ® (u00ae) < ¿ (u00bf)
+conn.execute("UPDATE StandardUtf82 SET ? = v1 WHERE KEY = k1", "¿")
+conn.execute("UPDATE StandardUtf82 SET ? = v1 WHERE KEY = k1", "©")
+conn.execute("UPDATE StandardUtf82 SET ? = v1 WHERE KEY = k1", "®")
+conn.execute("UPDATE StandardUtf82 SET ? = v1 WHERE KEY = k1", "¢")
+
+r = conn.execute("SELECT * FROM StandardUtf82 WHERE KEY = k1")
+assert r[0][0].name == "¢"
+assert r[0][1].name == "©"
+assert r[0][2].name == "®"
+assert r[0][3].name == "¿"
+
+r = conn.execute("SELECT ?..'' FROM StandardUtf82 WHERE KEY = k1", 
"©")
+assert len(r[0]) == 3
+assert r[0][0].name == "©"
+assert r[0][1].name == "®"
+assert r[0][2].name == "¿"
+
+
 
+

svn commit: r1083127 - /cassandra/trunk/drivers/py/cql/results.py

[eevans]

Author: eevans
Date: Sat Mar 19 02:09:39 2011
New Revision: 1083127

URL: http://svn.apache.org/viewvc?rev=1083127&view=rev
Log:
len and getitem magic methods for Row instances

Patch by eevans

Modified:
cassandra/trunk/drivers/py/cql/results.py

Modified: cassandra/trunk/drivers/py/cql/results.py
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/drivers/py/cql/results.py?rev=1083127&r1=1083126&r2=1083127&view=diff
==
--- cassandra/trunk/drivers/py/cql/results.py (original)
+++ cassandra/trunk/drivers/py/cql/results.py Sat Mar 19 02:09:39 2011
@@ -43,6 +43,12 @@ class Row(object):
 
 def __iter__(self):
 return iter(self.columns)
+
+def __getitem__(self, idx):
+return self.columns[idx]
+
+def __len__(self):
+return len(self.columns)
 
 class ColumnsProxy(object):
 def __init__(self, columns, keyspace, cfam, decoder):

[jira] Updated: (CASSANDRA-2357) Load spikes on coordinators since upgrade from 0.6.8 to 0.7

[Jason Harvey (JIRA)]

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

Jason Harvey updated CASSANDRA-2357:


Attachment: thread_dump.txt

> Load spikes on coordinators since upgrade from 0.6.8 to 0.7
> ---
>
> Key: CASSANDRA-2357
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2357
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 0.7.4
>Reporter: Jason Harvey
> Attachments: thread_dump.txt
>
>
> Since our move from 0.6.8 to 0.7, all of the nodes which speak with clients 
> have been having periodic, abrupt load spikes going into the hundreds. We 
> have been seeing these load spikes 1 to 2 times per hour on every node which 
> clients are speaking with. The load graph for a typical spike: 
> http://i.imgur.com/jY8AV.png
> I have verified that client connections are not spiking at the same time via 
> TCP statistics. I have also verified that we aren't seeing any spikes in 
> reads/mutations/etc. 
> We were using the DynamicSnitch, but I turned that off as a troubleshooting 
> step. The issue was unchanged.
> When the spikes occur, the box's responsiveness slows to a crawl so I am 
> unable to do much in terms of real-time diagnostics. I was able to get a 
> thread dump a few seconds after a spike, which I have attached to this 
> ticket. Not sure if it will show anything since I couldn't capture it 
> immediately during the spike.
> I should note that David King noticed a similar problem (#2058) when he tried 
> moving us from 0.6.8 to 0.6.10. The main issue at the time was a long-lasting 
> load spike, but he also saw occasional abrupt load spikes like we are seeing 
> now. When we moved back to 0.6.8, we didn't see the problem again, until the 
> move to 0.7.
> I realize this information is somewhat nebulous. If there is any further info 
> I can provide, please let me know. The spikes are causing quite a bit of 
> instability, so we are considering retreating back to 0.6.8. I'd like to 
> investigate every possible solution before we resort to that.

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

[jira] Created: (CASSANDRA-2357) Load spikes on coordinators since upgrade from 0.6.8 to 0.7

[Jason Harvey (JIRA)]

Load spikes on coordinators since upgrade from 0.6.8 to 0.7
---

 Key: CASSANDRA-2357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2357
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.7.4
Reporter: Jason Harvey
 Attachments: thread_dump.txt

Since our move from 0.6.8 to 0.7, all of the nodes which speak with clients 
have been having periodic, abrupt load spikes going into the hundreds. We have 
been seeing these load spikes 1 to 2 times per hour on every node which clients 
are speaking with. The load graph for a typical spike: 
http://i.imgur.com/jY8AV.png

I have verified that client connections are not spiking at the same time via 
TCP statistics. I have also verified that we aren't seeing any spikes in 
reads/mutations/etc. 

We were using the DynamicSnitch, but I turned that off as a troubleshooting 
step. The issue was unchanged.

When the spikes occur, the box's responsiveness slows to a crawl so I am unable 
to do much in terms of real-time diagnostics. I was able to get a thread dump a 
few seconds after a spike, which I have attached to this ticket. Not sure if it 
will show anything since I couldn't capture it immediately during the spike.

I should note that David King noticed a similar problem (#2058) when he tried 
moving us from 0.6.8 to 0.6.10. The main issue at the time was a long-lasting 
load spike, but he also saw occasional abrupt load spikes like we are seeing 
now. When we moved back to 0.6.8, we didn't see the problem again, until the 
move to 0.7.

I realize this information is somewhat nebulous. If there is any further info I 
can provide, please let me know. The spikes are causing quite a bit of 
instability, so we are considering retreating back to 0.6.8. I'd like to 
investigate every possible solution before we resort to that.

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

[jira] Commented: (CASSANDRA-2353) JMX call StorageService.Operations.getNaturalEndpoints returns an NPE

[Karl Mueller (JIRA)]

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

Karl Mueller commented on CASSANDRA-2353:
-

I don't have 0.7.4 in my environment.. but when I upgrade to .4 or .5 I'll post 
it.  I think driftx on irc had a newer version.

> JMX call StorageService.Operations.getNaturalEndpoints returns an NPE
> -
>
> Key: CASSANDRA-2353
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2353
> Project: Cassandra
>  Issue Type: Bug
>  Components: API
>Affects Versions: 0.7.0
>Reporter: Karl Mueller
>Priority: Minor
> Fix For: 0.7.5
>
>
> The JMX operation StorageService.Operations.getNaturalEndpoints in 
> cassandra.db always returns an NPE.

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

[jira] Issue Comment Edited: (CASSANDRA-2233) Add unified UUIDType

[Ed Anuff (JIRA)]

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

Ed Anuff edited comment on CASSANDRA-2233 at 3/18/11 9:46 PM:
--

bq.* generalize the type, make it deal with all kinds of variants/versions. 
(http://tools.ietf.org/html/rfc4122)

-I'm not sure how useful the natural order of the other UUID versions is.-  
Minor point of correction, as per [Java bug 
7025832|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7025832], the 
LexicalUUIDType inherits java.util.UUID.compareTo()'s signed comparison flaw, 
since the LexicalUUIDType doesn't do byte comparison, it's converting the bytes 
into java.util.UUIDs and using the UUID class' compareTo() method.  Doing a 
byte comparison would match the rfc, which is reflected in the most recent 
version of patch proposed.

bq.* check if it makes sense to treat the Nil UUID differently (similarly to 
NULL in popular SQL databases).

Yes, it does make sense.  Nil UUID should always compare as less than.


  was (Author: edanuff):
bq.* generalize the type, make it deal with all kinds of variants/versions. 
(http://tools.ietf.org/html/rfc4122)

I'm not sure how useful the natural order of the other UUID versions is.  I 
suppose for everything but version 1 time-based UUID's, we could use DCE's 
comparison rules rather than the current byte comparison used by the lexical 
comparer, that would at least be standard.  
http://www.opengroup.org/onlinepubs/9629399/apdxa.htm#tagtcjh_38

bq.* check if it makes sense to treat the Nil UUID differently (similarly to 
NULL in popular SQL databases).

Yes, it does make sense.  Nil UUID should always compare as less than.

  
> Add unified UUIDType
> 
>
> Key: CASSANDRA-2233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2233
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 0.7.3
>Reporter: Ed Anuff
>Priority: Minor
> Attachments: UUIDType.java, UUIDTypeTest.java
>
>
> Unified UUIDType comparator, compares as time-based if both UUIDs are 
> time-based, otherwise uses byte comparison.  Based on code from the current 
> LexicalUUIDType and TimeUUIDType comparers, so performance and behavior 
> should be consistent and compatible.

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

[jira] Updated: (CASSANDRA-2354) CLI should allow users to chose consistency level

[Edward Capriolo (JIRA)]

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

Edward Capriolo updated CASSANDRA-2354:
---

Description: Currently the CLI runs at CL.ONE. If the CLI can operate at 
other levels it makes it easier to test multi-dc and failure scenarios  (was: 
Currently the CLI runs at CL.ONE. If the CLI can operate at other levels it 
makes it easier to test multi-dc in failure scenarios)

> CLI should allow users to chose consistency level
> -
>
> Key: CASSANDRA-2354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2354
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Affects Versions: 0.7.0
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: CASSANDRA-2354-v4.patch, cassandra-2354-1.patch.txt, 
> cassandra-2354-2.patch.txt, cassandra-2354-3.patch.txt
>
>
> Currently the CLI runs at CL.ONE. If the CLI can operate at other levels it 
> makes it easier to test multi-dc and failure scenarios

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

[jira] Commented: (CASSANDRA-2354) CLI should allow users to chose consistency level

[Edward Capriolo (JIRA)]

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

Edward Capriolo commented on CASSANDRA-2354:


+1 on ConsistencyLevel.valueOf(). That makes the code more future proof.

> CLI should allow users to chose consistency level
> -
>
> Key: CASSANDRA-2354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2354
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Affects Versions: 0.7.0
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: CASSANDRA-2354-v4.patch, cassandra-2354-1.patch.txt, 
> cassandra-2354-2.patch.txt, cassandra-2354-3.patch.txt
>
>
> Currently the CLI runs at CL.ONE. If the CLI can operate at other levels it 
> makes it easier to test multi-dc in failure scenarios

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

[jira] Updated: (CASSANDRA-2316) NoSuchElement exception on node which is streaming a repair

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-2316:
--

Attachment: 2316-assert.txt

proposed assert attached

> NoSuchElement exception on node which is streaming a repair
> ---
>
> Key: CASSANDRA-2316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2316
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 0.6
>Reporter: Jason Harvey
>Assignee: Stu Hood
>  Labels: repair
> Fix For: 0.7.5
>
> Attachments: 2316-assert.txt
>
>
> Running latest SVN snapshot of 0.7.
> When I ran a repair on a node, that node's neighbor threw the following 
> exception. Let me know what other info could be helpful.
> {code}
>  INFO 23:43:44,358 Streaming to /10.251.166.15
> ERROR 23:50:21,321 Fatal exception in thread 
> Thread[CompactionExecutor:1,1,main]
> java.util.NoSuchElementException
> at 
> com.google.common.collect.AbstractIterator.next(AbstractIterator.java:146)
> at 
> org.apache.cassandra.service.AntiEntropyService$Validator.add(AntiEntropyService.java:366)
> at 
> org.apache.cassandra.db.CompactionManager.doValidationCompaction(CompactionManager.java:825)
> at 
> org.apache.cassandra.db.CompactionManager.access$800(CompactionManager.java:56)
> at 
> org.apache.cassandra.db.CompactionManager$6.call(CompactionManager.java:358)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> {code}

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

[jira] Updated: (CASSANDRA-2354) CLI should allow users to chose consistency level

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich updated CASSANDRA-2354:
---

Attachment: CASSANDRA-2354-v4.patch

Minor change in the executeConsistencyLevelStatement, changed all if/else to 
ConsistencyLevel.valueOf(), +1 now

> CLI should allow users to chose consistency level
> -
>
> Key: CASSANDRA-2354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2354
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Affects Versions: 0.7.0
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: CASSANDRA-2354-v4.patch, cassandra-2354-1.patch.txt, 
> cassandra-2354-2.patch.txt, cassandra-2354-3.patch.txt
>
>
> Currently the CLI runs at CL.ONE. If the CLI can operate at other levels it 
> makes it easier to test multi-dc in failure scenarios

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

[jira] Commented: (CASSANDRA-2269) OOM in the Thrift thread doesn't shut down server

[Hudson (JIRA)]

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

Hudson commented on CASSANDRA-2269:
---

Integrated in Cassandra-0.6 #63 (See 
[https://hudson.apache.org/hudson/job/Cassandra-0.6/63/])


> OOM in the Thrift thread doesn't shut down server
> -
>
> Key: CASSANDRA-2269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2269
> Project: Cassandra
>  Issue Type: Bug
>  Components: API
>Affects Versions: 0.6
>Reporter: Jonathan Ellis
>Assignee: Jonathan Ellis
>Priority: Minor
> Fix For: 0.6.13, 0.7.5
>
> Attachments: 2269-0.6.txt
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> Example:
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> at 
> org.cliffc.high_scale_lib.NonBlockingHashMap$CHM.resize(NonBlockingHashMap.java:849)
> at 
> org.cliffc.high_scale_lib.NonBlockingHashMap$CHM.access$200(NonBlockingHashMap.java:699)
> at 
> org.cliffc.high_scale_lib.NonBlockingHashMap.putIfMatch(NonBlockingHashMap.java:634)
> at 
> org.cliffc.high_scale_lib.NonBlockingHashMap.putIfMatch(NonBlockingHashMap.java:339)
> at 
> org.cliffc.high_scale_lib.NonBlockingHashMap.put(NonBlockingHashMap.java:302)
> at org.apache.cassandra.utils.ExpiringMap.put(ExpiringMap.java:112)
> at 
> org.apache.cassandra.net.MessagingService.addCallback(MessagingService.java:237)
> at 
> org.apache.cassandra.net.MessagingService.sendRR(MessagingService.java:305)
> at 
> org.apache.cassandra.service.StorageProxy.weakRead(StorageProxy.java:386)
> at 
> org.apache.cassandra.service.StorageProxy.readProtocol(StorageProxy.java:347)
> at 
> org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:92)
> at 
> org.apache.cassandra.thrift.CassandraServer.getSlice(CassandraServer.java:175)
> at 
> org.apache.cassandra.thrift.CassandraServer.multigetSliceInternal(CassandraServer.java:254)
> at 
> org.apache.cassandra.thrift.CassandraServer.get_slice(CassandraServer.java:215)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$get_slice.process(Cassandra.java:1272)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:1166)
> at 
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}

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

[jira] Updated: (CASSANDRA-2354) CLI should allow users to chose consistency level

[Edward Capriolo (JIRA)]

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

Edward Capriolo updated CASSANDRA-2354:
---

Attachment: cassandra-2354-3.patch.txt

Removed not needed this.(s). Added completer support. 

> CLI should allow users to chose consistency level
> -
>
> Key: CASSANDRA-2354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2354
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Affects Versions: 0.7.0
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: cassandra-2354-1.patch.txt, cassandra-2354-2.patch.txt, 
> cassandra-2354-3.patch.txt
>
>
> Currently the CLI runs at CL.ONE. If the CLI can operate at other levels it 
> makes it easier to test multi-dc in failure scenarios

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

[jira] Commented: (CASSANDRA-2346) Windows: SSTableWriterTest Fails

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-2346:
---

My guess is, this part of closeAndOpenReader just prior to the delete attempt 
is responsible:

{code}
SegmentedFile ifile = 
iwriter.builder.complete(newdesc.filenameFor(SSTable.COMPONENT_INDEX));
SegmentedFile dfile = 
dbuilder.complete(newdesc.filenameFor(SSTable.COMPONENT_DATA));
SSTableReader sstable = SSTableReader.internalOpen(newdesc, components, 
metadata, partitioner, ifile, dfile, iwriter.summary, iwriter.bf, maxDataAge, 
estimatedRowSize, estimatedColumnCount);
{code}

In particular, iwriter.builder.complete mmap's the index file, which for 
Windows also counts as having an open fd.  A reference to the mmap'd segments 
is retained by the returned sstable.

A nasty hack that MIGHT work (depending on GC to clean things up is awful) 
would be to change the test to something like

{code}
// avoid retaining a reference to the returned sstable
Descriptor descriptor = 
SSTableUtils.prepare().cf("Indexed1").writeRaw(entries).descriptor;
// clean up mmap'd segments in the reader we just created so Windows 
allows deleting the backing file
System.gc();
// whack the index to trigger the recover

FileUtils.deleteWithConfirm(descriptor.filenameFor(Component.PRIMARY_INDEX));
FileUtils.deleteWithConfirm(descriptor.filenameFor(Component.FILTER));
{code}

A cleaner approach would be to ditch SSTableUtils (not my favorite class to 
begin with), expose a method in SSTWriter that just does data appends (no 
index) and create just the data file that way, instead of trying to delete the 
supporting files later.

An in-between approach might be to create a SSTW close() method that just 
returns the descriptor after shutting things down, without opening the 
problematic reader.  Then the test would work as-is.

> Windows: SSTableWriterTest Fails
> 
>
> Key: CASSANDRA-2346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 0.7.4
> Environment: Windows
>Reporter: Benjamin Coverston
>  Labels: windows
> Fix For: 0.7.5
>
>
> Fails with the following exception[1]
> Which looks like there's a stream keeping this file open somewhere.
> I looked for the culprit, but I was unable to identify it. Following it 
> through it appears that if the following two lines of code are executed from 
> IndexWriter.afterAppend:
> ByteBufferUtil.writeWithShortLength(key.key, indexFile);
> indexFile.writeLong(dataPosition);
> Then the indexFile gets touched and that generally triggers this situation. 
> One thing interesting here is that an index file without any rows will 
> trigger a divide by zero exception [2].
> I looked at this quite a bit without being able to make much progress.
> [1]
> java.io.IOException: Failed to delete 
> C:\Users\Ben\AppData\Local\Temp\Keyspace12505092819180437091Indexed1\Keyspace1\Indexed1-f-0-Index.db
>   at 
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:51)
>   at 
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:41)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriterTest.testRecoverAndOpen(SSTableWriterTest.java:79)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
>   at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 

[jira] Updated: (CASSANDRA-2346) Windows: SSTableWriterTest Fails

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-2346:
--

  Component/s: Tests
 Priority: Minor  (was: Major)
Fix Version/s: 0.7.5
 Assignee: Benjamin Coverston

> Windows: SSTableWriterTest Fails
> 
>
> Key: CASSANDRA-2346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 0.7.4
> Environment: Windows
>Reporter: Benjamin Coverston
>Assignee: Benjamin Coverston
>Priority: Minor
>  Labels: windows
> Fix For: 0.7.5
>
>
> Fails with the following exception[1]
> Which looks like there's a stream keeping this file open somewhere.
> I looked for the culprit, but I was unable to identify it. Following it 
> through it appears that if the following two lines of code are executed from 
> IndexWriter.afterAppend:
> ByteBufferUtil.writeWithShortLength(key.key, indexFile);
> indexFile.writeLong(dataPosition);
> Then the indexFile gets touched and that generally triggers this situation. 
> One thing interesting here is that an index file without any rows will 
> trigger a divide by zero exception [2].
> I looked at this quite a bit without being able to make much progress.
> [1]
> java.io.IOException: Failed to delete 
> C:\Users\Ben\AppData\Local\Temp\Keyspace12505092819180437091Indexed1\Keyspace1\Indexed1-f-0-Index.db
>   at 
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:51)
>   at 
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:41)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriterTest.testRecoverAndOpen(SSTableWriterTest.java:79)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
>   at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:97)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:196)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:65)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)
> [2]
> ERROR 16:57:48,119 Error in ThreadPoolExecutor
> java.lang.ArithmeticException: / by zero
>   at 
> org.apache.cassandra.io.sstable.SSTable.estimateRowsFromData(SSTable.java:218)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:291)
>   at 
> org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:942)
>   at 
> org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:935)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:619)
> java.util.concurrent.ExecutionException: java.lang.Arithmetic

[jira] Updated: (CASSANDRA-2212) Cannot get range slice of super columns in reversed order

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-2212:
--

Affects Version/s: (was: 0.7.2)
   0.6
Fix Version/s: 0.6.13

committed for 0.6.13

> Cannot get range slice of super columns in reversed order
> -
>
> Key: CASSANDRA-2212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2212
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 0.6
> Environment: Fedore 11, Intel Core i5
>Reporter: Muga Nishizawa
>Assignee: Sylvain Lebresne
> Fix For: 0.6.13, 0.7.3
>
> Attachments: 0001-Fix-IndexHelp.indexFor-for-reverse-query.patch, 
> 2212_0.6.patch, cassandra_sample_insert.py, cassandra_sample_rangeslice.py, 
> create_table.cli
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> I cannot get range slice of super columns in reversed order.  These data are 
> stored in Cassandra in advance.  On the other hand, range slice of these data 
> in normal order can be acquired.
> You can reproduce the bug by executing attached programs.  
> - 1. Start Cassandra daemon on localhost (number of thrift port is 9160)
> - 2. Create keyspace and column family, according to "create_table.cli", 
> - 3. Execute "cassandra_sample_insert.py", storing pairs of row keys and 
> super columns
> - 4. Execute "cassandra_sample_rangeslice.py" and get range slice of stored 
> super columns
> "cassandra_sample_insert.py" and "cassandra_sample_rangeslice.py" require 
> pycassa.  
> You will need to execute 4."cassandra_sample_rangeslice.py" with following 
> options so that you get range slice of super columns in reversed order.  
>  % python cassandra_sample_rangeslice.py -r 00082 00083
> On the other hand, to get range slice in normal order, you will need to use 
> following options.  
>  % python cassandra_sample_rangeslice.py -f 00082 00083
> 00082 and 00083 are the specified key range.  Range slice can be acquired in 
> normal order but, I cannot get it in reversed order.  
> I assume that there may be a bug within the code for acquiring the index 
> block of specified range.  In fact, 00083 is included in gap between lastName 
> of index block and firstName of next index block.   

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

svn commit: r1083000 - in /cassandra/branches/cassandra-0.6: CHANGES.txt src/java/org/apache/cassandra/db/filter/SSTableNamesIterator.java src/java/org/apache/cassandra/db/filter/SSTableSliceIterator.

[jbellis]

Author: jbellis
Date: Fri Mar 18 18:10:58 2011
New Revision: 1083000

URL: http://svn.apache.org/viewvc?rev=1083000&view=rev
Log:
fix reversed slices on large supercolumn rows

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

cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableNamesIterator.java

cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableSliceIterator.java

cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/io/IndexHelper.java

Modified: cassandra/branches/cassandra-0.6/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/CHANGES.txt?rev=1083000&r1=1082999&r2=1083000&view=diff
==
--- cassandra/branches/cassandra-0.6/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.6/CHANGES.txt Fri Mar 18 18:10:58 2011
@@ -1,5 +1,6 @@
 0.6.13
  * shut down server for OOM on a Thrift thread (CASSANDRA-2269)
+ * fix reversed slices on large supercolumn rows (CASSANDRA-2212)
 
 
 0.6.12

Modified: 
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableNamesIterator.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableNamesIterator.java?rev=1083000&r1=1082999&r2=1083000&view=diff
==
--- 
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableNamesIterator.java
 (original)
+++ 
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableNamesIterator.java
 Fri Mar 18 18:10:58 2011
@@ -80,7 +80,7 @@ public class SSTableNamesIterator extend
 
 /* get the various column ranges we have to read */
 AbstractType comparator = ssTable.getColumnComparator();
-SortedSet ranges = new 
TreeSet(IndexHelper.getComparator(comparator));
+SortedSet ranges = new 
TreeSet(IndexHelper.getComparator(comparator, false));
 for (byte[] name : filteredColumnNames)
 {
 int index = IndexHelper.indexFor(name, indexList, comparator, 
false);

Modified: 
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableSliceIterator.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableSliceIterator.java?rev=1083000&r1=1082999&r2=1083000&view=diff
==
--- 
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableSliceIterator.java
 (original)
+++ 
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/filter/SSTableSliceIterator.java
 Fri Mar 18 18:10:58 2011
@@ -139,8 +139,6 @@ class SSTableSliceIterator extends Abstr
 
 file.mark();
 curRangeIndex = IndexHelper.indexFor(startColumn, indexes, 
comparator, reversed);
-if (reversed && curRangeIndex == indexes.size())
-curRangeIndex--;
 }
 
 public ColumnFamily getEmptyColumnFamily()

Modified: 
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/io/IndexHelper.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/io/IndexHelper.java?rev=1083000&r1=1082999&r2=1083000&view=diff
==
--- 
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/io/IndexHelper.java
 (original)
+++ 
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/io/IndexHelper.java
 Fri Mar 18 18:10:58 2011
@@ -103,26 +103,39 @@ public class IndexHelper
 
 /**
  * the index of the IndexInfo in which @name will be found.
- * If the index is @indexList.size(), the @name appears nowhere.
+ * If the index is @indexList.size() or -1, the @name appears nowhere.
  */
 public static int indexFor(byte[] name, List indexList, 
AbstractType comparator, boolean reversed)
 {
 if (name.length == 0 && reversed)
 return indexList.size() - 1;
 IndexInfo target = new IndexInfo(name, name, 0, 0);
-int index = Collections.binarySearch(indexList, target, 
getComparator(comparator));
-return index < 0 ? -1 * (index + 1) : index;
+int index = Collections.binarySearch(indexList, target, 
getComparator(comparator, reversed));
+return index < 0 ? -index - (reversed ? 2 : 1) : index;
 }
 
-public static Comparator getComparator(final AbstractType 
nameComparator)
+public static Comparator getComparator(final AbstractType 
nameComparator, boolean reversed)
 {
-return new Comparator()
+if (reversed)
 {
-public int compare(IndexInfo o1, IndexInfo o2)
+return new Comparator()
 {
-return nam

[jira] Issue Comment Edited: (CASSANDRA-2341) Cli support for counters

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich edited comment on CASSANDRA-2341 at 3/18/11 5:51 PM:
-

Patch looks good to me but please add new statements to the CliTest before this 
can be committed. Also, please add new commands to the CliCompleter, so we can 
get autocomplete for them.

  was (Author: xedin):
Patch looks good to me but please add new statements to the CliTest before 
this can be committed.
  
> Cli support for counters
> 
>
> Key: CASSANDRA-2341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2341
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 0.8
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.8
>
> Attachments: 0001-Add-counter-support-to-cli.patch
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> The cli should have support for counters operation

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

[jira] Commented: (CASSANDRA-2354) CLI should allow users to chose consistency level

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich commented on CASSANDRA-2354:


Few notes: 

1. we are trying to avoid unnecessary "this." usage; 
2. executeConsistencyLevelStatement method should not require from user to be 
logged into keyspace, so !hasKeySpace() is not needed. 
3. please add this command to the CliCompleter, so we can get autocomplete.

> CLI should allow users to chose consistency level
> -
>
> Key: CASSANDRA-2354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2354
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Affects Versions: 0.7.0
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: cassandra-2354-1.patch.txt, cassandra-2354-2.patch.txt
>
>
> Currently the CLI runs at CL.ONE. If the CLI can operate at other levels it 
> makes it easier to test multi-dc in failure scenarios

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

[jira] Created: (CASSANDRA-2356) make the debian package never start by default

[Jeremy Hanna (JIRA)]

make the debian package never start by default
--

 Key: CASSANDRA-2356
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2356
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jeremy Hanna
Priority: Minor


Currently the debian package that installs cassandra starts cassandra by 
default.  It sounds like that is a standard debian packaging convention.  
However, if you want to bootstrap a new node and want to configure it before it 
creates any sort of state information, it's a pain.  I would think that the 
common use case would be to have it install all of the init scripts and such 
but *not* have it start up by default.  That way an admin can configure 
cassandra with seed, token, host, etc. information and then start it.  That 
makes it easier to programmatically do this as well - have chef/puppet install 
cassandra, do some configuration, then do the service start.

With the current setup, it sounds like cassandra creates state on startup that 
has to be cleaned before a new configuration can take effect.  So the process 
of installing turns into:
* install debian package
* shutdown cassandra
* clean out state (data/log dirs)
* configure cassandra
* start cassandra

That seems suboptimal for the default case, especially when trying to automate 
new nodes being bootstrapped.

Another case might be when a downed node comes back up and starts by default 
and tries to claim a token that has already been claimed by another newly 
bootstrapped node.  Rob is more familiar with that case so I'll let him explain 
it in the comments.

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

[jira] Commented: (CASSANDRA-2341) Cli support for counters

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich commented on CASSANDRA-2341:


Patch looks good to me but please add new statements to the CliTest before this 
can be committed.

> Cli support for counters
> 
>
> Key: CASSANDRA-2341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2341
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 0.8
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.8
>
> Attachments: 0001-Add-counter-support-to-cli.patch
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> The cli should have support for counters operation

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

[jira] Commented: (CASSANDRA-2355) Have an easy way to define the reverse comparator of any comparator

[Ed Anuff (JIRA)]

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

Ed Anuff commented on CASSANDRA-2355:
-

In Cassandra-2231 it was suggested that this be implemented by making 
comparators parameterizable.  The idea would be to perhaps replace 
FBUtilities.getComparator() with a ComparatorFactory that could be passed 
something like "UUIDType(restrictTo=time,sort=desc)" and parse out the 
parameters in order to construct the instance.  For Cassandra-2231, the 
proposed patch requires that FBUtilities.getComparator() caches and returns the 
same singleton comparator instances, so that requesting "UUIDType" will always 
return the same instance.  It would be necessary to cache the parameterized 
version in a similar way, and would probably need to be able to know that 
"UUIDType(restrictTo=time,sort=desc)" and "UUIDType(sort=desc,restrictTo=time)" 
should return the same cached comparator.

> Have an easy way to define the reverse comparator of any comparator
> ---
>
> Key: CASSANDRA-2355
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2355
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Minor
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>


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

[jira] Commented: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-2231:
-

bq. For parameterized behavior of comparators, my assumption is that this would 
work within the DynamicCompositeType as well?

It would.

bq. but ultimately we'd need a more robust comparator factory

That's the idea. I intent to add this as part of CASSANDRA-2355.

> Add CompositeType comparer to the comparers provided in 
> org.apache.cassandra.db.marshal
> ---
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Contrib
>Affects Versions: 0.7.3
>Reporter: Ed Anuff
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
> 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip
>
>
> CompositeType is a custom comparer that makes it possible to create 
> comparable composite values out of the basic types that Cassandra currently 
> supports, such as Long, UUID, etc.  This is very useful in both the creation 
> of custom inverted indexes using columns in a skinny row, where each column 
> name is a composite value, and also when using Cassandra's built-in secondary 
> index support, where it can be used to encode the values in the columns that 
> Cassandra indexes.  One scenario for the usage of these is documented here: 
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
> contribution is attached and has been previously maintained on github here: 
> https://github.com/edanuff/CassandraCompositeType

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

[jira] Commented: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

[Ed Anuff (JIRA)]

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

Ed Anuff commented on CASSANDRA-2231:
-

For parameterized behavior of comparators, my assumption is that this would 
work within the DynamicCompositeType as well?  I'll add this to Cassandra-2235, 
but I'm thinking about the embedded comparator names in the dynamic format.  
Right now, you're simply calling FBUtilities.getComparator() with the name, but 
ultimately we'd need a more robust comparator factory that could be passed 
something like "UUIDType(restrictTo=time,sort=desc)" and parse out the 
parameters in order to construct the instance and was able to cache the 
parameterized version in a similar way to how your patch currently caches the 
comparators it instantiates, and would probably need to be able to know that 
"UUIDType(restrictTo=time,sort=desc)" and "UUIDType(sort=desc,restrictTo=time)" 
are the same comparator.

> Add CompositeType comparer to the comparers provided in 
> org.apache.cassandra.db.marshal
> ---
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Contrib
>Affects Versions: 0.7.3
>Reporter: Ed Anuff
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
> 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip
>
>
> CompositeType is a custom comparer that makes it possible to create 
> comparable composite values out of the basic types that Cassandra currently 
> supports, such as Long, UUID, etc.  This is very useful in both the creation 
> of custom inverted indexes using columns in a skinny row, where each column 
> name is a composite value, and also when using Cassandra's built-in secondary 
> index support, where it can be used to encode the values in the columns that 
> Cassandra indexes.  One scenario for the usage of these is documented here: 
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
> contribution is attached and has been previously maintained on github here: 
> https://github.com/edanuff/CassandraCompositeType

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

[jira] Resolved: (CASSANDRA-2230) Allow to specify ConsistencyLevel in cassandra-cli

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis resolved CASSANDRA-2230.
---

Resolution: Duplicate
  Assignee: (was: Norman Maurer)

CASSANDRA-2354 got a patch first

> Allow to specify ConsistencyLevel in cassandra-cli
> --
>
> Key: CASSANDRA-2230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2230
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Norman Maurer
>Priority: Minor
>
> At the moment when using cassandra-cli all operations are done with 
> ConsistencyLevel.ONE. This works well but I think it would be overall useful 
> to allow to override this ConsistencyLevel on per command basis. 

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

svn commit: r1082953 - /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java

[eevans]

Author: eevans
Date: Fri Mar 18 15:29:52 2011
New Revision: 1082953

URL: http://svn.apache.org/viewvc?rev=1082953&view=rev
Log:
retain default validation when creating indexes

Patch by eevans

Modified:
cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java

Modified: cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java?rev=1082953&r1=1082952&r2=1082953&view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java 
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java Fri 
Mar 18 15:29:52 2011
@@ -707,7 +707,9 @@ public class QueryProcessor
 else
 {
 columnDef = new ColumnDefinition(columnName,
- null,
+ 
DatabaseDescriptor.getValueValidator(keyspace,
+   
   createIdx.getColumnFamily(),
+   
   columnName),
  
org.apache.cassandra.thrift.IndexType.KEYS,
  createIdx.getIndexName());
 }

svn commit: r1082952 - /cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java

[eevans]

Author: eevans
Date: Fri Mar 18 15:29:47 2011
New Revision: 1082952

URL: http://svn.apache.org/viewvc?rev=1082952&view=rev
Log:
make utf8 default comparator/validator for CQL (not ascii)

Patch by eevans

Modified:

cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java

Modified: 
cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java?rev=1082952&r1=1082951&r2=1082952&view=diff
==
--- 
cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java
 (original)
+++ 
cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java
 Fri Mar 18 15:29:47 2011
@@ -210,8 +210,8 @@ public class CreateColumnFamilyStatement
 try
 {
 // RPC uses BytesType as the default validator/comparator but 
BytesType expects hex for string terms, (not convenient).
-AbstractType comparator = 
DatabaseDescriptor.getComparator(comparators.get(getPropertyString(KW_COMPARATOR,
 "ascii")));
-String validator = getPropertyString(KW_DEFAULTVALIDATION, 
"ascii");
+AbstractType comparator = 
DatabaseDescriptor.getComparator(comparators.get(getPropertyString(KW_COMPARATOR,
 "utf8")));
+String validator = getPropertyString(KW_DEFAULTVALIDATION, "utf8");
 
 newCFMD = new CFMetaData(keyspace,
  name,

[jira] Commented: (CASSANDRA-2352) zero-length strings should result in zero-length ByteBuffers

[Eric Evans (JIRA)]

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

Eric Evans commented on CASSANDRA-2352:
---

bq. Does this mean empty strings will validate as column names?

The {{AbstractType.validate()}} methods already allow this.  As Jonathan says, 
wherever that's not acceptable, {{ThriftValidation}} has tests to ensure 
name.remaining() != 0.

> zero-length strings should result in zero-length ByteBuffers
> 
>
> Key: CASSANDRA-2352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2352
> Project: Cassandra
>  Issue Type: Bug
>  Components: API, Core
>Reporter: Eric Evans
>Assignee: Eric Evans
>  Labels: cql
> Fix For: 0.8
>
> Attachments: 
> v1-0001-CASSANDRA-2352-AT.fromString-should-return-empty-BB-fo.txt
>
>
> The {{o.a.c.db.marshal.AbstractType.fromString()}} methods should return an 
> empty {{ByteBuffer}} when passed a zero-length string, (empty bytes do 
> {{validate()}} properly).

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

[jira] Updated: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-2231:


Attachment: 0001-Add-compositeType-and-DynamicCompositeType.patch

Patch rebased (against 0.7)

> Add CompositeType comparer to the comparers provided in 
> org.apache.cassandra.db.marshal
> ---
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Contrib
>Affects Versions: 0.7.3
>Reporter: Ed Anuff
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
> 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip
>
>
> CompositeType is a custom comparer that makes it possible to create 
> comparable composite values out of the basic types that Cassandra currently 
> supports, such as Long, UUID, etc.  This is very useful in both the creation 
> of custom inverted indexes using columns in a skinny row, where each column 
> name is a composite value, and also when using Cassandra's built-in secondary 
> index support, where it can be used to encode the values in the columns that 
> Cassandra indexes.  One scenario for the usage of these is documented here: 
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
> contribution is attached and has been previously maintained on github here: 
> https://github.com/edanuff/CassandraCompositeType

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

[jira] Updated: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-2231:


Attachment: (was: 0001-Add-compositeType-and-DynamicCompositeType.patch)

> Add CompositeType comparer to the comparers provided in 
> org.apache.cassandra.db.marshal
> ---
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Contrib
>Affects Versions: 0.7.3
>Reporter: Ed Anuff
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
> 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip
>
>
> CompositeType is a custom comparer that makes it possible to create 
> comparable composite values out of the basic types that Cassandra currently 
> supports, such as Long, UUID, etc.  This is very useful in both the creation 
> of custom inverted indexes using columns in a skinny row, where each column 
> name is a composite value, and also when using Cassandra's built-in secondary 
> index support, where it can be used to encode the values in the columns that 
> Cassandra indexes.  One scenario for the usage of these is documented here: 
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
> contribution is attached and has been previously maintained on github here: 
> https://github.com/edanuff/CassandraCompositeType

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

[jira] Commented: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-2231:
-

I've removed myself as reviewer as I don't think it make sense for me to review 
my code. Imho, this can go into 0.7, given how little interaction this has with 
existing code.

> Add CompositeType comparer to the comparers provided in 
> org.apache.cassandra.db.marshal
> ---
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Contrib
>Affects Versions: 0.7.3
>Reporter: Ed Anuff
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
> 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip
>
>
> CompositeType is a custom comparer that makes it possible to create 
> comparable composite values out of the basic types that Cassandra currently 
> supports, such as Long, UUID, etc.  This is very useful in both the creation 
> of custom inverted indexes using columns in a skinny row, where each column 
> name is a composite value, and also when using Cassandra's built-in secondary 
> index support, where it can be used to encode the values in the columns that 
> Cassandra indexes.  One scenario for the usage of these is documented here: 
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
> contribution is attached and has been previously maintained on github here: 
> https://github.com/edanuff/CassandraCompositeType

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

[jira] Commented: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-2231:
-

That would be better solved by having reversed comparator for all comparators, 
and I would much prefer a general way to define a reversed comparator.  That 
is, for instance, you could declare comparator=LongType(order=desc).  Having a 
way That would be better solved by having reversed comparator for all 
comparators, and I would much prefer having a general way to define a reversed 
comparator. That is, for instance, you could declare 
{{comparator=LongType(order=desc)}}.

That way you don't have to mess with the composite types encoded format (and 
I'm really keen on keeping it as simple as possible). Plus have a reversed 
comparator for all comparator is generally useful even outside composite types 
(granted it's a bit less useful for simple types since you can always query in 
reverse, but reverse queries are probably a bit slower due to reverse seeks).

Even more generally, I think being able to parametrize the behavior of 
comparators is genuinely useful. For instance, I could see having only one 
comparator for UUIDs (in the spirit of CASSANDRA-2233) and being able to say 
stuffs like 
{noformat}
  comparator=UUIDType // accepts both time based and lexical
  comparator=UUIDType(restrictTo=time)// time based only
  comparator=UUIDType(restrictTo=lexical) // lexical only
{noformat}
or something along those lines.

I've opened CASSANDRA-2355 for doing the reverse part of this.

> Add CompositeType comparer to the comparers provided in 
> org.apache.cassandra.db.marshal
> ---
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Contrib
>Affects Versions: 0.7.3
>Reporter: Ed Anuff
>Priority: Minor
> Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
> 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip
>
>
> CompositeType is a custom comparer that makes it possible to create 
> comparable composite values out of the basic types that Cassandra currently 
> supports, such as Long, UUID, etc.  This is very useful in both the creation 
> of custom inverted indexes using columns in a skinny row, where each column 
> name is a composite value, and also when using Cassandra's built-in secondary 
> index support, where it can be used to encode the values in the columns that 
> Cassandra indexes.  One scenario for the usage of these is documented here: 
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
> contribution is attached and has been previously maintained on github here: 
> https://github.com/edanuff/CassandraCompositeType

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

[jira] Updated: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-2231:


Reviewer:   (was: slebresne)
Assignee: Sylvain Lebresne

> Add CompositeType comparer to the comparers provided in 
> org.apache.cassandra.db.marshal
> ---
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Contrib
>Affects Versions: 0.7.3
>Reporter: Ed Anuff
>Assignee: Sylvain Lebresne
>Priority: Minor
> Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
> 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip
>
>
> CompositeType is a custom comparer that makes it possible to create 
> comparable composite values out of the basic types that Cassandra currently 
> supports, such as Long, UUID, etc.  This is very useful in both the creation 
> of custom inverted indexes using columns in a skinny row, where each column 
> name is a composite value, and also when using Cassandra's built-in secondary 
> index support, where it can be used to encode the values in the columns that 
> Cassandra indexes.  One scenario for the usage of these is documented here: 
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
> contribution is attached and has been previously maintained on github here: 
> https://github.com/edanuff/CassandraCompositeType

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

[jira] Created: (CASSANDRA-2355) Have an easy way to define the reverse comparator of any comparator

[Sylvain Lebresne (JIRA)]

Have an easy way to define the reverse comparator of any comparator
---

 Key: CASSANDRA-2355
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2355
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor




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

[jira] Commented: (CASSANDRA-2279) Tombstones not collected post-repair

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-2279:
-

bq. we'll need a separate patch for 0.6

I don't think 0.6 suffers from the problem fixed by the attached patch. It uses 
CFStore.getFamily() for range slices to do its bidding which handles correctly 
the column family deletion times as far as I can tell.

Which make me think that there could be something else at hand here. I'll have 
a look at Joaquin instructions to try to reproduce what he is seeing. 

> Tombstones not collected post-repair
> 
>
> Key: CASSANDRA-2279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2279
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 0.6
>Reporter: Joaquin Casares
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.6.13, 0.7.5
>
> Attachments: RowIteration-unit-tests.patch, 
> fix-RowIteratorFactory.patch, nodeA.txt, nodeB.txt
>
>
> The keys would only show up in sstables2json and look like this:
> (root@aps4):/opt/cassandra/storage/queue/data/Panama Wed Feb 23 07:24:34am 
> ===> /opt/cassandra/bin/sstable2json Queue-2527-Data.db -k 
> waq:publicMessageIndexingWorkArea:PUM8a65ce95-9d35-4941-928c-dd5965e8b29b 
> 2011-02-23 07:24:43,710 INFO [org.apache.cassandra.config.DatabaseDescriptor] 
> - DiskAccessMode 'auto' determined to be mmap, indexAccessMode is mmap 
> 2011-02-23 07:24:43,972 INFO [org.apache.cassandra.io.SSTableReader] - 
> Opening /opt/cassandra/storage/queue/data/Panama/Queue-2527-Data.db 
> { 
> "waq:publicMessageIndexingWorkArea:PUM8a65ce95-9d35-4941-928c-dd5965e8b29b": 
> [] 
> } 
> (root@aps4):/opt/cassandra/storage/queue/data/Panama Wed Feb 23 07:24:44am 
> ===>
> The steps that I took to reproduce it were:
> Create a keyspace, column family, and a key
> Delete the key on Node 1 using the cli (del cf['key'];)
> Flush 
> Repair on a cluster with more than 1 node
> Wait GCSeconds 
> Compact
> And the empty row would appear on Node 2
> However, when I was able to get rid of the empty rows, I was following these 
> steps on a single machine: 
> Create a keyspace, column family, and a key
> Delete the key
> Flush
> Sample write (writing to some temporary key)
> Deleting the attribute to that temporary key (not the entire key)
> Flush
> Compact
> or these steps:
> Create a keyspace, column family, and a key
> Delete the key
> Flush 
> Wait GCseconds
> Compact

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

[jira] Updated: (CASSANDRA-2212) Cannot get range slice of super columns in reversed order

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-2212:


Attachment: 2212_0.6.patch

Attaching patch against 0.6

> Cannot get range slice of super columns in reversed order
> -
>
> Key: CASSANDRA-2212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2212
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 0.7.2
> Environment: Fedore 11, Intel Core i5
>Reporter: Muga Nishizawa
>Assignee: Sylvain Lebresne
> Fix For: 0.7.3
>
> Attachments: 0001-Fix-IndexHelp.indexFor-for-reverse-query.patch, 
> 2212_0.6.patch, cassandra_sample_insert.py, cassandra_sample_rangeslice.py, 
> create_table.cli
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> I cannot get range slice of super columns in reversed order.  These data are 
> stored in Cassandra in advance.  On the other hand, range slice of these data 
> in normal order can be acquired.
> You can reproduce the bug by executing attached programs.  
> - 1. Start Cassandra daemon on localhost (number of thrift port is 9160)
> - 2. Create keyspace and column family, according to "create_table.cli", 
> - 3. Execute "cassandra_sample_insert.py", storing pairs of row keys and 
> super columns
> - 4. Execute "cassandra_sample_rangeslice.py" and get range slice of stored 
> super columns
> "cassandra_sample_insert.py" and "cassandra_sample_rangeslice.py" require 
> pycassa.  
> You will need to execute 4."cassandra_sample_rangeslice.py" with following 
> options so that you get range slice of super columns in reversed order.  
>  % python cassandra_sample_rangeslice.py -r 00082 00083
> On the other hand, to get range slice in normal order, you will need to use 
> following options.  
>  % python cassandra_sample_rangeslice.py -f 00082 00083
> 00082 and 00083 are the specified key range.  Range slice can be acquired in 
> normal order but, I cannot get it in reversed order.  
> I assume that there may be a bug within the code for acquiring the index 
> block of specified range.  In fact, 00083 is included in gap between lastName 
> of index block and firstName of next index block.   

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

[jira] Commented: (CASSANDRA-2354) CLI should allow users to chose consistency level

[Norman Maurer (JIRA)]

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

Norman Maurer commented on CASSANDRA-2354:
--

This is a duplicate of CASSANDRA-2230. I think once you have committed your 
work you should also close CASSANDRA-2230.

Thanks

> CLI should allow users to chose consistency level
> -
>
> Key: CASSANDRA-2354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2354
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Affects Versions: 0.7.0
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: cassandra-2354-1.patch.txt, cassandra-2354-2.patch.txt
>
>
> Currently the CLI runs at CL.ONE. If the CLI can operate at other levels it 
> makes it easier to test multi-dc in failure scenarios

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

[jira] Updated: (CASSANDRA-2354) CLI should allow users to chose consistency level

[Edward Capriolo (JIRA)]

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

Edward Capriolo updated CASSANDRA-2354:
---

Attachment: cassandra-2354-2.patch.txt

Like the last patch however separate READ|WRITE CONSISTENCY is replaced by a 
single consistency.

> CLI should allow users to chose consistency level
> -
>
> Key: CASSANDRA-2354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2354
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Affects Versions: 0.7.0
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: cassandra-2354-1.patch.txt, cassandra-2354-2.patch.txt
>
>
> Currently the CLI runs at CL.ONE. If the CLI can operate at other levels it 
> makes it easier to test multi-dc in failure scenarios

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

[jira] Resolved: (CASSANDRA-2245) Enable map reduce to use indexes for ColumnFamilyInputFormat

[Mck SembWever (JIRA)]

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

Mck SembWever resolved CASSANDRA-2245.
--

Resolution: Duplicate

As far as i understand CASSANDRA-1125 covers your needs.

> Enable map reduce to use indexes for ColumnFamilyInputFormat
> 
>
> Key: CASSANDRA-2245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2245
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Hadoop
>Affects Versions: 0.7.2
> Environment: Cassandra 0.7 or later and Hadoop 0.20.1 or later
>Reporter: Matt Kennedy
>Priority: Minor
>  Labels: hadoop
> Fix For: 0.8
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Enable the ability to run a MapReduce job that takes a value in an indexed 
> column as a parameter, and use that to select the data that the MapReduce job 
> operates on.  Right now, it looks like this isn't possible because 
> org.apache.cassandra.hadoop.ColumnFamilyRecordReader will only fetch data 
> with get_range_slices, not get_indexed_slices.

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

svn commit: r1082910 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/db/CompactionManager.java src/java/org/apache/cassandra/db/Table.java

[jbellis]

Author: jbellis
Date: Fri Mar 18 13:20:39 2011
New Revision: 1082910

URL: http://svn.apache.org/viewvc?rev=1082910&view=rev
Log:
fix race when iterating CFs during add/drop
patch by jbellis; reviewed by gdusbabek for CASSANDRA-2350

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

cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/Table.java

Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1082910&r1=1082909&r2=1082910&view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Fri Mar 18 13:20:39 2011
@@ -12,6 +12,7 @@
(CASSANDRA-2347)
  * ensure size calculation and write phase of large-row compaction use
the same threshold for TTL expiration (CASSANDRA-2349)
+ * fix race when iterating CFs during add/drop (CASSANDRA-2350)
 
 
 0.7.4

Modified: 
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java?rev=1082910&r1=1082909&r2=1082910&view=diff
==
--- 
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java
 (original)
+++ 
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java
 Fri Mar 18 13:20:39 2011
@@ -372,8 +372,7 @@ public class CompactionManager implement
 {
 for (String ksname : DatabaseDescriptor.getNonSystemTables())
 {
-Table ks = Table.open(ksname);
-for (ColumnFamilyStore cfs : ks.columnFamilyStores.values())
+for (ColumnFamilyStore cfs : 
Table.open(ksname).getColumnFamilyStores())
 cfs.disableAutoCompaction();
 }
 }

Modified: 
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/Table.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/Table.java?rev=1082910&r1=1082909&r2=1082910&view=diff
==
--- 
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/Table.java 
(original)
+++ 
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/Table.java 
Fri Mar 18 13:20:39 2011
@@ -23,10 +23,7 @@ import java.io.IOError;
 import java.io.IOException;
 import java.nio.ByteBuffer;
 import java.util.*;
-import java.util.concurrent.ExecutionException;
-import java.util.concurrent.Future;
-import java.util.concurrent.ScheduledFuture;
-import java.util.concurrent.TimeUnit;
+import java.util.concurrent.*;
 import java.util.concurrent.locks.Lock;
 import java.util.concurrent.locks.ReentrantReadWriteLock;
 
@@ -89,7 +86,7 @@ public class Table
 /* Table name. */
 public final String name;
 /* ColumnFamilyStore per column family */
-public final Map columnFamilyStores = new 
HashMap(); // TODO make private again
+private final Map columnFamilyStores = new 
ConcurrentHashMap();
 private final Object[] indexLocks;
 private ScheduledFuture flushTask;
 private volatile AbstractReplicationStrategy replicationStrategy;

[jira] Commented: (CASSANDRA-2352) zero-length strings should result in zero-length ByteBuffers

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-2352:
---

We have separate checks in ThriftValidation for name.remaining() != 0.

I'm guessing this is to make it easier to do slicing, where empty start is 
valid?

> zero-length strings should result in zero-length ByteBuffers
> 
>
> Key: CASSANDRA-2352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2352
> Project: Cassandra
>  Issue Type: Bug
>  Components: API, Core
>Reporter: Eric Evans
>Assignee: Eric Evans
>  Labels: cql
> Fix For: 0.8
>
> Attachments: 
> v1-0001-CASSANDRA-2352-AT.fromString-should-return-empty-BB-fo.txt
>
>
> The {{o.a.c.db.marshal.AbstractType.fromString()}} methods should return an 
> empty {{ByteBuffer}} when passed a zero-length string, (empty bytes do 
> {{validate()}} properly).

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

[jira] Commented: (CASSANDRA-2350) Races between schema changes and StorageService operations

[Gary Dusbabek (JIRA)]

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

Gary Dusbabek commented on CASSANDRA-2350:
--

+1

> Races between schema changes and StorageService operations
> --
>
> Key: CASSANDRA-2350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2350
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 0.7.0
>Reporter: Jeffrey Wang
>Assignee: Jonathan Ellis
>Priority: Minor
> Fix For: 0.7.5
>
> Attachments: 2350.txt
>
>
> I only tested this on 0.7.0, but it judging by the 0.7.3 code (latest I've 
> looked at) the same thing should happen.
> The case in particular that I ran into is this: I force a compaction for all 
> CFs in a keyspace, and while the compaction is happening I add another CF to 
> the keyspace. I get the following exception because the underlying set of CFs 
> has changed while being iterated over.
> {noformat}
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
> at java.util.HashMap$ValueIterator.next(Unknown Source)
> at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
> at 
> org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1140)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown 
> Source)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown 
> Source)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(Unknown Source)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(Unknown Source)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown 
> Source)
> at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown 
> Source)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown 
> Source)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown 
> Source)
> at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown 
> Source)
> at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> at sun.rmi.transport.Transport$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown 
> Source)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown 
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source) 
> {noformat}
> The problem is a little more fundamental than that, though, as I believe any 
> schema change of CFs in the keyspace during one of these operations (e.g. 
> flush, compaction, etc) has the potential to cause a race. I'm not sure what 
> would happen if the set of CFs to compact was acquired and one of them was 
> dropped before it had been compacted.

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

[jira] Commented: (CASSANDRA-2319) Promote row index

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-2319:
-

bq. Agreed... my point is simply that the number of columns-per-key and the 
number of keys are inversely proportional: if you have more columns-per-key, 
you have less keys, and vice-versa. The index will grow proportionally with the 
total number of columns, not with the number of keys.

I do not share your confidence that this is axiomatic. It is certainly not 
axiomatic to the data model. Anyway, that was just a remark, not a criticism of 
the approach.

bq. Yea... the key cache as it exists does not necessarily need to change, but 
at some point we'll want to update it to include the improvements from this 
ticket.

Maybe there is a misunderstanding here. I assumed that promoting the row index 
implied removing the row index (in the favor of a richer sstable index).  And 
even though a first iteration of this doesn't necessary imply this removal, 
I'll still assume it because I believe this would be weird to keep in the long 
run even if we keep it in the short run.

So if you don't have a row index, caching row key position as the actual key 
cache does will be counter-productive for any non-narrow row, since looking at 
the sstable index would give you closer to the column. So it would make the key 
cache as it exists only useful for narrow row (which makes it less useful 
though not useless).

bq. It depends on the number of unique queries to the row, but I'm willing to 
bet that the number of unique queries to a row is relatively low.

Take time series (which I doubt can be called a niche use case). If the start 
of your slice query depends on the current time, almost all the query will be 
unique. Or if you page on the time series and it have a reasonably high rate of 
inserts, then the pages will be always changing and thus will be your query.  
Given how long it took me to come up with those two examples (that I did 
personally used btw, it's not just my imagination running wild), I suspect 
there is a number of other similar cases.

Will those be a minority of all the queries on wide rows ? I don't know, 
probably for some people but maybe not for others. People come up with new ways 
to use the Cassandra data model all the time, let's not base our reflexion on 
unchecked assumptions of the kind of queries people do.

Is that a big deal considering that in promoting the row index we will be at 2 
seeks for those case but we're already at 2 seeks on a key cache hit ?  
Probably not (though for the pleasure of nitpicking I'll add that the 2 seeks 
in the current case of a key cache hit are closer on disk that how the 2 seeks 
with the promoted index would be).

Am I willing to not keep those case in mind because Stu is willing to bet it 
doesn't matter ? Certainly not (which doesn't mean I don't love you).

Anyways, I'm in favor of trying this (honestly more because I believe this 
could make checksumming and compression easier to add than anything else).

> Promote row index
> -
>
> Key: CASSANDRA-2319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Stu Hood
>Assignee: Stu Hood
>  Labels: index, timeseries
> Fix For: 0.8
>
>
> The row index contains entries for configurably sized blocks of a wide row. 
> For a row of appreciable size, the row index ends up directing the third seek 
> (1. index, 2. row index, 3. content) to nearby the first column of a scan.
> Since the row index is always used for wide rows, and since it contains 
> information that tells us whether or not the 3rd seek is necessary (the 
> column range or name we are trying to slice may not exist in a given 
> sstable), promoting the row index into the sstable index would allow us to 
> drop the maximum number of seeks for wide rows back to 2, and, more 
> importantly, would allow sstables to be eliminated using only the index.
> An example usecase that benefits greatly from this change is time series data 
> in wide rows, where data is appended to the beginning or end of the row. Our 
> existing compaction strategy gets lucky and clusters the oldest data in the 
> oldest sstables: for queries to recently appended data, we would be able to 
> eliminate wide rows using only the sstable index, rather than needing to seek 
> into the data file to determine that it isn't interesting. For narrow rows, 
> this change would have no effect, as they will not reach the threshold for 
> indexing anyway.
> A first cut design for this change would look very similar to the file format 
> design proposed on #674: 
> http://wiki.apache.org/cassandra/FileFormatDesign

[jira] Commented: (CASSANDRA-2212) Cannot get range slice of super columns in reversed order

[Paul R. Brown (JIRA)]

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

Paul R. Brown commented on CASSANDRA-2212:
--

I think that I have a situation where this occurs against 0.6.8 as well.  Is 
this fix suitable for backporting onto 0.6?

> Cannot get range slice of super columns in reversed order
> -
>
> Key: CASSANDRA-2212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2212
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 0.7.2
> Environment: Fedore 11, Intel Core i5
>Reporter: Muga Nishizawa
>Assignee: Sylvain Lebresne
> Fix For: 0.7.3
>
> Attachments: 0001-Fix-IndexHelp.indexFor-for-reverse-query.patch, 
> cassandra_sample_insert.py, cassandra_sample_rangeslice.py, create_table.cli
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> I cannot get range slice of super columns in reversed order.  These data are 
> stored in Cassandra in advance.  On the other hand, range slice of these data 
> in normal order can be acquired.
> You can reproduce the bug by executing attached programs.  
> - 1. Start Cassandra daemon on localhost (number of thrift port is 9160)
> - 2. Create keyspace and column family, according to "create_table.cli", 
> - 3. Execute "cassandra_sample_insert.py", storing pairs of row keys and 
> super columns
> - 4. Execute "cassandra_sample_rangeslice.py" and get range slice of stored 
> super columns
> "cassandra_sample_insert.py" and "cassandra_sample_rangeslice.py" require 
> pycassa.  
> You will need to execute 4."cassandra_sample_rangeslice.py" with following 
> options so that you get range slice of super columns in reversed order.  
>  % python cassandra_sample_rangeslice.py -r 00082 00083
> On the other hand, to get range slice in normal order, you will need to use 
> following options.  
>  % python cassandra_sample_rangeslice.py -f 00082 00083
> 00082 and 00083 are the specified key range.  Range slice can be acquired in 
> normal order but, I cannot get it in reversed order.  
> I assume that there may be a bug within the code for acquiring the index 
> block of specified range.  In fact, 00083 is included in gap between lastName 
> of index block and firstName of next index block.   

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

[jira] Commented: (CASSANDRA-2316) NoSuchElement exception on node which is streaming a repair

[Stu Hood (JIRA)]

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

Stu Hood commented on CASSANDRA-2316:
-

Order matters, because there will be up to 2^16 invalid ranges. If keys arrive 
out of order we will consume ranges that should have contained keys, possibly 
leading us to consume all invalid ranges.

Either way, an assert that keys are arriving in order would be handy here.

> NoSuchElement exception on node which is streaming a repair
> ---
>
> Key: CASSANDRA-2316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2316
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 0.6
>Reporter: Jason Harvey
>Assignee: Stu Hood
>  Labels: repair
> Fix For: 0.7.5
>
>
> Running latest SVN snapshot of 0.7.
> When I ran a repair on a node, that node's neighbor threw the following 
> exception. Let me know what other info could be helpful.
> {code}
>  INFO 23:43:44,358 Streaming to /10.251.166.15
> ERROR 23:50:21,321 Fatal exception in thread 
> Thread[CompactionExecutor:1,1,main]
> java.util.NoSuchElementException
> at 
> com.google.common.collect.AbstractIterator.next(AbstractIterator.java:146)
> at 
> org.apache.cassandra.service.AntiEntropyService$Validator.add(AntiEntropyService.java:366)
> at 
> org.apache.cassandra.db.CompactionManager.doValidationCompaction(CompactionManager.java:825)
> at 
> org.apache.cassandra.db.CompactionManager.access$800(CompactionManager.java:56)
> at 
> org.apache.cassandra.db.CompactionManager$6.call(CompactionManager.java:358)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> {code}

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

[jira] Commented: (CASSANDRA-2352) zero-length strings should result in zero-length ByteBuffers

[Stu Hood (JIRA)]

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

Stu Hood commented on CASSANDRA-2352:
-

Does this mean empty strings will validate as column names?

> zero-length strings should result in zero-length ByteBuffers
> 
>
> Key: CASSANDRA-2352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2352
> Project: Cassandra
>  Issue Type: Bug
>  Components: API, Core
>Reporter: Eric Evans
>Assignee: Eric Evans
>  Labels: cql
> Fix For: 0.8
>
> Attachments: 
> v1-0001-CASSANDRA-2352-AT.fromString-should-return-empty-BB-fo.txt
>
>
> The {{o.a.c.db.marshal.AbstractType.fromString()}} methods should return an 
> empty {{ByteBuffer}} when passed a zero-length string, (empty bytes do 
> {{validate()}} properly).

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