[jira] [Comment Edited] (CASSANDRA-10592) IllegalArgumentException in DataOutputBuffer.reallocate

2015-11-02 Thread Benedict (JIRA)

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

Benedict edited comment on CASSANDRA-10592 at 11/2/15 3:52 PM:
---

We should probably switch to a consistent {+ 1/2} growth.

I'll also note I'm not super keen on using {{Precondition}} to check a 
post-condition


was (Author: benedict):
We should probably switch to a consistent {+ 1/2} growth.

> IllegalArgumentException in DataOutputBuffer.reallocate
> ---
>
> Key: CASSANDRA-10592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10592
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sebastian Estevez
>Assignee: Ariel Weisberg
> Fix For: 2.2.4, 3.0.0
>
>
> CORRECTION-
> It turns out the exception occurs when running a read using a thrift jdbc 
> driver. Once you have loaded the data with stress below, run 
> SELECT * FROM "autogeneratedtest"."transaction_by_retailer" using this tool - 
> http://www.aquafold.com/aquadatastudio_downloads.html
>  
> The exception:
> {code}
> WARN  [SharedPool-Worker-1] 2015-10-22 12:58:20,792 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-1,5,main]: {}
> java.lang.RuntimeException: java.lang.IllegalArgumentException
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2366)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  ~[main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> Caused by: java.lang.IllegalArgumentException: null
>   at java.nio.ByteBuffer.allocate(ByteBuffer.java:334) ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:63)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:57)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.BufferCell$Serializer.serialize(BufferCell.java:263)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:183)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:96)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:381)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289) 
> ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1697)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2362)
>  ~[main/:na]
>   ... 4 common frames omitted
> {code}
> I was running this command:
> {code}
> tools/bin/cassandra-stress user 
> profile=~/Desktop/startup/stress/stress.yaml n=10 ops\(insert=1\) -rate 
> threads=30
> {code}
> Here's the stress.yaml UPDATED!
> {code}
> ### DML ### THIS IS UNDER 

[jira] [Commented] (CASSANDRA-10579) IndexOutOfBoundsException during memtable flushing at startup (with offheap_objects)

2015-11-02 Thread Branimir Lambov (JIRA)

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

Branimir Lambov commented on CASSANDRA-10579:
-

Did [the change to 
NodeBuilder|https://github.com/apache/cassandra/compare/trunk...belliottsmith:10579-fix#diff-6b122288f2082207dfa7648c36988a65L189]
 sneak in unintentionally?

Other than that, the patch looks good to me.

> IndexOutOfBoundsException during memtable flushing at startup (with 
> offheap_objects)
> 
>
> Key: CASSANDRA-10579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10579
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.1.10 on linux
>Reporter: Jeff Griffith
>Assignee: Benedict
> Fix For: 2.1.x
>
>
> Sometimes we have problems at startup where memtable flushes with an index 
> out of bounds exception as seen below. Cassandra is then dead in the water 
> until we track down the corresponding commit log via the segment ID and 
> remove it:
> {code}
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,595 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log (CL version 4, 
> messaging version 8)
> WARN  [SharedPool-Worker-5] 2015-10-23 14:43:36,747 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-5,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 6
> at 
> org.apache.cassandra.db.AbstractNativeCell.nametype(AbstractNativeCell.java:204)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AbstractNativeCell.isStatic(AbstractNativeCell.java:199)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCType.compare(AbstractCType.java:166)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.find(BTree.java:277) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:154) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:225)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Memtable.put(Memtable.java:210) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1225) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer$1.runMayThrow(CommitLogReplayer.java:455)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> 

[jira] [Assigned] (CASSANDRA-10631) JSON Update not working with PreparedStatement

2015-11-02 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne reassigned CASSANDRA-10631:


Assignee: Sylvain Lebresne

> JSON Update not working with PreparedStatement
> --
>
> Key: CASSANDRA-10631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10631
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Windows 7, Datastax Java Driver 2.2.0-rc2
>Reporter: Henrik Karlsson
>Assignee: Sylvain Lebresne
> Fix For: 2.2.x
>
> Attachments: test-json.zip
>
>
> When using PreparedStatement to insert and update a row with JSON the first 
> "INSERT INTO {tablename} JSON ?" statement works OK. But when calling it a 
> second time with a changed value on a field the field is not updated. If I 
> use a SimpleStatement instead ("INSERT INTO {tablename} JSON '"+json+"'") the 
> modified field is updated as expected.
> Attaching a test project that shows the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-10491) Inconsistent "position" numbering for keys in "system_schema.columns"

2015-11-02 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-10491:
--
Assignee: Sylvain Lebresne  (was: Aleksey Yeschenko)

> Inconsistent "position" numbering for keys in "system_schema.columns"
> -
>
> Key: CASSANDRA-10491
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10491
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Penick
>Assignee: Sylvain Lebresne
>Priority: Minor
>  Labels: client-impacting
> Fix For: 3.0.0
>
>
> A single component partition key starts off with a -1 position.
> {code}
> cqlsh> CREATE TABLE test.table1 (key1 text, value1 text, value2 text, PRIMARY 
> KEY(key1));
> cqlsh> SELECT keyspace_name, table_name, column_name, kind, position FROM 
> system_schema.columns WHERE keyspace_name = 'test' and  table_name = 'table1' 
> ;
>  keyspace_name | table_name | column_name | kind  | position
> ---++-+---+--
>   test | table1 |key1 | partition_key |   -1
>   test | table1 |  value1 |   regular |   -1
>   test | table1 |  value2 |   regular |   -1
> {code}
> A single component clustering key starts off with a 0 position.
> {code}
> cqlsh> CREATE TABLE test.table2 (key1 text, value1 text, value2 text, PRIMARY 
> KEY(key1, value1));
> cqlsh> SELECT keyspace_name, table_name, column_name, kind, position FROM 
> system_schema.columns WHERE keyspace_name = 'test' and  table_name = 'table2' 
> ;
>  keyspace_name | table_name | column_name | kind  | position
> ---++-+---+--
>   test | table2 |key1 | partition_key |   -1
>   test | table2 |  value1 |clustering |0
>   test | table2 |  value2 |   regular |   -1
> {code}
> When another component is added to the partition key it starts at 0.
> {code}
> cqlsh> CREATE TABLE test.table3 (key1 text, value1 text, value2 text, PRIMARY 
> KEY((key1, value1)));
> cqlsh> SELECT keyspace_name, table_name, column_name, kind, position FROM 
> system_schema.columns WHERE keyspace_name = 'test' and  table_name = 'table3' 
> ;
>  keyspace_name | table_name | column_name | kind  | position
> ---++-+---+--
>   test | table3 |key1 | partition_key |0
>   test | table3 |  value1 | partition_key |1
>   test | table3 |  value2 |   regular |   -1
> {code}
> which is the same as a multiple component clustering key.
> {code}
> cqlsh> CREATE TABLE test.table4 (key1 text, value1 text, value2 text, PRIMARY 
> KEY(key1, value1, value2));
> cqlsh> SELECT keyspace_name, table_name, column_name, kind, position FROM 
> system_schema.columns WHERE keyspace_name = 'test' and  table_name = 'table4' 
> ;
>  keyspace_name | table_name | column_name | kind  | position
> ---++-+---+--
>   test | table4 |key1 | partition_key |   -1
>   test | table4 |  value1 |clustering |0
>   test | table4 |  value2 |clustering |1
> {code}
> Shouldn't a single component partition key start off with a position of 0?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[2/2] cassandra git commit: Don't use the timestamp ordered path for name queries with counters/collections

2015-11-02 Thread slebresne
Don't use the timestamp ordered path for name queries with counters/collections

patch by slebresne; reviewed by iamaleksey for CASSANDRA-10572

Name queries usually query sstable sequentially in recency order in the
hope of only needing the more recent sstable(s). We cannot ever save
sstable that way for counters and collections however.

The patch makes name queries with either counters or collections use the
more generic path of looking at all sstables simultaneously. For that,
the patch remove the sublcasses of SinglePartitionReadCommand: those
classes were mostly justified by having name and slice queries using
different path, but it's not fully the case anymore. Both path
(timestamp ordered and all sstable simultaneously) are moved to
SinglePartitionReadCommand and used when relevant.

This actually fix a bug with counters since those were previously using
the timestamp ordered path and were potentially skipping older sstable
which is incorrect.


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

Branch: refs/heads/cassandra-3.0
Commit: 4beb54da50752fdd5573d8d1d2b0da108eaded6c
Parents: f27cc7e
Author: Sylvain Lebresne 
Authored: Fri Oct 23 11:25:49 2015 +0200
Committer: Sylvain Lebresne 
Committed: Mon Nov 2 15:11:08 2015 +0100

--
 CHANGES.txt |   1 +
 .../cql3/statements/CQL3CasRequest.java |   2 +-
 .../cql3/statements/ModificationStatement.java  |   4 +-
 .../cql3/statements/SelectStatement.java|   2 +-
 .../db/AbstractReadCommandBuilder.java  |   2 +-
 .../org/apache/cassandra/db/ReadCommand.java|  36 +-
 .../db/SinglePartitionNamesCommand.java | 276 --
 .../db/SinglePartitionReadCommand.java  | 504 +--
 .../db/SinglePartitionSliceCommand.java | 265 --
 .../db/partitions/PartitionIterators.java   |   2 +-
 .../UnfilteredPartitionIterators.java   |   2 +-
 .../internal/composites/CompositesSearcher.java |  14 +-
 .../cassandra/schema/LegacySchemaMigrator.java  |   2 +-
 .../apache/cassandra/schema/SchemaKeyspace.java |   4 +-
 .../apache/cassandra/service/DataResolver.java  |  16 +-
 .../apache/cassandra/service/StorageProxy.java  |   6 +-
 .../service/pager/SinglePartitionPager.java |   4 +-
 .../cassandra/thrift/CassandraServer.java   |  14 +-
 .../org/apache/cassandra/db/KeyspaceTest.java   |  30 +-
 .../apache/cassandra/db/RangeTombstoneTest.java |   2 +-
 .../db/SinglePartitionSliceCommandTest.java |  16 +-
 .../cassandra/service/QueryPagerTest.java   |  12 +-
 22 files changed, 541 insertions(+), 675 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 72f48f5..6d5d49b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Don't use 'names query' read path for counters (CASSANDRA-10572)
  * Fix backward compatibility for counters (CASSANDRA-10470)
  * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581)
  * Execute the metadata reload task of all registered indexes on CFS::reload 
(CASSANDRA-10604)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java 
b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
index 41aef83..9564005 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
@@ -133,7 +133,7 @@ public class CQL3CasRequest implements CASRequest
 return conditionColumns;
 }
 
-public SinglePartitionReadCommand readCommand(int nowInSec)
+public SinglePartitionReadCommand readCommand(int nowInSec)
 {
 assert !conditions.isEmpty();
 Slices.Builder builder = new Slices.Builder(cfm.comparator, 
conditions.size());

http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
index eb0f9ff..71597f4 100644
--- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
+++ 

[1/2] cassandra git commit: Don't use the timestamp ordered path for name queries with counters/collections

2015-11-02 Thread slebresne
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 f27cc7ef3 -> 4beb54da5


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/src/java/org/apache/cassandra/thrift/CassandraServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CassandraServer.java 
b/src/java/org/apache/cassandra/thrift/CassandraServer.java
index 02c0871..ee86f9d 100644
--- a/src/java/org/apache/cassandra/thrift/CassandraServer.java
+++ b/src/java/org/apache/cassandra/thrift/CassandraServer.java
@@ -85,7 +85,7 @@ public class CassandraServer implements Cassandra.Iface
 return ThriftSessionManager.instance.currentSession();
 }
 
-protected PartitionIterator read(List 
commands, org.apache.cassandra.db.ConsistencyLevel consistency_level, 
ClientState cState)
+protected PartitionIterator read(List 
commands, org.apache.cassandra.db.ConsistencyLevel consistency_level, 
ClientState cState)
 throws org.apache.cassandra.exceptions.InvalidRequestException, 
UnavailableException, TimedOutException
 {
 try
@@ -257,7 +257,7 @@ public class CassandraServer implements Cassandra.Iface
  : result;
 }
 
-private Map 
getSlice(List commands, boolean subColumnsOnly, 
int cellLimit, org.apache.cassandra.db.ConsistencyLevel consistency_level, 
ClientState cState)
+private Map 
getSlice(List commands, boolean subColumnsOnly, int 
cellLimit, org.apache.cassandra.db.ConsistencyLevel consistency_level, 
ClientState cState)
 throws org.apache.cassandra.exceptions.InvalidRequestException, 
UnavailableException, TimedOutException
 {
 try (PartitionIterator results = read(commands, consistency_level, 
cState))
@@ -551,7 +551,7 @@ public class CassandraServer implements Cassandra.Iface
 org.apache.cassandra.db.ConsistencyLevel consistencyLevel = 
ThriftConversion.fromThrift(consistency_level);
 consistencyLevel.validateForRead(keyspace);
 
-List commands = new 
ArrayList<>(keys.size());
+List commands = new 
ArrayList<>(keys.size());
 ColumnFilter columnFilter = makeColumnFilter(metadata, column_parent, 
predicate);
 ClusteringIndexFilter filter = toInternalFilter(metadata, 
column_parent, predicate);
 DataLimits limits = getLimits(1, metadata.isSuper() && 
!column_parent.isSetSuper_column(), predicate);
@@ -641,7 +641,7 @@ public class CassandraServer implements Cassandra.Iface
 }
 
 DecoratedKey dk = metadata.decorateKey(key);
-SinglePartitionReadCommand command = 
SinglePartitionReadCommand.create(true, metadata, FBUtilities.nowInSeconds(), 
columns, RowFilter.NONE, DataLimits.NONE, dk, filter);
+SinglePartitionReadCommand command = 
SinglePartitionReadCommand.create(true, metadata, FBUtilities.nowInSeconds(), 
columns, RowFilter.NONE, DataLimits.NONE, dk, filter);
 
 try (RowIterator result = 
PartitionIterators.getOnlyElement(read(Arrays.asList(command), 
consistencyLevel, cState), command))
 {
@@ -2437,8 +2437,8 @@ public class CassandraServer implements Cassandra.Iface
 
 ThriftValidation.validateKey(metadata, request.key);
 DecoratedKey dk = metadata.decorateKey(request.key);
-SinglePartitionReadCommand cmd = 
SinglePartitionReadCommand.create(true, metadata, FBUtilities.nowInSeconds(), 
columns, RowFilter.NONE, limits, dk, filter);
-return 
getSlice(Collections.singletonList(cmd),
+SinglePartitionReadCommand cmd = 
SinglePartitionReadCommand.create(true, metadata, FBUtilities.nowInSeconds(), 
columns, RowFilter.NONE, limits, dk, filter);
+return 
getSlice(Collections.singletonList(cmd),
 false,
 limits.perPartitionCount(),
 consistencyLevel,
@@ -2525,7 +2525,7 @@ public class CassandraServer implements Cassandra.Iface
 // We want to know if the partition exists, so just fetch a 
single cell.
 ClusteringIndexSliceFilter filter = new 
ClusteringIndexSliceFilter(Slices.ALL, false);
 DataLimits limits = DataLimits.thriftLimits(1, 1);
-return new SinglePartitionSliceCommand(false, 0, true, 
metadata, nowInSec, ColumnFilter.all(metadata), RowFilter.NONE, limits, key, 
filter);
+return new SinglePartitionReadCommand(false, 0, true, 
metadata, nowInSec, ColumnFilter.all(metadata), RowFilter.NONE, limits, key, 
filter);
 }
 
 // Gather the clustering for the expected values and query those.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/test/unit/org/apache/cassandra/db/KeyspaceTest.java

[jira] [Commented] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds

2015-11-02 Thread Kenneth Failbus (JIRA)

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

Kenneth Failbus commented on CASSANDRA-8072:


I am seeing this issue in 2.0.14. And it's reproducible. We are adding a node 
in a large vnode based cluster. All the other time we have successfully added 
the node in the past and this time around we are seeing this issue.

Is there a work around for this situation? Any ideas?



> Exception during startup: Unable to gossip with any seeds
> -
>
> Key: CASSANDRA-8072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8072
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ryan Springer
>Assignee: Stefania
> Fix For: 2.1.x
>
> Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, 
> casandra-system-log-with-assert-patch.log, screenshot-1.png, 
> trace_logs.tar.bz2
>
>
> When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster 
> in either ec2 or locally, an error occurs sometimes with one of the nodes 
> refusing to start C*.  The error in the /var/log/cassandra/system.log is:
> ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 513) 
> Exception encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:444)
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:609)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:502)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:52,326 Gossiper.java 
> (line 1279) Announcing shutdown
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:54,326 
> MessagingService.java (line 701) Waiting for messaging service to quiesce
>  INFO [ACCEPT-localhost/127.0.0.1] 2014-10-06 15:54:54,327 
> MessagingService.java (line 941) MessagingService has terminated the accept() 
> thread
> This errors does not always occur when provisioning a 2-node cluster, but 
> probably around half of the time on only one of the nodes.  I haven't been 
> able to reproduce this error with DSC 2.0.9, and there have been no code or 
> definition file changes in Opscenter.
> I can reproduce locally with the above steps.  I'm happy to test any proposed 
> fixes since I'm the only person able to reproduce reliably so far.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10208) Windows dtest 2.2: commitlog_test.TestCommitLog.stop_failure_policy_test

2015-11-02 Thread Joshua McKenzie (JIRA)

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

Joshua McKenzie commented on CASSANDRA-10208:
-

I'm unable to reproduce any of these failures locally though I see them popping 
up on CI on the 2.2 test runs. Are you able to reproduce any of these locally 
[~philipthompson]?

> Windows dtest 2.2: commitlog_test.TestCommitLog.stop_failure_policy_test
> 
>
> Key: CASSANDRA-10208
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10208
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
>  Labels: Windows
> Fix For: 2.2.x
>
>
> {{commitlog_test.TestCommitLog.stop_commit_failure_policy_test}} and 
> {{commitlog_test.TestCommitLog.stop_failure_policy_test}} are failing here: 
> http://cassci.datastax.com/job/cassandra-2.2_dtest_win32/72/testReport/#
> The stack trace is as follows:
> {code}
> File "C:\tools\python2\lib\unittest\case.py", line 329, in run
> testMethod()
>   File 
> "D:\jenkins\workspace\cassandra-2.2_dtest_win32\cassandra-dtest\commitlog_test.py",
>  line 254, in stop_failure_policy_test
> self.assertTrue(failure, "Cannot find the commitlog failure message in 
> logs")
>   File "C:\tools\python2\lib\unittest\case.py", line 422, in assertTrue
> raise self.failureException(msg)
> 'Cannot find the commitlog failure message in logs
> {code}
> I can only reproduce the failure for {{stop_commit_failure_policy_test}} 
> locally, but I assume that's just flakiness.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace

2015-11-02 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko resolved CASSANDRA-9960.
--
   Resolution: Cannot Reproduce
Fix Version/s: (was: 2.2.x)

> UDTs still visible after drop/recreate keyspace
> ---
>
> Key: CASSANDRA-9960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9960
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Jaroslav Kamenik
>Assignee: Robert Stupp
>Priority: Minor
> Attachments: CrashTest.java
>
>
> When deploying my app from the scratch I run sequence - drop keyspaces, 
> create keyspaces, create UDTs, create tables, generate lots of data... After 
> few cycles, randomly, cassandra ends in state, where I cannot see anything in 
> table system.schema_usertypes, when I select all rows, but queries with 
> specified keyspace_name and type_name return old values. Usually it helps to 
> restart C* and old data disapear, sometimes it needs to delete all C* data. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10579) IndexOutOfBoundsException during memtable flushing at startup (with offheap_objects)

2015-11-02 Thread Jeff Griffith (JIRA)

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

Jeff Griffith commented on CASSANDRA-10579:
---

Does the NodeBuilder thing prevent me from going to prod with your branch 
[~benedict] ?

> IndexOutOfBoundsException during memtable flushing at startup (with 
> offheap_objects)
> 
>
> Key: CASSANDRA-10579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10579
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.1.10 on linux
>Reporter: Jeff Griffith
>Assignee: Benedict
> Fix For: 2.1.x
>
>
> Sometimes we have problems at startup where memtable flushes with an index 
> out of bounds exception as seen below. Cassandra is then dead in the water 
> until we track down the corresponding commit log via the segment ID and 
> remove it:
> {code}
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,595 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log (CL version 4, 
> messaging version 8)
> WARN  [SharedPool-Worker-5] 2015-10-23 14:43:36,747 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-5,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 6
> at 
> org.apache.cassandra.db.AbstractNativeCell.nametype(AbstractNativeCell.java:204)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AbstractNativeCell.isStatic(AbstractNativeCell.java:199)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCType.compare(AbstractCType.java:166)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.find(BTree.java:277) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:154) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:225)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Memtable.put(Memtable.java:210) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1225) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer$1.runMayThrow(CommitLogReplayer.java:455)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_31]
> at 
> 

[1/3] cassandra git commit: Don't use the timestamp ordered path for name queries with counters/collections

2015-11-02 Thread slebresne
Repository: cassandra
Updated Branches:
  refs/heads/trunk cad3a2d51 -> b1f2d14f4


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/src/java/org/apache/cassandra/thrift/CassandraServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CassandraServer.java 
b/src/java/org/apache/cassandra/thrift/CassandraServer.java
index 02c0871..ee86f9d 100644
--- a/src/java/org/apache/cassandra/thrift/CassandraServer.java
+++ b/src/java/org/apache/cassandra/thrift/CassandraServer.java
@@ -85,7 +85,7 @@ public class CassandraServer implements Cassandra.Iface
 return ThriftSessionManager.instance.currentSession();
 }
 
-protected PartitionIterator read(List 
commands, org.apache.cassandra.db.ConsistencyLevel consistency_level, 
ClientState cState)
+protected PartitionIterator read(List 
commands, org.apache.cassandra.db.ConsistencyLevel consistency_level, 
ClientState cState)
 throws org.apache.cassandra.exceptions.InvalidRequestException, 
UnavailableException, TimedOutException
 {
 try
@@ -257,7 +257,7 @@ public class CassandraServer implements Cassandra.Iface
  : result;
 }
 
-private Map 
getSlice(List commands, boolean subColumnsOnly, 
int cellLimit, org.apache.cassandra.db.ConsistencyLevel consistency_level, 
ClientState cState)
+private Map 
getSlice(List commands, boolean subColumnsOnly, int 
cellLimit, org.apache.cassandra.db.ConsistencyLevel consistency_level, 
ClientState cState)
 throws org.apache.cassandra.exceptions.InvalidRequestException, 
