date:20130226

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

Sylvain Lebresne commented on CASSANDRA-2699:
-

bq. I'm pretty sure this means that we should be able to XOR the buckets
together from pre-computed merkle tree SSTable components

No, I don't think that works. Because nodes are certainly not guaranteed to be
at the same state of compaction, even if they have the same data. Meaning that
for a given column whose value A has been overwritten to B at some point, one
of the nodes may have 1 sstable with just B while another node may have 2
sstables, one with A and one with B, because it hasn't compacted things yet.
But hash(B) (on the first node) will not be equal to hash(A) xor hash(B) (on
the second node), even though both node really have the same data (since B
overwrites A upon column merge on the 2nd node).

continuous incremental anti-entropy
---

Key: CASSANDRA-2699
URL: https://issues.apache.org/jira/browse/CASSANDRA-2699
Project: Cassandra
Issue Type: Improvement
Reporter: Peter Schuller
Assignee: Peter Schuller

Currently, repair works by periodically running bulk jobs that (1)
performs a validating compaction building up an in-memory merkle tree,
and (2) streaming ring segments as needed according to differences
indicated by the merkle tree.
There are some disadvantages to this approach:
* There is a trade-off between memory usage and the precision of the
merkle tree. Less precision means more data streamed relative to
what is strictly required.
* Repair is a periodic bulk process that runs for a significant
period and, although possibly rate limited as compaction (if 0.8 or
backported throttling patch applied), is a divergence in terms of
performance characteristics from normal operation of the cluster.
* The impact of imprecision can be huge on a workload dominated by I/O
and with cache locality being critical, since you will suddenly
transfers lots of data to the target node.
I propose a more incremental process whereby anti-entropy is
incremental and continuous over time. In order to avoid being
seek-bound one still wants to do work in some form of bursty fashion,
but the amount of data processed at a time could be sufficiently small
that the impact on the cluster feels a lot more continuous, and that
the page cache allows us to avoid re-reading differing data twice.
Consider a process whereby a node is constantly performing a per-CF
repair operation for each CF. The current state of the repair process
is defined by:
* A starting timestamp of the current iteration through the token
range the node is responsible for.
* A finger indicating the current position along the token ring to
which iteration has completed.
This information, other than being in-memory, could periodically (every
few minutes or something) be stored persistently on disk.
The finger advances by the node selecting the next small bit of the
ring and doing whatever merkling/hashing/checksumming is necessary on
that small part, and then asking neighbors to do the same, and
arranging for neighbors to send the node data for mismatching
ranges. The data would be sent either by way of mutations like with
read repair, or by streaming sstables. But it would be small amounts
of data that will act roughly the same as regular writes for the
perspective of compaction.
Some nice properties of this approach:
* It's always on; no periodic sudden effects on cluster performance.
* Restarting nodes never cancels or breaks anti-entropy.
* Huge compactions of entire CF:s never clog up the compaction queue
(not necessarily a non-issue even with concurrent compactions in
0.8).
* Because we're always operating on small chunks, there is never the
same kind of trade-off for memory use. A merkel tree or similar
could be calculated at a very detailed level potentially. Although
the precision from the perspective of reading from disk would likely
not matter much if we are in page cache anyway, very high precision
could be *very* useful when doing anti-entropy across data centers
on slow links.
There are devils in details, like how to select an appropriate ring
segment given that you don't have knowledge of the data density on
other nodes. But I feel that the overall idea/process seems very
promising.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5251) Hadoop support should be able to work with multiple column families

2013-02-26 Thread Illarion Kovalchuk (JIRA)


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

Illarion Kovalchuk commented on CASSANDRA-5251:
---

Well, in our case we have multiple cf's, keeping different aspects of 
information about same objects. We want to merge them in a single map-reduce 
pass, in a way that mapper gets data from all column families (distinguishing 
them by context.getCurrentSplit()). 

I think you're right and if it causes random I/O, could you please suggest a 
workaround? 

Thank you.

 Hadoop support should be able to work with multiple column families
 ---

 Key: CASSANDRA-5251
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5251
 Project: Cassandra
  Issue Type: Improvement
  Components: Hadoop
Affects Versions: 1.1.0, 1.1.11, 1.2.0, 2.0
Reporter: Illarion Kovalchuk
Priority: Minor
 Attachments: trunk-5251.txt


 This patch affects api, so I changed hadoop example in it. The main 
 difference is that now ColumnFamilyInput format generates splits for all 
 input column families, and ColumnFamilyOutputFormat works not with 
 ListMutation, but with ListPairString,Mutation, where Pair.left is for 
 column family name.
 Thank you

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-1311) Triggers

2013-02-26 Thread Abhijit Dhariya (JIRA)


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

Abhijit Dhariya commented on CASSANDRA-1311:


like to know by when this trigger feature will be available?

 Triggers
 

 Key: CASSANDRA-1311
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
 Project: Cassandra
  Issue Type: New Feature
Reporter: Maxim Grinev
Assignee: Vijay
 Fix For: 2.0

 Attachments: HOWTO-PatchAndRunTriggerExample.txt, 
 HOWTO-PatchAndRunTriggerExample-update1.txt, ImplementationDetails.pdf, 
 ImplementationDetails-update1.pdf, trunk-967053.txt, 
 trunk-984391-update1.txt, trunk-984391-update2.txt


 Asynchronous triggers is a basic mechanism to implement various use cases of 
 asynchronous execution of application code at database side. For example to 
 support indexes and materialized views, online analytics, push-based data 
 propagation.
 Please find the motivation, triggers description and list of applications:
 http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/
 An example of using triggers for indexing:
 http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/
 Implementation details are attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: Fix possible assertion triggered in SliceFromReadCommand

Updated Branches:
  refs/heads/cassandra-1.1 3b98e63dd - 05709f74e


Fix possible assertion triggered in SliceFromReadCommand

patch by slebresne; reviewed by jbellis for CASSANDRA-5284


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

Branch: refs/heads/cassandra-1.1
Commit: 05709f74eda7259f4dcc9cc909cee6f0b8b2dbe9
Parents: 3b98e63
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 26 10:58:05 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 26 10:58:05 2013 +0100

--
 CHANGES.txt|1 +
 .../apache/cassandra/db/SliceFromReadCommand.java  |3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/05709f74/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1fe1160..ff820fd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
 1.1.11
  * cli: Add JMX authentication support (CASSANDRA-5080)
  * nodetool: ability to repair specific range (CASSANDRA-5280)
+ * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
 
 
 1.1.10

http://git-wip-us.apache.org/repos/asf/cassandra/blob/05709f74/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
--
diff --git a/src/java/org/apache/cassandra/db/SliceFromReadCommand.java 
b/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
index be73472..6aaa71e 100644
--- a/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
+++ b/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
@@ -75,10 +75,9 @@ public class SliceFromReadCommand extends ReadCommand
 int maxLiveColumns = handler.getMaxLiveColumns();
 int liveColumnsInRow = row != null ? row.getLiveColumnCount() : 0;
 
-assert maxLiveColumns = count;
 // We generate a retry if at least one node reply with count live 
columns but after merge we have less
 // than the total number of column we are interested in (which may be 
 count on a retry)