UnavailableException, TimedOutException
 {
 try (PartitionIterator results = read(commands, consistency_level, 
cState))
@@ -551,7 +551,7 @@ public class CassandraServer implements Cassandra.Iface
 org.apache.cassandra.db.ConsistencyLevel consistencyLevel = 
ThriftConversion.fromThrift(consistency_level);
 consistencyLevel.validateForRead(keyspace);
 
-List commands = new 
ArrayList<>(keys.size());
+List commands = new 
ArrayList<>(keys.size());
 ColumnFilter columnFilter = makeColumnFilter(metadata, column_parent, 
predicate);
 ClusteringIndexFilter filter = toInternalFilter(metadata, 
column_parent, predicate);
 DataLimits limits = getLimits(1, metadata.isSuper() && 
!column_parent.isSetSuper_column(), predicate);
@@ -641,7 +641,7 @@ public class CassandraServer implements Cassandra.Iface
 }
 
 DecoratedKey dk = metadata.decorateKey(key);
-SinglePartitionReadCommand command = 
SinglePartitionReadCommand.create(true, metadata, FBUtilities.nowInSeconds(), 
columns, RowFilter.NONE, DataLimits.NONE, dk, filter);
+SinglePartitionReadCommand command = 
SinglePartitionReadCommand.create(true, metadata, FBUtilities.nowInSeconds(), 
columns, RowFilter.NONE, DataLimits.NONE, dk, filter);
 
 try (RowIterator result = 
PartitionIterators.getOnlyElement(read(Arrays.asList(command), 
consistencyLevel, cState), command))
 {
@@ -2437,8 +2437,8 @@ public class CassandraServer implements Cassandra.Iface
 
 ThriftValidation.validateKey(metadata, request.key);
 DecoratedKey dk = metadata.decorateKey(request.key);
-SinglePartitionReadCommand cmd = 
SinglePartitionReadCommand.create(true, metadata, FBUtilities.nowInSeconds(), 
columns, RowFilter.NONE, limits, dk, filter);
-return 
getSlice(Collections.singletonList(cmd),
+SinglePartitionReadCommand cmd = 
SinglePartitionReadCommand.create(true, metadata, FBUtilities.nowInSeconds(), 
columns, RowFilter.NONE, limits, dk, filter);
+return 
getSlice(Collections.singletonList(cmd),
 false,
 limits.perPartitionCount(),
 consistencyLevel,
@@ -2525,7 +2525,7 @@ public class CassandraServer implements Cassandra.Iface
 // We want to know if the partition exists, so just fetch a 
single cell.
 ClusteringIndexSliceFilter filter = new 
ClusteringIndexSliceFilter(Slices.ALL, false);
 DataLimits limits = DataLimits.thriftLimits(1, 1);
-return new SinglePartitionSliceCommand(false, 0, true, 
metadata, nowInSec, ColumnFilter.all(metadata), RowFilter.NONE, limits, key, 
filter);
+return new SinglePartitionReadCommand(false, 0, true, 
metadata, nowInSec, ColumnFilter.all(metadata), RowFilter.NONE, limits, key, 
filter);
 }
 
 // Gather the clustering for the expected values and query those.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/test/unit/org/apache/cassandra/db/KeyspaceTest.java

[2/3] cassandra git commit: Don't use the timestamp ordered path for name queries with counters/collections

2015-11-02 Thread slebresne
Don't use the timestamp ordered path for name queries with counters/collections

patch by slebresne; reviewed by iamaleksey for CASSANDRA-10572

Name queries usually query sstable sequentially in recency order in the
hope of only needing the more recent sstable(s). We cannot ever save
sstable that way for counters and collections however.

The patch makes name queries with either counters or collections use the
more generic path of looking at all sstables simultaneously. For that,
the patch remove the sublcasses of SinglePartitionReadCommand: those
classes were mostly justified by having name and slice queries using
different path, but it's not fully the case anymore. Both path
(timestamp ordered and all sstable simultaneously) are moved to
SinglePartitionReadCommand and used when relevant.

This actually fix a bug with counters since those were previously using
the timestamp ordered path and were potentially skipping older sstable
which is incorrect.


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

Branch: refs/heads/trunk
Commit: 4beb54da50752fdd5573d8d1d2b0da108eaded6c
Parents: f27cc7e
Author: Sylvain Lebresne 
Authored: Fri Oct 23 11:25:49 2015 +0200
Committer: Sylvain Lebresne 
Committed: Mon Nov 2 15:11:08 2015 +0100

--
 CHANGES.txt |   1 +
 .../cql3/statements/CQL3CasRequest.java |   2 +-
 .../cql3/statements/ModificationStatement.java  |   4 +-
 .../cql3/statements/SelectStatement.java|   2 +-
 .../db/AbstractReadCommandBuilder.java  |   2 +-
 .../org/apache/cassandra/db/ReadCommand.java|  36 +-
 .../db/SinglePartitionNamesCommand.java | 276 --
 .../db/SinglePartitionReadCommand.java  | 504 +--
 .../db/SinglePartitionSliceCommand.java | 265 --
 .../db/partitions/PartitionIterators.java   |   2 +-
 .../UnfilteredPartitionIterators.java   |   2 +-
 .../internal/composites/CompositesSearcher.java |  14 +-
 .../cassandra/schema/LegacySchemaMigrator.java  |   2 +-
 .../apache/cassandra/schema/SchemaKeyspace.java |   4 +-
 .../apache/cassandra/service/DataResolver.java  |  16 +-
 .../apache/cassandra/service/StorageProxy.java  |   6 +-
 .../service/pager/SinglePartitionPager.java |   4 +-
 .../cassandra/thrift/CassandraServer.java   |  14 +-
 .../org/apache/cassandra/db/KeyspaceTest.java   |  30 +-
 .../apache/cassandra/db/RangeTombstoneTest.java |   2 +-
 .../db/SinglePartitionSliceCommandTest.java |  16 +-
 .../cassandra/service/QueryPagerTest.java   |  12 +-
 22 files changed, 541 insertions(+), 675 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 72f48f5..6d5d49b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Don't use 'names query' read path for counters (CASSANDRA-10572)
  * Fix backward compatibility for counters (CASSANDRA-10470)
  * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581)
  * Execute the metadata reload task of all registered indexes on CFS::reload 
(CASSANDRA-10604)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java 
b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
index 41aef83..9564005 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
@@ -133,7 +133,7 @@ public class CQL3CasRequest implements CASRequest
 return conditionColumns;
 }
 
-public SinglePartitionReadCommand readCommand(int nowInSec)
+public SinglePartitionReadCommand readCommand(int nowInSec)
 {
 assert !conditions.isEmpty();
 Slices.Builder builder = new Slices.Builder(cfm.comparator, 
conditions.size());

http://git-wip-us.apache.org/repos/asf/cassandra/blob/4beb54da/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
index eb0f9ff..71597f4 100644
--- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
+++ 

[jira] [Commented] (CASSANDRA-10579) IndexOutOfBoundsException during memtable flushing at startup (with offheap_objects)

2015-11-02 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-10579:
--

Pushed an update.

> IndexOutOfBoundsException during memtable flushing at startup (with 
> offheap_objects)
> 
>
> Key: CASSANDRA-10579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10579
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.1.10 on linux
>Reporter: Jeff Griffith
>Assignee: Benedict
> Fix For: 2.1.x
>
>
> Sometimes we have problems at startup where memtable flushes with an index 
> out of bounds exception as seen below. Cassandra is then dead in the water 
> until we track down the corresponding commit log via the segment ID and 
> remove it:
> {code}
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,595 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log (CL version 4, 
> messaging version 8)
> WARN  [SharedPool-Worker-5] 2015-10-23 14:43:36,747 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-5,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 6
> at 
> org.apache.cassandra.db.AbstractNativeCell.nametype(AbstractNativeCell.java:204)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AbstractNativeCell.isStatic(AbstractNativeCell.java:199)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCType.compare(AbstractCType.java:166)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.find(BTree.java:277) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:154) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:225)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Memtable.put(Memtable.java:210) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1225) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer$1.runMayThrow(CommitLogReplayer.java:455)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_31]
> at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)

[jira] [Updated] (CASSANDRA-9748) Can't see other nodes when using multiple network interfaces

2015-11-02 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg updated CASSANDRA-9748:
--
Reviewer: Ariel Weisberg

> Can't see other nodes when using multiple network interfaces
> 
>
> Key: CASSANDRA-9748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9748
> Project: Cassandra
>  Issue Type: Improvement
> Environment: Cassandra 2.0.16; multi-DC configuration
>Reporter: Roman Bielik
>Assignee: Paulo Motta
>  Labels: docs-impacting
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: system_node1.log, system_node2.log
>
>
> The idea is to setup a multi-DC environment across 2 different networks based 
> on the following configuration recommendations:
> http://docs.datastax.com/en/cassandra/2.0/cassandra/configuration/configMultiNetworks.html
> Each node has 2 network interfaces. One used as a private network (DC1: 
> 10.0.1.x and DC2: 10.0.2.x). The second one a "public" network where all 
> nodes can see each other (this one has a higher latency). 
> Using the following settings in cassandra.yaml:
> *seeds:* public IP (same as used in broadcast_address)
> *listen_address:* private IP
> *broadcast_address:* public IP
> *rpc_address:* 0.0.0.0
> *endpoint_snitch:* GossipingPropertyFileSnitch
> _(tried different combinations with no luck)_
> No firewall and no SSL/encryption used.
> The problem is that nodes do not see each other (a gossip problem I guess). 
> The nodetool ring/status shows only the local node but not the other ones 
> (even from the same DC).
> When I set listen_address to public IP, then everything works fine, but that 
> is not the required configuration.
> _Note: Not using EC2 cloud!_
> netstat -anp | grep -E "(7199|9160|9042|7000)"
> tcp0  0 0.0.0.0:71990.0.0.0:*   
> LISTEN  3587/java   
> tcp0  0 10.0.1.1:9160   0.0.0.0:*   
> LISTEN  3587/java   
> tcp0  0 10.0.1.1:9042   0.0.0.0:*   
> LISTEN  3587/java   
> tcp0  0 10.0.1.1:7000   0.0.0.0:*   
> LISTEN  3587/java   
> tcp0  0 127.0.0.1:7199  127.0.0.1:52874 
> ESTABLISHED 3587/java   
> tcp0  0 10.0.1.1:7199   10.0.1.1:39650  
> ESTABLISHED 3587/java 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10579) IndexOutOfBoundsException during memtable flushing at startup (with offheap_objects)

2015-11-02 Thread Branimir Lambov (JIRA)

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

Branimir Lambov commented on CASSANDRA-10579:
-

I see, {{addNewKey}} calls it as well. I would remove the separate comment and 
change the "handles..." one to include that it applies {{updateFunction}}.

> IndexOutOfBoundsException during memtable flushing at startup (with 
> offheap_objects)
> 
>
> Key: CASSANDRA-10579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10579
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.1.10 on linux
>Reporter: Jeff Griffith
>Assignee: Benedict
> Fix For: 2.1.x
>
>
> Sometimes we have problems at startup where memtable flushes with an index 
> out of bounds exception as seen below. Cassandra is then dead in the water 
> until we track down the corresponding commit log via the segment ID and 
> remove it:
> {code}
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,595 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log (CL version 4, 
> messaging version 8)
> WARN  [SharedPool-Worker-5] 2015-10-23 14:43:36,747 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-5,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 6
> at 
> org.apache.cassandra.db.AbstractNativeCell.nametype(AbstractNativeCell.java:204)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AbstractNativeCell.isStatic(AbstractNativeCell.java:199)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCType.compare(AbstractCType.java:166)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.find(BTree.java:277) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:154) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:225)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Memtable.put(Memtable.java:210) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1225) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer$1.runMayThrow(CommitLogReplayer.java:455)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> 

[jira] [Commented] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair

2015-11-02 Thread Piotr Westfalewicz (JIRA)

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

Piotr Westfalewicz commented on CASSANDRA-10448:


I might have the same problem, when doing nodetool rebuild. I'm using Cassandra 
2.2.3 and want to add a new node to existing, one node cluster in Amazon AWS. 
I'll add system.log files to this issue. I can get also debug.log files but I 
prefer to send them in private to you [~yukim]. Should I send them by email for 
example?

> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Yuki Morishita
> Fix For: 2.2.x
>
> Attachments: casslogs.txt
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail 
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330 
> for range (59694553044959221,86389982480621619] failed with error [repair 
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between 
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Creating new streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10 
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.81.104 is complete
> WARN  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO  [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86 
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for 
> Repair
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061 
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Starting streaming to /10.240.134.221
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063 
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Beginning stream session with /10.240.134.221
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13 
> files(517391317 bytes)
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
>   at 
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) 
> ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
>  

[jira] [Commented] (CASSANDRA-10581) Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0

2015-11-02 Thread Jim Witschey (JIRA)

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

Jim Witschey commented on CASSANDRA-10581:
--

It's a visibility issue -- outside of some kind of logging at startup, there's 
no real feedback that you're successfully using JEMAlloc, unless there's 
something I've missed.

I hadn't though about the minor release part of it, though. Adding a warning is 
probably too much, I agree.

> Update cassandra.yaml comments to reflect memory_allocator deprecation, 
> remove in 3.0
> -
>
> Key: CASSANDRA-10581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10581
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.4, 3.0.0
>
>
> Looks like in 2.2+ changing the {{memory_allocator}} field in cassandra.yaml 
> has no effect:
> https://github.com/apache/cassandra/commit/0d2ec11c7e0abfb84d872289af6d3ac386cf381f#diff-b66584c9ce7b64019b5db5a531deeda1R207
> The instructions in comments on how to use jemalloc haven't been updated to 
> reflect this change. [~snazy], is that an accurate assessment?
> [~iamaleksey] How do we want to handle the deprecation more generally? Warn 
> on 2.2, remove in 3.0?
> EDIT: I described this in a way that isn't very clear to those unfamiliar 
> with Robert's change. To be clear: You can still use JEMAlloc with Cassandra. 
> The {{memory_allocator}} option was deprecated in favor of automatically 
> detecting if JEMAlloc is installed, and, if so, using it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10628) get JEMAlloc debug output out of nodetool output

2015-11-02 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-10628:
--

Was was the ticket that introduced that output?

> get JEMAlloc debug output out of nodetool output
> 
>
> Key: CASSANDRA-10628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10628
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.4, 3.0.0
>
>
> This is a followup ticket for CASSANDRA-10581. The consensus on the Cassandra 
> TE is that the debug output for loading JEMAlloc is helpful (or at least 
> harmless when starting C*, but not when starting {{nodetool}}, which, it 
> turns out, sources {{cassandra-env}}:
> https://github.com/apache/cassandra/blob/trunk/bin/nodetool#L53
> You can reproduce the excessive output with
> {code}
> ccm create test-nodetool-output -v git:cassandra-3.0 -n 1 ; ccm start 
> --wait-for-binary-proto ; ccm node1 nodetool ring
> {code}
> The simplest solution would probably be to redirect the output of the 
> sourcing to {{/dev/null/}}. I don't know if that's the right thing to do; it 
> may be better to move the {{LD_PRELOAD}}-setting logic to {{bin/cassandra}}. 
> I'm not sure what the reasoning would be for putting something in one place 
> or another, so I leave it to the dev team to decide on the best solution.
> Assigning [~snazy] for now; feel free to reassign



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10023) Emit a metric for number of local read and write calls

2015-11-02 Thread Chris Burroughs (JIRA)

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

Chris Burroughs commented on CASSANDRA-10023:
-

I think these would be more useful as Meter (like timeouts & failures) instead 
of just all time counters.  For example it would be easy to answer at a glance 
"are token aware clients working as expected" or "what is the ratio of local to 
remote reads since $BAD_PERF_THING happened".

> Emit a metric for number of local read and write calls
> --
>
> Key: CASSANDRA-10023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10023
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Tushar Agrawal
>Priority: Minor
>  Labels: lhf
> Attachments: 0001-CASSANDRA-10023.patch
>
>
> Many C* drivers have feature to be replica aware and chose the co-ordinator 
> which is a replica. We should add a metric which tells us whether all calls 
> to the co-ordinator are replica aware.
> We have seen issues where client thinks they are replica aware when they 
> forget to add routing key at various places in the code. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10608) Adding a dynamic column to a compact storage table with the same name as the partition key causes a memtable flush deadlock

2015-11-02 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-10608:
--

That last unit tests looks good. The 
{{CQLMetricsTest.testPreparedStatementsExecuted}} is definitively not related 
to this (I've seen that test flapping on other branches). Let's wait on the new 
dtest run to finish just to be sure and I'll commit (but please do ping me once 
the dtests finish since I won't get an email :)).

> Adding a dynamic column to a compact storage table with the same name as the 
> partition key causes a memtable flush deadlock
> ---
>
> Key: CASSANDRA-10608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10608
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: 10608.txt
>
>
> The reproduction steps for this are as follows: 
> # Create the following schema:
> {noformat}
> CREATE KEYSPACE ks WITH replication = { 'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> CREATE TABLE ks.cf (k int, v int, PRIMARY KEY(k)) WITH COMPACT STORAGE;
> {noformat}
> # Using the thrift client execute the following:
> {noformat}
> Column column = new Column(ByteBufferUtil.bytes("k"));
> column.setValue(ByteBufferUtil.bytes(1));
> column.setTimestamp(1);
> client.insert(key, new ColumnParent(compactCf), column, 
> ConsistencyLevel.ONE);
> {noformat}
> This causes an invalid {{PartitionUpdate}} to be added to {{Memtable}} 
> containing a {{PartitionColumns}} containing the partition key 
> {{ColumnDefinition}}.
> This happens because {{LegacyLayout.decodeCellName}} does not check whether 
> the {{ColumnDefinition}} is a partition key 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10579) IndexOutOfBoundsException during memtable flushing at startup (with offheap_objects)

2015-11-02 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-10579:
--

Good point. In fact, strengthening that position, it is already returning an 
unsigned short for architectures not supporting unaligned memory accesses. So 
it is definitely an oversight in the original API implementation.

I've pushed an update that fixes the {{MemoryUtil.getShort}} for unaligned 
accesses, and removed the propagation to call-sites.

> IndexOutOfBoundsException during memtable flushing at startup (with 
> offheap_objects)
> 
>
> Key: CASSANDRA-10579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10579
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.1.10 on linux
>Reporter: Jeff Griffith
>Assignee: Benedict
> Fix For: 2.1.x
>
>
> Sometimes we have problems at startup where memtable flushes with an index 
> out of bounds exception as seen below. Cassandra is then dead in the water 
> until we track down the corresponding commit log via the segment ID and 
> remove it:
> {code}
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,595 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log (CL version 4, 
> messaging version 8)
> WARN  [SharedPool-Worker-5] 2015-10-23 14:43:36,747 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-5,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 6
> at 
> org.apache.cassandra.db.AbstractNativeCell.nametype(AbstractNativeCell.java:204)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AbstractNativeCell.isStatic(AbstractNativeCell.java:199)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCType.compare(AbstractCType.java:166)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.find(BTree.java:277) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:154) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:225)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Memtable.put(Memtable.java:210) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1225) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer$1.runMayThrow(CommitLogReplayer.java:455)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> 

[jira] [Commented] (CASSANDRA-10579) IndexOutOfBoundsException during memtable flushing at startup (with offheap_objects)

2015-11-02 Thread Branimir Lambov (JIRA)

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

Branimir Lambov commented on CASSANDRA-10579:
-

LGTM

> IndexOutOfBoundsException during memtable flushing at startup (with 
> offheap_objects)
> 
>
> Key: CASSANDRA-10579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10579
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.1.10 on linux
>Reporter: Jeff Griffith
>Assignee: Benedict
> Fix For: 2.1.x
>
>
> Sometimes we have problems at startup where memtable flushes with an index 
> out of bounds exception as seen below. Cassandra is then dead in the water 
> until we track down the corresponding commit log via the segment ID and 
> remove it:
> {code}
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,595 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log (CL version 4, 
> messaging version 8)
> WARN  [SharedPool-Worker-5] 2015-10-23 14:43:36,747 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-5,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 6
> at 
> org.apache.cassandra.db.AbstractNativeCell.nametype(AbstractNativeCell.java:204)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AbstractNativeCell.isStatic(AbstractNativeCell.java:199)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCType.compare(AbstractCType.java:166)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.find(BTree.java:277) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:154) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:225)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Memtable.put(Memtable.java:210) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1225) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer$1.runMayThrow(CommitLogReplayer.java:455)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_31]
> at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)

[jira] [Commented] (CASSANDRA-10628) get JEMAlloc debug output out of nodetool output

2015-11-02 Thread Jim Witschey (JIRA)

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

Jim Witschey commented on CASSANDRA-10628:
--

[~slebresne] it was CASSANDRA-10581.

> get JEMAlloc debug output out of nodetool output
> 
>
> Key: CASSANDRA-10628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10628
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.4, 3.0.0
>
>
> This is a followup ticket for CASSANDRA-10581. The consensus on the Cassandra 
> TE is that the debug output for loading JEMAlloc is helpful (or at least 
> harmless when starting C*, but not when starting {{nodetool}}, which, it 
> turns out, sources {{cassandra-env}}:
> https://github.com/apache/cassandra/blob/trunk/bin/nodetool#L53
> You can reproduce the excessive output with
> {code}
> ccm create test-nodetool-output -v git:cassandra-3.0 -n 1 ; ccm start 
> --wait-for-binary-proto ; ccm node1 nodetool ring
> {code}
> The simplest solution would probably be to redirect the output of the 
> sourcing to {{/dev/null/}}. I don't know if that's the right thing to do; it 
> may be better to move the {{LD_PRELOAD}}-setting logic to {{bin/cassandra}}. 
> I'm not sure what the reasoning would be for putting something in one place 
> or another, so I leave it to the dev team to decide on the best solution.
> Assigning [~snazy] for now; feel free to reassign



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10485) Missing host ID on hinted handoff write

2015-11-02 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg commented on CASSANDRA-10485:


Having reviewed this further the entire approach of presenting a mutable TMD to 
readers is a little iffy.

pendingRangesFor() is not isolated from removeEndpoint() so remove endpoint is 
tearing apart the datastructure while readers of TMD are viewing an 
inconsistent state.