-if ((maxLiveColumns == count)  (liveColumnsInRow  
getOriginalRequestedCount()))
+if ((maxLiveColumns = count)  (liveColumnsInRow  
getOriginalRequestedCount()))
 {
 // We asked t (= count) live columns and got l (=liveColumnsInRow) 
ones.
 // From that, we can estimate that on this row, for x requested

[Cassandra Wiki] Trivial Update of PilarXIOD by PilarXIOD

Dear Wiki user,

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

The PilarXIOD page has been changed by PilarXIOD:
http://wiki.apache.org/cassandra/PilarXIOD

New page:
Hey !! I am ARLYNE HOLDER. I reside in Brownsville. My age is 50.BR
I and my sister go to The Valuable School in Memphis. My hobby is Darts. My 
papa name is Charles and he is a Chancellor. My mother is a Sniper.BR
BR
Here is my site: [[http://www.chanelbagsbuild.com|chanel purse]]

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

Updated Branches:
  refs/heads/cassandra-1.2 9d0571acf - 88b9d9516


Merge branch 'cassandra-1.1' into cassandra-1.2

Conflicts:
src/java/org/apache/cassandra/db/SliceFromReadCommand.java


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

Branch: refs/heads/cassandra-1.2
Commit: 88b9d95165b5f83896be740bcfff260ff8e2009d
Parents: 9d0571a 05709f7
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 26 11:02:08 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 26 11:02:08 2013 +0100

--
 CHANGES.txt|6 +-
 .../apache/cassandra/db/SliceFromReadCommand.java  |3 +--
 2 files changed, 2 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/88b9d951/CHANGES.txt
--
diff --cc CHANGES.txt
index 42a6e6d,ff820fd..d4a74c0
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,93 -1,9 +1,89 @@@
 -1.1.11
 - * cli: Add JMX authentication support (CASSANDRA-5080)
 +1.2.3
 +Merged from 1.1:
- ===
   * nodetool: ability to repair specific range (CASSANDRA-5280)
+  * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
  
 +1.2.2
 + * fix potential for multiple concurrent compactions of the same sstables
 +   (CASSANDRA-5256)
 + * avoid no-op caching of byte[] on commitlog append (CASSANDRA-5199)
 + * fix symlinks under data dir not working (CASSANDRA-5185)
 + * fix bug in compact storage metadata handling (CASSANDRA-5189)
 + * Validate login for USE queries (CASSANDRA-5207)
 + * cli: remove default username and password (CASSANDRA-5208)
 + * configure populate_io_cache_on_flush per-CF (CASSANDRA-4694)
 + * allow configuration of internode socket buffer (CASSANDRA-3378)
 + * Make sstable directory picking blacklist-aware again (CASSANDRA-5193)
 + * Correctly expire gossip states for edge cases (CASSANDRA-5216)
 + * Improve handling of directory creation failures (CASSANDRA-5196)
 + * Expose secondary indicies to the rest of nodetool (CASSANDRA-4464)
 + * Binary protocol: avoid sending notification for 0.0.0.0 (CASSANDRA-5227)
 + * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366)
 + * CQL3 refactor to allow conversion function (CASSANDRA-5226)
 + * Fix drop of sstables in some circumstance (CASSANDRA-5232)
 + * Implement caching of authorization results (CASSANDRA-4295)
 + * Add support for LZ4 compression (CASSANDRA-5038)
 + * Fix missing columns in wide rows queries (CASSANDRA-5225)
 + * Simplify auth setup and make system_auth ks alterable (CASSANDRA-5112)
 + * Stop compactions from hanging during bootstrap (CASSANDRA-5244)
 + * fix compressed streaming sending extra chunk (CASSANDRA-5105)
 + * Add CQL3-based implementations of IAuthenticator and IAuthorizer
 +   (CASSANDRA-4898)
 + * Fix timestamp-based tomstone removal logic (CASSANDRA-5248)
 + * cli: Add JMX authentication support (CASSANDRA-5080)
 + * Fix forceFlush behavior (CASSANDRA-5241)
 + * cqlsh: Add username autocompletion (CASSANDRA-5231)
 + * Fix CQL3 composite partition key error (CASSANDRA-5240)
 + * Allow IN clause on last clustering key (CASSANDRA-5230)
 +
 +
 +1.2.1
 + * stream undelivered hints on decommission (CASSANDRA-5128)
 + * GossipingPropertyFileSnitch loads saved dc/rack info if needed 
(CASSANDRA-5133)
 + * drain should flush system CFs too (CASSANDRA-4446)
 + * add inter_dc_tcp_nodelay setting (CASSANDRA-5148)
 + * re-allow wrapping ranges for start_token/end_token range pairing 
(CASSANDRA-5106)
 + * fix validation compaction of empty rows (CASSADRA-5136)
 + * nodetool methods to enable/disable hint storage/delivery (CASSANDRA-4750)
 + * disallow bloom filter false positive chance of 0 (CASSANDRA-5013)
 + * add threadpool size adjustment methods to JMXEnabledThreadPoolExecutor and 
 +   CompactionManagerMBean (CASSANDRA-5044)
 + * fix hinting for dropped local writes (CASSANDRA-4753)
 + * off-heap cache doesn't need mutable column container (CASSANDRA-5057)
 + * apply disk_failure_policy to bad disks on initial directory creation 
 +   (CASSANDRA-4847)
 + * Optimize name-based queries to use ArrayBackedSortedColumns 
(CASSANDRA-5043)
 + * Fall back to old manifest if most recent is unparseable (CASSANDRA-5041)
 + * pool [Compressed]RandomAccessReader objects on the partitioned read path
 +   (CASSANDRA-4942)
 + * Add debug logging to list filenames processed by Directories.migrateFile 
 +   method (CASSANDRA-4939)
 + * Expose black-listed directories via JMX (CASSANDRA-4848)
 + * Log compaction merge counts (CASSANDRA-4894)
 + * Minimize byte array allocation by

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

Updated Branches:
  refs/heads/trunk b096d0bf4 - 7d5490b58


Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: 7d5490b585fd018119a8a4085ca2a572424165f4
Parents: b096d0b 88b9d95
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 26 11:02:46 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 26 11:02:46 2013 +0100

--
 CHANGES.txt|5 +
 .../apache/cassandra/db/SliceFromReadCommand.java  |3 +--
 2 files changed, 2 insertions(+), 6 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7d5490b5/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
--

[1/3] git commit: Fix possible assertion triggered in SliceFromReadCommand

Fix possible assertion triggered in SliceFromReadCommand

patch by slebresne; reviewed by jbellis for CASSANDRA-5284


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

Branch: refs/heads/trunk
Commit: 05709f74eda7259f4dcc9cc909cee6f0b8b2dbe9
Parents: 3b98e63
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 26 10:58:05 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 26 10:58:05 2013 +0100

--
 CHANGES.txt|1 +
 .../apache/cassandra/db/SliceFromReadCommand.java  |3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/05709f74/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1fe1160..ff820fd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
 1.1.11
  * cli: Add JMX authentication support (CASSANDRA-5080)
  * nodetool: ability to repair specific range (CASSANDRA-5280)
+ * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
 
 
 1.1.10

http://git-wip-us.apache.org/repos/asf/cassandra/blob/05709f74/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
--
diff --git a/src/java/org/apache/cassandra/db/SliceFromReadCommand.java 
b/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
index be73472..6aaa71e 100644
--- a/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
+++ b/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
@@ -75,10 +75,9 @@ public class SliceFromReadCommand extends ReadCommand
 int maxLiveColumns = handler.getMaxLiveColumns();
 int liveColumnsInRow = row != null ? row.getLiveColumnCount() : 0;
 
-assert maxLiveColumns = count;
 // We generate a retry if at least one node reply with count live 
columns but after merge we have less
 // than the total number of column we are interested in (which may be 
 count on a retry)
-if ((maxLiveColumns == count)  (liveColumnsInRow  
getOriginalRequestedCount()))
+if ((maxLiveColumns = count)  (liveColumnsInRow  
getOriginalRequestedCount()))
 {
 // We asked t (= count) live columns and got l (=liveColumnsInRow) 
ones.
 // From that, we can estimate that on this row, for x requested

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

Merge branch 'cassandra-1.1' into cassandra-1.2

Conflicts:
src/java/org/apache/cassandra/db/SliceFromReadCommand.java


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

Branch: refs/heads/trunk
Commit: 88b9d95165b5f83896be740bcfff260ff8e2009d
Parents: 9d0571a 05709f7
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Feb 26 11:02:08 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Feb 26 11:02:08 2013 +0100

--
 CHANGES.txt|6 +-
 .../apache/cassandra/db/SliceFromReadCommand.java  |3 +--
 2 files changed, 2 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/88b9d951/CHANGES.txt
--
diff --cc CHANGES.txt
index 42a6e6d,ff820fd..d4a74c0
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,93 -1,9 +1,89 @@@
 -1.1.11
 - * cli: Add JMX authentication support (CASSANDRA-5080)
 +1.2.3
 +Merged from 1.1:
- ===
   * nodetool: ability to repair specific range (CASSANDRA-5280)
+  * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
  
 +1.2.2
 + * fix potential for multiple concurrent compactions of the same sstables
 +   (CASSANDRA-5256)
 + * avoid no-op caching of byte[] on commitlog append (CASSANDRA-5199)
 + * fix symlinks under data dir not working (CASSANDRA-5185)
 + * fix bug in compact storage metadata handling (CASSANDRA-5189)
 + * Validate login for USE queries (CASSANDRA-5207)
 + * cli: remove default username and password (CASSANDRA-5208)
 + * configure populate_io_cache_on_flush per-CF (CASSANDRA-4694)
 + * allow configuration of internode socket buffer (CASSANDRA-3378)
 + * Make sstable directory picking blacklist-aware again (CASSANDRA-5193)
 + * Correctly expire gossip states for edge cases (CASSANDRA-5216)
 + * Improve handling of directory creation failures (CASSANDRA-5196)
 + * Expose secondary indicies to the rest of nodetool (CASSANDRA-4464)
 + * Binary protocol: avoid sending notification for 0.0.0.0 (CASSANDRA-5227)
 + * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366)
 + * CQL3 refactor to allow conversion function (CASSANDRA-5226)
 + * Fix drop of sstables in some circumstance (CASSANDRA-5232)
 + * Implement caching of authorization results (CASSANDRA-4295)
 + * Add support for LZ4 compression (CASSANDRA-5038)
 + * Fix missing columns in wide rows queries (CASSANDRA-5225)
 + * Simplify auth setup and make system_auth ks alterable (CASSANDRA-5112)
 + * Stop compactions from hanging during bootstrap (CASSANDRA-5244)
 + * fix compressed streaming sending extra chunk (CASSANDRA-5105)
 + * Add CQL3-based implementations of IAuthenticator and IAuthorizer
 +   (CASSANDRA-4898)
 + * Fix timestamp-based tomstone removal logic (CASSANDRA-5248)
 + * cli: Add JMX authentication support (CASSANDRA-5080)
 + * Fix forceFlush behavior (CASSANDRA-5241)
 + * cqlsh: Add username autocompletion (CASSANDRA-5231)
 + * Fix CQL3 composite partition key error (CASSANDRA-5240)
 + * Allow IN clause on last clustering key (CASSANDRA-5230)
 +
 +
 +1.2.1
 + * stream undelivered hints on decommission (CASSANDRA-5128)
 + * GossipingPropertyFileSnitch loads saved dc/rack info if needed 
(CASSANDRA-5133)
 + * drain should flush system CFs too (CASSANDRA-4446)
 + * add inter_dc_tcp_nodelay setting (CASSANDRA-5148)
 + * re-allow wrapping ranges for start_token/end_token range pairing 
(CASSANDRA-5106)
 + * fix validation compaction of empty rows (CASSADRA-5136)
 + * nodetool methods to enable/disable hint storage/delivery (CASSANDRA-4750)
 + * disallow bloom filter false positive chance of 0 (CASSANDRA-5013)
 + * add threadpool size adjustment methods to JMXEnabledThreadPoolExecutor and 
 +   CompactionManagerMBean (CASSANDRA-5044)
 + * fix hinting for dropped local writes (CASSANDRA-4753)
 + * off-heap cache doesn't need mutable column container (CASSANDRA-5057)
 + * apply disk_failure_policy to bad disks on initial directory creation 
 +   (CASSANDRA-4847)
 + * Optimize name-based queries to use ArrayBackedSortedColumns 
(CASSANDRA-5043)
 + * Fall back to old manifest if most recent is unparseable (CASSANDRA-5041)
 + * pool [Compressed]RandomAccessReader objects on the partitioned read path
 +   (CASSANDRA-4942)
 + * Add debug logging to list filenames processed by Directories.migrateFile 
 +   method (CASSANDRA-4939)
 + * Expose black-listed directories via JMX (CASSANDRA-4848)
 + * Log compaction merge counts (CASSANDRA-4894)
 + * Minimize byte array allocation by AbstractData{Input,Output} 
(CASSANDRA-5090)
 + * Add SSL support for the

[jira] [Created] (CASSANDRA-5290) Refactor SSL support to make it possible enable without total cluster downtime

Marcus Eriksson created CASSANDRA-5290:
--

 Summary: Refactor SSL support to make it possible enable without 
total cluster downtime
 Key: CASSANDRA-5290
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5290
 Project: Cassandra
  Issue Type: Improvement
Reporter: Marcus Eriksson
Priority: Minor


should be possible by doing something similar to what compression does today:

* node A connects to node B, indicating that it wants SSL
* node A and B upgrade/wrap sockets
* node B must still be able to talk to A (and all other nodes) without SSL

nothing secret is shared during hand shake phase

one difference compared to compression is that after the cluster is rolled 
there must be a way to not allow any non-ssl talk at all to avoid any 
plaintext-communication due to configuration mistakes. this should be doable 
via configuration and perhaps JMX

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5290) Refactor inter-node SSL support to make it possible enable without total cluster downtime


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

Marcus Eriksson updated CASSANDRA-5290:
---

Summary: Refactor inter-node SSL support to make it possible enable without 
total cluster downtime  (was: Refactor SSL support to make it possible enable 
without total cluster downtime)

 Refactor inter-node SSL support to make it possible enable without total 
 cluster downtime
 -

 Key: CASSANDRA-5290
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5290
 Project: Cassandra
  Issue Type: Improvement
Reporter: Marcus Eriksson
Priority: Minor

 should be possible by doing something similar to what compression does today:
 * node A connects to node B, indicating that it wants SSL
 * node A and B upgrade/wrap sockets
 * node B must still be able to talk to A (and all other nodes) without SSL
 nothing secret is shared during hand shake phase
 one difference compared to compression is that after the cluster is rolled 
 there must be a way to not allow any non-ssl talk at all to avoid any 
 plaintext-communication due to configuration mistakes. this should be doable 
 via configuration and perhaps JMX

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5149) Respect slice count even if column expire mid-request


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

Sylvain Lebresne commented on CASSANDRA-5149:
-

bq. I have trouble coming up with a use case for it.

You mean, for querying the expiration time of a column? My own experience with 
TTL leads me to believe that anyone using expiring columns will want to query 
the expiration time at one point or another. I personally had a case where if 
some TTLed columns were read, we were extending the TTL and how long it was 
extended depended on the current expiration time. Or, on the other end of the 
spectrum, wanting to update a column value without extending the TTL. I had 
also a number of case where not all columns had the same TTL, if any, and just 
knowing if the column was an expiring one was necessary (including but not 
limited to checking during development that the code was doing what it was 
supposed to do in terms of setting TTLs).

Also, if we were to transform expiring column to standard column on read, even 
ignoring the fact that we wouldn't be able to return the expiration time to 
clients, you'd have to be careful about read-repair cancelling your TTLs.  

Besides, as said above, especially if it's fix-for 2.0 (and so things like 
this may require a protocol change become largely irrelevant), I think 
normalizing all code on having expiration be based on a time fixed at well know 
places (like we do for gcBefore really) is the right long term solution.

 Respect slice count even if column expire mid-request
 -

 Key: CASSANDRA-5149
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.7.0
Reporter: Sylvain Lebresne
 Fix For: 2.0


 This is a follow-up of CASSANDRA-5099.
 If a column expire just while a slice query is performed, it is possible for 
 replicas to count said column as live but to have the coordinator seeing it 
 as dead when building the final result. The effect that the query might 
 return strictly less columns that the requested slice count even though there 
 is some live columns matching the slice predicate but not returned in the 
 result.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5291) Document how setting internode_{send|recv}_buff_size_in_bytes might give you worse performance


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

Marcus Eriksson updated CASSANDRA-5291:
---

Attachment: 0001-clarify-so_sndbuf.patch

 Document how setting internode_{send|recv}_buff_size_in_bytes might give you 
 worse performance
 --

 Key: CASSANDRA-5291
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5291
 Project: Cassandra
  Issue Type: Improvement
 Environment: linux
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
Priority: Trivial
 Attachments: 0001-clarify-so_sndbuf.patch


 By setting SO_SNDBUF (or RCVBUF) (which is what 
 internode_{send|recv}_buff_size_in_bytes does), the actual buffers will be 
 limited by net.core.wmem_max and net.core.rmem_max which defaults to 131071 
 on Debian, but if you dont set it, it will use net.ipv4.tcp_(w|r)mem which by 
 default has a max value of 4194304.
 So, if you set internode_{send|recv}_buff_size_in_bytes, you will most likely 
 not get the buffer size you want unless you have also tweaked your OS.
 Patch adds a few comments about this. Unsure if it should go in the config 
 file, but it should at least be mentioned somewhere
 see:
 /proc/sys/net/core/wmem_max
 /proc/sys/net/core/rmem_max
 /proc/sys/net/ipv4/tcp_wmem
 /proc/sys/net/ipv4/tcp_rmem
 man tcp

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5291) Document how setting internode_{send|recv}_buff_size_in_bytes might give you worse performance

Marcus Eriksson created CASSANDRA-5291:
--

 Summary: Document how setting 
internode_{send|recv}_buff_size_in_bytes might give you worse performance
 Key: CASSANDRA-5291
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5291
 Project: Cassandra
  Issue Type: Improvement
 Environment: linux
Reporter: Marcus Eriksson
Priority: Trivial
 Attachments: 0001-clarify-so_sndbuf.patch