So you could call pendingEndpointsFor() and think you are supposed to submit a 
hint, but when the time comes to submit the hint the endpoint is already 
removed from the TMD.

I think you either need to make the entire thing atomic and make TMD COW and 
propagate the TMD the entire way. Or alternatively optimistic and if the data 
isn't there just abort dropping the hint instead of asserting that it is an 
error. You could assert instead that pendingEndpointsFor() doesn't include the 
missing endpoint.

> Missing host ID on hinted handoff write
> ---
>
> Key: CASSANDRA-10485
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10485
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> when I restart one of them I receive the error "Missing host ID":
> {noformat}
> WARN  [SharedPool-Worker-1] 2015-10-08 13:15:33,882 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-1,5,main]: {}
> java.lang.AssertionError: Missing host ID for 63.251.156.141
> at 
> org.apache.cassandra.service.StorageProxy.writeHintForMutation(StorageProxy.java:978)
>  ~[apache-cassandra-2.1.3.jar:2.1.3]
> at 
> org.apache.cassandra.service.StorageProxy$6.runMayThrow(StorageProxy.java:950)
>  ~[apache-cassandra-2.1.3.jar:2.1.3]
> at 
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2235)
>  ~[apache-cassandra-2.1.3.jar:2.1.3]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
> at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  ~[apache-cassandra-2.1.3.jar:2.1.3]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-2.1.3.jar:2.1.3]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> {noformat}
> If I made nodetool status, the problematic node has ID:
> {noformat}
> UN  10.10.10.12  1.3 TB 1   ?   
> 4d5c8fd2-a909-4f09-a23c-4cd6040f338a  rack3
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10581) Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0

2015-11-02 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-10581:
--

Are we convinced adding a new warning at every startup if you don't have 
JEMalloc in a minor release (2.2) is a good idea? Won't this freak out people, 
especially since there is no real mention of that new warning in the news file 
(the only mention is the deprecation of the yaml option)?



> Update cassandra.yaml comments to reflect memory_allocator deprecation, 
> remove in 3.0
> -
>
> Key: CASSANDRA-10581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10581
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.4, 3.0.0
>
>
> Looks like in 2.2+ changing the {{memory_allocator}} field in cassandra.yaml 
> has no effect:
> https://github.com/apache/cassandra/commit/0d2ec11c7e0abfb84d872289af6d3ac386cf381f#diff-b66584c9ce7b64019b5db5a531deeda1R207
> The instructions in comments on how to use jemalloc haven't been updated to 
> reflect this change. [~snazy], is that an accurate assessment?
> [~iamaleksey] How do we want to handle the deprecation more generally? Warn 
> on 2.2, remove in 3.0?
> EDIT: I described this in a way that isn't very clear to those unfamiliar 
> with Robert's change. To be clear: You can still use JEMAlloc with Cassandra. 
> The {{memory_allocator}} option was deprecated in favor of automatically 
> detecting if JEMAlloc is installed, and, if so, using it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair

2015-11-02 Thread Piotr Westfalewicz (JIRA)

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

Piotr Westfalewicz edited comment on CASSANDRA-10448 at 11/2/15 3:54 PM:
-

I might have the same problem, when doing nodetool rebuild. I'm using Cassandra 
2.2.3 and want to add a new node to existing, one node cluster in Amazon AWS. 
I'll add system.log files to this issue. I can get also debug.log files but I 
prefer to send them in private to you [~yukim]. Should I send them by email for 
example?


was (Author: piotrwest):
nodetool rebuild "Unknown type 0" error

> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Yuki Morishita
> Fix For: 2.2.x
>
> Attachments: casslogs.txt, receiversystem.log, sendersystem.log
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail 
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330 
> for range (59694553044959221,86389982480621619] failed with error [repair 
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between 
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Creating new streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10 
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.81.104 is complete
> WARN  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO  [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86 
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for 
> Repair
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061 
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Starting streaming to /10.240.134.221
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063 
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Beginning stream session with /10.240.134.221
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13 
> files(517391317 bytes)
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
>   at 
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) 
> ~[apache-cassandra-2.2.2.jar:2.2.2]

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

2015-11-02 Thread slebresne
Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: b1f2d14f4484ba9d6f4a84d7e0daef600fdcb7db
Parents: cad3a2d 4beb54d
Author: Sylvain Lebresne 
Authored: Mon Nov 2 15:16:57 2015 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 2 15:16:57 2015 +0100

--
 CHANGES.txt |   1 +
 .../cql3/statements/CQL3CasRequest.java |   2 +-
 .../cql3/statements/ModificationStatement.java  |   4 +-
 .../cql3/statements/SelectStatement.java|   2 +-
 .../db/AbstractReadCommandBuilder.java  |   2 +-
 .../org/apache/cassandra/db/ReadCommand.java|  36 +-
 .../db/SinglePartitionNamesCommand.java | 276 --
 .../db/SinglePartitionReadCommand.java  | 504 +--
 .../db/SinglePartitionSliceCommand.java | 262 --
 .../db/partitions/PartitionIterators.java   |   2 +-
 .../UnfilteredPartitionIterators.java   |   2 +-
 .../internal/composites/CompositesSearcher.java |  14 +-
 .../cassandra/schema/LegacySchemaMigrator.java  |   2 +-
 .../apache/cassandra/schema/SchemaKeyspace.java |   4 +-
 .../apache/cassandra/service/DataResolver.java  |  16 +-
 .../apache/cassandra/service/StorageProxy.java  |   6 +-
 .../service/pager/SinglePartitionPager.java |   4 +-
 .../cassandra/thrift/CassandraServer.java   |  14 +-
 .../org/apache/cassandra/db/KeyspaceTest.java   |  30 +-
 .../apache/cassandra/db/RangeTombstoneTest.java |   2 +-
 .../db/SinglePartitionSliceCommandTest.java |  16 +-
 .../cassandra/service/QueryPagerTest.java   |  12 +-
 22 files changed, 541 insertions(+), 672 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b1f2d14f/CHANGES.txt
--
diff --cc CHANGES.txt
index 71330e1,6d5d49b..3b33f5d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,10 -1,5 +1,11 @@@
 +3.2
 + * Added graphing option to cassandra-stress (CASSANDRA-7918)
 + * Abort in-progress queries that time out (CASSANDRA-7392)
 + * Add transparent data encryption core classes (CASSANDRA-9945)
 +
 +
  3.0
+  * Don't use 'names query' read path for counters (CASSANDRA-10572)
   * Fix backward compatibility for counters (CASSANDRA-10470)
   * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581)
   * Execute the metadata reload task of all registered indexes on CFS::reload 
(CASSANDRA-10604)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b1f2d14f/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
--
diff --cc 
src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
index 89d5165,71597f4..08b8527
--- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
@@@ -574,10 -573,9 +574,10 @@@ public abstract class ModificationState
  {
  UUID ballot = UUIDGen.getTimeUUIDFromMicros(state.getTimestamp());
  
- SinglePartitionReadCommand readCommand = 
request.readCommand(FBUtilities.nowInSeconds());
+ SinglePartitionReadCommand readCommand = 
request.readCommand(FBUtilities.nowInSeconds());
  FilteredPartition current;
 -try (ReadOrderGroup orderGroup = readCommand.startOrderGroup(); 
PartitionIterator iter = readCommand.executeInternal(orderGroup))
 +try (ReadExecutionController executionController = 
readCommand.executionController();
 + PartitionIterator iter = 
readCommand.executeInternal(executionController))
  {
  current = 
FilteredPartition.create(PartitionIterators.getOnlyElement(iter, readCommand));
  }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b1f2d14f/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b1f2d14f/src/java/org/apache/cassandra/db/ReadCommand.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b1f2d14f/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
--
diff --cc src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
index 448eaa6,4d7d93c..e7c763e
--- a/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
+++ 

[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

2015-11-02 Thread slebresne
Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: 9c9e39263d50b789f59855d7a7b55397c5820a4d
Parents: 40d1425 1e8007b
Author: Sylvain Lebresne 
Authored: Mon Nov 2 15:35:59 2015 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 2 15:35:59 2015 +0100

--
 CHANGES.txt |  1 +
 .../db/SinglePartitionReadCommand.java  | 22 
 .../db/filter/ClusteringIndexNamesFilter.java   | 14 +++--
 3 files changed, 35 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c9e3926/CHANGES.txt
--
diff --cc CHANGES.txt
index 37f7aa4,080cc51..c412bb3
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,10 -1,5 +1,11 @@@
 +3.2
 + * Added graphing option to cassandra-stress (CASSANDRA-7918)
 + * Abort in-progress queries that time out (CASSANDRA-7392)
 + * Add transparent data encryption core classes (CASSANDRA-9945)
 +
 +
  3.0
+  * Skip sstables by clustering in query by names path (10571)
   * Fix implementation of LegacyLayout.LegacyBoundComparator (CASSANDRA-10602)
   * Don't use 'names query' read path for counters (CASSANDRA-10572)
   * Fix backward compatibility for counters (CASSANDRA-10470)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c9e3926/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c9e3926/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java
--



[1/2] cassandra git commit: Exclude sstable based on clustering in query by name path

2015-11-02 Thread slebresne
Repository: cassandra
Updated Branches:
  refs/heads/trunk 40d1425a1 -> 9c9e39263


Exclude sstable based on clustering in query by name path

patch by slebresne; reviewed by iamaleksey for CASSANDRA-10571


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

Branch: refs/heads/trunk
Commit: 1e8007b1a0a1baac6282d142fbb54a7d0860e751
Parents: cba5ef6
Author: Sylvain Lebresne 
Authored: Fri Oct 23 12:20:28 2015 +0200
Committer: Sylvain Lebresne 
Committed: Mon Nov 2 15:35:20 2015 +0100

--
 CHANGES.txt |  1 +
 .../db/SinglePartitionReadCommand.java  | 22 
 .../db/filter/ClusteringIndexNamesFilter.java   | 14 +++--
 3 files changed, 35 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8007b1/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1724f01..080cc51 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Skip sstables by clustering in query by names path (10571)
  * Fix implementation of LegacyLayout.LegacyBoundComparator (CASSANDRA-10602)
  * Don't use 'names query' read path for counters (CASSANDRA-10572)
  * Fix backward compatibility for counters (CASSANDRA-10470)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8007b1/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
--
diff --git a/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java 
b/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
index 4d7d93c..065a247 100644
--- a/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
+++ b/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
@@ -675,6 +675,28 @@ public class SinglePartitionReadCommand extends ReadCommand
 if (filter == null)
 break;
 
+if (!filter.shouldInclude(sstable))
+{
+// This mean that nothing queried by the filter can be in the 
sstable. One exception is the top-level partition deletion
+// however: if it is set, it impacts everything and must be 
included. Getting that top-level partition deletion costs us
+// some seek in general however (unless the partition is 
indexed and is in the key cache), so we first check if the sstable
+// has any tombstone at all as a shortcut.
+if (sstable.getSSTableMetadata().maxLocalDeletionTime == 
Integer.MAX_VALUE)
+continue; // Means no tombstone at all, we can skip that 
sstable
+
+// We need to get the partition deletion and include it if 
it's live. In any case though, we're done with that sstable.
+sstable.incrementReadCount();
+try (UnfilteredRowIterator iter = 
sstable.iterator(partitionKey(), columnFilter(), filter.isReversed(), 
isForThrift()))
+{
+if (iter.partitionLevelDeletion().isLive())
+{
+sstablesIterated++;
+result = 
add(UnfilteredRowIterators.noRowsIterator(iter.metadata(), iter.partitionKey(), 
Rows.EMPTY_STATIC_ROW, iter.partitionLevelDeletion(), filter.isReversed()), 
result, filter, sstable.isRepaired());
+}
+}
+continue;
+}
+
 Tracing.trace("Merging data from sstable {}", 
sstable.descriptor.generation);
 sstable.incrementReadCount();
 try (UnfilteredRowIterator iter = 
filter.filter(sstable.iterator(partitionKey(), columnFilter(), 
filter.isReversed(), isForThrift(

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8007b1/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java
--
diff --git 
a/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java 
b/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java
index 388cd50..a81a7a6 100644
--- a/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java
+++ b/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java
@@ -18,6 +18,7 @@
 package org.apache.cassandra.db.filter;
 
 import java.io.IOException;
+import java.nio.ByteBuffer;
 import java.util.*;
 
 import org.apache.cassandra.config.CFMetaData;
@@ -201,8 +202,17 @@ public class ClusteringIndexNamesFilter extends 

[jira] [Commented] (CASSANDRA-10608) Adding a dynamic column to a compact storage table with the same name as the partition key causes a memtable flush deadlock

2015-11-02 Thread Mike Adamson (JIRA)

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

Mike Adamson commented on CASSANDRA-10608:
--

[~slebresne] Apologies, I thought I'd rebased before the last run but obviously 
not. I've kicked off the test builds again and am seeing 6 failures on the 3.0 
branch. 4 of these are failing on the current 3.0 test build and the other 2 
are successful here but seem to be failing on cassci. 

> Adding a dynamic column to a compact storage table with the same name as the 
> partition key causes a memtable flush deadlock
> ---
>
> Key: CASSANDRA-10608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10608
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: 10608.txt
>
>
> The reproduction steps for this are as follows: 
> # Create the following schema:
> {noformat}
> CREATE KEYSPACE ks WITH replication = { 'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> CREATE TABLE ks.cf (k int, v int, PRIMARY KEY(k)) WITH COMPACT STORAGE;
> {noformat}
> # Using the thrift client execute the following:
> {noformat}
> Column column = new Column(ByteBufferUtil.bytes("k"));
> column.setValue(ByteBufferUtil.bytes(1));
> column.setTimestamp(1);
> client.insert(key, new ColumnParent(compactCf), column, 
> ConsistencyLevel.ONE);
> {noformat}
> This causes an invalid {{PartitionUpdate}} to be added to {{Memtable}} 
> containing a {{PartitionColumns}} containing the partition key 
> {{ColumnDefinition}}.
> This happens because {{LegacyLayout.decodeCellName}} does not check whether 
> the {{ColumnDefinition}} is a partition key 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-8970) Allow custom time_format on cqlsh COPY TO

2015-11-02 Thread Aaron Ploetz (JIRA)

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

Aaron Ploetz commented on CASSANDRA-8970:
-

Not sure what happened here, but although this patch has not yet made it into 
the community version, it *IS* out there in DSE 4.8.1.  I ran across this 
StackOverflow question on Thursday (and recognized the variable name):

http://stackoverflow.com/questions/33424739/display-timestamp-format-issue-on-cql

As this *did* work at one point, this issue would seem to suggest that some 
kind of merge error took place.  Especially since patches are supposed to 
"bake" in DSC for a bit before making their way into DSE.

Basically, it looks like {{display_timestamp_format}} is not being defined.  It 
was previously defined where the {{shell}} was instantiated ({{shell = 
Shell(}}) in the "main" method, but I don't see it in the version of cqlsh that 
ships with DSE 4.8.1.  Not sure where that got lost, but that definition needs 
to be accounted for.

> Allow custom time_format on cqlsh COPY TO
> -
>
> Key: CASSANDRA-8970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8970
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Aaron Ploetz
>Assignee: Aaron Ploetz
>Priority: Trivial
>  Labels: cqlsh
> Fix For: 3.0.0 rc2, 2.2.4, 2.1.12
>
> Attachments: CASSANDRA-8970.patch
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> When executing a COPY TO from cqlsh, the user is currently has no control 
> over the format of exported timestamp columns.  If the user has indicated a 
> {{time_format}} in their cqlshrc file, that format will be used.  Otherwise, 
> the system default format will be used.
> The problem comes into play when the timestamp format used on a COPY TO, is 
> not valid when the data is sent back into Cassandra with a COPY FROM.
> For instance, if a user has {{time_format = %Y-%m-%d %H:%M:%S%Z}} specified 
> in their cqlshrc, COPY TO will format timestamp columns like this:
> {{userid|posttime|postcontent}}
> {{0|2015-03-14 14:59:00CDT|rtyeryerweh}}
> {{0|2015-03-14 14:58:00CDT|sdfsdfsdgfjdsgojr}}
> {{0|2015-03-12 14:27:00CDT|sdgfjdsgojr}}
> Executing a COPY FROM on that same file will produce an "unable to coerce to 
> formatted date(long)" error.
> Right now, the only way to change the way timestamps are formatted is to exit 
> cqlsh, modify the {{time_format}} property in cqlshrc, and restart cqlsh.  
> The ability to specify a COPY option of TIME_FORMAT with a Python strftime 
> format, would allow the user to quickly alter the timestamp format for 
> export, without reconfiguring cqlsh.
> {{aploetz@cqlsh:stackoverflow> COPY posts1 TO '/home/aploetz/posts1.csv' WITH 
> DELIMITER='|' AND HEADER=true AND TIME_FORMAT='%Y-%m-%d %H:%M:%S%z;}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Issue Comment Deleted] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair

2015-11-02 Thread Piotr Westfalewicz (JIRA)

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

Piotr Westfalewicz updated CASSANDRA-10448:
---
Comment: was deleted

(was: I might have the same problem, when doing nodetool rebuild. I'm using 
Cassandra 2.2.3 and want to add a new node to existing, one node cluster in 
Amazon AWS. I'll add system.log files to this issue. I can get also debug.log 
files but I prefer to send them in private to you [~yukim]. Should I send them 
by email for example?)

> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Yuki Morishita
> Fix For: 2.2.x
>
> Attachments: casslogs.txt, receiversystem.log, sendersystem.log
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail 
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330 
> for range (59694553044959221,86389982480621619] failed with error [repair 
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between 
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Creating new streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10 
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.81.104 is complete
> WARN  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO  [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86 
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for 
> Repair
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061 
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Starting streaming to /10.240.134.221
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063 
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Beginning stream session with /10.240.134.221
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13 
> files(517391317 bytes)
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
>   at 
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) 
> ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
>  

[jira] [Updated] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair

2015-11-02 Thread Piotr Westfalewicz (JIRA)

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

Piotr Westfalewicz updated CASSANDRA-10448:
---
Attachment: sendersystem.log
receiversystem.log

nodetool rebuild "Unknown type 0" error

> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Yuki Morishita
> Fix For: 2.2.x
>
> Attachments: casslogs.txt, receiversystem.log, sendersystem.log
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail 
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330 
> for range (59694553044959221,86389982480621619] failed with error [repair 
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between 
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Creating new streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063 
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Received streaming plan for Repair
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10 
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.81.104 is complete
> WARN  [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302 
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO  [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86 
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for 
> Repair
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061 
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Starting streaming to /10.240.134.221
> INFO  [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063 
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550, 
> ID#0] Beginning stream session with /10.240.134.221
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098 
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550 
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13 
> files(517391317 bytes)
> INFO  [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349 
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] 
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
>   at 
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) 
> ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:76)
>  ~[apache-cassandra-2.2.2.jar:2.2.2]
>   at 
> 

[jira] [Assigned] (CASSANDRA-10208) Windows dtest 2.2: commitlog_test.TestCommitLog.stop_failure_policy_test

2015-11-02 Thread Joshua McKenzie (JIRA)

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

Joshua McKenzie reassigned CASSANDRA-10208:
---

Assignee: Alan Boudreault  (was: Joshua McKenzie)

Assigning to [~aboudreault] as he wrote the tests.

> Windows dtest 2.2: commitlog_test.TestCommitLog.stop_failure_policy_test
> 
>
> Key: CASSANDRA-10208
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10208
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Philip Thompson
>Assignee: Alan Boudreault
>  Labels: Windows
> Fix For: 2.2.x
>
>
> {{commitlog_test.TestCommitLog.stop_commit_failure_policy_test}} and 
> {{commitlog_test.TestCommitLog.stop_failure_policy_test}} are failing here: 
> http://cassci.datastax.com/job/cassandra-2.2_dtest_win32/72/testReport/#
> The stack trace is as follows:
> {code}
> File "C:\tools\python2\lib\unittest\case.py", line 329, in run
> testMethod()
>   File 
> "D:\jenkins\workspace\cassandra-2.2_dtest_win32\cassandra-dtest\commitlog_test.py",
>  line 254, in stop_failure_policy_test
> self.assertTrue(failure, "Cannot find the commitlog failure message in 
> logs")
>   File "C:\tools\python2\lib\unittest\case.py", line 422, in assertTrue
> raise self.failureException(msg)
> 'Cannot find the commitlog failure message in logs
> {code}
> I can only reproduce the failure for {{stop_commit_failure_policy_test}} 
> locally, but I assume that's just flakiness.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10579) IndexOutOfBoundsException during memtable flushing at startup (with offheap_objects)

2015-11-02 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-10579:
--

No. I should have mentioned that. That's another bug that was exhibited by the 
stack trace provided by [~jeffery.griffith], and as a result should be fixed at 
the same time IMO. The {{apply}} happens twice, when it should only happen 
once. This means we're wasting space in the offheap memtables, as we copy the 
data twice. It's also a waste of cycles. The stack trace above would never have 
been encountered without this bug, so it's within scope of the ticket. Mea 
culpa for not calling it out (I actually forgot I'd done it, despite its 
importance)



> IndexOutOfBoundsException during memtable flushing at startup (with 
> offheap_objects)
> 
>
> Key: CASSANDRA-10579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10579
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.1.10 on linux
>Reporter: Jeff Griffith
>Assignee: Benedict
> Fix For: 2.1.x
>
>
> Sometimes we have problems at startup where memtable flushes with an index 
> out of bounds exception as seen below. Cassandra is then dead in the water 
> until we track down the corresponding commit log via the segment ID and 
> remove it:
> {code}
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,595 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log (CL version 4, 
> messaging version 8)
> WARN  [SharedPool-Worker-5] 2015-10-23 14:43:36,747 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-5,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 6
> at 
> org.apache.cassandra.db.AbstractNativeCell.nametype(AbstractNativeCell.java:204)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AbstractNativeCell.isStatic(AbstractNativeCell.java:199)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCType.compare(AbstractCType.java:166)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.find(BTree.java:277) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:154) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:225)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Memtable.put(Memtable.java:210) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1225) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
>  

[1/2] cassandra git commit: Proper implementation of LegacyBoundComparator

2015-11-02 Thread slebresne
Repository: cassandra
Updated Branches:
  refs/heads/trunk b1f2d14f4 -> 40d1425a1


Proper implementation of LegacyBoundComparator

patch by slebresne; reviewed by blerer for CASSANDRA-10602


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

Branch: refs/heads/trunk
Commit: cba5ef609d6d25380afcb0dff06fe325101c727c
Parents: 4beb54d
Author: Sylvain Lebresne 
Authored: Tue Oct 27 16:27:14 2015 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 2 15:28:45 2015 +0100

--
 CHANGES.txt|  1 +
 src/java/org/apache/cassandra/db/LegacyLayout.java | 16 
 2 files changed, 17 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/cba5ef60/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6d5d49b..1724f01 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Fix implementation of LegacyLayout.LegacyBoundComparator (CASSANDRA-10602)
  * Don't use 'names query' read path for counters (CASSANDRA-10572)
  * Fix backward compatibility for counters (CASSANDRA-10470)
  * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/cba5ef60/src/java/org/apache/cassandra/db/LegacyLayout.java
--
diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java 
b/src/java/org/apache/cassandra/db/LegacyLayout.java
index 6e04559..3c64443 100644
--- a/src/java/org/apache/cassandra/db/LegacyLayout.java
+++ b/src/java/org/apache/cassandra/db/LegacyLayout.java
@@ -1698,10 +1698,26 @@ public abstract class LegacyLayout
 
 public int compare(LegacyBound a, LegacyBound b)
 {
+// In the legacy sorting, BOTTOM comes before anything else
+if (a == LegacyBound.BOTTOM)
+return b == LegacyBound.BOTTOM ? 0 : -1;
+if (b == LegacyBound.BOTTOM)
+return 1;
+
+// Excluding BOTTOM, statics are always before anything else.
+if (a.isStatic != b.isStatic)
+return a.isStatic ? -1 : 1;
+
 int result = this.clusteringComparator.compare(a.bound, b.bound);
 if (result != 0)
 return result;
 
+// If both have equal "bound" but one is a collection tombstone 
and not the other, then the other comes before as it points to the beginning of 
the row.
+if (a.collectionName == null)
+return b.collectionName == null ? 0 : 1;
+if (b.collectionName == null)
+return -1;
+
 return UTF8Type.instance.compare(a.collectionName.name.bytes, 
b.collectionName.name.bytes);
 }
 }



[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

2015-11-02 Thread slebresne
Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: 40d1425a155a3b5cd8d5a7cd98900283ed5be143
Parents: b1f2d14 cba5ef6
Author: Sylvain Lebresne 
Authored: Mon Nov 2 15:29:15 2015 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 2 15:29:15 2015 +0100

--
 CHANGES.txt|  1 +
 src/java/org/apache/cassandra/db/LegacyLayout.java | 16 
 2 files changed, 17 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/40d1425a/CHANGES.txt
--
diff --cc CHANGES.txt
index 3b33f5d,1724f01..37f7aa4
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,10 -1,5 +1,11 @@@
 +3.2
 + * Added graphing option to cassandra-stress (CASSANDRA-7918)
 + * Abort in-progress queries that time out (CASSANDRA-7392)
 + * Add transparent data encryption core classes (CASSANDRA-9945)
 +
 +
  3.0
+  * Fix implementation of LegacyLayout.LegacyBoundComparator (CASSANDRA-10602)
   * Don't use 'names query' read path for counters (CASSANDRA-10572)
   * Fix backward compatibility for counters (CASSANDRA-10470)
   * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581)



cassandra git commit: Proper implementation of LegacyBoundComparator

2015-11-02 Thread slebresne
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 4beb54da5 -> cba5ef609


Proper implementation of LegacyBoundComparator

patch by slebresne; reviewed by blerer for CASSANDRA-10602


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

Branch: refs/heads/cassandra-3.0
Commit: cba5ef609d6d25380afcb0dff06fe325101c727c
Parents: 4beb54d
Author: Sylvain Lebresne 
Authored: Tue Oct 27 16:27:14 2015 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 2 15:28:45 2015 +0100

--
 CHANGES.txt|  1 +
 src/java/org/apache/cassandra/db/LegacyLayout.java | 16 
 2 files changed, 17 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/cba5ef60/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6d5d49b..1724f01 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Fix implementation of LegacyLayout.LegacyBoundComparator (CASSANDRA-10602)
  * Don't use 'names query' read path for counters (CASSANDRA-10572)
  * Fix backward compatibility for counters (CASSANDRA-10470)
  * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/cba5ef60/src/java/org/apache/cassandra/db/LegacyLayout.java
--
diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java 
b/src/java/org/apache/cassandra/db/LegacyLayout.java
index 6e04559..3c64443 100644
--- a/src/java/org/apache/cassandra/db/LegacyLayout.java
+++ b/src/java/org/apache/cassandra/db/LegacyLayout.java
@@ -1698,10 +1698,26 @@ public abstract class LegacyLayout
 
 public int compare(LegacyBound a, LegacyBound b)
 {
+// In the legacy sorting, BOTTOM comes before anything else
+if (a == LegacyBound.BOTTOM)
+return b == LegacyBound.BOTTOM ? 0 : -1;
+if (b == LegacyBound.BOTTOM)
+return 1;
+
+// Excluding BOTTOM, statics are always before anything else.
+if (a.isStatic != b.isStatic)
+return a.isStatic ? -1 : 1;
+
 int result = this.clusteringComparator.compare(a.bound, b.bound);
 if (result != 0)
 return result;
 
+// If both have equal "bound" but one is a collection tombstone 
and not the other, then the other comes before as it points to the beginning of 
the row.
+if (a.collectionName == null)
+return b.collectionName == null ? 0 : 1;
+if (b.collectionName == null)
+return -1;
+
 return UTF8Type.instance.compare(a.collectionName.name.bytes, 
b.collectionName.name.bytes);
 }
 }



cassandra git commit: Exclude sstable based on clustering in query by name path

2015-11-02 Thread slebresne
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 cba5ef609 -> 1e8007b1a


Exclude sstable based on clustering in query by name path

patch by slebresne; reviewed by iamaleksey for CASSANDRA-10571


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

Branch: refs/heads/cassandra-3.0
Commit: 1e8007b1a0a1baac6282d142fbb54a7d0860e751
Parents: cba5ef6
Author: Sylvain Lebresne 
Authored: Fri Oct 23 12:20:28 2015 +0200
Committer: Sylvain Lebresne 
Committed: Mon Nov 2 15:35:20 2015 +0100

--
 CHANGES.txt |  1 +
 .../db/SinglePartitionReadCommand.java  | 22 
 .../db/filter/ClusteringIndexNamesFilter.java   | 14 +++--
 3 files changed, 35 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8007b1/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1724f01..080cc51 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Skip sstables by clustering in query by names path (10571)
  * Fix implementation of LegacyLayout.LegacyBoundComparator (CASSANDRA-10602)
  * Don't use 'names query' read path for counters (CASSANDRA-10572)
  * Fix backward compatibility for counters (CASSANDRA-10470)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8007b1/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
--
diff --git a/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java 
b/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
index 4d7d93c..065a247 100644
--- a/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
+++ b/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
@@ -675,6 +675,28 @@ public class SinglePartitionReadCommand extends ReadCommand
 if (filter == null)
 break;
 
+if (!filter.shouldInclude(sstable))
+{
+// This mean that nothing queried by the filter can be in the 
sstable. One exception is the top-level partition deletion
+// however: if it is set, it impacts everything and must be 
included. Getting that top-level partition deletion costs us
+// some seek in general however (unless the partition is 
indexed and is in the key cache), so we first check if the sstable
+// has any tombstone at all as a shortcut.
+if (sstable.getSSTableMetadata().maxLocalDeletionTime == 
Integer.MAX_VALUE)
+continue; // Means no tombstone at all, we can skip that 
sstable
+
+// We need to get the partition deletion and include it if 
it's live. In any case though, we're done with that sstable.
+sstable.incrementReadCount();
+try (UnfilteredRowIterator iter = 
sstable.iterator(partitionKey(), columnFilter(), filter.isReversed(), 
isForThrift()))
+{
+if (iter.partitionLevelDeletion().isLive())
+{
+sstablesIterated++;
+result = 
add(UnfilteredRowIterators.noRowsIterator(iter.metadata(), iter.partitionKey(), 
Rows.EMPTY_STATIC_ROW, iter.partitionLevelDeletion(), filter.isReversed()), 
result, filter, sstable.isRepaired());
+}
+}
+continue;
+}
+
 Tracing.trace("Merging data from sstable {}", 
sstable.descriptor.generation);
 sstable.incrementReadCount();
 try (UnfilteredRowIterator iter = 
filter.filter(sstable.iterator(partitionKey(), columnFilter(), 
filter.isReversed(), isForThrift(

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8007b1/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java
--
diff --git 
a/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java 
b/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java
index 388cd50..a81a7a6 100644
--- a/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java
+++ b/src/java/org/apache/cassandra/db/filter/ClusteringIndexNamesFilter.java
@@ -18,6 +18,7 @@
 package org.apache.cassandra.db.filter;
 
 import java.io.IOException;
+import java.nio.ByteBuffer;
 import java.util.*;
 
 import org.apache.cassandra.config.CFMetaData;
@@ -201,8 +202,17 @@ public class ClusteringIndexNamesFilter extends 

[jira] [Commented] (CASSANDRA-10628) get JEMAlloc debug output out of nodetool output

2015-11-02 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-10628:
--

This seems to be breaking a bunch of dtests for the record. 

> get JEMAlloc debug output out of nodetool output
> 
>
> Key: CASSANDRA-10628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10628
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.4, 3.0.0
>
>
> This is a followup ticket for CASSANDRA-10581. The consensus on the Cassandra 
> TE is that the debug output for loading JEMAlloc is helpful (or at least 
> harmless when starting C*, but not when starting {{nodetool}}, which, it 
> turns out, sources {{cassandra-env}}:
> https://github.com/apache/cassandra/blob/trunk/bin/nodetool#L53
> You can reproduce the excessive output with
> {code}
> ccm create test-nodetool-output -v git:cassandra-3.0 -n 1 ; ccm start 
> --wait-for-binary-proto ; ccm node1 nodetool ring
> {code}
> The simplest solution would probably be to redirect the output of the 
> sourcing to {{/dev/null/}}. I don't know if that's the right thing to do; it 
> may be better to move the {{LD_PRELOAD}}-setting logic to {{bin/cassandra}}. 
> I'm not sure what the reasoning would be for putting something in one place 
> or another, so I leave it to the dev team to decide on the best solution.
> Assigning [~snazy] for now; feel free to reassign



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10592) IllegalArgumentException in DataOutputBuffer.reallocate

2015-11-02 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-10592:
--

We should probably switch to a consistent {+ 1/2} growth.

> IllegalArgumentException in DataOutputBuffer.reallocate
> ---
>
> Key: CASSANDRA-10592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10592
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sebastian Estevez
>Assignee: Ariel Weisberg
> Fix For: 2.2.4, 3.0.0
>
>
> CORRECTION-
> It turns out the exception occurs when running a read using a thrift jdbc 
> driver. Once you have loaded the data with stress below, run 
> SELECT * FROM "autogeneratedtest"."transaction_by_retailer" using this tool - 
> http://www.aquafold.com/aquadatastudio_downloads.html
>  
> The exception:
> {code}
> WARN  [SharedPool-Worker-1] 2015-10-22 12:58:20,792 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-1,5,main]: {}
> java.lang.RuntimeException: java.lang.IllegalArgumentException
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2366)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  ~[main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> Caused by: java.lang.IllegalArgumentException: null
>   at java.nio.ByteBuffer.allocate(ByteBuffer.java:334) ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:63)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:57)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.BufferCell$Serializer.serialize(BufferCell.java:263)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:183)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:96)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:381)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289) 
> ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1697)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2362)
>  ~[main/:na]
>   ... 4 common frames omitted
> {code}
> I was running this command:
> {code}
> tools/bin/cassandra-stress user 
> profile=~/Desktop/startup/stress/stress.yaml n=10 ops\(insert=1\) -rate 
> threads=30
> {code}
> Here's the stress.yaml UPDATED!
> {code}
> ### DML ### THIS IS UNDER CONSTRUCTION!!!
> # Keyspace Name
> keyspace: autogeneratedtest
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
>   CREATE KEYSPACE autogeneratedtest WITH replication = {'class': 
> 

[jira] [Commented] (CASSANDRA-10208) Windows dtest 2.2: commitlog_test.TestCommitLog.stop_failure_policy_test

2015-11-02 Thread Philip Thompson (JIRA)

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

Philip Thompson commented on CASSANDRA-10208:
-

None of the tests that fail on CI fail locally for me, but I see 
{{die_failure_policy_test}} and {{test_compression_error}} fail.

> Windows dtest 2.2: commitlog_test.TestCommitLog.stop_failure_policy_test
> 
>
> Key: CASSANDRA-10208
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10208
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Philip Thompson
>Assignee: Alan Boudreault
>  Labels: Windows
> Fix For: 2.2.x
>
>
> {{commitlog_test.TestCommitLog.stop_commit_failure_policy_test}} and 
> {{commitlog_test.TestCommitLog.stop_failure_policy_test}} are failing here: 
> http://cassci.datastax.com/job/cassandra-2.2_dtest_win32/72/testReport/#
> The stack trace is as follows:
> {code}
> File "C:\tools\python2\lib\unittest\case.py", line 329, in run
> testMethod()
>   File 
> "D:\jenkins\workspace\cassandra-2.2_dtest_win32\cassandra-dtest\commitlog_test.py",
>  line 254, in stop_failure_policy_test
> self.assertTrue(failure, "Cannot find the commitlog failure message in 
> logs")
>   File "C:\tools\python2\lib\unittest\case.py", line 422, in assertTrue
> raise self.failureException(msg)
> 'Cannot find the commitlog failure message in logs
> {code}
> I can only reproduce the failure for {{stop_commit_failure_policy_test}} 
> locally, but I assume that's just flakiness.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds

2015-11-02 Thread Kenneth Failbus (JIRA)

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

Kenneth Failbus commented on CASSANDRA-8072:


Upon enabling trace on the one see and re-bootstrapping the new node, I got the 
following exception
{code}
2015-11-02 17:34:52,150 [ACCEPT-/10.22.168.53] DEBUG MessagingService Error 
reading the socket Socket[addr=/10.xx.xx.xx,port=46678,localport=10xxx]
java.net.SocketTimeoutException
at 
sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:229)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at java.io.InputStream.read(InputStream.java:101)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:81)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at 
org.apache.cassandra.net.MessagingService$SocketThread.run(MessagingService.java:916)
{code}

> Exception during startup: Unable to gossip with any seeds
> -
>
> Key: CASSANDRA-8072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8072
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ryan Springer
>Assignee: Stefania
> Fix For: 2.1.x
>
> Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, 
> casandra-system-log-with-assert-patch.log, screenshot-1.png, 
> trace_logs.tar.bz2
>
>
> When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster 
> in either ec2 or locally, an error occurs sometimes with one of the nodes 
> refusing to start C*.  The error in the /var/log/cassandra/system.log is:
> ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 513) 
> Exception encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:444)
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:609)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:502)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:52,326 Gossiper.java 
> (line 1279) Announcing shutdown
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:54,326 
> MessagingService.java (line 701) Waiting for messaging service to quiesce
>  INFO [ACCEPT-localhost/127.0.0.1] 2014-10-06 15:54:54,327 
> MessagingService.java (line 941) MessagingService has terminated the accept() 
> thread
> This errors does not always occur when provisioning a 2-node cluster, but 
> probably around half of the time on only one of the nodes.  I haven't been 
> able to reproduce this error with DSC 2.0.9, and there have been no code or 
> definition file changes in Opscenter.
> I can reproduce locally with the above steps.  I'm happy to test any proposed 
> fixes since I'm the only person able to reproduce reliably so far.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds

2015-11-02 Thread Kenneth Failbus (JIRA)

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

Kenneth Failbus edited comment on CASSANDRA-8072 at 11/2/15 5:38 PM:
-

Upon enabling trace on the one see and re-bootstrapping the new node, I got the 
following exception on the node that was bootstrapping.
{code}
2015-11-02 17:34:52,150 [ACCEPT-/10.22.168.53] DEBUG MessagingService Error 
reading the socket Socket[addr=/10.xx.xx.xx,port=46678,localport=10xxx]
java.net.SocketTimeoutException
at 
sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:229)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at java.io.InputStream.read(InputStream.java:101)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:81)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at 
org.apache.cassandra.net.MessagingService$SocketThread.run(MessagingService.java:916)
{code}


was (Author: kenfailbus):
Upon enabling trace on the one see and re-bootstrapping the new node, I got the 
following exception
{code}
2015-11-02 17:34:52,150 [ACCEPT-/10.22.168.53] DEBUG MessagingService Error 
reading the socket Socket[addr=/10.xx.xx.xx,port=46678,localport=10xxx]
java.net.SocketTimeoutException
at 
sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:229)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at java.io.InputStream.read(InputStream.java:101)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:81)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at 
org.apache.cassandra.net.MessagingService$SocketThread.run(MessagingService.java:916)
{code}

> Exception during startup: Unable to gossip with any seeds
> -
>
> Key: CASSANDRA-8072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8072
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ryan Springer
>Assignee: Stefania
> Fix For: 2.1.x
>
> Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, 
> casandra-system-log-with-assert-patch.log, screenshot-1.png, 
> trace_logs.tar.bz2
>
>
> When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster 
> in either ec2 or locally, an error occurs sometimes with one of the nodes 
> refusing to start C*.  The error in the /var/log/cassandra/system.log is:
> ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 513) 
> Exception encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:444)
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:609)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:502)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:52,326 Gossiper.java 
> (line 1279) Announcing shutdown
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:54,326 
> MessagingService.java (line 701) Waiting for messaging service to quiesce
>  INFO [ACCEPT-localhost/127.0.0.1] 2014-10-06 15:54:54,327 
> MessagingService.java (line 941) MessagingService has terminated the accept() 
> thread
> This errors does not always occur when provisioning a 2-node cluster, but 
> probably around half of the time on only one of the nodes.  I haven't been 
> able to reproduce this error with DSC 2.0.9, and there have been no code or 
> definition file changes in Opscenter.
> I can reproduce locally with the above steps.  I'm happy to test any proposed 
> fixes since I'm the only person able to reproduce reliably so far.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds

2015-11-02 Thread Kenneth Failbus (JIRA)

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

Kenneth Failbus edited comment on CASSANDRA-8072 at 11/2/15 5:49 PM:
-

Upon enabling trace on the one seed node and re-bootstrapping the new node, I 
got the following exception on the node that was bootstrapping.
{code}
2015-11-02 17:34:52,150 [ACCEPT-/10.22.168.53] DEBUG MessagingService Error 
reading the socket Socket[addr=/10.xx.xx.xx,port=46678,localport=10xxx]
java.net.SocketTimeoutException
at 
sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:229)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at java.io.InputStream.read(InputStream.java:101)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:81)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at 
org.apache.cassandra.net.MessagingService$SocketThread.run(MessagingService.java:916)
{code}


was (Author: kenfailbus):
Upon enabling trace on the one see and re-bootstrapping the new node, I got the 
following exception on the node that was bootstrapping.
{code}
2015-11-02 17:34:52,150 [ACCEPT-/10.22.168.53] DEBUG MessagingService Error 
reading the socket Socket[addr=/10.xx.xx.xx,port=46678,localport=10xxx]
java.net.SocketTimeoutException
at 
sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:229)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at java.io.InputStream.read(InputStream.java:101)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:81)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at 
org.apache.cassandra.net.MessagingService$SocketThread.run(MessagingService.java:916)
{code}

> Exception during startup: Unable to gossip with any seeds
> -
>
> Key: CASSANDRA-8072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8072
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ryan Springer
>Assignee: Stefania
> Fix For: 2.1.x
>
> Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, 
> casandra-system-log-with-assert-patch.log, screenshot-1.png, 
> trace_logs.tar.bz2
>
>
> When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster 
> in either ec2 or locally, an error occurs sometimes with one of the nodes 
> refusing to start C*.  The error in the /var/log/cassandra/system.log is:
> ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 513) 
> Exception encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:444)
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:609)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:502)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:52,326 Gossiper.java 
> (line 1279) Announcing shutdown
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:54,326 
> MessagingService.java (line 701) Waiting for messaging service to quiesce
>  INFO [ACCEPT-localhost/127.0.0.1] 2014-10-06 15:54:54,327 
> MessagingService.java (line 941) MessagingService has terminated the accept() 
> thread
> This errors does not always occur when provisioning a 2-node cluster, but 
> probably around half of the time on only one of the nodes.  I haven't been 
> able to reproduce this error with DSC 2.0.9, and there have been no code or 
> definition file changes in Opscenter.
> I can reproduce locally with the above steps.  I'm happy to test any proposed 
> fixes since I'm the only person able to reproduce reliably so far.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CASSANDRA-10632) sstableutil tests failing on Windows

2015-11-02 Thread Jim Witschey (JIRA)
Jim Witschey created CASSANDRA-10632:


 Summary: sstableutil tests failing on Windows
 Key: CASSANDRA-10632
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10632
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey
Assignee: Jim Witschey


{{sstableutil_test.py:SSTableUtilTest.abortedcompaction_test}} and 
{{sstableutil_test.py:SSTableUtilTest.compaction_test}} fail on Windows:

http://cassci.datastax.com/view/win32/job/cassandra-3.0_dtest_win32/100/testReport/sstableutil_test/SSTableUtilTest/abortedcompaction_test/
http://cassci.datastax.com/view/win32/job/cassandra-3.0_dtest_win32/100/testReport/sstableutil_test/SSTableUtilTest/compaction_test/