By setting SO_SNDBUF (or RCVBUF) (which is what 
internode_{send|recv}_buff_size_in_bytes does), the actual buffers will be 
limited by net.core.wmem_max and net.core.rmem_max which defaults to 131071 on 
Debian, but if you dont set it, it will use net.ipv4.tcp_(w|r)mem which by 
default has a max value of 4194304.

So, if you set internode_{send|recv}_buff_size_in_bytes, you will most likely 
not get the buffer size you want unless you have also tweaked your OS.

Patch adds a few comments about this. Unsure if it should go in the config 
file, but it should at least be mentioned somewhere

see:
/proc/sys/net/core/wmem_max
/proc/sys/net/core/rmem_max
/proc/sys/net/ipv4/tcp_wmem
/proc/sys/net/ipv4/tcp_rmem
man tcp

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Trivial Update of ToddIrm by ToddIrm

Dear Wiki user,

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

The ToddIrm page has been changed by ToddIrm:
http://wiki.apache.org/cassandra/ToddIrm

New page:
Hey !! My name is SHERYL DAVENPORT. I live in Port Arthur.BR
Soon i will turn 60. I and my sister go to The Dizzy Institute of Refundable 
Children which has a branch in Newport. I am self employed as a Fire officer. 
My hobby is Belly Dancing. My dad name is Cary  and he is a Paramedic. My momy 
is a Instructor.BR
BR
Here is my page - 
[[http://www.blindchildrenscenter.org/cheapbeatsheadphones.html|beats by dre 
monster]]

[6/6] git commit: Merge branch 'cassandra-1.2' into trunk

Updated Branches:
  refs/heads/cassandra-1.2 88b9d9516 - a4166496f
  refs/heads/trunk 7d5490b58 - c5f9ac87f


Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: c5f9ac87f6478d71ea22ad1f7e9e46f9aae9c8c8
Parents: 635e213 a416649
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Feb 26 10:07:56 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Feb 26 10:07:56 2013 -0600

--
 CHANGES.txt|2 +
 .../db/compaction/LeveledCompactionStrategy.java   |2 +-
 .../io/sstable/SSTableBoundedScanner.java  |   16 ++---
 .../apache/cassandra/io/sstable/SSTableReader.java |   54 ++-
 4 files changed, 60 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c5f9ac87/CHANGES.txt
--
diff --cc CHANGES.txt
index badc87c,b19b092..fcd2115
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,17 -1,6 +1,19 @@@
 +1.3
 + * Move sstable level information into the Stats component, removing the
 +   need for a separate Manifest file (CASSANDRA-4872)
 + * avoid serializing to byte[] on commitlog append (CASSANDRA-5199)
 + * make index_interval configurable per columnfamily (CASSANDRA-3961)
 + * add default_tim_to_live (CASSANDRA-3974)
 + * add memtable_flush_period_in_ms (CASSANDRA-4237)
 + * replace supercolumns internally by composites (CASSANDRA-3237, 5123)
 + * upgrade thrift to 0.9.0 (CASSANDRA-3719)
 + * drop unnecessary keyspace from user-defined compaction API (CASSANDRA-5139)
 + * more robust solution to incomplete compactions + counters (CASSANDRA-5151)
 + * Change order of directory searching for c*.in.sh (CASSANDRA-3983)
 +
  1.2.3
+  * Avoid allocating SSTableBoundedScanner during repair when the range does 
+not intersect the sstable (CASSANDRA-5249)
  Merged from 1.1:
   * nodetool: ability to repair specific range (CASSANDRA-5280)
   * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c5f9ac87/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c5f9ac87/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
--

[2/6] git commit: add buffer size comments patch by Marcus Eriksson for CASSANDRA-5291

add buffer size comments
patch by Marcus Eriksson for CASSANDRA-5291


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

Branch: refs/heads/trunk
Commit: 02ea439a4356558654a837f420cf62af0b8f3bc4
Parents: 88b9d95
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Feb 26 09:49:22 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Feb 26 09:49:22 2013 -0600

--
 conf/cassandra.yaml |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/02ea439a/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 8e910d8..6d0528a 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -389,7 +389,15 @@ rpc_server_type: sync
 # rpc_send_buff_size_in_bytes:
 # rpc_recv_buff_size_in_bytes:
 
-# uncomment to set socket buffer size for internode communication
+# Uncomment to set socket buffer size for internode communication
+# Note that when setting this, the buffer size is limited by net.core.wmem_max
+# and when not setting it it is defined by net.ipv4.tcp_wmem
+# See:
+# /proc/sys/net/core/wmem_max
+# /proc/sys/net/core/rmem_max
+# /proc/sys/net/ipv4/tcp_wmem
+# /proc/sys/net/ipv4/tcp_wmem
+# and: man tcp
 # internode_send_buff_size_in_bytes:
 # internode_recv_buff_size_in_bytes:

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

Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: 635e2138055353a32852badb6e31f3ad9f5bee73
Parents: 7d5490b 02ea439
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Feb 26 09:49:31 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Feb 26 09:49:31 2013 -0600

--
 conf/cassandra.yaml |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/635e2138/conf/cassandra.yaml
--

[1/6] git commit: add buffer size comments patch by Marcus Eriksson for CASSANDRA-5291

add buffer size comments
patch by Marcus Eriksson for CASSANDRA-5291


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

Branch: refs/heads/cassandra-1.2
Commit: 02ea439a4356558654a837f420cf62af0b8f3bc4
Parents: 88b9d95
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Feb 26 09:49:22 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Feb 26 09:49:22 2013 -0600

--
 conf/cassandra.yaml |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/02ea439a/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 8e910d8..6d0528a 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -389,7 +389,15 @@ rpc_server_type: sync
 # rpc_send_buff_size_in_bytes:
 # rpc_recv_buff_size_in_bytes:
 
-# uncomment to set socket buffer size for internode communication
+# Uncomment to set socket buffer size for internode communication
+# Note that when setting this, the buffer size is limited by net.core.wmem_max
+# and when not setting it it is defined by net.ipv4.tcp_wmem
+# See:
+# /proc/sys/net/core/wmem_max
+# /proc/sys/net/core/rmem_max
+# /proc/sys/net/ipv4/tcp_wmem
+# /proc/sys/net/ipv4/tcp_wmem
+# and: man tcp
 # internode_send_buff_size_in_bytes:
 # internode_recv_buff_size_in_bytes:

[4/6] git commit: Avoid allocating SSTableBoundedScanner during repair when the range does not intersect the sstable patch by jbellis; reviewed by slebresne for CASSANDRA-5249

Avoid allocating SSTableBoundedScanner during repair when the range does not 
intersect the sstable
patch by jbellis; reviewed by slebresne for CASSANDRA-5249


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

Branch: refs/heads/trunk
Commit: a4166496f2df6bc8072e7b30c29102937788f400
Parents: 02ea439
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Feb 26 10:07:47 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Feb 26 10:07:47 2013 -0600

--
 CHANGES.txt|2 +
 .../db/compaction/LeveledCompactionStrategy.java   |2 +-
 .../io/sstable/SSTableBoundedScanner.java  |   16 ++---
 .../apache/cassandra/io/sstable/SSTableReader.java |   54 ++-
 4 files changed, 60 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4166496/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d4a74c0..b19b092 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 1.2.3
+ * Avoid allocating SSTableBoundedScanner during repair when the range does 
+   not intersect the sstable (CASSANDRA-5249)
 Merged from 1.1:
  * nodetool: ability to repair specific range (CASSANDRA-5280)
  * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4166496/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java 
b/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
index 5b29bfc..6a1bf4b 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
@@ -200,7 +200,7 @@ public class LeveledCompactionStrategy extends 
AbstractCompactionStrategy implem
 private final IteratorSSTableReader sstableIterator;
 private final long totalLength;
 
-private SSTableScanner currentScanner;
+private ICompactionScanner currentScanner;
 private long positionOffset;
 
 public LeveledScanner(CollectionSSTableReader sstables, RangeToken 
range)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4166496/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java 
b/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java
index 788f4ca..a571901 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java
@@ -35,19 +35,13 @@ public class SSTableBoundedScanner extends SSTableScanner
 private final IteratorPairLong, Long rangeIterator;
 private PairLong, Long currentRange;
 