This is a pretty simple failure -- looks like the underlying behavior is ok, 
but string comparison fails when the leading {{d}} in the filename is lowercase 
as returned by {{sstableutil}} (see the [{{_invoke_sstableutil}} test 
function|https://github.com/riptano/cassandra-dtest/blob/master/sstableutil_test.py#L128]),
 but uppercase as returned by {{glob.glob}} (see the [{{_get_sstable_files}} 
test 
function|https://github.com/riptano/cassandra-dtest/blob/master/sstableutil_test.py#L160]).

Do I understand correctly that Windows filenames are case-insensitive, 
including the drive portion? If that's the case, then we can just lowercase the 
file names in the test helper functions above when the tests are run on 
Windows. [~JoshuaMcKenzie] can you confirm? I'll fix this in the tests if so. 
If I'm wrong, and something in {{sstableutil}} needs to be fixed, could you 
find an assignee?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10632) sstableutil tests failing on Windows

2015-11-02 Thread Joshua McKenzie (JIRA)

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

Joshua McKenzie commented on CASSANDRA-10632:
-

While NTFS itself is case sensitive, most things in the Windows API / using 
Win32 are case-insensitive (tools used in command-prompt, command-prompt 
itself, etc), including treatment of file names. 

> sstableutil tests failing on Windows
> 
>
> Key: CASSANDRA-10632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10632
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Jim Witschey
> Fix For: 3.0.0
>
>
> {{sstableutil_test.py:SSTableUtilTest.abortedcompaction_test}} and 
> {{sstableutil_test.py:SSTableUtilTest.compaction_test}} fail on Windows:
> http://cassci.datastax.com/view/win32/job/cassandra-3.0_dtest_win32/100/testReport/sstableutil_test/SSTableUtilTest/abortedcompaction_test/
> http://cassci.datastax.com/view/win32/job/cassandra-3.0_dtest_win32/100/testReport/sstableutil_test/SSTableUtilTest/compaction_test/
> This is a pretty simple failure -- looks like the underlying behavior is ok, 
> but string comparison fails when the leading {{d}} in the filename is 
> lowercase as returned by {{sstableutil}} (see the [{{_invoke_sstableutil}} 
> test 
> function|https://github.com/riptano/cassandra-dtest/blob/master/sstableutil_test.py#L128]),
>  but uppercase as returned by {{glob.glob}} (see the [{{_get_sstable_files}} 
> test 
> function|https://github.com/riptano/cassandra-dtest/blob/master/sstableutil_test.py#L160]).
> Do I understand correctly that Windows filenames are case-insensitive, 
> including the drive portion? If that's the case, then we can just lowercase 
> the file names in the test helper functions above when the tests are run on 
> Windows. [~JoshuaMcKenzie] can you confirm? I'll fix this in the tests if so. 
> If I'm wrong, and something in {{sstableutil}} needs to be fixed, could you 
> find an assignee?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-10358) Allow CQLSSTableWriter.Builder to use custom AbstractSSTableSimpleWriter

2015-11-02 Thread Andre Turgeon (JIRA)

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

Andre Turgeon updated CASSANDRA-10358:
--
Attachment: SSTableWriterCreationStrategy.patch

Alternate implementation using a SSTableWriterCreationFactory. 

> Allow CQLSSTableWriter.Builder to use custom AbstractSSTableSimpleWriter 
> -
>
> Key: CASSANDRA-10358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10358
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Andre Turgeon
>Priority: Minor
> Attachments: SSTableWriterCreationStrategy.patch, patch.txt
>
>
> I've created a patch for your consideration. 
> This change to CQLSSTableWriter allows for a custom 
> AbstractSSTableSimpleWriter to be specified. 
> I needed this for a bulkload process I wrote. I believe the change would be 
> beneficial for other people as well. 
> Below are the reasons I needed a custom implementation of 
> AbstractSSTableSimpleWriter:
> 1) The available implementations of AbstractSSTableSimpleWriter do not 
> provide a way to specify the filename (or rather revision) of the sstable. I 
> needed to control the name because my bulkload process write sstables in 
> parallel (on multiple machines) and I wish to avoid name collisions.
> 2) I discovered a problem with SSTableSimpleUnsortedWriter where it creates 
> invalid level-compaction-style sstables; It allows a partition to span 2 
> sstables which violates the "no overlap of token ranges" constraint of level 
> compaction.   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds

2015-11-02 Thread Kenneth Failbus (JIRA)

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

Kenneth Failbus edited comment on CASSANDRA-8072 at 11/2/15 5:50 PM:
-

Upon enabling trace on the one seed node and re-bootstrapping the new node, I 
got the following exception on the node that was bootstrapping.
{code}
2015-11-02 17:34:52,150 [ACCEPT-/10.22.168.53] DEBUG MessagingService Error 
reading the socket Socket[addr=/10.xx.xx.xx,port=46678,localport=10xxx]
java.net.SocketTimeoutException
at 
sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:229)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at java.io.InputStream.read(InputStream.java:101)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:81)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at 
org.apache.cassandra.net.MessagingService$SocketThread.run(MessagingService.java:916)
{code}

And then usual exception that this ticket is mentioning about
{code}
2015-11-02 17:34:55,526 [EXPIRING-MAP-REAPER:1] TRACE ExpiringMap Expired 0 
entries
2015-11-02 17:35:00,526 [EXPIRING-MAP-REAPER:1] TRACE ExpiringMap Expired 0 
entries
2015-11-02 17:35:05,527 [EXPIRING-MAP-REAPER:1] TRACE ExpiringMap Expired 0 
entries
2015-11-02 17:35:10,527 [EXPIRING-MAP-REAPER:1] TRACE ExpiringMap Expired 0 
entries
2015-11-02 17:35:11,982 [main] ERROR CassandraDaemon Exception encountered 
during startup
java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1296)
at 
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:457)
at 
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:671)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:623)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:515)
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:437)
at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:423)
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
at com.datastax.bdp.server.DseDaemon.main(DseDaemon.java:641)
2015-11-02 17:35:11,986 [Thread-7] INFO DseDaemon DSE shutting down...
2015-11-02 17:35:11,987 [StorageServiceShutdownHook] WARN Gossiper No local 
state or state is in silent shutdown, not announcing shutdown
2015-11-02 17:35:11,987 [StorageServiceShutdownHook] INFO MessagingService 
Waiting for messaging service to quiesce
2015-11-02 17:35:11,987 [StorageServiceShutdownHook] DEBUG MessagingService 
Closing accept() thread
2015-11-02 17:35:11,988 [ACCEPT-/10.22.168.53] DEBUG MessagingService 
Asynchronous close seen by server thread
2015-11-02 17:35:11,988 [ACCEPT-/10.22.168.53] INFO MessagingService 
MessagingService has terminated the accept() thread
2015-11-02 17:35:12,068 [Thread-7] ERROR CassandraDaemon Exception in thread 
Thread[Thread-7,5,main]
{code}


was (Author: kenfailbus):
Upon enabling trace on the one seed node and re-bootstrapping the new node, I 
got the following exception on the node that was bootstrapping.
{code}
2015-11-02 17:34:52,150 [ACCEPT-/10.22.168.53] DEBUG MessagingService Error 
reading the socket Socket[addr=/10.xx.xx.xx,port=46678,localport=10xxx]
java.net.SocketTimeoutException
at 
sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:229)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at java.io.InputStream.read(InputStream.java:101)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:81)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at 
org.apache.cassandra.net.MessagingService$SocketThread.run(MessagingService.java:916)
{code}

> Exception during startup: Unable to gossip with any seeds
> -
>
> Key: CASSANDRA-8072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8072
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ryan Springer
>Assignee: Stefania
> Fix For: 2.1.x
>
> Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, 
> casandra-system-log-with-assert-patch.log, screenshot-1.png, 
> trace_logs.tar.bz2
>
>
> When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster 
> in either ec2 or locally, an error occurs sometimes with one of the nodes 
> refusing to start C*.  The error in the /var/log/cassandra/system.log is:
> ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 

[jira] [Commented] (CASSANDRA-10592) IllegalArgumentException in DataOutputBuffer.reallocate

2015-11-02 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-10592:
--

That sounds pretty reasonable to me, yeah.

> IllegalArgumentException in DataOutputBuffer.reallocate
> ---
>
> Key: CASSANDRA-10592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10592
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sebastian Estevez
>Assignee: Ariel Weisberg
> Fix For: 2.2.4, 3.0.0
>
>
> CORRECTION-
> It turns out the exception occurs when running a read using a thrift jdbc 
> driver. Once you have loaded the data with stress below, run 
> SELECT * FROM "autogeneratedtest"."transaction_by_retailer" using this tool - 
> http://www.aquafold.com/aquadatastudio_downloads.html
>  
> The exception:
> {code}
> WARN  [SharedPool-Worker-1] 2015-10-22 12:58:20,792 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-1,5,main]: {}
> java.lang.RuntimeException: java.lang.IllegalArgumentException
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2366)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  ~[main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> Caused by: java.lang.IllegalArgumentException: null
>   at java.nio.ByteBuffer.allocate(ByteBuffer.java:334) ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:63)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:57)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.BufferCell$Serializer.serialize(BufferCell.java:263)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:183)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:96)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:381)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289) 
> ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1697)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2362)
>  ~[main/:na]
>   ... 4 common frames omitted
> {code}
> I was running this command:
> {code}
> tools/bin/cassandra-stress user 
> profile=~/Desktop/startup/stress/stress.yaml n=10 ops\(insert=1\) -rate 
> threads=30
> {code}
> Here's the stress.yaml UPDATED!
> {code}
> ### DML ### THIS IS UNDER CONSTRUCTION!!!
> # Keyspace Name
> keyspace: autogeneratedtest
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
>   CREATE KEYSPACE autogeneratedtest WITH replication = {'class': 
> 

[jira] [Commented] (CASSANDRA-10358) Allow CQLSSTableWriter.Builder to use custom AbstractSSTableSimpleWriter

2015-11-02 Thread Andre Turgeon (JIRA)

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

Andre Turgeon commented on CASSANDRA-10358:
---

Thanks for the feedback [~slebresne]. I forgot to mention another requirement I 
have: I need to control the level at which an SSTable is created. 
How would you feel about having a SSTableWriter creation strategy? Something 
like this:

public interface SSTableWriterCreationStrategy {
  SSTableWriter createWriter(File directory, CFMetaData metadata);
} 

I submitted a patch with more details.


> Allow CQLSSTableWriter.Builder to use custom AbstractSSTableSimpleWriter 
> -
>
> Key: CASSANDRA-10358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10358
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Andre Turgeon
>Priority: Minor
> Attachments: SSTableWriterCreationStrategy.patch, patch.txt
>
>
> I've created a patch for your consideration. 
> This change to CQLSSTableWriter allows for a custom 
> AbstractSSTableSimpleWriter to be specified. 
> I needed this for a bulkload process I wrote. I believe the change would be 
> beneficial for other people as well. 
> Below are the reasons I needed a custom implementation of 
> AbstractSSTableSimpleWriter:
> 1) The available implementations of AbstractSSTableSimpleWriter do not 
> provide a way to specify the filename (or rather revision) of the sstable. I 
> needed to control the name because my bulkload process write sstables in 
> parallel (on multiple machines) and I wish to avoid name collisions.
> 2) I discovered a problem with SSTableSimpleUnsortedWriter where it creates 
> invalid level-compaction-style sstables; It allows a partition to span 2 
> sstables which violates the "no overlap of token ranges" constraint of level 
> compaction.   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-10358) Allow CQLSSTableWriter.Builder to use custom AbstractSSTableSimpleWriter

2015-11-02 Thread Andre Turgeon (JIRA)

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

Andre Turgeon edited comment on CASSANDRA-10358 at 11/2/15 6:53 PM:


Thanks for the feedback [~slebresne]. I forgot to mention another requirement I 
have: I need to control the level at which a SSTable is created. 
How would you feel about having a SSTableWriter creation strategy? Something 
like this:

{quote}
public interface SSTableWriterCreationStrategy {
  SSTableWriter createWriter(File directory, CFMetaData metadata);
} 
{quote}

I submitted a patch with more details.



was (Author: symbiosix):
Thanks for the feedback [~slebresne]. I forgot to mention another requirement I 
have: I need to control the level at which an SSTable is created. 
How would you feel about having a SSTableWriter creation strategy? Something 
like this:

public interface SSTableWriterCreationStrategy {
  SSTableWriter createWriter(File directory, CFMetaData metadata);
} 

I submitted a patch with more details.


> Allow CQLSSTableWriter.Builder to use custom AbstractSSTableSimpleWriter 
> -
>
> Key: CASSANDRA-10358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10358
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Andre Turgeon
>Priority: Minor
> Attachments: SSTableWriterCreationStrategy.patch, patch.txt
>
>
> I've created a patch for your consideration. 
> This change to CQLSSTableWriter allows for a custom 
> AbstractSSTableSimpleWriter to be specified. 
> I needed this for a bulkload process I wrote. I believe the change would be 
> beneficial for other people as well. 
> Below are the reasons I needed a custom implementation of 
> AbstractSSTableSimpleWriter:
> 1) The available implementations of AbstractSSTableSimpleWriter do not 
> provide a way to specify the filename (or rather revision) of the sstable. I 
> needed to control the name because my bulkload process write sstables in 
> parallel (on multiple machines) and I wish to avoid name collisions.
> 2) I discovered a problem with SSTableSimpleUnsortedWriter where it creates 
> invalid level-compaction-style sstables; It allows a partition to span 2 
> sstables which violates the "no overlap of token ranges" constraint of level 
> compaction.   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-10358) Allow CQLSSTableWriter.Builder to use custom AbstractSSTableSimpleWriter

2015-11-02 Thread Andre Turgeon (JIRA)

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

Andre Turgeon edited comment on CASSANDRA-10358 at 11/2/15 6:54 PM:


Thanks for the feedback [~slebresne]. I forgot to mention another requirement I 
have: I need to control the level at which a SSTable is created. 
How would you feel about having a SSTableWriter creation strategy? Something 
like this:

{noformat}
public interface SSTableWriterCreationStrategy {
  SSTableWriter createWriter(File directory, CFMetaData metadata);
} 
{noformat}

I submitted a patch with more details.



was (Author: symbiosix):
Thanks for the feedback [~slebresne]. I forgot to mention another requirement I 
have: I need to control the level at which a SSTable is created. 
How would you feel about having a SSTableWriter creation strategy? Something 
like this:

{quote}
public interface SSTableWriterCreationStrategy {
  SSTableWriter createWriter(File directory, CFMetaData metadata);
} 
{quote}

I submitted a patch with more details.


> Allow CQLSSTableWriter.Builder to use custom AbstractSSTableSimpleWriter 
> -
>
> Key: CASSANDRA-10358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10358
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Andre Turgeon
>Priority: Minor
> Attachments: SSTableWriterCreationStrategy.patch, patch.txt
>
>
> I've created a patch for your consideration. 
> This change to CQLSSTableWriter allows for a custom 
> AbstractSSTableSimpleWriter to be specified. 
> I needed this for a bulkload process I wrote. I believe the change would be 
> beneficial for other people as well. 
> Below are the reasons I needed a custom implementation of 
> AbstractSSTableSimpleWriter:
> 1) The available implementations of AbstractSSTableSimpleWriter do not 
> provide a way to specify the filename (or rather revision) of the sstable. I 
> needed to control the name because my bulkload process write sstables in 
> parallel (on multiple machines) and I wish to avoid name collisions.
> 2) I discovered a problem with SSTableSimpleUnsortedWriter where it creates 
> invalid level-compaction-style sstables; It allows a partition to span 2 
> sstables which violates the "no overlap of token ranges" constraint of level 
> compaction.   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10365) Store types by their CQL names in schema tables instead of fully-qualified internal class names

2015-11-02 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-10365:
---

Rebased on top of most recent cassandra-3.0 (otherwise no changes to the 
initial commits) and pushed an extra one that deals with cross-referencing 
UDTs, so that should work now.

Will have another go at it, and incorporate Sylvain's feedback/Robert's code 
tomorrow. Aside from those things, there should be nothing blocking the drivers 
at the moment.

> Store types by their CQL names in schema tables instead of fully-qualified 
> internal class names
> ---
>
> Key: CASSANDRA-10365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10365
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>  Labels: client-impacting
> Fix For: 3.0.0
>
>
> Consider saving CQL types names for column, UDF/UDA arguments and return 
> types, and UDT components.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10592) IllegalArgumentException in DataOutputBuffer.reallocate

2015-11-02 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg commented on CASSANDRA-10592:


Maybe we should use the same strategy that assumes we know how many bytes we 
are appending for both? Have doFlush() take a count and then we can make sure 
that when we double there is enough room to store the entire thing we are 
trying to write?



> IllegalArgumentException in DataOutputBuffer.reallocate
> ---
>
> Key: CASSANDRA-10592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10592
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sebastian Estevez
>Assignee: Ariel Weisberg
> Fix For: 2.2.4, 3.0.0
>
>
> CORRECTION-
> It turns out the exception occurs when running a read using a thrift jdbc 
> driver. Once you have loaded the data with stress below, run 
> SELECT * FROM "autogeneratedtest"."transaction_by_retailer" using this tool - 
> http://www.aquafold.com/aquadatastudio_downloads.html
>  
> The exception:
> {code}
> WARN  [SharedPool-Worker-1] 2015-10-22 12:58:20,792 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-1,5,main]: {}
> java.lang.RuntimeException: java.lang.IllegalArgumentException
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2366)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  ~[main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> Caused by: java.lang.IllegalArgumentException: null
>   at java.nio.ByteBuffer.allocate(ByteBuffer.java:334) ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:63)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:57)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.BufferCell$Serializer.serialize(BufferCell.java:263)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:183)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:96)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:381)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289) 
> ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1697)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2362)
>  ~[main/:na]
>   ... 4 common frames omitted
> {code}
> I was running this command:
> {code}
> tools/bin/cassandra-stress user 
> profile=~/Desktop/startup/stress/stress.yaml n=10 ops\(insert=1\) -rate 
> threads=30
> {code}
> Here's the stress.yaml UPDATED!
> {code}
> ### DML ### THIS IS UNDER CONSTRUCTION!!!
> # 

[08/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

2015-11-02 Thread benedict
Merge branch 'cassandra-2.2' into cassandra-3.0

Conflicts:
src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
test/unit/org/apache/cassandra/db/NativeCellTest.java


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

Branch: refs/heads/cassandra-3.0
Commit: 79f230f30d3834aa1b9f2d009c51b6dfc4c37288
Parents: 1e8007b 82aa796
Author: Benedict Elliott Smith 
Authored: Mon Nov 2 18:59:24 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 18:59:24 2015 +

--
 .../cassandra/utils/btree/NodeBuilder.java  |  11 +-
 .../cassandra/utils/btree/TreeBuilder.java  |   2 +-
 .../cassandra/utils/memory/MemoryUtil.java  |   2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 280 +++
 4 files changed, 288 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/79f230f3/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/79f230f3/src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
--
diff --cc src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
index cb3ddc5,000..024902e
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
+++ b/src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
@@@ -1,119 -1,0 +1,119 @@@
 +/*
 + * Licensed to the Apache Software Foundation (ASF) under one
 + * or more contributor license agreements.  See the NOTICE file
 + * distributed with this work for additional information
 + * regarding copyright ownership.  The ASF licenses this file
 + * to you under the Apache License, Version 2.0 (the
 + * "License"); you may not use this file except in compliance
 + * with the License.  You may obtain a copy of the License at
 + *
 + *   http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing,
 + * software distributed under the License is distributed on an
 + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 + * KIND, either express or implied.  See the License for the
 + * specific language governing permissions and limitations
 + * under the License.
 + */
 +package org.apache.cassandra.utils.btree;
 +
 +import java.util.Comparator;
 +
 +import static org.apache.cassandra.utils.btree.BTree.EMPTY_LEAF;
 +import static org.apache.cassandra.utils.btree.BTree.FAN_SHIFT;
 +import static org.apache.cassandra.utils.btree.BTree.POSITIVE_INFINITY;
 +
 +/**
 + * A class for constructing a new BTree, either from an existing one and some 
set of modifications
 + * or a new tree from a sorted collection of items.
 + * 
 + * This is a fairly heavy-weight object, so a ThreadLocal instance is created 
for making modifications to a tree
 + */
 +final class TreeBuilder
 +{
 +private final NodeBuilder rootBuilder = new NodeBuilder();
 +
 +/**
 + * At the highest level, we adhere to the classic b-tree insertion 
algorithm:
 + *
 + * 1. Add to the appropriate leaf
 + * 2. Split the leaf if necessary, add the median to the parent
 + * 3. Split the parent if necessary, etc.
 + *
 + * There is one important difference: we don't actually modify the 
original tree, but copy each node that we
 + * modify.  Note that every node on the path to the key being inserted or 
updated will be modified; this
 + * implies that at a minimum, the root node will be modified for every 
update, so every root is a "snapshot"
 + * of a tree that can be iterated or sliced without fear of concurrent 
modifications.
 + *
 + * The NodeBuilder class handles the details of buffering the copied 
contents of the original tree and
 + * adding in our changes.  Since NodeBuilder maintains parent/child 
references, it also handles parent-splitting
 + * (easy enough, since any node affected by the split will already be 
copied into a NodeBuilder).
 + *
 + * One other difference from the simple algorithm is that we perform 
modifications in bulk;
 + * we assume @param source has been sorted, e.g. by BTree.update, so the 
update of each key resumes where
 + * the previous left off.
 + */
 +public  Object[] update(Object[] btree, 
Comparator comparator, Iterable source, UpdateFunction updateF)
 +{
 +assert updateF != null;
 +
 +NodeBuilder current = rootBuilder;
 +current.reset(btree, 

[2/3] cassandra git commit: comment out NativeCellTest, since we don't support it in 3.0

2015-11-02 Thread benedict
comment out NativeCellTest, since we don't support it in 3.0


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

Branch: refs/heads/trunk
Commit: fd59549a39542386e681524b8760a8533d9c227d
Parents: 79f230f
Author: Benedict Elliott Smith 
Authored: Mon Nov 2 19:46:19 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 19:46:19 2015 +

--
 .../org/apache/cassandra/db/NativeCellTest.java | 551 +--
 1 file changed, 271 insertions(+), 280 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fd59549a/test/unit/org/apache/cassandra/db/NativeCellTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/NativeCellTest.java 
b/test/unit/org/apache/cassandra/db/NativeCellTest.java
index 70b7b87..b804412 100644
--- a/test/unit/org/apache/cassandra/db/NativeCellTest.java
+++ b/test/unit/org/apache/cassandra/db/NativeCellTest.java
@@ -1,280 +1,271 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.db;
-
-import java.io.ByteArrayInputStream;
-import java.io.DataInputStream;
-import java.io.IOException;
-import java.nio.ByteBuffer;
-import java.security.MessageDigest;
-import java.security.NoSuchAlgorithmException;
-import java.util.Arrays;
-import java.util.Random;
-import java.util.concurrent.ThreadLocalRandom;
-
-import org.junit.Assert;
-import org.junit.Test;
-
-import org.apache.cassandra.config.CFMetaData;
-import org.apache.cassandra.config.ColumnDefinition;
-import org.apache.cassandra.cql3.ColumnIdentifier;
-import org.apache.cassandra.db.composites.CellName;
-import org.apache.cassandra.db.composites.CellNameType;
-import org.apache.cassandra.db.composites.CompoundDenseCellNameType;
-import org.apache.cassandra.db.composites.CompoundSparseCellNameType;
-import org.apache.cassandra.db.composites.SimpleDenseCellNameType;
-import org.apache.cassandra.db.composites.SimpleSparseCellNameType;
-import org.apache.cassandra.db.context.CounterContext;
-import org.apache.cassandra.db.marshal.AbstractType;
-import org.apache.cassandra.db.marshal.UTF8Type;
-import org.apache.cassandra.exceptions.ConfigurationException;
-import org.apache.cassandra.io.util.DataOutputBuffer;
-import org.apache.cassandra.utils.concurrent.OpOrder;
-import org.apache.cassandra.utils.memory.NativeAllocator;
-import org.apache.cassandra.utils.memory.NativePool;
-
-import static org.apache.cassandra.db.composites.CellNames.compositeDense;
-import static org.apache.cassandra.db.composites.CellNames.compositeSparse;
-import static org.apache.cassandra.db.composites.CellNames.simpleDense;
-import static org.apache.cassandra.db.composites.CellNames.simpleSparse;
-import static org.apache.cassandra.utils.ByteBufferUtil.bytes;
-
-public class NativeCellTest
-{
-
-private static final NativeAllocator nativeAllocator = new 
NativePool(Integer.MAX_VALUE, Integer.MAX_VALUE, 1f, null).newAllocator();
-private static final OpOrder.Group group = new OpOrder().start();
-
-static class Name
-{
-final CellName name;
-final CellNameType type;
-Name(CellName name, CellNameType type)
-{
-this.name = name;
-this.type = type;
-}
-}
-
-static ByteBuffer[] bytess(String ... strings)
-{
-ByteBuffer[] r = new ByteBuffer[strings.length];
-for (int i = 0 ; i < r.length ; i++)
-r[i] = bytes(strings[i]);
-return r;
-}
-
-final static Name[] TESTS = new Name[]
-  {
-  new Name(simpleDense(bytes("a")), new 
SimpleDenseCellNameType(UTF8Type.instance)),
-  new Name(simpleSparse(new ColumnIdentifier("a", 
true)), new SimpleSparseCellNameType(UTF8Type.instance)),
-  

[1/3] cassandra git commit: comment out NativeCellTest, since we don't support it in 3.0

2015-11-02 Thread benedict
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 79f230f30 -> fd59549a3
  refs/heads/trunk fbdeef836 -> 663cd43ab


comment out NativeCellTest, since we don't support it in 3.0


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

Branch: refs/heads/cassandra-3.0
Commit: fd59549a39542386e681524b8760a8533d9c227d
Parents: 79f230f
Author: Benedict Elliott Smith 
Authored: Mon Nov 2 19:46:19 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 19:46:19 2015 +

--
 .../org/apache/cassandra/db/NativeCellTest.java | 551 +--
 1 file changed, 271 insertions(+), 280 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fd59549a/test/unit/org/apache/cassandra/db/NativeCellTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/NativeCellTest.java 
b/test/unit/org/apache/cassandra/db/NativeCellTest.java
index 70b7b87..b804412 100644
--- a/test/unit/org/apache/cassandra/db/NativeCellTest.java
+++ b/test/unit/org/apache/cassandra/db/NativeCellTest.java
@@ -1,280 +1,271 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.db;
-
-import java.io.ByteArrayInputStream;
-import java.io.DataInputStream;
-import java.io.IOException;
-import java.nio.ByteBuffer;
-import java.security.MessageDigest;
-import java.security.NoSuchAlgorithmException;
-import java.util.Arrays;
-import java.util.Random;
-import java.util.concurrent.ThreadLocalRandom;
-
-import org.junit.Assert;
-import org.junit.Test;
-
-import org.apache.cassandra.config.CFMetaData;
-import org.apache.cassandra.config.ColumnDefinition;
-import org.apache.cassandra.cql3.ColumnIdentifier;
-import org.apache.cassandra.db.composites.CellName;
-import org.apache.cassandra.db.composites.CellNameType;
-import org.apache.cassandra.db.composites.CompoundDenseCellNameType;
-import org.apache.cassandra.db.composites.CompoundSparseCellNameType;
-import org.apache.cassandra.db.composites.SimpleDenseCellNameType;
-import org.apache.cassandra.db.composites.SimpleSparseCellNameType;
-import org.apache.cassandra.db.context.CounterContext;
-import org.apache.cassandra.db.marshal.AbstractType;
-import org.apache.cassandra.db.marshal.UTF8Type;
-import org.apache.cassandra.exceptions.ConfigurationException;
-import org.apache.cassandra.io.util.DataOutputBuffer;
-import org.apache.cassandra.utils.concurrent.OpOrder;
-import org.apache.cassandra.utils.memory.NativeAllocator;
-import org.apache.cassandra.utils.memory.NativePool;
-
-import static org.apache.cassandra.db.composites.CellNames.compositeDense;
-import static org.apache.cassandra.db.composites.CellNames.compositeSparse;
-import static org.apache.cassandra.db.composites.CellNames.simpleDense;
-import static org.apache.cassandra.db.composites.CellNames.simpleSparse;
-import static org.apache.cassandra.utils.ByteBufferUtil.bytes;
-
-public class NativeCellTest
-{
-
-private static final NativeAllocator nativeAllocator = new 
NativePool(Integer.MAX_VALUE, Integer.MAX_VALUE, 1f, null).newAllocator();
-private static final OpOrder.Group group = new OpOrder().start();
-
-static class Name
-{
-final CellName name;
-final CellNameType type;
-Name(CellName name, CellNameType type)
-{
-this.name = name;
-this.type = type;
-}
-}
-
-static ByteBuffer[] bytess(String ... strings)
-{
-ByteBuffer[] r = new ByteBuffer[strings.length];
-for (int i = 0 ; i < r.length ; i++)
-r[i] = bytes(strings[i]);
-return r;
-}
-
-final static Name[] TESTS = new Name[]
-  {
-  new Name(simpleDense(bytes("a")), new 

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

2015-11-02 Thread benedict
Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: 663cd43ab17454fe7d926b38de48e9b7bf908ca9
Parents: fbdeef8 fd59549
Author: Benedict Elliott Smith 
Authored: Mon Nov 2 19:46:27 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 19:46:27 2015 +

--
 .../org/apache/cassandra/db/NativeCellTest.java | 551 +--
 1 file changed, 271 insertions(+), 280 deletions(-)
--




[10/10] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

2015-11-02 Thread benedict
Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: fbdeef836ae8f88bb0e0a7081c512629caf61c1d
Parents: 9c9e392 79f230f
Author: Benedict Elliott Smith 
Authored: Mon Nov 2 18:59:35 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 18:59:35 2015 +

--
 .../cassandra/utils/btree/NodeBuilder.java  |  11 +-
 .../cassandra/utils/btree/TreeBuilder.java  |   2 +-
 .../cassandra/utils/memory/MemoryUtil.java  |   2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 280 +++
 4 files changed, 288 insertions(+), 7 deletions(-)
--




[jira] [Updated] (CASSANDRA-9712) Refactor CFMetaData

2015-11-02 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-9712:
-
Assignee: (was: Aleksey Yeschenko)

> Refactor CFMetaData
> ---
>
> Key: CASSANDRA-9712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9712
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
> Fix For: 3.x
>
>
> As part of CASSANDRA-9425 and a follow-up to CASSANDRA-9665, and a 
> pre-requisite for new schema change protocol, this ticket will do the 
> following
> 1. Make the triggers {{HashMap}} immutable (new {{Triggers}} class)
> 2. Allow multiple 2i definitions per column in CFMetaData
> 3. 
> 4. Rename and move {{config.CFMetaData}} to {{schema.TableMetadata}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10592) IllegalArgumentException in DataOutputBuffer.reallocate

2015-11-02 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg commented on CASSANDRA-10592:


Pushed an update with what I am thinking.

> IllegalArgumentException in DataOutputBuffer.reallocate
> ---
>
> Key: CASSANDRA-10592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10592
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sebastian Estevez
>Assignee: Ariel Weisberg
> Fix For: 2.2.4, 3.0.0
>
>
> CORRECTION-
> It turns out the exception occurs when running a read using a thrift jdbc 
> driver. Once you have loaded the data with stress below, run 
> SELECT * FROM "autogeneratedtest"."transaction_by_retailer" using this tool - 
> http://www.aquafold.com/aquadatastudio_downloads.html
>  
> The exception:
> {code}
> WARN  [SharedPool-Worker-1] 2015-10-22 12:58:20,792 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-1,5,main]: {}
> java.lang.RuntimeException: java.lang.IllegalArgumentException
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2366)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  ~[main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> Caused by: java.lang.IllegalArgumentException: null
>   at java.nio.ByteBuffer.allocate(ByteBuffer.java:334) ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:63)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:57)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:374)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.BufferCell$Serializer.serialize(BufferCell.java:263)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:183)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:96)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:381)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289) 
> ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1697)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2362)
>  ~[main/:na]
>   ... 4 common frames omitted
> {code}
> I was running this command:
> {code}
> tools/bin/cassandra-stress user 
> profile=~/Desktop/startup/stress/stress.yaml n=10 ops\(insert=1\) -rate 
> threads=30
> {code}
> Here's the stress.yaml UPDATED!
> {code}
> ### DML ### THIS IS UNDER CONSTRUCTION!!!
> # Keyspace Name
> keyspace: autogeneratedtest
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
>   CREATE KEYSPACE autogeneratedtest WITH replication = {'class': 
> 

[jira] [Commented] (CASSANDRA-9748) Can't see other nodes when using multiple network interfaces

2015-11-02 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg commented on CASSANDRA-9748:
---

I'm a little confused as to why binding to the private IP for the interface 
isn't working? I thought you can't bind to the public IP. You have to bind to 
the private one and I thought that was how you accepted connections on the 
public IP and private IP. It's not two different interfaces it's one interface.

I just did a quick test. I bound with socat using the private IP and then 
connected using the public IP and it worked fine.

Is there an explanation for that?

I also thought that it was always safe to use the public IP when advertising 
and not the local one and that EC2 magically takes care of not routing 
everything over the wider network.

> Can't see other nodes when using multiple network interfaces
> 
>
> Key: CASSANDRA-9748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9748
> Project: Cassandra
>  Issue Type: Improvement
> Environment: Cassandra 2.0.16; multi-DC configuration
>Reporter: Roman Bielik
>Assignee: Paulo Motta
>  Labels: docs-impacting
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: system_node1.log, system_node2.log
>
>
> The idea is to setup a multi-DC environment across 2 different networks based 
> on the following configuration recommendations:
> http://docs.datastax.com/en/cassandra/2.0/cassandra/configuration/configMultiNetworks.html
> Each node has 2 network interfaces. One used as a private network (DC1: 
> 10.0.1.x and DC2: 10.0.2.x). The second one a "public" network where all 
> nodes can see each other (this one has a higher latency). 
> Using the following settings in cassandra.yaml:
> *seeds:* public IP (same as used in broadcast_address)
> *listen_address:* private IP
> *broadcast_address:* public IP
> *rpc_address:* 0.0.0.0
> *endpoint_snitch:* GossipingPropertyFileSnitch
> _(tried different combinations with no luck)_
> No firewall and no SSL/encryption used.
> The problem is that nodes do not see each other (a gossip problem I guess). 
> The nodetool ring/status shows only the local node but not the other ones 
> (even from the same DC).
> When I set listen_address to public IP, then everything works fine, but that 
> is not the required configuration.
> _Note: Not using EC2 cloud!_
> netstat -anp | grep -E "(7199|9160|9042|7000)"
> tcp0  0 0.0.0.0:71990.0.0.0:*   
> LISTEN  3587/java   
> tcp0  0 10.0.1.1:9160   0.0.0.0:*   
> LISTEN  3587/java   
> tcp0  0 10.0.1.1:9042   0.0.0.0:*   
> LISTEN  3587/java   
> tcp0  0 10.0.1.1:7000   0.0.0.0:*   
> LISTEN  3587/java   
> tcp0  0 127.0.0.1:7199  127.0.0.1:52874 
> ESTABLISHED 3587/java   
> tcp0  0 10.0.1.1:7199   10.0.1.1:39650  
> ESTABLISHED 3587/java 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[05/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2015-11-02 Thread benedict
Merge branch 'cassandra-2.1' into cassandra-2.2

Conflicts:
src/java/org/apache/cassandra/utils/btree/NodeBuilder.java


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

Branch: refs/heads/cassandra-3.0
Commit: 82aa7969c1b77967ef2e6ab847cb5c11cc4c002c
Parents: 0fbf715 986a1a7
Author: Benedict Elliott Smith 
Authored: Mon Nov 2 18:57:37 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 18:57:37 2015 +

--
 .../apache/cassandra/utils/btree/Builder.java   |  2 +-
 .../cassandra/utils/btree/NodeBuilder.java  | 11 +++
 .../cassandra/utils/memory/MemoryUtil.java  |  2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 31 +++-
 4 files changed, 38 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/82aa7969/src/java/org/apache/cassandra/utils/btree/Builder.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/82aa7969/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/82aa7969/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
--



[03/10] cassandra git commit: 10579: fix NativeCell behaviour when clustering components > 32K in size

2015-11-02 Thread benedict
10579: fix NativeCell behaviour when clustering components > 32K in size


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

Branch: refs/heads/cassandra-3.0
Commit: 986a1a769437bf1e47248e257772a074c27bac92
Parents: 83fb3cc
Author: Benedict Elliott Smith 
Authored: Mon Oct 26 16:50:39 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 16:40:35 2015 +

--
 .../cassandra/utils/btree/NodeBuilder.java  |  9 +++---
 .../cassandra/utils/memory/MemoryUtil.java  |  2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 31 +++-
 3 files changed, 36 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
--
diff --git a/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java 
b/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
index 9d57182..0e304e5 100644
--- a/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
+++ b/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
@@ -185,9 +185,8 @@ final class NodeBuilder
 }
 else
 {
-// if not found, we need to apply updateFunction still
-key = updateFunction.apply(key);
-addNewKey(key); // handles splitting parent if necessary 
via ensureRoom
+// if not found, we need to apply updateFunction still, 
which is handled in addNewKey
+addNewKey(key);
 }
 
 // done, so return null
@@ -315,7 +314,9 @@ final class NodeBuilder
 copyFromKeyPosition++;
 }
 
-// puts the provided key in the builder, with no impact on treatment of 
data from copyf
+// applies the updateFunction
+// puts the resulting key into the builder
+// splits the parent if necessary via ensureRoom
 void addNewKey(Object key)
 {
 ensureRoom(buildKeyPosition + 1);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
--
diff --git a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java 
b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
index 57edc52..f96957d 100644
--- a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
+++ b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
@@ -98,7 +98,7 @@ public abstract class MemoryUtil
 
 public static int getShort(long address)
 {
-return UNALIGNED ? unsafe.getShort(address) : getShortByByte(address);
+return UNALIGNED ? unsafe.getShort(address) & 0x : 
getShortByByte(address);
 }
 
 public static int getInt(long address)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/test/unit/org/apache/cassandra/db/NativeCellTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/NativeCellTest.java 
b/test/unit/org/apache/cassandra/db/NativeCellTest.java
index 6a2bf73..70b7b87 100644
--- a/test/unit/org/apache/cassandra/db/NativeCellTest.java
+++ b/test/unit/org/apache/cassandra/db/NativeCellTest.java
@@ -85,9 +85,38 @@ public class NativeCellTest
   new Name(simpleSparse(new ColumnIdentifier("a", 
true)), new SimpleSparseCellNameType(UTF8Type.instance)),
   new Name(compositeDense(bytes("a"), bytes("b")), 
new CompoundDenseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
   new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), false), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
-  new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), true), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance)))
+  new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), true), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
+  new Name(simpleDense(huge('a', 4)), new 
SimpleDenseCellNameType(UTF8Type.instance)),
+  new Name(simpleSparse(new 
ColumnIdentifier(hugestr('a', 4), true)), new 

[07/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2015-11-02 Thread benedict
Merge branch 'cassandra-2.1' into cassandra-2.2

Conflicts:
src/java/org/apache/cassandra/utils/btree/NodeBuilder.java


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

Branch: refs/heads/trunk
Commit: 82aa7969c1b77967ef2e6ab847cb5c11cc4c002c
Parents: 0fbf715 986a1a7
Author: Benedict Elliott Smith 
Authored: Mon Nov 2 18:57:37 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 18:57:37 2015 +

--
 .../apache/cassandra/utils/btree/Builder.java   |  2 +-
 .../cassandra/utils/btree/NodeBuilder.java  | 11 +++
 .../cassandra/utils/memory/MemoryUtil.java  |  2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 31 +++-
 4 files changed, 38 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/82aa7969/src/java/org/apache/cassandra/utils/btree/Builder.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/82aa7969/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/82aa7969/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
--



[04/10] cassandra git commit: 10579: fix NativeCell behaviour when clustering components > 32K in size

2015-11-02 Thread benedict
10579: fix NativeCell behaviour when clustering components > 32K in size


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

Branch: refs/heads/trunk
Commit: 986a1a769437bf1e47248e257772a074c27bac92
Parents: 83fb3cc
Author: Benedict Elliott Smith 
Authored: Mon Oct 26 16:50:39 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 16:40:35 2015 +

--
 .../cassandra/utils/btree/NodeBuilder.java  |  9 +++---
 .../cassandra/utils/memory/MemoryUtil.java  |  2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 31 +++-
 3 files changed, 36 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
--
diff --git a/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java 
b/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
index 9d57182..0e304e5 100644
--- a/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
+++ b/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
@@ -185,9 +185,8 @@ final class NodeBuilder
 }
 else
 {
-// if not found, we need to apply updateFunction still
-key = updateFunction.apply(key);
-addNewKey(key); // handles splitting parent if necessary 
via ensureRoom
+// if not found, we need to apply updateFunction still, 
which is handled in addNewKey
+addNewKey(key);
 }
 
 // done, so return null
@@ -315,7 +314,9 @@ final class NodeBuilder
 copyFromKeyPosition++;
 }
 
-// puts the provided key in the builder, with no impact on treatment of 
data from copyf
+// applies the updateFunction
+// puts the resulting key into the builder
+// splits the parent if necessary via ensureRoom
 void addNewKey(Object key)
 {
 ensureRoom(buildKeyPosition + 1);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
--
diff --git a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java 
b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
index 57edc52..f96957d 100644
--- a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
+++ b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
@@ -98,7 +98,7 @@ public abstract class MemoryUtil
 
 public static int getShort(long address)
 {
-return UNALIGNED ? unsafe.getShort(address) : getShortByByte(address);
+return UNALIGNED ? unsafe.getShort(address) & 0x : 
getShortByByte(address);
 }
 
 public static int getInt(long address)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/test/unit/org/apache/cassandra/db/NativeCellTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/NativeCellTest.java 
b/test/unit/org/apache/cassandra/db/NativeCellTest.java
index 6a2bf73..70b7b87 100644
--- a/test/unit/org/apache/cassandra/db/NativeCellTest.java
+++ b/test/unit/org/apache/cassandra/db/NativeCellTest.java
@@ -85,9 +85,38 @@ public class NativeCellTest
   new Name(simpleSparse(new ColumnIdentifier("a", 
true)), new SimpleSparseCellNameType(UTF8Type.instance)),
   new Name(compositeDense(bytes("a"), bytes("b")), 
new CompoundDenseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
   new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), false), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