-SSTableBoundedScanner(SSTableReader sstable, boolean skipCache, 
RangeToken range)
+SSTableBoundedScanner(SSTableReader sstable, boolean skipCache, 
IteratorPairLong, Long rangeIterator)
 {
 super(sstable, skipCache);
-this.rangeIterator = 
sstable.getPositionsForRanges(Collections.singletonList(range)).iterator();
-if (rangeIterator.hasNext())
-{
-currentRange = rangeIterator.next();
-dfile.seek(currentRange.left);
-}
-else
-{
-exhausted = true;
-}
+this.rangeIterator = rangeIterator;
+assert rangeIterator.hasNext(); // use EmptyCompactionScanner otherwise
+currentRange = rangeIterator.next();
+dfile.seek(currentRange.left);
 }
 
 /*

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4166496/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableReader.java 
b/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
index d0ef5d8..51f2344 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
@@ -35,7 +35,9 @@ import org.apache.cassandra.config.ColumnDefinition;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.config.Schema;
 import org.apache.cassandra.db.*;
+import org.apache.cassandra.db.columniterator.OnDiskAtomIterator;
 import

[5/6] git commit: Avoid allocating SSTableBoundedScanner during repair when the range does not intersect the sstable patch by jbellis; reviewed by slebresne for CASSANDRA-5249

Avoid allocating SSTableBoundedScanner during repair when the range does not 
intersect the sstable
patch by jbellis; reviewed by slebresne for CASSANDRA-5249


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

Branch: refs/heads/cassandra-1.2
Commit: a4166496f2df6bc8072e7b30c29102937788f400
Parents: 02ea439
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Feb 26 10:07:47 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Feb 26 10:07:47 2013 -0600

--
 CHANGES.txt|2 +
 .../db/compaction/LeveledCompactionStrategy.java   |2 +-
 .../io/sstable/SSTableBoundedScanner.java  |   16 ++---
 .../apache/cassandra/io/sstable/SSTableReader.java |   54 ++-
 4 files changed, 60 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4166496/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d4a74c0..b19b092 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 1.2.3
+ * Avoid allocating SSTableBoundedScanner during repair when the range does 
+   not intersect the sstable (CASSANDRA-5249)
 Merged from 1.1:
  * nodetool: ability to repair specific range (CASSANDRA-5280)
  * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4166496/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java 
b/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
index 5b29bfc..6a1bf4b 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
@@ -200,7 +200,7 @@ public class LeveledCompactionStrategy extends 
AbstractCompactionStrategy implem
 private final IteratorSSTableReader sstableIterator;
 private final long totalLength;
 
-private SSTableScanner currentScanner;
+private ICompactionScanner currentScanner;
 private long positionOffset;
 
 public LeveledScanner(CollectionSSTableReader sstables, RangeToken 
range)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4166496/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java 
b/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java
index 788f4ca..a571901 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java
@@ -35,19 +35,13 @@ public class SSTableBoundedScanner extends SSTableScanner
 private final IteratorPairLong, Long rangeIterator;
 private PairLong, Long currentRange;
 
-SSTableBoundedScanner(SSTableReader sstable, boolean skipCache, 
RangeToken range)
+SSTableBoundedScanner(SSTableReader sstable, boolean skipCache, 
IteratorPairLong, Long rangeIterator)
 {
 super(sstable, skipCache);
-this.rangeIterator = 
sstable.getPositionsForRanges(Collections.singletonList(range)).iterator();
-if (rangeIterator.hasNext())
-{
-currentRange = rangeIterator.next();
-dfile.seek(currentRange.left);
-}
-else
-{
-exhausted = true;
-}
+this.rangeIterator = rangeIterator;
+assert rangeIterator.hasNext(); // use EmptyCompactionScanner otherwise
+currentRange = rangeIterator.next();
+dfile.seek(currentRange.left);
 }
 
 /*

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4166496/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableReader.java 
b/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
index d0ef5d8..51f2344 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
@@ -35,7 +35,9 @@ import org.apache.cassandra.config.ColumnDefinition;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.config.Schema;
 import org.apache.cassandra.db.*;
+import org.apache.cassandra.db.columniterator.OnDiskAtomIterator;

[Cassandra Wiki] Trivial Update of DarrenDor by DarrenDor

Dear Wiki user,

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

The DarrenDor page has been changed by DarrenDor:
http://wiki.apache.org/cassandra/DarrenDor

New page:
Hi !! I am JENEVA BOOKER. I have applied for distance learning at The Excellent 
Institute which has a branch in Kaneohe.BR
I work as a Computer hardware engineer. I am a fan of Backgammon. My papa name 
is Peter  and he is a Wood-cutter. My momy is a Firefighter.BR
BR
my web page [[http://www.redwing.lib.mn.us/beatsbydre.html|dre beats cheap]]

[jira] [Updated] (CASSANDRA-5249) Avoid allocateding SSTableBoundedScanner when the range does not intersect the sstable


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

Jonathan Ellis updated CASSANDRA-5249:
--

Component/s: Core
   Priority: Minor  (was: Major)

 Avoid allocateding SSTableBoundedScanner when the range does not intersect 
 the sstable
 --

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

 Attachments: 5249.txt


 See 
 https://issues.apache.org/jira/browse/CASSANDRA-5222?focusedCommentId=13577420page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13577420

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

buildbot failure in ASF Buildbot on cassandra-trunk

2013-02-26 Thread buildbot

The Buildbot has detected a new failure on builder cassandra-trunk while 
building cassandra.
Full details are available at:
 http://ci.apache.org/builders/cassandra-trunk/builds/2378

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: portunus_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch trunk] c5f9ac87f6478d71ea22ad1f7e9e46f9aae9c8c8
Blamelist: Jonathan Ellis jbel...@apache.org

BUILD FAILED: failed

sincerely,
 -The Buildbot

[jira] [Commented] (CASSANDRA-5249) Avoid allocateding SSTableBoundedScanner when the range does not intersect the sstable


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

Jonathan Ellis commented on CASSANDRA-5249:
---

rebased to 1.2 + committed

 Avoid allocateding SSTableBoundedScanner when the range does not intersect 
 the sstable
 --

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

 Attachments: 5249.txt


 See 
 https://issues.apache.org/jira/browse/CASSANDRA-5222?focusedCommentId=13577420page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13577420

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Trivial Update of MckinleyA by MckinleyA

Dear Wiki user,

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

The MckinleyA page has been changed by MckinleyA:
http://wiki.apache.org/cassandra/MckinleyA

New page:
Yo guys !! I am PRUDENCE CHANDLER. I have a house in Kennewick.BR
I might take night schooling in The Crisp Prep School located in Daly City. I 
am working as Verger. I am a fan of R/C Helicopters. My dad name is Edwin  and 
he is a Police Detective. My momy is a Principal.BR
BR
Also visit my site [[http://www.reachchanelhandbags.com|chanel replica]]

[jira] [Commented] (CASSANDRA-4973) Secondary Index stops returning rows when caching=ALL

2013-02-26 Thread JIRA


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

André Cruz commented on CASSANDRA-4973:
---

I also have this problem. Secondary index stops working on CFs with 
caching=ALL. Dropping the index and re-creating fixes it temporarily.

Running 1.1.5.

 Secondary Index stops returning rows when caching=ALL
 -

 Key: CASSANDRA-4973
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2, 1.1.6
 Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
Reporter: Daniel Strawson
 Attachments: secondary_index_rowcache_restart_test.py


 I've been using cassandra on a project for a little while in development and 
 have recently suddenly started having an issue where the secondary index 
 stops working, this is happening on my new production system, we are not yet 
 live.   Things work ok one moment, then suddenly queries to the cf through 
 the secondary index stop returning data.  I've seen it happen on 3 CFs. I've 
 tried:
 - various nodetools repair / scrub / rebuild_indexes options, none seem to 
 make a difference.
 - Doing a 'update column family whatever with column_metadata=[]' then 
 repeating with my correct column_metadata definition.  This seems to fix the 
 problem (temporarily) until it comes back.
 The last time it happened I had just restarted cassandra, so it could be that 
 which is causing the issue, I've got the production system ok at the moment, 
 I will try restarting a bit later when its not being used and if I can get 
 the issue to reoccur I will add more information.
 The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this 
 has not fixed it.
 Here is an example of the create column family I'm using for one of the CFs 
 that affected:
 create column family region
   with column_type = 'Standard'
   and comparator = 'UTF8Type'
   and default_validation_class = 'BytesType'
   and key_validation_class = 'UTF8Type'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 4
   and max_compaction_threshold = 32
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and column_metadata = [
 
 {column_name : 'label',
 validation_class : UTF8Type},
 
 {column_name : 'countryCode',
 validation_class : UTF8Type,
 index_name : 'region_countryCode_idx',
 index_type : 0},
 
 ]
   and compression_options = {'sstable_compression' : 
 'org.apache.cassandra.io.compress.SnappyCompressor'};
 I've noticed that CASSANDRA-4785 looks similar, in my case once the system 
 has the problem, it doesn't go away until I fix it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5292) CQL3 shouldn't lowercase DC names for NTS

Sylvain Lebresne created CASSANDRA-5292:
---

 Summary: CQL3 shouldn't lowercase DC names for NTS
 Key: CASSANDRA-5292
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5292
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
 Fix For: 1.2.3
 Attachments: 5292-option3.txt

In CREATE and ALTER statements, when a property map is given (replication, 
compaction and compression options), CQL3 lowercase the map keys to provide 
case insensitivity. The goal is to allow things like:
{noformat}
  replication = { 'Class' : 'SimpleStrategy', 'Replication_factor' : '1' }
{noformat}

However, this messes up with NTS, as it ends up lower-casing the datacenter 
names. As a consequence,
{noformat}
  replication = { 'class' : 'NetworkTopologyStrategy', 'DC1' : '1' }
{noformat}
will currently create a DC that is really called 'dc1', which is a problem 
because DC names are interpreted case sensitively otherwise (at least in 
PropertyFileSnitch).

That's the problem. Now I'm kind of hesitant on what is the right fix. I see 
the following possibilities:
# Remove the CQL3 lower-casing completely. I'll admit that providing case 
insensitivy for property map keys may not have been such a good idea in the 
first place. After all, those map keys are string literal, which rather suggest 
case sensitivity. However, making that change would be a break strictly 
speaking.
# Make DC name case insensitive. As much as I think DC names ought to be case 
insensitive, I'm not sure that's very doable in practice because that would 
imply storing DC names lower-cased internally, but DC names are exchanged over 
gossip and whatnot, so that would probably break all hell loose.
# Keep CQL3 case insensitivity for property map keys in general but special 
case internally for NTS. The problems I see with that is that 1) this will be 
ugly and 2) if we special case too much, we might break potential custom 
strategies inspired by NTS. I also had the idea of changing strategy options 
internally from MapString, String to some custom object that would be 
essentially a case insensitive string map (general case), but that would also 
hold the original case of keys so NTS (and any other likely-minded strategy) 
can do its stuff. This happens to not be a small patch however (I'm attaching 
the patch for reference because I wrote it, but I'm seriously wondering if it's 
not too overkill).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5292) CQL3 shouldn't lowercase DC names for NTS

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

Sylvain Lebresne updated CASSANDRA-5292:

Attachment: 5292-option3.txt

CQL3 shouldn't lowercase DC names for NTS
-

Key: CASSANDRA-5292
URL: https://issues.apache.org/jira/browse/CASSANDRA-5292
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 1.2.3

Attachments: 5292-option3.txt

In CREATE and ALTER statements, when a property map is given (replication,
compaction and compression options), CQL3 lowercase the map keys to provide
case insensitivity. The goal is to allow things like:
{noformat}
replication = { 'Class' : 'SimpleStrategy', 'Replication_factor' : '1' }
{noformat}
However, this messes up with NTS, as it ends up lower-casing the datacenter
names. As a consequence,
{noformat}
replication = { 'class' : 'NetworkTopologyStrategy', 'DC1' : '1' }
{noformat}
will currently create a DC that is really called 'dc1', which is a problem
because DC names are interpreted case sensitively otherwise (at least in
PropertyFileSnitch).
That's the problem. Now I'm kind of hesitant on what is the right fix. I see
the following possibilities:
# Remove the CQL3 lower-casing completely. I'll admit that providing case
insensitivy for property map keys may not have been such a good idea in the
first place. After all, those map keys are string literal, which rather
suggest case sensitivity. However, making that change would be a break
strictly speaking.
# Make DC name case insensitive. As much as I think DC names ought to be case
insensitive, I'm not sure that's very doable in practice because that would
imply storing DC names lower-cased internally, but DC names are exchanged
over gossip and whatnot, so that would probably break all hell loose.
# Keep CQL3 case insensitivity for property map keys in general but special
case internally for NTS. The problems I see with that is that 1) this will be
ugly and 2) if we special case too much, we might break potential custom
strategies inspired by NTS. I also had the idea of changing strategy options
internally from MapString, String to some custom object that would be
essentially a case insensitive string map (general case), but that would also
hold the original case of keys so NTS (and any other likely-minded strategy)
can do its stuff. This happens to not be a small patch however (I'm attaching
the patch for reference because I wrote it, but I'm seriously wondering if
it's not too overkill).

[Cassandra Wiki] Trivial Update of SadiePren by SadiePren

Dear Wiki user,

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

The SadiePren page has been changed by SadiePren:
http://wiki.apache.org/cassandra/SadiePren

New page:
Hey guys !! The name is AGUSTINA MCFADDEN. I belong to Akron.BR
I want to study at The Hungry Finishing School located in Houston. I am self 
employed as a Diplomat. I also like to Hothouse Gardening. My daddy name is 
David  and he is a Explorer. My momy is a Meteorologist.BR
BR
Feel free to visit my blog post: [[http://www.focuschanelbags.com|chanel bag]]

[jira] [Updated] (CASSANDRA-4655) Truncate operation doesn't delete rows from HintsColumnFamily.

2013-02-26 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-4655:

Reviewer: vijay2...@yahoo.com

Truncate operation doesn't delete rows from HintsColumnFamily.
--

Key: CASSANDRA-4655
URL: https://issues.apache.org/jira/browse/CASSANDRA-4655
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0
Environment: Centos 6.2, Cassandra 1.1.4 (DataStax distribution),
three-nodes cluster.
Reporter: Alexey Zotov
Assignee: Alexey Zotov
Priority: Minor
Labels: hintedhandoff, truncate
Fix For: 1.2.3

Attachments: cassandra-1.2-4655-hints_truncation.txt,
cassandra-1.2-4655-hints_truncation-v2.txt

Steps to reproduce:
1. Start writing of data to some column family, let name it 'MyCF'
2. Stop 1 node
3. Wait some time (until some data will be collected in HintsColumnFamily)
4. Start node (HintedHandoff will be started automatically for 'MyCF')
5. Run 'truncate' command for 'MyCF' column family from command from cli
6. Wait until truncate will be finished
7. You will see that 'MyCF' is not empty because HintedHandoff is copying
data
So, I suggest to clean HintsColumnFamily (for truncated column family) before
we had started to discard sstables.
I think it should be done in CompactionManager#submitTrucate() method. I can
try to create patch but I need to know right way of cleaning
HintsColumnFamily. Could you clarify it?

[jira] [Commented] (CASSANDRA-5292) CQL3 shouldn't lowercase DC names for NTS

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

Jonathan Ellis commented on CASSANDRA-5292:
---

IMO there are two principles we should be following here:

# schema options should be just a Map. This is the most straightforward and
trying to be clever here will surprise people more than it will help. Nor do I
want to maintain almost-Map structures in the code.
# CQL should not helpfully lowercase Map keys.

My understanding is that we observe #2 elsewhere, but schema options are
not-quite-a-Map in this respect. In that case I think we should suck it up and
take the backwards incompatibility to fix this.

If we violate #2 in general, that is a bitter pill to swallow, but it's still a
bug that should be fixed.

CQL3 shouldn't lowercase DC names for NTS
-

Attachments: 5292-option3.txt

[jira] [Updated] (CASSANDRA-5292) CQL3 shouldn't lowercase DC names for NTS

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

Sylvain Lebresne updated CASSANDRA-5292:

Attachment: 5292.txt

bq. My understanding is that we observe #2 elsewhere

Yes, we do.

bq. In that case I think we should suck it up and take the backwards
incompatibility to fix this.

Yeah, I think I agree really. I'm attaching the trivial patch to do that.

bq. Nor do I want to maintain almost-Map structures in the code.

For the record, schema options and normal map don't really share any code
outside the parser. But I agree on the rest, just saying :)

CQL3 shouldn't lowercase DC names for NTS
-

Attachments: 5292-option3.txt, 5292.txt

[jira] [Commented] (CASSANDRA-5062) Support CAS


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

Jonathan Ellis commented on CASSANDRA-5062:
---

The thing that is stopping me from hacking together a Paxos prototype is, where 
do we store the accepted-but-not-committed proposals?  Sticking them on the 
end of the row data in an sstable would be ugly.  Ignoring it and saying 
paxos proposals have to fit in memory is attractive, but then we can't remove 
commitlog segments until each proposal is committed or overridden.

(Timing out accepted proposals and discarding them would put us back in the 
lost ack problem space; we could commit multiple, conflicting proposals 
during a network partition at the right time.)

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5287) Composite comparators for super CFs broken in 1.2


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

Sylvain Lebresne updated CASSANDRA-5287:


Attachment: 5287.txt

 Composite comparators for super CFs broken in 1.2
 -

 Key: CASSANDRA-5287
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5287
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Tyler Hobbs
 Attachments: 5287-pycassa-repro.py, 5287.txt


 In Cassandra 1.2.0 through 1.2.2, attempting to insert data into a super 
 column family with a CompositeType comparator results in the following 
 stacktrace:
 {noformat}
 ERROR 14:56:49,920 Error occurred during processing of message.
 java.lang.IllegalArgumentException
   at java.nio.Buffer.limit(Buffer.java:249)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:51)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:60)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:126)
   at 
 org.apache.cassandra.config.CFMetaData.getColumnDefinitionFromColumnName(CFMetaData.java:920)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnData(ThriftValidation.java:404)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnOrSuperColumn(ThriftValidation.java:287)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateMutation(ThriftValidation.java:343)
   at 
 org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:704)
   at 
 org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:752)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3622)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3610)
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 {noformat}
 Client-side, you'll just see {{TTransportException: TSocket read 0 bytes}}.
 Cassandra 1.1 doesn't have the same problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-5062) Support CAS

2013-02-26 Thread Cristian Opris (JIRA)

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

Cristian Opris edited comment on CASSANDRA-5062 at 2/26/13 6:23 PM:

Afaict from the Spinnaker paper they only require ZK for fault tolerant leader
election, failure detection and possibly cluster membership. (The right lower
box in the diagram in 4.1) The rest of it is their actual data storage engine.

A few more comments:

1. Paxos can be made very efficient particularly in stable operation scenarios.
-I believe Zab devolves effectively in atomic broadcast (not even 2PC) with a
stable leader. So you can normally do writes with a single roundtrip just like
now.-
Edit: Zab requires 4 delays (2 roundtrips) actually

2. There is a difference between what I described above and what Spinnaker
does. I believe they elect a leader for the entire replica group while my
description assumes 1 full paxos instance per row write. I'm not fully clear
atm how this would work but I believe even that can be optimized to single
roundtrips per write in normal operation (I believe it's in one of Google's
papers that they piggyback the commit on the next proposal for example)

Off the top of my head: coordinator assumes one of the replicas as being most
up-to-date, attempts to use it as leader. Replica starts Paxos round attaching
the write payload. If accepted on a majority replica can send commit.
Opportunistically attaches further proposals to it. If Paxos round fails (or a
number of rounds fail) it's likely the replica is behind on many rows so
coordinator switches to another replica.

Now this is all preliminary as I haven't fully thought this through but I think
it's definitely worth investigating. While it may be a complicated protocol it
has significant performance advantages over locks. Just count how many
roundtrips you'd need in the wait chain algorithm. Not to mentioned handling
expired/orphan locks

was (Author: onetoinfin...@yahoo.com):
Afaict from the Spinnaker paper they only require ZK for fault tolerant
leader election, failure detection and possibly cluster membership. (The right
lower box in the diagram in 4.1) The rest of it is their actual data storage
engine.

A few more comments:

1. Paxos can be made very efficient particularly in stable operation scenarios.
I believe Zab devolves effectively in atomic broadcast (not even 2PC) with a
stable leader. So you can normally do writes with a single roundtrip just like
now.

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

Strong consistency is not enough to prevent race conditions. The classic
example is user account creation: we want to ensure usernames are unique, so
we only want to signal account creation success if nobody else has created
the account yet. But naive read-then-write allows clients to race and both
think they have a green light to create.

[jira] [Comment Edited] (CASSANDRA-5062) Support CAS

2013-02-26 Thread Cristian Opris (JIRA)

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

Cristian Opris edited comment on CASSANDRA-5062 at 2/26/13 6:24 PM:

So I guess what I'm proposing is similar to what Piotr said above: each CAS is
a round of Paxos.
With some cleverness this can be collapsed to Multi-Paxos.

Spinnaker does leader election with ZK precisely because they did not want to
implement Paxos themselves.

From the paper, section 5: The replication protocol has two phases: a leader
election phase, followed by a quorum phase where the leader proposes a write
and the followers accept it.

-That is Multi-Paxos, with first phase (leader election) handled by ZK and
second phase being the steady state (propose/accept) with the actual
write/commit-
Edit: it's not, see below

was (Author: onetoinfin...@yahoo.com):
So I guess what I'm proposing is similar to what Piotr said above: each CAS
is a round of Paxos.
With some cleverness this can be collapsed to Multi-Paxos.

Spinnaker does leader election with ZK precisely because they did not want to
implement Paxos themselves.

From the paper, section 5: The replication protocol has two phases: a leader
election phase, followed by a quorum phase where the leader proposes a write
and the followers accept it.

That is Multi-Paxos, with first phase (leader election) handled by ZK and
second phase being the steady state (propose/accept) with the actual
write/commit

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Commented] (CASSANDRA-5062) Support CAS

2013-02-26 Thread Sergio Bossa (JIRA)


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

Sergio Bossa commented on CASSANDRA-5062:
-

So many comments, I'll try to address some:

1) Paxos complexity.

I believe Paxos *is* complex in its original form, and ZK two-phase protocol is 
actually a simplification, because election is only employed to establish a 
single proposer and then 2PC-like atomic broadcast is used; if multiple nodes 
can propose at the same time, it means running several Paxos instances with 
several proposers.
Here's also an interesting paper about engineering problems and tradeoffs in 
implementing Paxos: 
http://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/paper2-1.pdf

2) Paxos election VS Paxos CAS

Doing direct CAS rounds would be pretty nice, but even with partitioning, my 
doubts about the protocol liveness still stand.

3) Lock-based approaches.

The word lock is probably misplaced here, my fault: as it would just be a 
simple leader election based on placing a lock value on a column (kind-of 
file locks), and use that to declare a leader; then, monotonically increasing 
numbered CAS rounds would go through the leader, and could be accomplished via 
a simplified 2PC protocol (to avoid lost acks).
If the leader fails, a new one will be elected among those ones with the 
highest committed CAS round number (to overcome partially committed rounds).
Note: now that I write of it, this is basically Zab on top of C*, but I still 
believe it is much cheaper and easier than Paxos. May be wrong obviously :)

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

2013-02-26 Thread Cristian Opris (JIRA)


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

Cristian Opris commented on CASSANDRA-5062:
---

Rereading the papers, Spinnaker, Zab and  Sergio's option 3) are pretty much 
the same thing.

The alternative is to do a true Paxos instance for each CAS round but not clear 
how that can be done efficiently (and simply)





 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5292) CQL3 shouldn't lowercase DC names for NTS

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

Jonathan Ellis commented on CASSANDRA-5292:
---

bq. For the record, schema options and normal map don't really share any code
outside the parser. But I agree on the rest, just saying

Right. But we're going to fix that, right? :)

+1 on the trivial patch.

CQL3 shouldn't lowercase DC names for NTS
-

Attachments: 5292-option3.txt, 5292.txt

[jira] [Assigned] (CASSANDRA-3647) Support collection (list, set, and map) value types in CQL

2013-02-26 Thread Brandon Williams (JIRA)


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

Brandon Williams reassigned CASSANDRA-3647:
---

Assignee: Brandon Williams  (was: Sylvain Lebresne)

 Support collection (list, set, and map) value types in CQL
 --

 Key: CASSANDRA-3647
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Brandon Williams
  Labels: cql
 Fix For: 1.2.0 beta 1

 Attachments: 3647-nit.txt, CASSANDRA-3647-alternative.patch


 Composite columns introduce the ability to have arbitrarily nested data in a 
 Cassandra row.  We should expose this through CQL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-3647) Support collection (list, set, and map) value types in CQL

2013-02-26 Thread Brandon Williams (JIRA)


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

Brandon Williams reassigned CASSANDRA-3647:
---

Assignee: Sylvain Lebresne  (was: Brandon Williams)

 Support collection (list, set, and map) value types in CQL
 --

 Key: CASSANDRA-3647
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
  Labels: cql
 Fix For: 1.2.0 beta 1

 Attachments: 3647-nit.txt, CASSANDRA-3647-alternative.patch


 Composite columns introduce the ability to have arbitrarily nested data in a 
 Cassandra row.  We should expose this through CQL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS


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

Jonathan Ellis commented on CASSANDRA-5062:
---

One more data point: there is an interesting description of Hibari, which uses 
chain replication, at 
http://www.snookles.com/scott/publications/erlang2010-slf.pdf.  It does not use 
ZK; instead, it relies on a SPOF admin server to coordinate chain 
reorganization when a block fails.

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Trivial Update of EricMicke by EricMicke

Dear Wiki user,

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

The EricMicke page has been changed by EricMicke:
http://wiki.apache.org/cassandra/EricMicke

New page:
This april i will be 38. I go to night school at The Colossal Finishing School 
which has a branch in Bakersfield.BR
I am working as Doctor. I am a fan of Macramé.BR
BR
My web site; [[http://www.chanelbagsbuild.com|chanel purse]]

[jira] [Updated] (CASSANDRA-3929) Support row size limits


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

Dave Brosius updated CASSANDRA-3929:


Attachment: 3929_f.txt

rebase line to trunk latest, fix ACS validations, and only do auto tombstoning 
if using compact storage.

doing non compact storage would mean (i think) deserializing each columns name 
to find where the first component changes to count rows, which seems to be 
performantly painful.

 Support row size limits
 ---

 Key: CASSANDRA-3929
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Dave Brosius
Priority: Minor
  Labels: ponies
 Fix For: 2.0

 Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt, 
 3929_f.txt, 3929.txt


 We currently support expiring columns by time-to-live; we've also had 
 requests for keeping the most recent N columns in a row.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3929) Support row size limits


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

Dave Brosius updated CASSANDRA-3929:


Attachment: 3929_g.txt

support removal of non compact storage (as well), by removing whole 'cql rows' 
at a time.

patch against trunk

 Support row size limits
 ---

 Key: CASSANDRA-3929
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Dave Brosius
Priority: Minor
  Labels: ponies
 Fix For: 2.0

 Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt, 
 3929_f.txt, 3929_g.txt, 3929.txt


 We currently support expiring columns by time-to-live; we've also had 
 requests for keeping the most recent N columns in a row.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-3929) Support row size limits


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

Dave Brosius edited comment on CASSANDRA-3929 at 2/27/13 4:29 AM:
--

support removal of non compact storage (as well), by removing whole 'cql rows' 
at a time.

patch against trunk


3292_g.txt

  was (Author: dbrosius):
support removal of non compact storage (as well), by removing whole 'cql 
rows' at a time.

patch against trunk
  
 Support row size limits
 ---

 Key: CASSANDRA-3929
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Dave Brosius
Priority: Minor
  Labels: ponies
 Fix For: 2.0

 Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt, 
 3929_f.txt, 3929_g.txt, 3929.txt


 We currently support expiring columns by time-to-live; we've also had 
 requests for keeping the most recent N columns in a row.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-3929) Support row size limits


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

Dave Brosius edited comment on CASSANDRA-3929 at 2/27/13 4:29 AM:
--

support removal of non compact storage (as well), by removing whole 'cql rows' 
at a time.

patch against trunk


3929_g.txt

  was (Author: dbrosius):
support removal of non compact storage (as well), by removing whole 'cql 
rows' at a time.

patch against trunk


3292_g.txt
  
 Support row size limits
 ---

 Key: CASSANDRA-3929
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Dave Brosius
Priority: Minor
  Labels: ponies
 Fix For: 2.0

 Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt, 
 3929_f.txt, 3929_g.txt, 3929.txt


 We currently support expiring columns by time-to-live; we've also had 
 requests for keeping the most recent N columns in a row.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-5258) Create dtests for all auth CQL3 statements + PasswordAuthenticator + CassandraAuthorizer

2013-02-26 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko resolved CASSANDRA-5258.
--

Resolution: Fixed

https://github.com/riptano/cassandra-dtest/pull/10

 Create dtests for all auth CQL3 statements + PasswordAuthenticator + 
 CassandraAuthorizer
 

 Key: CASSANDRA-5258
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5258
 Project: Cassandra
  Issue Type: Test
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Priority: Trivial

 Now that we ship default implementations of IAuthenticator and IAuthorizer 
 it's time to create dtests for everything auth-related (and the new 
 implementations, too).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5236) Migration during shutdown can cause AE

2013-02-26 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko updated CASSANDRA-5236:
-

Reviewer: iamaleksey

 Migration during shutdown can cause AE
 --

 Key: CASSANDRA-5236
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5236
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Trivial
 Fix For: 1.1.11

 Attachments: 5236.txt


 Mostly just a problem for the dtests on occasion:
 {noformat}
  INFO [FlushWriter:1] 2013-02-08 17:03:49,727 Memtable.java (line 453) 
 Writing Memtable-schema_columns@1757448463(793/793 serialized/live bytes, 15 
 ops)
  INFO [FlushWriter:1] 2013-02-08 17:03:49,752 Memtable.java (line 487) 
 Completed flushing 
 /tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-4-Data.db
  (339 bytes) for commitlog position ReplayPosition(segmentId=1360364624598, 
 position=66887)
  INFO [CompactionExecutor:2] 2013-02-08 17:03:49,754 CompactionTask.java 
 (line 112) Compacting 
 [SSTableReader(path='/tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-4-Data.db'),
  
 SSTableReader(path='/tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-3-Data.db'),
  
 SSTableReader(path='/tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-2-Data.db'),
  
 SSTableReader(path='/tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-1-Data.db')]
  INFO [CompactionExecutor:3] 2013-02-08 17:03:49,759 CompactionTask.java 
 (line 272) Compacted 4 sstables to 
 [/tmp/dtest-gEW6x2/test/node3/data/system/schema_columnfamilies/system-schema_columnfamilies-ib-5,].
   7,473 bytes to 5,595 (~74% of original) in 32ms = 0.166744MB/s.  6 total 
 rows, 4 unique.  Row merge counts were {1:3, 2:0, 3:1, 4:0, }
 ERROR [InternalResponseStage:1] 2013-02-08 17:03:49,787 CassandraDaemon.java 
 (line 135) Exception in thread Thread[InternalResponseStage:1,5,main]
 java.lang.AssertionError
 at 
 org.apache.cassandra.service.MigrationManager.passiveAnnounce(MigrationManager.java:320)
 at 
 org.apache.cassandra.config.Schema.updateVersionAndAnnounce(Schema.java:458)
 at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:347)
 at 
 org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:66)
 at 
 org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:47)
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS


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

Jonathan Ellis commented on CASSANDRA-5062:
---

bq. The thing that is stopping me from hacking together a Paxos prototype is, 
where do we store the accepted-but-not-committed proposals?

Thinking that just dumping them to a separate file (like the pre-2.0 manifest) 
will be adequate to start with.  We can also trade off how fine-grained the 
paxos ensemble is (one per row, vs one per vnode) for storage space.

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

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

Jonathan Ellis commented on CASSANDRA-5062:
---

bq. because election is only employed to establish a single proposer and then
2PC-like atomic broadcast is used

This is not correct for Paxos. (Not sufficiently familiar with ZAB to comment
there.) Leader election is an optimization to avoid conflicts from multiple
proposers from reducing performance; the leader still follows the full Paxos
algorithm when proposing, to prevent the kind of lost ack problem I described
above if the leader fails and is replaced. (See section 3 of Paxos made
Simple.)

bq. use that to declare a leader; then, monotonically increasing numbered CAS
rounds would go through the leader, and could be accomplished via a simplified
2PC protocol (to avoid lost acks).

What does this 2PC-that-avoids-lost-acks look like? Because I'm very satisfied
that 2PC itself has this problem, so it's far from clear to me how you get
there by simplifying it.

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Updated] (CASSANDRA-3929) Support row size limits


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

Dave Brosius updated CASSANDRA-3929:


Attachment: 3929_g_tests.txt

add tests for compact storage and composite cases

3929_g_tests.txt

 Support row size limits
 ---

 Key: CASSANDRA-3929
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Dave Brosius
Priority: Minor
  Labels: ponies
 Fix For: 2.0

 Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt, 
 3929_f.txt, 3929_g_tests.txt, 3929_g.txt, 3929.txt


 We currently support expiring columns by time-to-live; we've also had 
 requests for keeping the most recent N columns in a row.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5293) formalize that timestamps are epoch-in-micros in 2.0

Jonathan Ellis created CASSANDRA-5293:
-

 Summary: formalize that timestamps are epoch-in-micros in 2.0
 Key: CASSANDRA-5293
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5293
 Project: Cassandra
  Issue Type: Task
  Components: Core
Reporter: Jonathan Ellis
 Fix For: 2.0


We've worked around don't assume timestamps are actually timestamps but the 
utility is not worth the complexity and lost opportunities to optimize this 
imposes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Trivial Update of Belen40F by Belen40F