-  new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), true), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance)))
+  new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), true), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
+  new Name(simpleDense(huge('a', 4)), new 
SimpleDenseCellNameType(UTF8Type.instance)),
+  new Name(simpleSparse(new 
ColumnIdentifier(hugestr('a', 4), true)), new 

[09/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

2015-11-02 Thread benedict
Merge branch 'cassandra-2.2' into cassandra-3.0

Conflicts:
src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
test/unit/org/apache/cassandra/db/NativeCellTest.java


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

Branch: refs/heads/trunk
Commit: 79f230f30d3834aa1b9f2d009c51b6dfc4c37288
Parents: 1e8007b 82aa796
Author: Benedict Elliott Smith 
Authored: Mon Nov 2 18:59:24 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 18:59:24 2015 +

--
 .../cassandra/utils/btree/NodeBuilder.java  |  11 +-
 .../cassandra/utils/btree/TreeBuilder.java  |   2 +-
 .../cassandra/utils/memory/MemoryUtil.java  |   2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 280 +++
 4 files changed, 288 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/79f230f3/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/79f230f3/src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
--
diff --cc src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
index cb3ddc5,000..024902e
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
+++ b/src/java/org/apache/cassandra/utils/btree/TreeBuilder.java
@@@ -1,119 -1,0 +1,119 @@@
 +/*
 + * Licensed to the Apache Software Foundation (ASF) under one
 + * or more contributor license agreements.  See the NOTICE file
 + * distributed with this work for additional information
 + * regarding copyright ownership.  The ASF licenses this file
 + * to you under the Apache License, Version 2.0 (the
 + * "License"); you may not use this file except in compliance
 + * with the License.  You may obtain a copy of the License at
 + *
 + *   http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing,
 + * software distributed under the License is distributed on an
 + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 + * KIND, either express or implied.  See the License for the
 + * specific language governing permissions and limitations
 + * under the License.
 + */
 +package org.apache.cassandra.utils.btree;
 +
 +import java.util.Comparator;
 +
 +import static org.apache.cassandra.utils.btree.BTree.EMPTY_LEAF;
 +import static org.apache.cassandra.utils.btree.BTree.FAN_SHIFT;
 +import static org.apache.cassandra.utils.btree.BTree.POSITIVE_INFINITY;
 +
 +/**
 + * A class for constructing a new BTree, either from an existing one and some 
set of modifications
 + * or a new tree from a sorted collection of items.
 + * 
 + * This is a fairly heavy-weight object, so a ThreadLocal instance is created 
for making modifications to a tree
 + */
 +final class TreeBuilder
 +{
 +private final NodeBuilder rootBuilder = new NodeBuilder();
 +
 +/**
 + * At the highest level, we adhere to the classic b-tree insertion 
algorithm:
 + *
 + * 1. Add to the appropriate leaf
 + * 2. Split the leaf if necessary, add the median to the parent
 + * 3. Split the parent if necessary, etc.
 + *
 + * There is one important difference: we don't actually modify the 
original tree, but copy each node that we
 + * modify.  Note that every node on the path to the key being inserted or 
updated will be modified; this
 + * implies that at a minimum, the root node will be modified for every 
update, so every root is a "snapshot"
 + * of a tree that can be iterated or sliced without fear of concurrent 
modifications.
 + *
 + * The NodeBuilder class handles the details of buffering the copied 
contents of the original tree and
 + * adding in our changes.  Since NodeBuilder maintains parent/child 
references, it also handles parent-splitting
 + * (easy enough, since any node affected by the split will already be 
copied into a NodeBuilder).
 + *
 + * One other difference from the simple algorithm is that we perform 
modifications in bulk;
 + * we assume @param source has been sorted, e.g. by BTree.update, so the 
update of each key resumes where
 + * the previous left off.
 + */
 +public  Object[] update(Object[] btree, 
Comparator comparator, Iterable source, UpdateFunction updateF)
 +{
 +assert updateF != null;
 +
 +NodeBuilder current = rootBuilder;
 +current.reset(btree, POSITIVE_INFINITY, 

[02/10] cassandra git commit: 10579: fix NativeCell behaviour when clustering components > 32K in size

2015-11-02 Thread benedict
10579: fix NativeCell behaviour when clustering components > 32K in size


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

Branch: refs/heads/cassandra-2.2
Commit: 986a1a769437bf1e47248e257772a074c27bac92
Parents: 83fb3cc
Author: Benedict Elliott Smith 
Authored: Mon Oct 26 16:50:39 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 16:40:35 2015 +

--
 .../cassandra/utils/btree/NodeBuilder.java  |  9 +++---
 .../cassandra/utils/memory/MemoryUtil.java  |  2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 31 +++-
 3 files changed, 36 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
--
diff --git a/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java 
b/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
index 9d57182..0e304e5 100644
--- a/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
+++ b/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
@@ -185,9 +185,8 @@ final class NodeBuilder
 }
 else
 {
-// if not found, we need to apply updateFunction still
-key = updateFunction.apply(key);
-addNewKey(key); // handles splitting parent if necessary 
via ensureRoom
+// if not found, we need to apply updateFunction still, 
which is handled in addNewKey
+addNewKey(key);
 }
 
 // done, so return null
@@ -315,7 +314,9 @@ final class NodeBuilder
 copyFromKeyPosition++;
 }
 
-// puts the provided key in the builder, with no impact on treatment of 
data from copyf
+// applies the updateFunction
+// puts the resulting key into the builder
+// splits the parent if necessary via ensureRoom
 void addNewKey(Object key)
 {
 ensureRoom(buildKeyPosition + 1);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
--
diff --git a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java 
b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
index 57edc52..f96957d 100644
--- a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
+++ b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
@@ -98,7 +98,7 @@ public abstract class MemoryUtil
 
 public static int getShort(long address)
 {
-return UNALIGNED ? unsafe.getShort(address) : getShortByByte(address);
+return UNALIGNED ? unsafe.getShort(address) & 0x : 
getShortByByte(address);
 }
 
 public static int getInt(long address)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/test/unit/org/apache/cassandra/db/NativeCellTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/NativeCellTest.java 
b/test/unit/org/apache/cassandra/db/NativeCellTest.java
index 6a2bf73..70b7b87 100644
--- a/test/unit/org/apache/cassandra/db/NativeCellTest.java
+++ b/test/unit/org/apache/cassandra/db/NativeCellTest.java
@@ -85,9 +85,38 @@ public class NativeCellTest
   new Name(simpleSparse(new ColumnIdentifier("a", 
true)), new SimpleSparseCellNameType(UTF8Type.instance)),
   new Name(compositeDense(bytes("a"), bytes("b")), 
new CompoundDenseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
   new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), false), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
-  new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), true), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance)))
+  new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), true), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
+  new Name(simpleDense(huge('a', 4)), new 
SimpleDenseCellNameType(UTF8Type.instance)),
+  new Name(simpleSparse(new 
ColumnIdentifier(hugestr('a', 4), true)), new 

[06/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2015-11-02 Thread benedict
Merge branch 'cassandra-2.1' into cassandra-2.2

Conflicts:
src/java/org/apache/cassandra/utils/btree/NodeBuilder.java


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

Branch: refs/heads/cassandra-2.2
Commit: 82aa7969c1b77967ef2e6ab847cb5c11cc4c002c
Parents: 0fbf715 986a1a7
Author: Benedict Elliott Smith 
Authored: Mon Nov 2 18:57:37 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 18:57:37 2015 +

--
 .../apache/cassandra/utils/btree/Builder.java   |  2 +-
 .../cassandra/utils/btree/NodeBuilder.java  | 11 +++
 .../cassandra/utils/memory/MemoryUtil.java  |  2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 31 +++-
 4 files changed, 38 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/82aa7969/src/java/org/apache/cassandra/utils/btree/Builder.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/82aa7969/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/82aa7969/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
--



[01/10] cassandra git commit: 10579: fix NativeCell behaviour when clustering components > 32K in size

2015-11-02 Thread benedict
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 83fb3cc42 -> 986a1a769
  refs/heads/cassandra-2.2 0fbf71591 -> 82aa7969c
  refs/heads/cassandra-3.0 1e8007b1a -> 79f230f30
  refs/heads/trunk 9c9e39263 -> fbdeef836


10579: fix NativeCell behaviour when clustering components > 32K in size


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

Branch: refs/heads/cassandra-2.1
Commit: 986a1a769437bf1e47248e257772a074c27bac92
Parents: 83fb3cc
Author: Benedict Elliott Smith 
Authored: Mon Oct 26 16:50:39 2015 +
Committer: Benedict Elliott Smith 
Committed: Mon Nov 2 16:40:35 2015 +

--
 .../cassandra/utils/btree/NodeBuilder.java  |  9 +++---
 .../cassandra/utils/memory/MemoryUtil.java  |  2 +-
 .../org/apache/cassandra/db/NativeCellTest.java | 31 +++-
 3 files changed, 36 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
--
diff --git a/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java 
b/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
index 9d57182..0e304e5 100644
--- a/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
+++ b/src/java/org/apache/cassandra/utils/btree/NodeBuilder.java
@@ -185,9 +185,8 @@ final class NodeBuilder
 }
 else
 {
-// if not found, we need to apply updateFunction still
-key = updateFunction.apply(key);
-addNewKey(key); // handles splitting parent if necessary 
via ensureRoom
+// if not found, we need to apply updateFunction still, 
which is handled in addNewKey
+addNewKey(key);
 }
 
 // done, so return null
@@ -315,7 +314,9 @@ final class NodeBuilder
 copyFromKeyPosition++;
 }
 
-// puts the provided key in the builder, with no impact on treatment of 
data from copyf
+// applies the updateFunction
+// puts the resulting key into the builder
+// splits the parent if necessary via ensureRoom
 void addNewKey(Object key)
 {
 ensureRoom(buildKeyPosition + 1);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
--
diff --git a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java 
b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
index 57edc52..f96957d 100644
--- a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
+++ b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
@@ -98,7 +98,7 @@ public abstract class MemoryUtil
 
 public static int getShort(long address)
 {
-return UNALIGNED ? unsafe.getShort(address) : getShortByByte(address);
+return UNALIGNED ? unsafe.getShort(address) & 0x : 
getShortByByte(address);
 }
 
 public static int getInt(long address)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/986a1a76/test/unit/org/apache/cassandra/db/NativeCellTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/NativeCellTest.java 
b/test/unit/org/apache/cassandra/db/NativeCellTest.java
index 6a2bf73..70b7b87 100644
--- a/test/unit/org/apache/cassandra/db/NativeCellTest.java
+++ b/test/unit/org/apache/cassandra/db/NativeCellTest.java
@@ -85,9 +85,38 @@ public class NativeCellTest
   new Name(simpleSparse(new ColumnIdentifier("a", 
true)), new SimpleSparseCellNameType(UTF8Type.instance)),
   new Name(compositeDense(bytes("a"), bytes("b")), 
new CompoundDenseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
   new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), false), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
-  new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), true), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance)))
+  new Name(compositeSparse(bytess("b", "c"), new 
ColumnIdentifier("a", true), true), new 
CompoundSparseCellNameType(Arrays.asList(UTF8Type.instance, 
UTF8Type.instance))),
+  

[jira] [Commented] (CASSANDRA-10579) IndexOutOfBoundsException during memtable flushing at startup (with offheap_objects)

2015-11-02 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-10579:
--

Thanks. Committed as 986a1a769437bf1e47248e257772a074c27bac92

> IndexOutOfBoundsException during memtable flushing at startup (with 
> offheap_objects)
> 
>
> Key: CASSANDRA-10579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10579
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.1.10 on linux
>Reporter: Jeff Griffith
>Assignee: Benedict
> Fix For: 2.1.x
>
>
> Sometimes we have problems at startup where memtable flushes with an index 
> out of bounds exception as seen below. Cassandra is then dead in the water 
> until we track down the corresponding commit log via the segment ID and 
> remove it:
> {code}
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,440 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832692.log
> INFO  [main] 2015-10-23 14:43:36,594 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,595 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log (CL version 4, 
> messaging version 8)
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:478 - Finished 
> reading /home/y/var/cassandra/commitlog/CommitLog-4-1445474832693.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:267 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log
> INFO  [main] 2015-10-23 14:43:36,699 CommitLogReplayer.java:270 - Replaying 
> /home/y/var/cassandra/commitlog/CommitLog-4-1445474832694.log (CL version 4, 
> messaging version 8)
> WARN  [SharedPool-Worker-5] 2015-10-23 14:43:36,747 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-5,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 6
> at 
> org.apache.cassandra.db.AbstractNativeCell.nametype(AbstractNativeCell.java:204)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AbstractNativeCell.isStatic(AbstractNativeCell.java:199)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCType.compare(AbstractCType.java:166)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:61)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType$1.compare(AbstractCellNameType.java:58)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.find(BTree.java:277) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:154) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:225)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Memtable.put(Memtable.java:210) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1225) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer$1.runMayThrow(CommitLogReplayer.java:455)
>  ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.10.jar:2.1.10-SNAPSHOT]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_31]
> at 
> 

[jira] [Updated] (CASSANDRA-9425) Make node-local schema fully immutable

2015-11-02 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-9425:
-
Assignee: (was: Aleksey Yeschenko)

> Make node-local schema fully immutable
> --
>
> Key: CASSANDRA-9425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9425
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
> Fix For: 3.x
>
>
> The way we handle schema changes currently is inherently racy.
> All of our {{SchemaAlteringStatement}} s perform validation on a schema state 
> that's won't necessarily be there when the statement gets executed and 
> mutates schema.
> We should make all the *Metadata classes ({{KeyspaceMetadata, 
> TableMetadata}}, {{ColumnMetadata}}, immutable, and local schema persistently 
> snapshottable, with a single top-level {{AtomicReference}} to the current 
> snapshot. Have DDL statements perform validation and transformation on the 
> same state.
> In pseudo-code, think
> {code}
> public interface DDLStatement
> {
> /**
>  * Validates that the DDL statement can be applied to the provided schema 
> snapshot.
>  *
>  * @param schema snapshot of schema before executing CREATE KEYSPACE
>  */
> void validate(SchemaSnapshot schema);
>  
> /**
>  * Applies the DDL statement to the provided schema snapshot.
>  * Implies that validate() has already been called on the provided 
> snapshot.
>  *
>  * @param schema snapshot of schema before executing the statement
>  * @return snapshot of schema as it would be after executing the statement
>  */
> SchemaSnapshot transform(SchemaSnapshot schema);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-8879) Alter table on compact storage broken

2015-11-02 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-8879:
-
Reviewer:   (was: Aleksey Yeschenko)

> Alter table on compact storage broken
> -
>
> Key: CASSANDRA-8879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8879
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Nick Bailey
>Assignee: Aleksey Yeschenko
> Fix For: 2.1.x
>
> Attachments: 8879-2.0.txt
>
>
> In 2.0 HEAD, alter table on compact storage tables seems to be broken. With 
> the following table definition, altering the column breaks cqlsh and 
> generates a stack trace in the log.
> {noformat}
> CREATE TABLE settings (
>   key blob,
>   column1 blob,
>   value blob,
>   PRIMARY KEY ((key), column1)
> ) WITH COMPACT STORAGE
> {noformat}
> {noformat}
> cqlsh:OpsCenter> alter table settings ALTER column1 TYPE ascii ;
> TSocket read 0 bytes
> cqlsh:OpsCenter> DESC TABLE settings;
> {noformat}
> {noformat}
> ERROR [Thrift:7] 2015-02-26 17:20:24,640 CassandraDaemon.java (line 199) 
> Exception in thread Thread[Thrift:7,5,main]
> java.lang.AssertionError
> >...at 
> >org.apache.cassandra.cql3.statements.AlterTableStatement.announceMigration(AlterTableStatement.java:198)
> >...at 
> >org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:79)
> >...at 
> >org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:158)
> >...at 
> >org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:175)
> >...at 
> >org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1958)
> >...at 
> >org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4486)
> >...at 
> >org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4470)
> >...at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> >...at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> >...at 
> >org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:204)
> >...at 
> >java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >...at 
> >java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >...at java.lang.Thread.run(Thread.java:724)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-7622) Implement virtual tables

2015-11-02 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-7622:
-
Reviewer:   (was: Aleksey Yeschenko)

> Implement virtual tables
> 
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tupshin Harper
> Fix For: 3.x
>
>
> There are a variety of reasons to want virtual tables, which would be any 
> table that would be backed by an API, rather than data explicitly managed and 
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a 
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml 
> configuration information. So it would be an alternate approach to 
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not 
> presupposing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-9543) Integrate release 2.2 java driver

2015-11-02 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan commented on CASSANDRA-9543:


[~snazy] force pushed to the same branch with a change to update to the 
3.0.0-alpha4 that is in cassandra-3.0.

After talking with the driver guys, they are going to discontinue the 2.2 
branch because the 3.0 branch is exactly the same, except it can also handle 
the new schema stuff.

> Integrate release 2.2 java driver
> -
>
> Key: CASSANDRA-9543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9543
> Project: Cassandra
>  Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Jeremiah Jordan
> Fix For: 2.2.x
>
>
> Follow-up of CASSANDRA-9493.
> Hint: cleanup {{build.xml}} for commented out {{çassandra-driver-core}} maven 
> dependencies.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10621) Error while bootstraping a new node with Materialized Views

2015-11-02 Thread Carl Yeksigian (JIRA)

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

Carl Yeksigian commented on CASSANDRA-10621:


These seem to correspond to the {{STARTING}}/{{JOINING}} operation modes that 
StorageService can be in; do any of the [other 
modes|https://github.com/apache/cassandra/blob/4beb54da50752fdd5573d8d1d2b0da108eaded6c/src/java/org/apache/cassandra/service/StorageService.java#L237]
 require special attention?

> Error while bootstraping a new node with Materialized Views
> ---
>
> Key: CASSANDRA-10621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10621
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Alan Boudreault
>Assignee: Joel Knighton
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: system.log
>
>
> If I try to add a new node in a cluster that has materialized views, I get 
> the following error:
> {code}
>  ERROR 19:05:15 Unknown exception caught while attempting to update 
> MaterializedView! mview.user_playlists
> java.lang.RuntimeException: Trying to get the view natural endpoint on a 
> non-data replica
> at 
> org.apache.cassandra.db.view.ViewUtils.getViewNaturalEndpoint(ViewUtils.java:103)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:693) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:145)
>  ~[main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:482) 
> [main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:387) 
> [main/:na]
> at org.apache.cassandra.db.Mutation.applyUnsafe(Mutation.java:215) 
> [main/:na]
> at 
> org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:162)
>  [main/:na]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> ERROR 19:05:15 Error applying streamed sstable: 
> java.lang.RuntimeException: Trying to get the view natural endpoint on a 
> non-data replica
> at 
> org.apache.cassandra.db.view.ViewUtils.getViewNaturalEndpoint(ViewUtils.java:103)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:693) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:145)
>  ~[main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:482) 
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:387) 
> ~[main/:na]
> at org.apache.cassandra.db.Mutation.applyUnsafe(Mutation.java:215) 
> ~[main/:na]
> at 
> org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:162)
>  ~[main/:na]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> WARN  19:05:18 Writing large partition mview/genre_to_user:genre_3 (116986142 
> bytes)
> WARN  19:05:21 Writing large partition mview/genre_to_user:genre_2 (116985746 
> bytes)
> WARN  19:05:24 Writing large partition mview/genre_to_user:genre_5 (116986337 
> bytes)
> ERROR 19:05:33 Unknown exception caught while attempting to update 
> MaterializedView! mview.user_playlists
> java.lang.RuntimeException: Trying to get the view natural endpoint on a 
> non-data replica
> at 
> org.apache.cassandra.db.view.ViewUtils.getViewNaturalEndpoint(ViewUtils.java:103)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:693) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:145)
>  ~[main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:482) 
> [main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:387) 
> [main/:na]
> at 

[jira] [Commented] (CASSANDRA-10581) Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0

2015-11-02 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-10581:
--

I'm all for visibility, but it would a lot better to have in the log file imo. 
Maybe we can set some custom environment variable based on our detection of 
JEMalloc, or pass some system option to the binary, so that we can do such 
logging.

> Update cassandra.yaml comments to reflect memory_allocator deprecation, 
> remove in 3.0
> -
>
> Key: CASSANDRA-10581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10581
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.4, 3.0.0
>
>
> Looks like in 2.2+ changing the {{memory_allocator}} field in cassandra.yaml 
> has no effect:
> https://github.com/apache/cassandra/commit/0d2ec11c7e0abfb84d872289af6d3ac386cf381f#diff-b66584c9ce7b64019b5db5a531deeda1R207
> The instructions in comments on how to use jemalloc haven't been updated to 
> reflect this change. [~snazy], is that an accurate assessment?
> [~iamaleksey] How do we want to handle the deprecation more generally? Warn 
> on 2.2, remove in 3.0?
> EDIT: I described this in a way that isn't very clear to those unfamiliar 
> with Robert's change. To be clear: You can still use JEMAlloc with Cassandra. 
> The {{memory_allocator}} option was deprecated in favor of automatically 
> detecting if JEMAlloc is installed, and, if so, using it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10208) Windows dtest 2.2: commitlog_test.TestCommitLog.stop_failure_policy_test

2015-11-02 Thread Philip Thompson (JIRA)

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

Philip Thompson commented on CASSANDRA-10208:
-

I am currently trying to, but as yet cannot.

> Windows dtest 2.2: commitlog_test.TestCommitLog.stop_failure_policy_test
> 
>
> Key: CASSANDRA-10208
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10208
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Philip Thompson
>Assignee: Alan Boudreault
>  Labels: Windows
> Fix For: 2.2.x
>
>
> {{commitlog_test.TestCommitLog.stop_commit_failure_policy_test}} and 
> {{commitlog_test.TestCommitLog.stop_failure_policy_test}} are failing here: 
> http://cassci.datastax.com/job/cassandra-2.2_dtest_win32/72/testReport/#
> The stack trace is as follows:
> {code}
> File "C:\tools\python2\lib\unittest\case.py", line 329, in run
> testMethod()
>   File 
> "D:\jenkins\workspace\cassandra-2.2_dtest_win32\cassandra-dtest\commitlog_test.py",
>  line 254, in stop_failure_policy_test
> self.assertTrue(failure, "Cannot find the commitlog failure message in 
> logs")
>   File "C:\tools\python2\lib\unittest\case.py", line 422, in assertTrue
> raise self.failureException(msg)
> 'Cannot find the commitlog failure message in logs
> {code}
> I can only reproduce the failure for {{stop_commit_failure_policy_test}} 
> locally, but I assume that's just flakiness.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-8068) Allow to create authenticator which is aware of the client connection

2015-11-02 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan commented on CASSANDRA-8068:


+1 that works for my use cases.

> Allow to create authenticator which is aware of the client connection
> -
>
> Key: CASSANDRA-8068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8068
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jacek Lewandowski
>Assignee: Sam Tunnicliffe
>Priority: Minor
>  Labels: security
> Fix For: 3.0.0
>
>
> Currently, the authenticator interface doesn't allow to make a decision 
> according to the client connection properties (especially the client host 
> name or address). 
> The idea is to add the interface which extends the current SASL aware 
> authenticator interface with additional method to set the client connection. 
> ServerConnection then could supply the connection to the authenticator if the 
> authenticator implements that interface. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns

2015-11-02 Thread Benjamin Lerer (JIRA)

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

Benjamin Lerer edited comment on CASSANDRA-10271 at 11/2/15 4:12 PM:
-

[~bsnyder788] Sorry, I realized that my previous comment was not clear.

The following queries should be valid:
* {{SELECT * FROM %s WHERE a=? AND b=? AND c >= ? ORDER BY c ASC}} (if b and c 
are the clustering columns)
* {{SELECT * FROM %s WHERE a=? AND b=? AND c IN (?, ?) ORDER BY c ASC}} (if b 
and c are the clustering columns)
* {{SELECT * FROM %s WHERE a=? AND b=? AND (c , d) > (?, ?) ORDER BY c ASC, d 
ASC}} (if b, c and d are the clustering columns)

As the order is specified for the {{c}} and {{d}} columns we should allow them.

We should probably even allow queries like:
  {{SELECT * FROM %s WHERE a=? AND b IN (?, ?) AND c = ? ORDER BY b ASC}}

[~thobbs] What do you think?



was (Author: blerer):
[~bsnyder788] Sorry, I realized that my previous comment was not clear.

The following queries should be valid:
* {{SELECT * FROM %s WHERE a=? AND b=? AND c >= ? ORDER BY c ASC}}
* {{SELECT * FROM %s WHERE a=? AND b=? AND c IN (?, ?) ORDER BY c ASC}}
* {{SELECT * FROM %s WHERE a=? AND b=? AND (c , d) > (?, ?) ORDER BY c ASC, d 
ASC}}

As the order is specified for the {{c}} and {{d}} columns we should allow them.

We should probably even allow queries like:
  {{SELECT * FROM %s WHERE a=? AND b IN (?, ?) AND c = ? ORDER BY b ASC}}

[~thobbs] What do you think?


> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Brett Snyder
>Priority: Minor
> Fix For: 3.x, 2.2.x
>
> Attachments: cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of 
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't 
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns

2015-11-02 Thread Benjamin Lerer (JIRA)

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

Benjamin Lerer commented on CASSANDRA-10271:


[~bsnyder788] Sorry, I realized that my previous comment was not clear.

The following queries should be valid:
* {{SELECT * FROM %s WHERE a=? AND b=? AND c >= ? ORDER BY c ASC}}
* {{SELECT * FROM %s WHERE a=? AND b=? AND c IN (?, ?) ORDER BY c ASC}}
* {{SELECT * FROM %s WHERE a=? AND b=? AND (c , d) > (?, ?) ORDER BY c ASC, d 
ASC}}

As the order is specified for the {{c}} and {{d}} columns we should allow them.

We should probably even allow queries like:
  {{SELECT * FROM %s WHERE a=? AND b IN (?, ?) AND c = ? ORDER BY b ASC}}

[~thobbs] What do you think?


> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Brett Snyder
>Priority: Minor
> Fix For: 3.x, 2.2.x
>
> Attachments: cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of 
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't 
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-9543) Integrate release 2.2 java driver

2015-11-02 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan edited comment on CASSANDRA-9543 at 11/2/15 4:40 PM:
-

[~snazy] force pushed to the same branch with a change to update to the 
3.0.0-alpha4 that is in cassandra-3.0.

After talking with the driver guys, they are going to discontinue the 2.2 
branch because the 3.0 branch is exactly the same, except it can also handle 
the new schema stuff.

http://cassci.datastax.com/view/Dev/view/zanson/job/JeremiahDJordan-updatejavadriver-dtest/
http://cassci.datastax.com/view/Dev/view/zanson/job/JeremiahDJordan-updatejavadriver-testall/


was (Author: jjordan):
[~snazy] force pushed to the same branch with a change to update to the 
3.0.0-alpha4 that is in cassandra-3.0.

After talking with the driver guys, they are going to discontinue the 2.2 
branch because the 3.0 branch is exactly the same, except it can also handle 
the new schema stuff.

> Integrate release 2.2 java driver
> -
>
> Key: CASSANDRA-9543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9543
> Project: Cassandra
>  Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Jeremiah Jordan
> Fix For: 2.2.x
>
>
> Follow-up of CASSANDRA-9493.
> Hint: cleanup {{build.xml}} for commented out {{çassandra-driver-core}} maven 
> dependencies.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10365) Store types by their CQL names in schema tables instead of fully-qualified internal class names

2015-11-02 Thread Adam Holmberg (JIRA)

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

Adam Holmberg commented on CASSANDRA-10365:
---

Our integration tests are seeing issues related to UDT frozenness. Most I've 
looked at are characterized by this:

{code}
cassandra@cqlsh:test> create type whatever (a int, b int);
cassandra@cqlsh:test> create TABLE t (k int PRIMARY KEY, m map);
ServerError: 
{code}

> Store types by their CQL names in schema tables instead of fully-qualified 
> internal class names
> ---
>
> Key: CASSANDRA-10365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10365
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>  Labels: client-impacting
> Fix For: 3.0.0
>
>
> Consider saving CQL types names for column, UDF/UDA arguments and return 
> types, and UDT components.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CASSANDRA-10634) Materialized Views filter paired endpoints to local DC even when not using DC-aware replication

2015-11-02 Thread Joel Knighton (JIRA)
Joel Knighton created CASSANDRA-10634:
-

 Summary: Materialized Views filter paired endpoints to local DC 
even when not using DC-aware replication
 Key: CASSANDRA-10634
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10634
 Project: Cassandra
  Issue Type: Bug
  Components: Coordination
Reporter: Joel Knighton
Assignee: Joel Knighton
Priority: Critical


In {[getViewNaturalEndpoint}}, when calculating paired view replicas, we filter 
out base and view replicas that aren't in the local datacenter. 

If we are using SimpleStrategy, this filtering is incorrect, since our replica 
placement is not datacenter aware.

We should behave the same as DC-aware consistency levels and only perform this 
datacenter-aware filtering if the replication strategy is an instance of 
NetworkTopologyStrategy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-10634) Materialized Views filter paired endpoints to local DC even when not using DC-aware replication

2015-11-02 Thread Joel Knighton (JIRA)

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

Joel Knighton updated CASSANDRA-10634:
--
Description: 
When calculating paired view replicas on MV writes, we filter out base and view 
replicas that aren't in the local datacenter. 

If we are using SimpleStrategy, this filtering is incorrect, since our replica 
placement is not datacenter aware.

We should behave the same as DC-aware consistency levels and only perform this 
datacenter-aware filtering if the replication strategy is an instance of 
NetworkTopologyStrategy.

  was:
In {[getViewNaturalEndpoint}}, when calculating paired view replicas, we filter 
out base and view replicas that aren't in the local datacenter. 

If we are using SimpleStrategy, this filtering is incorrect, since our replica 
placement is not datacenter aware.

We should behave the same as DC-aware consistency levels and only perform this 
datacenter-aware filtering if the replication strategy is an instance of 
NetworkTopologyStrategy.


> Materialized Views filter paired endpoints to local DC even when not using 
> DC-aware replication
> ---
>
> Key: CASSANDRA-10634
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10634
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>Priority: Critical
>
> When calculating paired view replicas on MV writes, we filter out base and 
> view replicas that aren't in the local datacenter. 
> If we are using SimpleStrategy, this filtering is incorrect, since our 
> replica placement is not datacenter aware.
> We should behave the same as DC-aware consistency levels and only perform 
> this datacenter-aware filtering if the replication strategy is an instance of 
> NetworkTopologyStrategy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10365) Store types by their CQL names in schema tables instead of fully-qualified internal class names

2015-11-02 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-10365:
---

bq. Our integration tests are seeing issues related to UDT frozenness.

That was a bug in {{toString()}} of {{Tuple}} and {{UserDefined}}. Force-pushed.

> Store types by their CQL names in schema tables instead of fully-qualified 
> internal class names
> ---
>
> Key: CASSANDRA-10365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10365
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>  Labels: client-impacting
> Fix For: 3.0.0
>
>
> Consider saving CQL types names for column, UDF/UDA arguments and return 
> types, and UDT components.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CASSANDRA-10633) cqlsh copy uses wrong variable name for time_format

2015-11-02 Thread Jeremiah Jordan (JIRA)
Jeremiah Jordan created CASSANDRA-10633:
---

 Summary: cqlsh copy uses wrong variable name for time_format
 Key: CASSANDRA-10633
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10633
 Project: Cassandra
  Issue Type: Bug
Reporter: Jeremiah Jordan
 Fix For: 2.1.x


{code}
diff --git a/bin/cqlsh b/bin/cqlsh
index ca45be3..ddf0314 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -1816,7 +1816,7 @@ class Shell(cmd.Cmd):
 encoding = opts.pop('encoding', 'utf8')
 nullval = opts.pop('null', '')
 header = bool(opts.pop('header', '').lower() == 'true')
-timestamp_format = opts.pop('time_format', 
self.display_timestamp_format)
+timestamp_format = opts.pop('time_format', self.display_time_format)
 if dialect_options['quotechar'] == dialect_options['escapechar']:
 dialect_options['doublequote'] = True
 del dialect_options['escape char']
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10401) Improve json2sstable error reporting on nonexistent column

2015-11-02 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg commented on CASSANDRA-10401:


Being the devilishly insightful reviewer that I am I have to ask. Is there a 
test?

The only bike shedding I have is that if 
ArrayBackedSortedColumns.factory.create() returns null why not check the output 
of that instead instead of checking via a different path? Is this implying that 
maybe ColumnFamily.Factory should be the the component that throws a more 
reasonable exception?

> Improve json2sstable error reporting on nonexistent column
> --
>
> Key: CASSANDRA-10401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10401
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Cassandra 2.1.8.621
>Reporter: Jose Martinez Poblete
>Assignee: Paulo Motta
>
> We have the following table...
> {noformat}
> CREATE TABLE keyspace_name.table_name (
> col1 text,
> col2 text,
> col3 text,
> col4 text,
> PRIMARY KEY ((col1, col2), col3)
> ) WITH CLUSTERING ORDER BY (col3 ASC)
> {noformat}
> And the following  json in a file created from sstable2json tool
> {noformat}
> [
> {"key": "This is col1:This is col2,
>  "cells": [["This is col3:","",1443217787319002],
>["This is col3:"col4","This is col4",1443217787319002]]}
> ]
> {noformat}
> Let's say we deleted that record form the DB and wanted to bring it back
> If we try to create an sstable from this data in a json file named 
> test_file.json, we get a NPE 
> {noformat}
> -bash-4.1$ json2sstable -K elp -c table_name-3264cbe063c211e5bc34e746786b7b29 
> test_file.json  
> /var/lib/cassandra/data/keyspace_name/table_name-3264cbe063c211e5bc34e746786b7b29/keyspace_name-table_name-ka-1-Data.db
> Importing 1 keys...
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.tools.SSTableImport.getKeyValidator(SSTableImport.java:442)
>   at 
> org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:316)
>   at 
> org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:287)
>   at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:514)
> ERROR: null
> -bash-4.1$
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-10633) cqlsh copy uses wrong variable name for time_format

2015-11-02 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan updated CASSANDRA-10633:

Component/s: Tools

> cqlsh copy uses wrong variable name for time_format
> ---
>
> Key: CASSANDRA-10633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10633
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Jeremiah Jordan
>Assignee: Jeremiah Jordan
> Fix For: 2.1.x
>
>
> {code}
> diff --git a/bin/cqlsh b/bin/cqlsh
> index ca45be3..ddf0314 100755
> --- a/bin/cqlsh
> +++ b/bin/cqlsh
> @@ -1816,7 +1816,7 @@ class Shell(cmd.Cmd):
>  encoding = opts.pop('encoding', 'utf8')
>  nullval = opts.pop('null', '')
>  header = bool(opts.pop('header', '').lower() == 'true')
> -timestamp_format = opts.pop('time_format', 
> self.display_timestamp_format)
> +timestamp_format = opts.pop('time_format', self.display_time_format)
>  if dialect_options['quotechar'] == dialect_options['escapechar']:
>  dialect_options['doublequote'] = True
>  del dialect_options['escape char']
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

2015-11-02 Thread Jeff Jirsa (JIRA)

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

Jeff Jirsa edited comment on CASSANDRA-7306 at 11/2/15 9:52 PM:


I've implemented some of this, primarily for my own education (learning some of 
the internals of gossip better). I've approached this by creating a pluggable 
IDatacenterTopologyProvider, and implemented a full mesh, file-based whitelist, 
and file-based-blacklist provider. I then extended Gossiper to filter it's list 
of live endpoitns by calling the IDatacenterTopologyProvider instance to filter 
non-gossipable endpoints, which seems to fit the goal of this ticket. This 
enables not only hub/spoke, but arbitrary graphs of database connectivity. 

However, the ticket is pretty poorly defined in terms of behaviors. 

[~tupshin] , This ticket title mentions "more flexible gossip" -  does this 
carry into requests/CL as well? What's the desired/expected behavior if a KS 
uses NTS to have rf=3 in dcs a,b, and c, but hosts in dc=b are set not to 
gossip with hosts in dc=c, and vice versa? CL=ALL fails, CL=QUORUM fills with 
a+b, and writes just assume all nodes in c are down? Or should it be smart 
enough to know that c is disconnected, and not count hosts in c towards 
quorum/ALL ? 

My primary hangup is finding the right way to notify the KS replication 
strategy to reload if the list of of whitelisted/blacklisted DCs changes. I 
know it's a solvable problem, but if it's out of scope, I won't waste time with 
it. I realize that this is a {{ponies}} ticket, and there's a ton of 
bike-shed/ponies opportunity here, but if we can get some consensus on 
definition, I can try to get this to a point where it can potentially be ready 
for real review. 


was (Author: jjirsa):
This ticket title mentions "more flexible gossip" -  does this carry into 
requests/CL as well? What's the desired/expected behavior if a KS uses NTS to 
have rf=3 in dcs {a,b,c}, but hosts in dc=b are set not to gossip with hosts in 
dc=c, and vice versa? CL=ALL fails, CL=QUORUM fills with a+b, and writes just 
assume all nodes in c are down? Or should it be smart enough to know that c is 
disconnected, and not count hosts in c towards quorum/ALL ? 


> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-10628) get JEMAlloc debug output out of nodetool output

2015-11-02 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg updated CASSANDRA-10628:
---
Reviewer: Ariel Weisberg

> get JEMAlloc debug output out of nodetool output
> 
>
> Key: CASSANDRA-10628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10628
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.4, 3.0.0
>
>
> This is a followup ticket for CASSANDRA-10581. The consensus on the Cassandra 
> TE is that the debug output for loading JEMAlloc is helpful (or at least 
> harmless when starting C*, but not when starting {{nodetool}}, which, it 
> turns out, sources {{cassandra-env}}:
> https://github.com/apache/cassandra/blob/trunk/bin/nodetool#L53
> You can reproduce the excessive output with
> {code}
> ccm create test-nodetool-output -v git:cassandra-3.0 -n 1 ; ccm start 
> --wait-for-binary-proto ; ccm node1 nodetool ring
> {code}
> The simplest solution would probably be to redirect the output of the 
> sourcing to {{/dev/null/}}. I don't know if that's the right thing to do; it 
> may be better to move the {{LD_PRELOAD}}-setting logic to {{bin/cassandra}}. 
> I'm not sure what the reasoning would be for putting something in one place 
> or another, so I leave it to the dev team to decide on the best solution.
> Assigning [~snazy] for now; feel free to reassign



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CASSANDRA-10633) cqlsh copy uses wrong variable name for time_format

2015-11-02 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan reassigned CASSANDRA-10633:
---

Assignee: Jeremiah Jordan

> cqlsh copy uses wrong variable name for time_format
> ---
>
> Key: CASSANDRA-10633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10633
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Jeremiah Jordan
> Fix For: 2.1.x
>
>
> {code}
> diff --git a/bin/cqlsh b/bin/cqlsh
> index ca45be3..ddf0314 100755
> --- a/bin/cqlsh
> +++ b/bin/cqlsh
> @@ -1816,7 +1816,7 @@ class Shell(cmd.Cmd):
>  encoding = opts.pop('encoding', 'utf8')
>  nullval = opts.pop('null', '')
>  header = bool(opts.pop('header', '').lower() == 'true')
> -timestamp_format = opts.pop('time_format', 
> self.display_timestamp_format)
> +timestamp_format = opts.pop('time_format', self.display_time_format)
>  if dialect_options['quotechar'] == dialect_options['escapechar']:
>  dialect_options['doublequote'] = True
>  del dialect_options['escape char']
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-10401) Improve json2sstable error reporting on nonexistent column

2015-11-02 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg updated CASSANDRA-10401:
---
Reviewer: Ariel Weisberg

> Improve json2sstable error reporting on nonexistent column
> --
>
> Key: CASSANDRA-10401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10401
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Cassandra 2.1.8.621
>Reporter: Jose Martinez Poblete
>Assignee: Paulo Motta
>
> We have the following table...
> {noformat}
> CREATE TABLE keyspace_name.table_name (
> col1 text,
> col2 text,
> col3 text,
> col4 text,
> PRIMARY KEY ((col1, col2), col3)
> ) WITH CLUSTERING ORDER BY (col3 ASC)
> {noformat}
> And the following  json in a file created from sstable2json tool
> {noformat}
> [
> {"key": "This is col1:This is col2,
>  "cells": [["This is col3:","",1443217787319002],
>["This is col3:"col4","This is col4",1443217787319002]]}
> ]
> {noformat}
> Let's say we deleted that record form the DB and wanted to bring it back
> If we try to create an sstable from this data in a json file named 
> test_file.json, we get a NPE 
> {noformat}
> -bash-4.1$ json2sstable -K elp -c table_name-3264cbe063c211e5bc34e746786b7b29 
> test_file.json  
> /var/lib/cassandra/data/keyspace_name/table_name-3264cbe063c211e5bc34e746786b7b29/keyspace_name-table_name-ka-1-Data.db
> Importing 1 keys...
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.tools.SSTableImport.getKeyValidator(SSTableImport.java:442)
>   at 
> org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:316)
>   at 
> org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:287)
>   at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:514)
> ERROR: null
> -bash-4.1$
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CASSANDRA-9358) RecoveryManagerTruncateTest.testTruncatePointInTimeReplayList times out periodically

2015-11-02 Thread Michael Shuler (JIRA)

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

Michael Shuler resolved CASSANDRA-9358.
---
Resolution: Not A Problem

This looks OK lately.
http://cassci.datastax.com/job/cassandra-2.1_utest/lastCompletedBuild/testReport/org.apache.cassandra.db/RecoveryManagerTruncateTest/history/

> RecoveryManagerTruncateTest.testTruncatePointInTimeReplayList times out 
> periodically
> 
>
> Key: CASSANDRA-9358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9358
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
> Fix For: 2.1.x
>
> Attachments: system.log
>
>
> This took me about 6 loops over this test to get it to time out
> {noformat}
> [junit] Testsuite: org.apache.cassandra.db.RecoveryManagerTruncateTest
> [junit] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> 9.262 sec
> [junit] 
> [junit] Testcase: 
> testTruncatePointInTimeReplayList(org.apache.cassandra.db.RecoveryManagerTruncateTest):
>FAILED
> [junit] 
> [junit] junit.framework.AssertionFailedError: 
> [junit] at 
> org.apache.cassandra.db.RecoveryManagerTruncateTest.testTruncatePointInTimeReplayList(RecoveryManagerTruncateTest.java:159)
> [junit] 
> [junit] 
> [junit] Test org.apache.cassandra.db.RecoveryManagerTruncateTest FAILED
> {noformat}
> system.log from timeout attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10628) get JEMAlloc debug output out of nodetool output

2015-11-02 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg commented on CASSANDRA-10628:


The dtests for this haven't run yet in Cassci. I started them on the 2.2 branch.

> get JEMAlloc debug output out of nodetool output
> 
>
> Key: CASSANDRA-10628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10628
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.4, 3.0.0
>
>
> This is a followup ticket for CASSANDRA-10581. The consensus on the Cassandra 
> TE is that the debug output for loading JEMAlloc is helpful (or at least 
> harmless when starting C*, but not when starting {{nodetool}}, which, it 
> turns out, sources {{cassandra-env}}:
> https://github.com/apache/cassandra/blob/trunk/bin/nodetool#L53
> You can reproduce the excessive output with
> {code}
> ccm create test-nodetool-output -v git:cassandra-3.0 -n 1 ; ccm start 
> --wait-for-binary-proto ; ccm node1 nodetool ring
> {code}
> The simplest solution would probably be to redirect the output of the 
> sourcing to {{/dev/null/}}. I don't know if that's the right thing to do; it 
> may be better to move the {{LD_PRELOAD}}-setting logic to {{bin/cassandra}}. 
> I'm not sure what the reasoning would be for putting something in one place 
> or another, so I leave it to the dev team to decide on the best solution.
> Assigning [~snazy] for now; feel free to reassign



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-9355) RecoveryManagerTruncateTest fails in test-compression

2015-11-02 Thread Michael Shuler (JIRA)

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

Michael Shuler commented on CASSANDRA-9355:
---

This does appear to fail periodically:
http://cassci.datastax.com/job/cassandra-2.1_utest_compression/lastCompletedBuild/testReport/org.apache.cassandra.db/RecoveryManagerTruncateTest/history/

> RecoveryManagerTruncateTest fails in test-compression
> -
>
> Key: CASSANDRA-9355
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9355
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: 2.1 commit: ac70e37
>Reporter: Michael Shuler
> Fix For: 2.1.x
>
> Attachments: system.log
>
>
> {noformat}
> $ ant test-compression -Dtest.name=RecoveryManagerTruncateTest
> ...
> [junit] Testsuite: org.apache.cassandra.db.RecoveryManagerTruncateTest
> [junit] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> 9.221 sec
> [junit] 
> [junit] Testcase: 
> testTruncatePointInTimeReplayList(org.apache.cassandra.db.RecoveryManagerTruncateTest):
>FAILED
> [junit] 
> [junit] junit.framework.AssertionFailedError: 
> [junit] at 
> org.apache.cassandra.db.RecoveryManagerTruncateTest.testTruncatePointInTimeReplayList(RecoveryManagerTruncateTest.java:159)
> [junit] 
> [junit] 
> [junit] Test org.apache.cassandra.db.RecoveryManagerTruncateTest FAILED
> {noformat}
> system.log from just this failed test attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-10634) Materialized Views filter paired endpoints to local DC even when not using DC-aware replication

2015-11-02 Thread Joel Knighton (JIRA)

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

Joel Knighton updated CASSANDRA-10634:
--
Priority: Major  (was: Critical)

> Materialized Views filter paired endpoints to local DC even when not using 
> DC-aware replication
> ---
>
> Key: CASSANDRA-10634
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10634
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>
> When calculating paired view replicas on MV writes, we filter out base and 
> view replicas that aren't in the local datacenter. 
> If we are using SimpleStrategy, this filtering is incorrect, since our 
> replica placement is not datacenter aware.
> We should behave the same as DC-aware consistency levels and only perform 
> this datacenter-aware filtering if the replication strategy is an instance of 
> NetworkTopologyStrategy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-10365) Store types by their CQL names in schema tables instead of fully-qualified internal class names

2015-11-02 Thread Adam Holmberg (JIRA)

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

Adam Holmberg commented on CASSANDRA-10365:
---

That fixed it. Thanks.
Presently we consider the Python driver ready for integration, pending two 
known issues:
1.) UDT quoting as mentioned by Sylvain
2.) Aggregate initcond to be stored as CQL literal

Once these items are addressed we should have a clean integration test suite.

Latest is still on the driver branch 
[here|https://github.com/datastax/python-driver/tree/422].

> Store types by their CQL names in schema tables instead of fully-qualified 
> internal class names
> ---
>
> Key: CASSANDRA-10365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10365
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>  Labels: client-impacting
> Fix For: 3.0.0
>
>
> Consider saving CQL types names for column, UDF/UDA arguments and return 
> types, and UDT components.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CASSANDRA-9061) Add backoff and recovery to cqlsh COPY FROM when write timeouts occur

2015-11-02 Thread Stefania (JIRA)

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

Stefania resolved CASSANDRA-9061.
-
Resolution: Duplicate

We'll add back-off and recovery in CASSANDRA-9302, closing this as duplicate.

> Add backoff and recovery to cqlsh COPY FROM when write timeouts occur
> -
>
> Key: CASSANDRA-9061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9061
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Carl Yeksigian
>Priority: Minor
>  Labels: cqlsh
> Fix For: 2.1.x
>
> Attachments: 9061-2.1.txt, 9061-suggested.txt
>
>
> Previous versions of COPY FROM didn't handle write timeouts because it was 
> rarely fast enough for that to matter.  Now that performance has improved, 
> write timeouts are more likely to occur.  We should handle these by backing 
> off and retrying the operation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


  1   2   >