[jira] [Created] (CASSANDRA-10584) reads with EACH_QUORUM on keyspace with SimpleTopologyStrategy throw a ClassCastException

[Andy Tolbert (JIRA)]

Andy Tolbert created CASSANDRA-10584:


 Summary: reads with EACH_QUORUM  on keyspace with 
SimpleTopologyStrategy throw a ClassCastException
 Key: CASSANDRA-10584
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10584
 Project: Cassandra
  Issue Type: Bug
Reporter: Andy Tolbert
Priority: Minor


I think this may be a regression introduced w/ [CASSANDRA-9602].  Starting with 
C* 3.0.0-rc2 an error is returned when querying a keyspace with 
{{SimpleTopologyStrategy}} using EACH_QUORUM CL:

{noformat}
cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
cqlsh> create table test.test (k int PRIMARY KEY, i int);
cqlsh> consistency EACH_QUORUM;
Consistency level set to EACH_QUORUM.
cqlsh> select * from test.test;
ServerError: 
{noformat}

The exception yielded in the system logs:

{noformat}
ERROR [SharedPool-Worker-1] 2015-10-23 13:02:15,405 ErrorMessage.java:336 - 
Unexpected exception during request
java.lang.ClassCastException: org.apache.cassandra.locator.SimpleStrategy 
cannot be cast to org.apache.cassandra.locator.NetworkTopologyStrategy
at 
org.apache.cassandra.db.ConsistencyLevel.filterForEachQuorum(ConsistencyLevel.java:227)
 ~[main/:na]
at 
org.apache.cassandra.db.ConsistencyLevel.filterForQuery(ConsistencyLevel.java:188)
 ~[main/:na]
at 
org.apache.cassandra.db.ConsistencyLevel.filterForQuery(ConsistencyLevel.java:180)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$RangeIterator.computeNext(StorageProxy.java:1795)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$RangeIterator.computeNext(StorageProxy.java:1762)
 ~[main/:na]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[main/:na]
at 
com.google.common.collect.Iterators$PeekingImpl.hasNext(Iterators.java:1149) 
~[guava-18.0.jar:na]
at 
org.apache.cassandra.service.StorageProxy$RangeMerger.computeNext(StorageProxy.java:1814)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$RangeMerger.computeNext(StorageProxy.java:1799)
 ~[main/:na]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$RangeCommandIterator.computeNext(StorageProxy.java:1925)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$RangeCommandIterator.computeNext(StorageProxy.java:1892)
 ~[main/:na]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[main/:na]
at 
org.apache.cassandra.db.partitions.WrappingPartitionIterator.hasNext(WrappingPartitionIterator.java:33)
 ~[main/:na]
at 
org.apache.cassandra.db.partitions.CountingPartitionIterator.hasNext(CountingPartitionIterator.java:49)
 ~[main/:na]
at 
org.apache.cassandra.db.partitions.WrappingPartitionIterator.hasNext(WrappingPartitionIterator.java:33)
 ~[main/:na]
at 
org.apache.cassandra.db.partitions.CountingPartitionIterator.hasNext(CountingPartitionIterator.java:49)
 ~[main/:na]
at 
org.apache.cassandra.service.pager.AbstractQueryPager$PagerIterator.hasNext(AbstractQueryPager.java:99)
 ~[main/:na]
at 
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:610)
 ~[main/:na]
at 
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:371)
 ~[main/:na]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:327)
 ~[main/:na]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:213)
 ~[main/:na]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
 ~[main/:na]
at 
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:205)
 ~[main/:na]
at 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:236) 
~[main/:na]
at 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:221) 
~[main/:na]
at 
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
 ~[main/:na]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
 [main/:na]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
 [main/:na]
at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
 

[jira] [Updated] (CASSANDRA-10583) After bulk loading CQL query on timestamp column returns wrong result

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-10583:

Reproduced In: 2.1.10
Fix Version/s: 2.2.x
   2.1.x
   3.x

> After bulk loading CQL query on timestamp column returns wrong result
> -
>
> Key: CASSANDRA-10583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10583
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Datastax Community Edition 2.1.10, Windows 2008 R2, Java 
> x64 1.8.0_60
>Reporter: Kai Wang
> Fix For: 3.x, 2.1.x, 2.2.x
>
>
> I have this table:
> {noformat}
> CREATE TABLE test (
> tag text,
> group int,
> timestamp timestamp,
> value double,
> PRIMARY KEY (tag, group, timestamp)
> ) WITH CLUSTERING ORDER BY (group ASC, timestamp DESC)
> {noformat}
> First I used CQLSSTableWriter to bulk load a bunch of sstables. Then I ran 
> this query:
> {noformat}
> cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp 
> ='2004-12-15 16:00:00-0500';
>  tag  | group | timestamp| value
> --+---+--+---
>  MSFT | 1 | 2004-12-15 21:00:00+ | 27.11
>  MSFT | 1 | 2004-12-16 21:00:00+ | 27.16
>  MSFT | 1 | 2004-12-17 21:00:00+ | 26.96
>  MSFT | 1 | 2004-12-20 21:00:00+ | 26.95
>  MSFT | 1 | 2004-12-21 21:00:00+ | 27.07
>  MSFT | 1 | 2004-12-22 21:00:00+ | 26.98
>  MSFT | 1 | 2004-12-23 21:00:00+ | 27.01
>  MSFT | 1 | 2004-12-27 21:00:00+ | 26.85
>  MSFT | 1 | 2004-12-28 21:00:00+ | 26.95
>  MSFT | 1 | 2004-12-29 21:00:00+ |  26.9
>  MSFT | 1 | 2004-12-30 21:00:00+ | 26.76
> (11 rows)
> {noformat}
> The result is obviously wrong.
> If I run this query:
> {noformat}
> cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp 
> ='2004-12-16 16:00:00-0500';
>  tag | group | timestamp | value
> -+---+---+---
> (0 rows)
> {noformat}
> In DevCenter I tried to create a similar table and insert a few rows but 
> couldn't reproduce this. This may have something to do with the bulk loading 
> process. But still, the fact cqlsh returns data that doesn't match the query 
> is concerning.



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

[jira] [Updated] (CASSANDRA-10583) After bulk loading CQL query on timestamp column returns wrong result

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-10583:

Description: 
I have this table:

{noformat}
CREATE TABLE test (
tag text,
group int,
timestamp timestamp,
value double,
PRIMARY KEY (tag, group, timestamp)
) WITH CLUSTERING ORDER BY (group ASC, timestamp DESC)
{noformat}

First I used CQLSSTableWriter to bulk load a bunch of sstables. Then I ran this 
query:

{noformat}
cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp 
='2004-12-15 16:00:00-0500';

 tag  | group | timestamp| value
--+---+--+---
 MSFT | 1 | 2004-12-15 21:00:00+ | 27.11
 MSFT | 1 | 2004-12-16 21:00:00+ | 27.16
 MSFT | 1 | 2004-12-17 21:00:00+ | 26.96
 MSFT | 1 | 2004-12-20 21:00:00+ | 26.95
 MSFT | 1 | 2004-12-21 21:00:00+ | 27.07
 MSFT | 1 | 2004-12-22 21:00:00+ | 26.98
 MSFT | 1 | 2004-12-23 21:00:00+ | 27.01
 MSFT | 1 | 2004-12-27 21:00:00+ | 26.85
 MSFT | 1 | 2004-12-28 21:00:00+ | 26.95
 MSFT | 1 | 2004-12-29 21:00:00+ |  26.9
 MSFT | 1 | 2004-12-30 21:00:00+ | 26.76
(11 rows)
{noformat}

The result is obviously wrong.

If I run this query:

{noformat}
cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp 
='2004-12-16 16:00:00-0500';

 tag | group | timestamp | value
-+---+---+---

(0 rows)
{noformat}

In DevCenter I tried to create a similar table and insert a few rows but 
couldn't reproduce this. This may have something to do with the bulk loading 
process. But still, the fact cqlsh returns data that doesn't match the query is 
concerning.

  was:
I have this table:

CREATE TABLE test (
tag text,
group int,
timestamp timestamp,
value double,
PRIMARY KEY (tag, group, timestamp)
) WITH CLUSTERING ORDER BY (group ASC, timestamp DESC)

First I used CQLSSTableWriter to bulk load a bunch of sstables. Then I ran this 
query:

cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp 
='2004-12-15 16:00:00-0500';

 tag  | group | timestamp| value
--+---+--+---
 MSFT | 1 | 2004-12-15 21:00:00+ | 27.11
 MSFT | 1 | 2004-12-16 21:00:00+ | 27.16
 MSFT | 1 | 2004-12-17 21:00:00+ | 26.96
 MSFT | 1 | 2004-12-20 21:00:00+ | 26.95
 MSFT | 1 | 2004-12-21 21:00:00+ | 27.07
 MSFT | 1 | 2004-12-22 21:00:00+ | 26.98
 MSFT | 1 | 2004-12-23 21:00:00+ | 27.01
 MSFT | 1 | 2004-12-27 21:00:00+ | 26.85
 MSFT | 1 | 2004-12-28 21:00:00+ | 26.95
 MSFT | 1 | 2004-12-29 21:00:00+ |  26.9
 MSFT | 1 | 2004-12-30 21:00:00+ | 26.76
(11 rows)

The result is obviously wrong.

If I run this query:

cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp 
='2004-12-16 16:00:00-0500';

 tag | group | timestamp | value
-+---+---+---

(0 rows)

In DevCenter I tried to create a similar table and insert a few rows but 
couldn't reproduce this. This may have something to do with the bulk loading 
process. But still, the fact cqlsh returns data that doesn't match the query is 
concerning.


> After bulk loading CQL query on timestamp column returns wrong result
> -
>
> Key: CASSANDRA-10583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10583
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Datastax Community Edition 2.1.10, Windows 2008 R2, Java 
> x64 1.8.0_60
>Reporter: Kai Wang
> Fix For: 3.x, 2.1.x, 2.2.x
>
>
> I have this table:
> {noformat}
> CREATE TABLE test (
> tag text,
> group int,
> timestamp timestamp,
> value double,
> PRIMARY KEY (tag, group, timestamp)
> ) WITH CLUSTERING ORDER BY (group ASC, timestamp DESC)
> {noformat}
> First I used CQLSSTableWriter to bulk load a bunch of sstables. Then I ran 
> this query:
> {noformat}
> cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp 
> ='2004-12-15 16:00:00-0500';
>  tag  | group | timestamp| value
> --+---+--+---
>  MSFT | 1 | 2004-12-15 21:00:00+ | 27.11
>  MSFT | 1 | 2004-12-16 21:00:00+ | 27.16
>  MSFT | 1 | 2004-12-17 21:00:00+ | 26.96
>  MSFT | 1 | 2004-12-20 21:00:00+ | 26.95
>  MSFT | 1 | 2004-12-21 21:00:00+ | 27.07
>  MSFT | 1 | 2004-12-22 21:00:00+ | 26.98
>  MSFT | 1 | 2004-12-23 21:00:00+ | 27.01
>  MSFT | 1 | 2004-12-27 21:00:00+ | 26.85
>  MSFT | 1 | 2004-12-28 21:00:00+ | 26.95
>  MSFT | 1 | 2004-12-29 21:00:00+ |  26.9
>  MSFT | 1 | 2004-12-30 

[jira] [Commented] (CASSANDRA-10444) Create an option to forcibly disable tracing

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-10444:


Really a subset of CASSANDRA-8303 but I suppose we could special case it for 
old versions.

> Create an option to forcibly disable tracing
> 
>
> Key: CASSANDRA-10444
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10444
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Brandon Williams
>Priority: Minor
> Fix For: 2.1.x
>
>
> Sometimes people will experience dropped TRACE messages.  Ostensibly, trace 
> is disabled on the server and we know it's from some client, somewhere.  With 
> an inability to locate exactly where client code is causing this, it would be 
> useful to just be able to kill it entirely on the server side.



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

[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend

[Ivan Burmistrov (JIRA)]

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

Ivan Burmistrov updated CASSANDRA-10585:

 Attachment: cassandra-10585.patch
Description: 
SSTablePerReadHistogram metric now not considers case when row has been read 
from row cache.
And so, this metric will have big values even almost all requests processed by 
row cache (and without touching SSTables, of course).
So, it seems that correct behavior is to consider that if we read row from row 
cache then we read zero SSTables by this request.
The patch at the attachment.

  was:
SSTablePerReadHistogram metric now not considers case when row has been read 
from row cache.
And so, this metric will have big values even almost all requests processed by 
row cache (and without touching SSTables, of course).
So, it seems that correct behavior is to consider that if we read row from row 
cache then we read zero SSTables by this request.



> SSTablesPerReadHistogram seems wrong when row cache hit happend
> ---
>
> Key: CASSANDRA-10585
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10585
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Ivan Burmistrov
>Priority: Minor
> Fix For: 2.1.x
>
> Attachments: cassandra-10585.patch
>
>
> SSTablePerReadHistogram metric now not considers case when row has been read 
> from row cache.
> And so, this metric will have big values even almost all requests processed 
> by row cache (and without touching SSTables, of course).
> So, it seems that correct behavior is to consider that if we read row from 
> row cache then we read zero SSTables by this request.
> The patch at the attachment.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Sergio Bossa (JIRA)]

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

Sergio Bossa commented on CASSANDRA-9318:
-

bq. The whole point of this ticket is to avoid the complexity of intra-node 
backpressure, and instead basing coordinator -> client backpressure on the 
coordinator's local knowledge.

Just to be clear, my proposal _does_ keep the back-pressure decision local to 
the coordinator, that is, there's no communication between nodes in such regard 
(which I agree would be a much different matter). The difference in my proposal 
is that we deal with back-pressure on a per-replica basis and in a fine grained 
way, rather than with coarse grained global memory limits which would end up 
flooding replicas before being triggered.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Ariel Weisberg
>Assignee: Jacek Lewandowski
> Fix For: 2.1.x, 2.2.x
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Commented] (CASSANDRA-10285) Compaction running indefinitely on system.hints

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-10285:
-

ping [~aboudreault]

> Compaction running indefinitely on system.hints 
> 
>
> Key: CASSANDRA-10285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10285
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alan Boudreault
>Assignee: Marcus Eriksson
>
> During my hints storage benchmarks, I've experienced an issue using C* 2.2. 
> The hints was never replayed. After a while (more than 24H ...), I noticed 
> that there were still compactions running on system.hints and that some new 
> ones was triggered every 10-20 minutes.
> To reproduce, we create a cluster of 2 nodes. RF=2 and we generate hints by 
> shutting down the node2.
> {code}
> ccm create --install-dir=`pwd` -n 2 local && ccm start
> ccm node1 stress -- write n=50M -rate threads=300 -port jmx=7198 -errors 
> ignore -schema replication\(factor=2\)
> # wait 5-6 seconds to get the schema creation propagated on all nodes, then 
> in another window, stop node 2
> ccm node2 stop
> # wait the initial 50M writes are finished, bring back node2 up and write 
> another 50M keys.
> ccm node2 start
> ccm node1 stress -- write n=50M -rate threads=300 -port jmx=7198 -errors 
> ignore -schema replication\(factor=2\)
> # You should get the initial compaction finished after 15-20 minutes. You can 
> set the mb throughput to 0 to get that done faster. 
> # Monitor the node1. the hints will never be replayed and you should see 
> compactions happening indefinitely. 
> {code}
> //cc [~krummas] [~yukim]



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

[jira] [Updated] (CASSANDRA-9363) Expose vnode to directory assignment

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-9363:
---
Fix Version/s: (was: 3.x)

> Expose vnode to directory assignment
> 
>
> Key: CASSANDRA-9363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9363
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Nick Bailey
>Assignee: Marcus Eriksson
>
> CASSANDRA-6696 adds the feature of pinning vnodes to specific disks to 
> improve things when JBOD is being used.
> We also need a way to introspect what vnodes are assigned where. I'm not sure 
> what the easiest/best way to expose that info is. JMX/manifest file/system 
> table could all be a valid option.



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

[jira] [Resolved] (CASSANDRA-9363) Expose vnode to directory assignment

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson resolved CASSANDRA-9363.

Resolution: Duplicate

Doing this as part of CASSANDRA-10540 (a jmx call will give you a directory to 
vnode mapping)

> Expose vnode to directory assignment
> 
>
> Key: CASSANDRA-9363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9363
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Nick Bailey
>Assignee: Marcus Eriksson
> Fix For: 3.x
>
>
> CASSANDRA-6696 adds the feature of pinning vnodes to specific disks to 
> improve things when JBOD is being used.
> We also need a way to introspect what vnodes are assigned where. I'm not sure 
> what the easiest/best way to expose that info is. JMX/manifest file/system 
> table could all be a valid option.



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

[jira] [Resolved] (CASSANDRA-10497) NPE on removeUnfinishedCompactionLeftovers after sstablesplit

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson resolved CASSANDRA-10497.
-
   Resolution: Duplicate
Fix Version/s: (was: 2.1.x)

this will be fixed by CASSANDRA-10501

> NPE on removeUnfinishedCompactionLeftovers after sstablesplit
> -
>
> Key: CASSANDRA-10497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10497
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, Tools
> Environment: Ubuntu 14.04
>Reporter: Robbie Strickland
>Assignee: Marcus Eriksson
> Attachments: npe_system.log
>
>
> After stopping the node and running {{sstablesplit}} on a single table, 
> restarting Cassandra results in an NPE:
> {noformat}
> INFO  [SSTableBatchOpen:2] 2015-10-09 13:15:38,745 SSTableReader.java:471 - 
> Opening 
> /var/lib/cassandra/xvdd/data/system/schema_keyspaces-b0f2235744583cdb9631c43e59ce3676/system-schema_keyspaces-ka-514
>  (175 bytes)
> INFO  [main] 2015-10-09 13:15:38,747 AutoSavingCache.java:146 - reading saved 
> cache 
> /var/lib/cassandra/xvdb/cache/system-schema_keyspaces-b0f2235744583cdb9631c43e59ce3676-KeyCache-b.db
> ERROR [main] 2015-10-09 13:15:39,114 CassandraDaemon.java:541 - Exception 
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.lang.NullPointerException
> at 
> org.apache.cassandra.db.ColumnFamilyStore.removeUnfinishedCompactionLeftovers(ColumnFamilyStore.java:641)
>  ~[apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:302) 
> [apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:524)
>  [apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:613) 
> [apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT]
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.cassandra.db.ColumnFamilyStore.removeUnfinishedCompactionLeftovers(ColumnFamilyStore.java:633)
>  ~[apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT]
> ... 3 common frames omitted
> {noformat}
> The node would only come back up after deleting all the files in 
> compactions_in_progress.



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

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

[jmckenzie]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-2.2
Commit: 013ce88512af839800597d1adc52689679a725a3
Parents: a5053fd 34b8d8f
Author: Joshua McKenzie 
Authored: Fri Oct 23 13:58:59 2015 -0400
Committer: Joshua McKenzie 
Committed: Fri Oct 23 13:58:59 2015 -0400

--
 pylib/cqlshlib/test/run_cqlsh.py |  2 +-
 pylib/cqlshlib/test/test_cqlsh_output.py | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/013ce885/pylib/cqlshlib/test/run_cqlsh.py
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/013ce885/pylib/cqlshlib/test/test_cqlsh_output.py
--

[03/10] cassandra git commit: Make cqlsh tests work when authentication is configured

[jmckenzie]

Make cqlsh tests work when authentication is configured

Patch by stefania; reviewed by aholmberg for CASSANDRA-10544


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

Branch: refs/heads/cassandra-3.0
Commit: 34b8d8fcbf528f21ac7869685e33214af381265c
Parents: 5a1d376
Author: Stefania Alborghetti 
Authored: Fri Oct 23 13:58:19 2015 -0400
Committer: Joshua McKenzie 
Committed: Fri Oct 23 13:58:19 2015 -0400

--
 pylib/cqlshlib/test/run_cqlsh.py |  2 +-
 pylib/cqlshlib/test/test_cqlsh_output.py | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/34b8d8fc/pylib/cqlshlib/test/run_cqlsh.py
--
diff --git a/pylib/cqlshlib/test/run_cqlsh.py b/pylib/cqlshlib/test/run_cqlsh.py
index 88b0ca6..cc929e1 100644
--- a/pylib/cqlshlib/test/run_cqlsh.py
+++ b/pylib/cqlshlib/test/run_cqlsh.py
@@ -27,7 +27,7 @@ import math
 from time import time
 from . import basecase
 
-DEFAULT_CQLSH_PROMPT = '\ncqlsh(:\S+)?> '
+DEFAULT_CQLSH_PROMPT = os.linesep + '(\S+@)?cqlsh(:\S+)?> '
 DEFAULT_CQLSH_TERM = 'xterm'
 
 cqlshlog = basecase.cqlshlog

http://git-wip-us.apache.org/repos/asf/cassandra/blob/34b8d8fc/pylib/cqlshlib/test/test_cqlsh_output.py
--
diff --git a/pylib/cqlshlib/test/test_cqlsh_output.py 
b/pylib/cqlshlib/test/test_cqlsh_output.py
index 64950e2..e3af8e8 100644
--- a/pylib/cqlshlib/test/test_cqlsh_output.py
+++ b/pylib/cqlshlib/test/test_cqlsh_output.py
@@ -522,26 +522,26 @@ class TestCqlshOutput(BaseTestCase):
 
 def test_prompt(self):
 with testrun_cqlsh(tty=True, keyspace=None, 
cqlver=cqlsh.DEFAULT_CQLVER) as c:
-self.assertEqual(c.output_header.splitlines()[-1], 'cqlsh> ')
+self.assertTrue(c.output_header.splitlines()[-1].endswith('cqlsh> 
'))
 
 c.send('\n')
 output = c.read_to_next_prompt().replace('\r\n', '\n')
-self.assertEqual(output, '\ncqlsh> ')
+self.assertTrue(output.endswith('cqlsh> '))
 
 cmd = "USE \"%s\";\n" % get_test_keyspace().replace('"', '""')
 c.send(cmd)
 output = c.read_to_next_prompt().replace('\r\n', '\n')
-self.assertEqual(output, '%scqlsh:%s> ' % (cmd, 
get_test_keyspace()))
+self.assertTrue(output.endswith('cqlsh:%s> ' % 
(get_test_keyspace(
 
 c.send('use system;\n')
 output = c.read_to_next_prompt().replace('\r\n', '\n')
-self.assertEqual(output, 'use system;\ncqlsh:system> ')
+self.assertTrue(output.endswith('cqlsh:system> '))
 
 c.send('use NONEXISTENTKEYSPACE;\n')
 outputlines = c.read_to_next_prompt().splitlines()
 
 self.assertEqual(outputlines[0], 'use NONEXISTENTKEYSPACE;')
-self.assertEqual(outputlines[2], 'cqlsh:system> ')
+self.assertTrue(outputlines[2].endswith('cqlsh:system> '))
 midline = ColoredText(outputlines[1])
 self.assertEqual(midline.plain(),
  'InvalidRequest: code=2200 [Invalid query] 
message="Keyspace \'nonexistentkeyspace\' does not exist"')

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

[jmckenzie]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/trunk
Commit: 013ce88512af839800597d1adc52689679a725a3
Parents: a5053fd 34b8d8f
Author: Joshua McKenzie 
Authored: Fri Oct 23 13:58:59 2015 -0400
Committer: Joshua McKenzie 
Committed: Fri Oct 23 13:58:59 2015 -0400

--
 pylib/cqlshlib/test/run_cqlsh.py |  2 +-
 pylib/cqlshlib/test/test_cqlsh_output.py | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/013ce885/pylib/cqlshlib/test/run_cqlsh.py
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/013ce885/pylib/cqlshlib/test/test_cqlsh_output.py
--

[jira] [Updated] (CASSANDRA-10446) Run repair with down replicas

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-10446:
---
Fix Version/s: 3.x

> Run repair with down replicas
> -
>
> Key: CASSANDRA-10446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10446
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Priority: Minor
> Fix For: 3.x
>
>
> We should have an option of running repair when replicas are down. We can 
> call it -force.



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

[jira] [Created] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend

[Ivan Burmistrov (JIRA)]

Ivan Burmistrov created CASSANDRA-10585:
---

 Summary: SSTablesPerReadHistogram seems wrong when row cache hit 
happend
 Key: CASSANDRA-10585
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10585
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Ivan Burmistrov
Priority: Minor
 Fix For: 2.1.x


SSTablePerReadHistogram metric now not considers case when row has been read 
from row cache.
And so, this metric will have big values even almost all requests processed by 
row cache (and without touching SSTables, of course).
So, it seems that correct behavior is to consider that if we read row from row 
cache then we read zero SSTables by this request.




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

[jira] [Resolved] (CASSANDRA-10564) AntiCompactionTest failed on cassandra 2.1.10 due to antiCompactionSizeTest method failed on s390x

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko resolved CASSANDRA-10564.
---
   Resolution: Invalid
Fix Version/s: (was: 2.1.10)

systemz is unfortunately not an officially supported platform for Cassandra, 
sorry.

Feel free to reopen if you have a patch ready, and we might commit it, assuming 
it causes no performance degradations on x86. Otherwise, there is simply no way 
for us to reproduce - we don't have the hardware to.

> AntiCompactionTest failed on cassandra 2.1.10 due to antiCompactionSizeTest 
> method failed on s390x
> --
>
> Key: CASSANDRA-10564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10564
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tests
> Environment: s390x - RHEL7 IBM systemz
>Reporter: Meerabo Shah
>Priority: Blocker
>
> testlist:
>  [echo] running test bucket 0 tests
> [junit] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
> [junit] Testsuite: org.apache.cassandra.db.compaction.AntiCompactionTest
> [junit] Testsuite: org.apache.cassandra.db.compaction.AntiCompactionTest
> [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 
> sec
> [junit]
> [junit] Testcase: 
> org.apache.cassandra.db.compaction.AntiCompactionTest:antiCompactionSizeTest: 
> Caused an ERROR
> [junit] Timeout occurred. Please note the time in the report does not 
> reflect the time until the timeout.
> [junit] junit.framework.AssertionFailedError: Timeout occurred. Please 
> note the time in the report does not reflect the time until the timeout.
> [junit] at java.lang.Thread.run(Thread.java:745)
> [junit]
> [junit]
> [junit] Test org.apache.cassandra.db.compaction.AntiCompactionTest FAILED 
> (timeout)
> [junitreport] Processing 
> /apache-cassandra-2.1.10-src/build/test/TESTS-TestSuites.xml to 
> /tmp/null155310269
> [junitreport] Loading stylesheet 
> jar:file:/apache-ant-1.9.2/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
> [junitreport] Transform time: 1421ms
> [junitreport] Deleting: /tmp/null155310269
> BUILD FAILED
> /apache-cassandra-2.1.10-src/build.xml:1146: Some test bucket 0 test(s) 
> failed.
> Total time: 1 minute 11 seconds



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

[jira] [Updated] (CASSANDRA-8586) support millions of sstables by lazily acquiring/caching/dropping filehandles

[Aleksey Yeschenko (JIRA)]

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

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

> support millions of sstables by lazily acquiring/caching/dropping filehandles
> -
>
> Key: CASSANDRA-8586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8586
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Tupshin Harper
>  Labels: dense-storage
> Fix For: 3.x
>
>
> This might turn into a meta ticket if other obstacles are found in the goal 
> of supporting a huge number of sstables.
> Technically, the only gap that I know of to prevent us from supporting absurd 
> numbers of sstables is the fact that we hold on to an open filehandle for 
> every single sstable. 
> For use cases that are willing to take a hit to read-performance in order to 
> achieve high densities and low write amplification, a mechanism for only 
> retaining file handles for recently read sstables could be very valuable.
> This will allow for alternate compaction strategies and compaction strategy 
> tuning that don't try to optimize for read performance as aggresively.



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

[jira] [Updated] (CASSANDRA-9836) Allow comments on CQL table columns

[Aleksey Yeschenko (JIRA)]

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

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

> Allow comments on CQL table columns
> ---
>
> Key: CASSANDRA-9836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9836
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> We have a _comment_ option for tables. Having such a comment on individual 
> columns (as many other databases have) would be nice especially when 
> executing a {{DESCRIBE TABLE foo}}.
> Further, we could add comments in the same way for UDTs and UDT fields.
> Also for UDFs, UDAs and MVs (maybe not on the MV columns individually).



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

[jira] [Comment Edited] (CASSANDRA-10576) Thrift CAS on static columns doesn't work as expected

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe edited comment on CASSANDRA-10576 at 10/23/15 2:12 PM:
---

This wasn't covered by the existing dtest, so I've refactored & extended it to 
cover static/dynamic/mixed CFs 
[here|https://github.com/riptano/cassandra-dtest/pull/626]
{{thrift_tests:TestMutations.test_cas}} fails against cassandra-3.0/trunk but 
with the changes in the linked branches, it's now passing.

||3.0||trunk||
|[branch|https://github.com/beobal/cassandra/tree/10576-3.0]|[branch|https://github.com/beobal/cassandra/tree/10576-trunk]|
|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-trunk-testall/]|
|[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-3.0-dtest/]|[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-trunk-dtest/]|



was (Author: beobal):
This wasn't covered by the existing dtest, so I've refactored & extended it to 
cover static/dynamic/mixed CFs 
[here:https://github.com/riptano/cassandra-dtest/pull/626]
{{thrift_tests:TestMutations.test_cas}} fails against cassandra-3.0/trunk but 
with the changes in the linked branches, it's now passing.

||3.0||trunk||
|[branch|https://github.com/beobal/cassandra/tree/10576-3.0]|[branch|https://github.com/beobal/cassandra/tree/10576-trunk]|
|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-trunk-testall/]|
|[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-3.0-dtest/]|[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-trunk-dtest/]|


> Thrift CAS on static columns doesn't work as expected
> -
>
> Key: CASSANDRA-10576
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10576
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.0
>
>
> Although the thrift cas call works as expected for dynamic column families, 
> using it on tables with statically defined columns produces unexpected 
> results. The problem, in {{ThriftCASRequest}}, is that while the {{expected}} 
> partition contains a static row, the {{current}} partition has been processed 
> by {{ThriftResultsMerger}} during the read, converting the static columns to 
> clusterings. If {{expected}} contains only a static row, no further checking 
> is carried out, {{appliesTo}} erroneously returns true and the conditional 
> update is performed regardless of the current state of the partition.



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

[jira] [Updated] (CASSANDRA-10059) Test Coverage for AbstractBTreePartition and hierarchy

[Benedict (JIRA)]

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

Benedict updated CASSANDRA-10059:
-
Assignee: (was: Benedict)

> Test Coverage for AbstractBTreePartition and hierarchy
> --
>
> Key: CASSANDRA-10059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10059
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Benedict
> Fix For: 3.0.x
>
>
> Follow up to CASSANDRA-9932. The test coverage for AbstractBTreePartition and 
> its hierarchy is entirely indirect. That is not to say it is not covered, but 
> we may have some unexplored behaviour. Coverage for BTree is also missing 
> around a couple of edges, and the gaps should be filled in.



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

[jira] [Updated] (CASSANDRA-8956) Deprecate SSTableSimpleWriter, SSTableImport, and SSTableExport in 2.1

[Aleksey Yeschenko (JIRA)]

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

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

> Deprecate SSTableSimpleWriter, SSTableImport, and SSTableExport in 2.1
> --
>
> Key: CASSANDRA-8956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8956
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Priority: Minor
>  Labels: docs-impacting
> Fix For: 2.1.x
>
>
> SSTableSimpleWriter doesn't make much sense in post CASSANDRA-8099 world, and 
> will be removed in 3.0.
> To do that we should deprecate it in 2.1 first, however.
> Same goes for both SSTableImport and SSTableExport - we should deprecate them 
> in 2.1.4, and eventually replace with CASSANDRA-7464 in 3.0.



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

[jira] [Updated] (CASSANDRA-8589) Reconciliation in presence of tombstone might yield state data

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-8589:
-
Fix Version/s: (was: 3.x)
   3.1

> Reconciliation in presence of tombstone might yield state data
> --
>
> Key: CASSANDRA-8589
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8589
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
> Fix For: 3.1
>
>
> Consider 3 replica A, B, C (so RF=3) and consider that we do the following 
> sequence of actions at {{QUORUM}} where I indicate the replicas acknowledging 
> each operation (and let's assume that a replica that don't ack is a replica 
> that don't get the update):
> {noformat}
> CREATE TABLE test (k text, t int, v int, PRIMARY KEY (k, t))
> INSERT INTO test(k, t, v) VALUES ('k', 0, 0); // acked by A, B and C
> INSERT INTO test(k, t, v) VALUES ('k', 1, 1); // acked by A, B and C
> INSERT INTO test(k, t, v) VALUES ('k', 2, 2); // acked by A, B and C
> DELETE FROM test WHERE k='k' AND t=1; // acked by A and C
> UPDATE test SET v = 3 WHERE k='k' AND t=2;// acked by B and C
> SELECT * FROM test WHERE k='k' LIMIT 2;   // answered by A and B
> {noformat}
> Every operation has achieved quorum, but on the last read, A will respond 
> {{0->0, tombstone 1, 2->2}} and B will respond {{0->0, 1->1}}. As a 
> consequence we'll answer {{0->0, 2->2}} which is incorrect (we should respond 
> {{0->0, 2->3}}).
> Put another way, if we have a limit, every replica honors that limit but 
> since tombstones can "suppress" results from other nodes, we may have some 
> cells for which we actually don't get a quorum of response (even though we 
> globally have a quorum of replica responses).
> In practice, this probably occurs rather rarely and so the "simpler" fix is 
> probably to do something similar to the "short reads protection": detect when 
> this could have happen (based on how replica response are reconciled) and do 
> an additional request in that case. That detection will have potential false 
> positives but I suspect we can be precise enough that those false positives 
> will be very very rare (we should nonetheless track how often this code gets 
> triggered and if we see that it's more often than we think, we could 
> pro-actively bump user limits internally to reduce those occurrences).



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

[jira] [Updated] (CASSANDRA-8655) Exception on upgrade to trunk

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-8655:
-
Fix Version/s: (was: 3.x)
   3.0.0

> Exception on upgrade to trunk
> -
>
> Key: CASSANDRA-8655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8655
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
> Fix For: 3.0.0
>
>
> The dtest 
> upgrade_through_versions_test.TestUpgrade_from_cassandra_2_1_latest_tag_to_trunk_HEAD.upgrade_test_mixed
>  is failing with the following exception:
> {code}
> ERROR [Thread-10] 2015-01-20 14:12:44,117 CassandraDaemon.java:170 - 
> Exception in thread Thread[Thread-10,5,main]
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.db.SliceFromReadCommandSerializer.deserialize(SliceFromReadCommand.java:153)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:157)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:131)
>  ~[main/:na]
> at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99) 
> ~[main/:na]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:168)
>  ~[main/:na]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:150)
>  ~[main/:na]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:82)
>  ~[main/:na]
> {code}
> It is trying to execute a simple "SELECT k,v FROM cf WHERE k=X" query on a 
> trunk node after upgrading from 2.1-HEAD.



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

[jira] [Updated] (CASSANDRA-9357) LongSharedExecutorPoolTest.testPromptnessOfExecution fails in 2.1

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9357:
-
Fix Version/s: (was: 2.2.x)
   (was: 2.1.x)
   (was: 3.x)
   3.1

> LongSharedExecutorPoolTest.testPromptnessOfExecution fails in 2.1
> -
>
> Key: CASSANDRA-9357
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9357
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tests
>Reporter: Michael Shuler
> Fix For: 3.1
>
> Attachments: system.log
>
>
> {noformat}
> [junit] Testsuite: 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest
> [junit] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> 1.353 sec
> [junit] 
> [junit] - Standard Output ---
> [junit] Completed 0K batches with 0.0M events
> [junit] Running for 120s with load multiplier 0.5
> [junit] -  ---
> [junit] Testcase: 
> testPromptnessOfExecution(org.apache.cassandra.concurrent.LongSharedExecutorPoolTest):
> FAILED
> [junit] null
> [junit] junit.framework.AssertionFailedError
> [junit] at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:215)
> [junit] at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:104)
> [junit] 
> [junit] 
> [junit] Test org.apache.cassandra.concurrent.LongSharedExecutorPoolTest 
> FAILED
> {noformat}



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

[jira] [Updated] (CASSANDRA-10059) Test Coverage for AbstractBTreePartition and hierarchy

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10059:
--
Issue Type: Test  (was: Bug)

> Test Coverage for AbstractBTreePartition and hierarchy
> --
>
> Key: CASSANDRA-10059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10059
> Project: Cassandra
>  Issue Type: Test
>  Components: Core
>Reporter: Benedict
> Fix For: 3.1
>
>
> Follow up to CASSANDRA-9932. The test coverage for AbstractBTreePartition and 
> its hierarchy is entirely indirect. That is not to say it is not covered, but 
> we may have some unexplored behaviour. Coverage for BTree is also missing 
> around a couple of edges, and the gaps should be filled in.



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

[jira] [Updated] (CASSANDRA-10059) Test Coverage for AbstractBTreePartition and hierarchy

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10059:
--
Fix Version/s: (was: 3.0.x)
   3.1

> Test Coverage for AbstractBTreePartition and hierarchy
> --
>
> Key: CASSANDRA-10059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10059
> Project: Cassandra
>  Issue Type: Test
>  Components: Core
>Reporter: Benedict
> Fix For: 3.1
>
>
> Follow up to CASSANDRA-9932. The test coverage for AbstractBTreePartition and 
> its hierarchy is entirely indirect. That is not to say it is not covered, but 
> we may have some unexplored behaviour. Coverage for BTree is also missing 
> around a couple of edges, and the gaps should be filled in.



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

[jira] [Updated] (CASSANDRA-10134) Always require replace_address to replace existing address

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10134:
--
Issue Type: Improvement  (was: Bug)

> Always require replace_address to replace existing address
> --
>
> Key: CASSANDRA-10134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10134
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Tyler Hobbs
>Assignee: Stefania
> Fix For: 3.x, 2.1.x, 2.2.x
>
>
> Normally, when a node is started from a clean state with the same address as 
> an existing down node, it will fail to start with an error like this:
> {noformat}
> ERROR [main] 2015-08-19 15:07:51,577 CassandraDaemon.java:554 - Exception 
> encountered during startup
> java.lang.RuntimeException: A node with address /127.0.0.3 already exists, 
> cancelling join. Use cassandra.replace_address if you want to replace this 
> node.
>   at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:543)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:783)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:720)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:611)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378) 
> [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
>  [main/:na]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:626) 
> [main/:na]
> {noformat}
> However, if {{auto_bootstrap}} is set to false or the node is in its own seed 
> list, it will not throw this error and will start normally.  The new node 
> then takes over the host ID of the old node (even if the tokens are 
> different), and the only message you will see is a warning in the other 
> nodes' logs:
> {noformat}
> logger.warn("Changing {}'s host ID from {} to {}", endpoint, storedId, 
> hostId);
> {noformat}
> This could cause an operator to accidentally wipe out the token information 
> for a down node without replacing it.  To fix this, we should check for an 
> endpoint collision even if {{auto_bootstrap}} is false or the node is a seed.



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

[jira] [Updated] (CASSANDRA-10175) cassandra-stress should be tolerant when a remote node shutdown

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10175:
--
Issue Type: Improvement  (was: Bug)

> cassandra-stress should be tolerant when a remote node shutdown 
> 
>
> Key: CASSANDRA-10175
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10175
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Alan Boudreault
> Fix For: 3.x
>
>
> Currently, if we start a stress session with 3 nodes and shutdown one node, 
> stress will crash. It is caused by the JMX connection lost on the node, which 
> is use to collect some gc stats IIRC. 
> backtrace: https://gist.github.com/aboudreault/6cd82bb0acc681992414
> Stress should handle that jmx connection lost in a better way so the session 
> could continue. Ideally, it should try to *reconnect* to JMX if the node is 
> back online?



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

[jira] [Updated] (CASSANDRA-10246) Named values don't work with batches

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10246:
--
Fix Version/s: (was: 3.0.x)
   3.1

> Named values don't work with batches
> 
>
> Key: CASSANDRA-10246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10246
> Project: Cassandra
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Penick
>  Labels: client-impacting
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> This is broken at the protocol-level and in the implementation.
> At the protocol-level the {{}} component of the batch comes after the 
> queries. That means the protocol parser would need to read ahead (and back 
> track) to determine the values encoding and correctly read the values from 
> the query entries. Also, a batch-level setting for named values forces all 
> queries to use the same encoding. Should batches force a single, homogenous 
> query value encoding? (This is confusing)
> In the implementation, values are indiscriminately read using 
> {{CBUtil.readValueList()}}, and the batch flags are never checked (for 
> {{(Flag.NAMES_FOR_VALUES}}) to see if {{CBUtil.readNameAndValueList()}} 
> should be called instead: 
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/transport/messages/BatchMessage.java#L64
> Proposed solution: CASSANDRA-10247



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

[jira] [Updated] (CASSANDRA-10089) NullPointerException in Gossip handleStateNormal

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10089:
--
Fix Version/s: (was: 3.0.x)
   3.1

> NullPointerException in Gossip handleStateNormal
> 
>
> Key: CASSANDRA-10089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10089
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.1
>
> Attachments: node1_debug.log, node2_debug.log, node3_debug.log
>
>
> Whilst comparing dtests for CASSANDRA-9970 I found [this failing 
> dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9970-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/]
>  in 2.2:
> {code}
> Unexpected error in node1 node log: ['ERROR [GossipStage:1] 2015-08-14 
> 15:39:57,873 CassandraDaemon.java:183 - Exception in thread 
> Thread[GossipStage:1,5,main] java.lang.NullPointerException: null \tat 
> org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1731)
>  ~[main/:na] \tat 
> org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1804)
>  ~[main/:na] \tat 
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1857)
>  ~[main/:na] \tat 
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1629)
>  ~[main/:na] \tat 
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2312) 
> ~[main/:na] \tat 
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1025) 
> ~[main/:na] \tat 
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1106) 
> ~[main/:na] \tat 
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>  ~[main/:na] \tat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) 
> ~[main/:na] \tat 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_80] \tat 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  ~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]']
> {code}
> I wasn't able to find it on unpatched branches  but it is clearly not related 
> to CASSANDRA-9970, if anything it could have been a side effect of 
> CASSANDRA-9871.



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

[jira] [Updated] (CASSANDRA-10474) Streaming should tolerate secondary index build failure

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10474:
--
Fix Version/s: (was: 3.0.x)
   3.1

> Streaming should tolerate secondary index build failure
> ---
>
> Key: CASSANDRA-10474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10474
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Yuki Morishita
>  Labels: streaming
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> When streaming failed to build secondary index at the end of streaming (like 
> in CASSANDRA-10449), streaming session can hang as it throws exception 
> without catching it.
> Streaming should tolerate secondary index build failure, and instead of 
> failing (hanging) streaming session, it should WARN user and go on.



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

[jira] [Updated] (CASSANDRA-10422) Avoid anticompaction when doing subrange repair

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10422:
--
Fix Version/s: (was: 3.x)
   3.1

> Avoid anticompaction when doing subrange repair
> ---
>
> Key: CASSANDRA-10422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10422
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> If we do split the owned range in say 1000 parts, and then do one repair 
> each, we could potentially anticompact every sstable 1000 times (ie, we 
> anticompact the repaired range out 1000 times). We should avoid 
> anticompacting at all in these cases.



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

[jira] [Updated] (CASSANDRA-5261) Remove token generator

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-5261:
-
Fix Version/s: (was: 3.x)
   3.0.0

> Remove token generator
> --
>
> Key: CASSANDRA-5261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5261
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Jonathan Ellis
>Priority: Minor
>  Labels: triaged
> Fix For: 3.0.0
>
>
> Obsoleted by vnodes



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

[jira] [Created] (CASSANDRA-10580) When mutations are dropped, the column family should be printed / have a counter per column family

[Anubhav Kale (JIRA)]

Anubhav Kale created CASSANDRA-10580:


 Summary: When mutations are dropped, the column family should be 
printed / have a counter per column family
 Key: CASSANDRA-10580
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10580
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
 Environment: Production
Reporter: Anubhav Kale
Priority: Minor
 Fix For: 2.1.x


In our production cluster, we are seeing a large number of dropped mutations. 
It would be really helpful to see which column families are really affected by 
this (either through logs or through a dedicated counter for every column 
family).

I have made a hack in StorageProxy (below) to help us with this. I am happy to 
extend this to a better solution (print the CF affected in as logger.debug and 
then manually grep) if experts agree this additional detail would be helpful in 
general. Any other suggestions are welcome.

private static abstract class LocalMutationRunnable implements Runnable
{
private final long constructionTime = System.currentTimeMillis();

private IMutation mutation;

public final void run()
{
if (System.currentTimeMillis() > constructionTime + 2000L)
{
long timeTaken = System.currentTimeMillis() - constructionTime;
logger.warn("Anubhav LocalMutationRunnable thread ran after " + 
timeTaken);

try
{
 for(ColumnFamily family : 
this.mutation.getColumnFamilies())
 {
if 
(family.toString().toLowerCase().contains("udsuserdailysnapshot"))
{

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.USERDAILY);
}

else if 
(family.toString().toLowerCase().contains("udsuserhourlysnapshot"))
{

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.USERHOURLY);
}

else if 
(family.toString().toLowerCase().contains("udstenantdailysnapshot"))
{

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.TENANTDAILY);
}

else if 
(family.toString().toLowerCase().contains("udstenanthourlysnapshot"))
{

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.TENANTHOURLY);
}

else if 
(family.toString().toLowerCase().contains("userdatasetraw"))
{

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.USERDSRAW);
}

else if 
(family.toString().toLowerCase().contains("tenants"))
{

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.TENANTS);
}

else if 
(family.toString().toLowerCase().contains("users"))
{

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.USERS);
}

else if 
(family.toString().toLowerCase().contains("tenantactivity"))
{

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.TENANTACTIVITY);
}

else if 
(family.getKeySpaceName().toLowerCase().contains("system"))
{

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.SYSTEMKS);
}

else
{
logger.warn("Anubhav LocalMutationRunnable 
updating mutations for " + family.toString().toLowerCase());

MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.OTHERTBL);
}
 }  
}
catch (Exception e)
{
logger.error("Anubhav LocalMutationRunnable Exception 
", e);
}

[jira] [Updated] (CASSANDRA-10096) SerializationHelper should provide a rewindable in-order tester

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10096:
--
Issue Type: Improvement  (was: Bug)

> SerializationHelper should provide a rewindable in-order tester
> ---
>
> Key: CASSANDRA-10096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10096
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Benedict
>Priority: Minor
> Fix For: 3.x
>
>
> When deserializing a row we perform a logarithmic lookup on column name for 
> every cell. There is also a lot of unnecessary indirection to reach this 
> method call.



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

[jira] [Updated] (CASSANDRA-9223) ArithmeticException after decommission

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9223:
-
Fix Version/s: (was: 3.x)
   3.1

> ArithmeticException after decommission
> --
>
> Key: CASSANDRA-9223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9223
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Brandon Williams
>Priority: Minor
> Fix For: 3.1
>
>
> Also seen on trunk while working on CASSANDRA-8072:
> {noformat}
> ERROR 19:21:33 Exception in thread Thread[BatchlogTasks:1,5,main]
> java.lang.ArithmeticException: / by zero
>  at 
> org.apache.cassandra.db.BatchlogManager.replayAllFailedBatches(BatchlogManager.java:173)
>  ~[main/:na]
>  at 
> org.apache.cassandra.db.BatchlogManager.access$000(BatchlogManager.java:61) 
> ~[main/:na]
>  at 
> org.apache.cassandra.db.BatchlogManager$1.runMayThrow(BatchlogManager.java:91)
>  ~[main/:na]
>  at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>  at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:82)
>  ~[main/:na]
>  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> [na:1.7.0_76]
>  at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) 
> [na:1.7.0_76]
>  at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>  [na:1.7.0_76]
>  at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.7.0_76]
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_76]
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_76]
>  at java.lang.Thread.run(Thread.java:745) [na:1.7.0_76]
> {noformat}



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

[jira] [Updated] (CASSANDRA-10179) Duplicate index should throw AlreadyExistsException

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10179:
--
Issue Type: Improvement  (was: Bug)

> Duplicate index should throw AlreadyExistsException
> ---
>
> Key: CASSANDRA-10179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10179
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: T Jake Luciani
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.x
>
>
> If a 2i already exists we currently throw a InvalidQueryException.  This 
> should be a AlreadyExistsException for consistency like trying to create the 
> same CQL Table twice.



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

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

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10271:
--
Issue Type: Improvement  (was: Bug)

> 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: API, Core
>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-10350) cqlsh describe keyspace output no longers keeps indexes in sorted order

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10350:
---

[~aholmber] Can we fix this in the driver?

> cqlsh describe keyspace output no longers keeps indexes in sorted order
> ---
>
> Key: CASSANDRA-10350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10350
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Andrew Hust
>Priority: Minor
>  Labels: cqlsh
> Fix For: 3.1
>
>
> cqlsh command {{describe keyspace }} no longer keeps indexes in alpha 
> sorted order.  This was caught with a dtest on 
> [cassci|http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe/].
> Tested on: C* {{b4544846def2bdd00ff841c7e3d9f2559620827b}}
> Can be reproduced with the following:
> {code}
> ccm stop
> ccm remove describe_order
> ccm create -n 1 -v git:cassandra-2.2 describe_order
> ccm start
> cat << EOF | ccm node1 cqlsh
> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> USE ks1;
> CREATE TABLE ks1.test (id int, col int, val text, val2 text, val3 text, 
> PRIMARY KEY(id, col));
> CREATE INDEX ix0 ON ks1.test (col);
> CREATE INDEX ix3 ON ks1.test (val3);
> CREATE INDEX ix2 ON ks1.test (val2);
> CREATE INDEX ix1 ON ks1.test (val);
> DESCRIBE KEYSPACE ks1;
> EOF
> ccm stop
> ccm setdir -v git:cassandra-3.0
> ccm start
> sleep 15
> cat << EOF | ccm node1 cqlsh
> DESCRIBE KEYSPACE ks1;
> EOF
> ccm stop
> {code}
> Ouput on <= cassandra-2.2:
> {code}
> CREATE INDEX ix0 ON ks1.test (col);
> CREATE INDEX ix1 ON ks1.test (val);
> CREATE INDEX ix2 ON ks1.test (val2);
> CREATE INDEX ix3 ON ks1.test (val3);
> {code}
> Output on cassandra-3.0:
> {code}
> CREATE INDEX ix2 ON ks1.test (val2);
> CREATE INDEX ix3 ON ks1.test (val3);
> CREATE INDEX ix0 ON ks1.test (col);
> CREATE INDEX ix1 ON ks1.test (val);
> {code}
> //CC [~enigmacurry]



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

[jira] [Updated] (CASSANDRA-10374) List and Map values incorrectly limited to 64k size

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10374:
--
Fix Version/s: (was: 3.0.x)
   3.1

> List and Map values incorrectly limited to 64k size
> ---
>
> Key: CASSANDRA-10374
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10374
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Tyler Hobbs
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> With the v3 native protocol, we switched from encoding collection element 
> sizes with shorts to ints.  However, in {{Lists.java}} and {{Maps.java}}, we 
> still validate that list and map values are smaller than 
> {{MAX_UNSIGNED_SHORT}}.
> Map keys and set elements are stored in the cell name, so they're implicitly 
> limited to the cell name size limit of 64k.  However, for non-frozen 
> collections, this limitation should not apply, so we probably don't want to 
> perform this check here for those either.
> The fix should include tests where we exceed the 64k limit for frozen and 
> non-frozen collections.  In the case of non-frozen lists and maps, we should 
> verify that the 64k cell-name size limit is enforced in a friendly way.



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

[jira] [Updated] (CASSANDRA-10405) MV updates should optionally wait for acknowledgement from view replicas

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-10405:
---
Priority: Minor  (was: Major)

> MV updates should optionally wait for acknowledgement from view replicas
> 
>
> Key: CASSANDRA-10405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10405
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Carl Yeksigian
>Priority: Minor
>  Labels: materializedviews
> Fix For: 3.x
>
>
> MV updates are currently completely asynchronous in order to provide 
> parallelism of updates trying to acquire the partition lock. For some use 
> cases, leaving the MV updates asynchronous is exactly what's needed.
> However, there are some use cases where knowing that the update has either 
> succeeded or failed on the view is necessary, especially when trying to allow 
> read-your-write behavior. In those cases, we would follow the same code path 
> as asynchronous writes, but at the end wait on the acknowledgements from the 
> view replicas before acknowledging our write. This option should be for each 
> MV separately, since MVs which need the synchronous properties might be mixed 
> with MV which do not need this.



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

[jira] [Updated] (CASSANDRA-10179) Duplicate index should throw AlreadyExistsException

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10179:
--
Issue Type: Sub-task  (was: Improvement)
Parent: CASSANDRA-9362

> Duplicate index should throw AlreadyExistsException
> ---
>
> Key: CASSANDRA-10179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10179
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: T Jake Luciani
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.x
>
>
> If a 2i already exists we currently throw a InvalidQueryException.  This 
> should be a AlreadyExistsException for consistency like trying to create the 
> same CQL Table twice.



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

[jira] [Comment Edited] (CASSANDRA-8653) Upgrading to trunk with auth throws exception

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe edited comment on CASSANDRA-8653 at 10/23/15 4:23 PM:
--

bq. This ticket mentions trunk, but any reason to think 3.0 is immune to that?
It's actually the 3.0 that the test upgrades to, or it would be except it's 
currently skipped (waiting on CASSANDRA-9704, so should be re-enabled). When I 
run locally I see no auth problems and the test completes as expected. It fails 
though because of an unexpected ERROR in the log of node1, which is thrown just 
after the last node is upgraded:

{noformat}
ERROR [HintsDispatcher:2] 2015-10-23 17:18:53,942 CassandraDaemon.java:195 - 
Exception in thread Thread[HintsDispatcher:2,1,main]
java.lang.RuntimeException: java.nio.file.NoSuchFileException: 
/home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints
at 
org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55) 
~[main/:na]
at org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66) 
~[main/:na]
at 
org.apache.cassandra.hints.ChecksummedDataInput.open(ChecksummedDataInput.java:63)
 ~[main/:na]
at org.apache.cassandra.hints.HintsReader.open(HintsReader.java:77) 
~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatcher.create(HintsDispatcher.java:71) 
~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
 ~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
 ~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
 ~[main/:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
Caused by: java.nio.file.NoSuchFileException: 
/home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) 
~[na:1.8.0_60]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) 
~[na:1.8.0_60]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) 
~[na:1.8.0_60]
at 
sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
 ~[na:1.8.0_60]
at java.nio.channels.FileChannel.open(FileChannel.java:287) ~[na:1.8.0_60]
at java.nio.channels.FileChannel.open(FileChannel.java:335) ~[na:1.8.0_60]
at 
org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:51) 
~[main/:na]
... 12 common frames omitted
{noformat}


was (Author: beobal):
b.q This ticket mentions trunk, but any reason to think 3.0 is immune to that?
It's actually the 3.0 that the test upgrades to, or it would be except it's 
currently skipped (waiting on CASSANDRA-9704, so should be re-enabled). When I 
run locally I see no auth problems and the test completes as expected. It fails 
though because of an unexpected ERROR in the log of node1, which is thrown just 
after the last node is upgraded:

{noformat}
RROR [HintsDispatcher:2] 2015-10-23 17:18:53,942 CassandraDaemon.java:195 - 
Exception in thread Thread[HintsDispatcher:2,1,main]
java.lang.RuntimeException: java.nio.file.NoSuchFileException: 
/home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints
at 
org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55) 
~[main/:na]
at org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66) 
~[main/:na]
at 
org.apache.cassandra.hints.ChecksummedDataInput.open(ChecksummedDataInput.java:63)
 ~[main/:na]
at org.apache.cassandra.hints.HintsReader.open(HintsReader.java:77) 
~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatcher.create(HintsDispatcher.java:71) 
~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
 ~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
 ~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
 ~[main/:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 

[jira] [Commented] (CASSANDRA-10258) Counter table written with CQLSSTableWriter generates exceptions and become corrupted at first use

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10258:
---

bq. So really, the simplest and imo best solution is to add "you cannot write 
sstable yourself with CQLSSTableWriter" to the list of counters limitations.

Basically, this.

> Counter table written with CQLSSTableWriter generates exceptions and become 
> corrupted at first use
> --
>
> Key: CASSANDRA-10258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10258
> Project: Cassandra
>  Issue Type: Bug
>  Components: API
> Environment: Linux Debian Wheezie 7.8 / Oracle Java 1.7.0_67
> Ubuntu 14.04.3 LTS / Oracle Java 1.7.0_75
> Cassandra 2.0.12 2.1.5 2.1.8
>Reporter: Guillaume VIEL
>Assignee: Paulo Motta
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> We use CQLSStableWriter to produce testing datasets.
> Here are the steps to reproduce this issue :
> 1) definition of a table with counter
> {code}
> CREATE TABLE my_counter (
>   my_id text,
>   my_counter counter,
>   PRIMARY KEY (my_id)
> )
> {code}
> 2) with CQLSSTableWriter initialize this table (about 2millions entries) with 
> this insert order (one insert / key only)
> {{UPDATE myks.my_counter SET my_counter = my_counter + ? WHERE my_id = ?}}
> 3) load the files written by CQLSSTableWriter with sstableloader in your 
> cassandra cluster (tested on a single node and a 3 nodes cluster)
> 4) start a process that updates the counters (we used 3millions entries 
> distributed on the key my_id)
> 5) after a while try to query a key in the my_counter table
> {{cqlsh:myks> select * from my_counter where my_id='001';}}
> Request did not complete within rpc_timeout.
> In the logs of cassandra (2.0.12) :
> {code}
> ERROR [CompactionExecutor:3] 2015-05-28 15:53:39,491 CassandraDaemon.java 
> (line 258) Exception in thread Thread[CompactionExecutor:3,1,main]
> java.lang.AssertionError: Wrong class type.
> at 
> org.apache.cassandra.db.CounterUpdateColumn.reconcile(CounterUpdateColumn.java:70)
> at 
> org.apache.cassandra.db.ArrayBackedSortedColumns.resolveAgainst(ArrayBackedSortedColumns.java:147)
> at 
> org.apache.cassandra.db.ArrayBackedSortedColumns.addColumn(ArrayBackedSortedColumns.java:126)
> at 
> org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:121)
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow$1.reduce(PrecompactedRow.java:120)
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow$1.reduce(PrecompactedRow.java:115)
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:112)
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98)
> at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at 
> org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:191)
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:144)
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:103)
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:85)
> at 
> org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:196)
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:74)
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:55)
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:115)
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98)
> at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:164)
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
> at 
> 

[jira] [Updated] (CASSANDRA-9181) Improve index versus secondary index selection

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9181:
-
Issue Type: Improvement  (was: Bug)

> Improve index versus secondary index selection
> --
>
> Key: CASSANDRA-9181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9181
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jeremy Hanna
>  Labels: 2i
> Fix For: 3.x
>
>
> There is a special case for secondary indexes if you always supply the 
> partition key.  For example, if you have a family with ID "a456" which has 6 
> family members and I have a secondary index on first name.  Currently, if I 
> do a query like this "select * from families where id = 'a456' and firstname 
> = 'alowishus';" you can see from a query trace, that it will first scan the 
> entire cluster based on the firstname, then look for the key within that.
> If it's not terribly invasive, I think this would be a valid use case to 
> narrow down the results by key first.



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

[jira] [Updated] (CASSANDRA-9654) Failure to open sstable after upgrade to trunk

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9654:
-
Fix Version/s: (was: 3.x)
   3.0.0

> Failure to open sstable after upgrade to trunk
> --
>
> Key: CASSANDRA-9654
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9654
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Philip Thompson
>Assignee: Branimir Lambov
> Fix For: 3.0.0
>
> Attachments: node1.log, node2.log, node3.log, sstables.tar.gz
>
>
> After upgrading a 3 node cluster on the path 1.2.19 -> 2.0.16 -> 2.1-head -> 
> 2.2-head -> trunk
> {code}
> ERROR [SSTableBatchOpen:1] 2015-06-25 17:16:55,424 SSTableReader.java:435 - 
> Cannot open /tmp/dtest-Ibi6zm/test/node1/data/upgrade/cf/la-7-big; 
> partitioner org.apache.cassandra.dht.LocalPartitioner does not match system 
> partitioner org.apache.cassandra.dht.Murmur3Partitioner.  Note that the 
> default partitioner starting with Cassandra 1.2 is Murmur3Partitioner, so you 
> will need to edit that to match your old partitioner if upgrading.
> ERROR [SSTableBatchOpen:2] 2015-06-25 17:16:55,425 SSTableReader.java:435 - 
> Cannot open /tmp/dtest-Ibi6zm/test/node1/data/upgrade/cf/la-10-big; 
> partitioner org.apache.cassandra.dht.LocalPartitioner does not match system 
> partitioner org.apache.cassandra.dht.Murmur3Partitioner.  Note that the 
> default partitioner starting with Cassandra 1.2 is Murmur3Partitioner, so you 
> will need to edit that to match your old partitioner if upgrading.
> {code}
> Node logs are attached.
> To reproduce, you'll need to run the upgrade dtest as follows:
> {{nosetests -sv 
> upgrade_through_versions_test.py:TestUpgradeThroughVersions.upgrade_test}}. I 
> don't have CI results for this yet, nor will I soon. To run this, you'll need 
> both JDK7 and JDK8 installed, for compilation reasons. Set the env vars 
> JAVA7_HOME and JAVA8_HOME, respectively. I'll work on finding an sstable that 
> represent the issue.



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

[jira] [Updated] (CASSANDRA-10050) Secondary Index Performance Dependent on TokenRange Searched in Analytics

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10050:
--
Issue Type: Improvement  (was: Bug)

> Secondary Index Performance Dependent on TokenRange Searched in Analytics
> -
>
> Key: CASSANDRA-10050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10050
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
> Environment: Single node, macbook, 2.1.8
>Reporter: Russell Alexander Spitzer
> Fix For: 3.x
>
>
> In doing some test work on the Spark Cassandra Connector I saw some odd 
> performance when pushing down range queries with Secondary Index filters. 
> When running the queries we see huge amount of time when the C* server is not 
> doing any work and the query seem to be hanging. This investigation led to 
> the work in this document
> https://docs.google.com/spreadsheets/d/1aJg3KX7nPnY77RJ9ZT-IfaYADgJh0A--nAxItvC6hb4/edit#gid=0
> The Spark Cassandra Connector builds up token range specific queries and 
> allows the user to pushdown relevant fields to C*. Here we have two indexed 
> fields (size) and (color) being pushed down to C*. 
> {code}
> SELECT count(*) FROM ks.tab WHERE token("store") > $min AND token("store") <= 
> $max AND color = 'red' AND size = 'P' ALLOW FILTERING;{code}
> These queries will have different token ranges inserted and executed as 
> separate spark tasks. Spark tasks with token ranges near the Min(token) end 
> up executing much faster than those near Max(token) which also happen to 
> through errors.
> {code}
> Coordinator node timed out waiting for replica nodes' responses] 
> message="Operation timed out - received only 0 responses." 
> info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> I took the queries and ran them through CQLSH to see the difference in time. 
> A linear relationship is seen based on where the tokenRange being queried is 
> starting with only 2 second for queries near the beginning of the full token 
> spectrum and over 12 seconds at the end of the spectrum. 
> The question is, can this behavior be improved? or should we not recommend 
> using secondary indexes with Analytics workloads?



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

[jira] [Updated] (CASSANDRA-10341) Streaming does not guarantee cache invalidation

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10341:
--
Fix Version/s: (was: 3.0.x)
   3.1

> Streaming does not guarantee cache invalidation
> ---
>
> Key: CASSANDRA-10341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10341
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Benedict
>Assignee: Paulo Motta
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> Looking at the code, we attempt to invalidate the row cache for any rows we 
> receive via streaming, however we invalidate them immediately, before the new 
> data is available. So, if it is requested (which is likely if it is "hot") in 
> the interval, it will be re-cached and not invalidated.



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

[jira] [Updated] (CASSANDRA-10511) Index summary downsampling prevents mmap access of large files after restart

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10511:
--
Fix Version/s: (was: 3.0.x)
   (was: 3.x)
   3.1

> Index summary downsampling prevents mmap access of large files after restart
> 
>
> Key: CASSANDRA-10511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10511
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Benedict
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> {{SSTableReader.cloneWithNewSummarySampleLevel}} constructs a 
> {{SegmentedFile.Builder}} but never populates it with any boundaries. For 
> files larger than 2Gb, this will result in their being accessed via buffered 
> io after a restart.



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

[jira] [Updated] (CASSANDRA-2986) Fix short reads in range (and index?) scans

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-2986:
-
Issue Type: Improvement  (was: Bug)

> Fix short reads in range (and index?) scans
> ---
>
> Key: CASSANDRA-2986
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2986
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 3.x
>
>
> See CASSANDRA-2643 for the [multi]get fix.



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

[jira] [Resolved] (CASSANDRA-8554) Node where gossip is disabled still shows as UP on that node; other nodes show it as DN

[Aleksey Yeschenko (JIRA)]

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

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

> Node where gossip is disabled still shows  as UP on that node; other nodes 
> show it as DN
> 
>
> Key: CASSANDRA-8554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8554
> Project: Cassandra
>  Issue Type: Bug
> Environment: Centos 6.5, DSE4.5.1 tarball install
>Reporter: Mark Curtis
>Priority: Minor
>
> When running nodetool drain, the drained node will still show the status of 
> itself as UP in nodetool status even after the drain has finished. For 
> example using a 3 node cluster on one of the nodes that is still operating 
> and not drained we see this:
> {code}
> $ ./dse-4.5.1/bin/nodetool status
> Note: Ownership information does not include topology; for complete 
> information, specify a keyspace
> Datacenter: Central
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  AddressLoad   Tokens  Owns   Host ID  
>  Rack
> UN  192.168.56.21  210.78 KB  256 32.1%  
> 82eb2fca-4f57-467b-a972-93096ec5d69f  RAC1
> DN  192.168.56.23  2.22 GB256 33.5%  
> a11bfac1-fad0-440b-bd68-7562a89ce3c7  RAC1
> UN  192.168.56.22  2.22 GB256 34.4%  
> 4250cb05-97be-4bac-887a-acc307d1bc0c  RAC1
> {code}
> While on the drained node we see this:
> {code}
> [datastax@DSE4 ~]$ ./dse-4.5.1/bin/nodetool drain
> [datastax@DSE4 ~]$ ./dse-4.5.1/bin/nodetool status
> Note: Ownership information does not include topology; for complete 
> information, specify a keyspace
> Datacenter: Central
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  AddressLoad   Tokens  Owns   Host ID  
>  Rack
> UN  192.168.56.21  210.78 KB  256 32.1%  
> 82eb2fca-4f57-467b-a972-93096ec5d69f  RAC1
> UN  192.168.56.23  2.22 GB256 33.5%  
> a11bfac1-fad0-440b-bd68-7562a89ce3c7  RAC1
> UN  192.168.56.22  2.22 GB256 34.4%  
> 4250cb05-97be-4bac-887a-acc307d1bc0c  RAC1
> {code}
> Netstat shows outgoing connections from the drained node to other nodes as 
> still established on port 7000 but the node is no longer listening on port 
> 7000 which I believe is expected.
> However the output of nodetool status on the drained node could be 
> interpreted as misleading.



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

[jira] [Updated] (CASSANDRA-9222) AssertionError after decommission

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9222:
-
Fix Version/s: (was: 3.x)
   3.1

> AssertionError after decommission
> -
>
> Key: CASSANDRA-9222
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9222
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Brandon Williams
>Priority: Minor
> Fix For: 3.1
>
>
> Saw this on trunk while working on CASSANDRA-8072, but it may affect earlier 
> revisions as well:
> {noformat}
> INFO  17:48:57 MessagingService has terminated the accept() thread
> INFO  17:48:58 DECOMMISSIONED
> ERROR 17:52:25 Exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.AssertionError: -1011553757645129692 not found in 
> -9212067178699207814, -9200531256183869940, -9166030381776079682, 
> -9162013024688602642, -9151724494713671168, -9095828490921521759, 
> -9035494031488373110, -8993765846966048219, -8912013107131353260, 
> -8909000788978186800, -8879514397454962673, -8868628980500567099, 
> -8850730903031889070, -8810378752213886595, -8779200870214886308, 
> -8758215747589442842, -8751091270073031687, -8727034084505556969, 
> -8665197275159395069, -8656563059526305598, -8468078121019364990, 
> -8465001791134178844, -8442193507205463429, -8422069069190372219, 
> -8342133517826612505, -8341643847610190520, -8340770353573450569, 
> -8337671516798157281, -8299063757464280571, -8294397037816683529, 
> -8190643358275415766, -8125907580996325958, -8080821167493102683, 
> -8058428707430264364, -8033777866368709204, -8018079744052327023, 
> -8005568943124488030, -7911488756902729132, -7831006227012170930, 
> -7824529182957931950, -7807286997402075771, -7795080548612350344, 
> -7778629955912441437, -7771701686959718810, -7759250335393772671, 
> -7745731940317799541, -7703194536911509010, -7694764467260740698, 
> -7691909270364954632, -7687121918922986909, -7682707339911246942, 
> -7517133373189921954, -7482800574078120526, -7475897243891441451, 
> -7334307376946940271, -7326649207653179327, -7258677281263041990, 
> -7221843646683358238, -7193299656451825680, -7105256682000196035, 
> -7035269781687029457, -7024278722443497027, -7019197046707993025, 
> -7015131617238216508, -7003811999522811317, -6980314778696530567, 
> -6966235125715836473, -691530498397662, -6912703644363131398, 
> -6881456879008059927, -6861265076865721267, -6850740895102395611, 
> -6808435504617684311, -6785202117470372844, -6782573711981746574, 
> -6763604807975420855, -6738443719321921481, -6718513123799422576, 
> -6711670508127917469, -6709012720615571304, -6645945635050443947, 
> -6629420613692951932, -6542209628003661283, -6535684002637060628, 
> -6507671461487774245, -6423206762015678338, -6409843839148310789, 
> -6404011469157179029, -6381904465334594648, -6311911206861962333, 
> -6296991709696294898, -6264931794517958640, -6261574198670386500, 
> -6261382604358802512, -6252257370391459113, -6241897861580419597, 
> -6227245701986117982, -6199525755295090433, -6180934919369759659, 
> -6144605078172691818, -6126223305042342065, -6118447361839427651, 
> -6074679422903704861, -6053157348245110185, -6029489996808528900, 
> -5984211855143878285, -5976157876053718897, -5960786495011670628, 
> -5958735514226770035, -5899767639655442330, -5822684184303415148, 
> -5781417439294763637, -5751460432371890910, -5740166642636309327, 
> -5695626417612186310, -5640765045723408247, -5617181156049689169, 
> -5609533985177356591, -5601369236916580549, -5597950494887081576, 
> -5563417985168606424, -5544827346340456629, -5532661047516804641, 
> -5522839053491352218, -5515748028172318343, -5503681859719385351, 
> -5454037971834611841, -5391841126413524561, -5391486446881271229, 
> -5345799278441821500, -5334673760925625816, -5223383618739305156, 
> -5221923994481449381, -5201263557535069480, -5146266397250565218, 
> -5129908985877585855, -5105202808286786842, -5087879514740126453, 
> -5015647678958926683, -4956601765875516828, -4870012706573251068, 
> -4843165740363419346, -4785540557423875550, -4769272272470020667, 
> -4743838345902355963, -4652149714081482841, -4651813505681686208, 
> -4633498525751156636, -4617489888285113964, -4575171285024168183, 
> -4426852178336308913, -4426400792698710435, -4389286320937036309, 
> -4324528033603203034, -4310368852323145495, -4302216608677327172, 
> -4229528661709148440, -4207740831738287983, -4203528661247313570, 
> -3948641241721335982, -3946554569612854645, -3931865850800685387, 
> -3925635355333550077, -3834502440481769685, -3827908348147378297, 
> -3805680095754927988, -3804947918584815385, -3800995210938487618, 
> -3783564223836955070, -3775028120786497996, -3711629770355538643, 
> -3710182799291812403, -3643158926306968005, -3625334149683154824, 

[jira] [Updated] (CASSANDRA-10350) cqlsh describe keyspace output no longers keeps indexes in sorted order

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10350:
--
Fix Version/s: (was: 3.0.x)
   3.1

> cqlsh describe keyspace output no longers keeps indexes in sorted order
> ---
>
> Key: CASSANDRA-10350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10350
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Andrew Hust
>Priority: Minor
>  Labels: cqlsh
> Fix For: 3.1
>
>
> cqlsh command {{describe keyspace }} no longer keeps indexes in alpha 
> sorted order.  This was caught with a dtest on 
> [cassci|http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe/].
> Tested on: C* {{b4544846def2bdd00ff841c7e3d9f2559620827b}}
> Can be reproduced with the following:
> {code}
> ccm stop
> ccm remove describe_order
> ccm create -n 1 -v git:cassandra-2.2 describe_order
> ccm start
> cat << EOF | ccm node1 cqlsh
> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> USE ks1;
> CREATE TABLE ks1.test (id int, col int, val text, val2 text, val3 text, 
> PRIMARY KEY(id, col));
> CREATE INDEX ix0 ON ks1.test (col);
> CREATE INDEX ix3 ON ks1.test (val3);
> CREATE INDEX ix2 ON ks1.test (val2);
> CREATE INDEX ix1 ON ks1.test (val);
> DESCRIBE KEYSPACE ks1;
> EOF
> ccm stop
> ccm setdir -v git:cassandra-3.0
> ccm start
> sleep 15
> cat << EOF | ccm node1 cqlsh
> DESCRIBE KEYSPACE ks1;
> EOF
> ccm stop
> {code}
> Ouput on <= cassandra-2.2:
> {code}
> CREATE INDEX ix0 ON ks1.test (col);
> CREATE INDEX ix1 ON ks1.test (val);
> CREATE INDEX ix2 ON ks1.test (val2);
> CREATE INDEX ix3 ON ks1.test (val3);
> {code}
> Output on cassandra-3.0:
> {code}
> CREATE INDEX ix2 ON ks1.test (val2);
> CREATE INDEX ix3 ON ks1.test (val3);
> CREATE INDEX ix0 ON ks1.test (col);
> CREATE INDEX ix1 ON ks1.test (val);
> {code}
> //CC [~enigmacurry]



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

[jira] [Updated] (CASSANDRA-9984) Improve error reporting for malformed schemas in stress profile

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9984:
-
Fix Version/s: (was: 3.x)
   3.1

> Improve error reporting for malformed schemas in stress profile
> ---
>
> Key: CASSANDRA-9984
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9984
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jim Witschey
>Assignee: T Jake Luciani
>Priority: Trivial
> Fix For: 3.1
>
>
> See this gist:
> https://gist.github.com/mambocab/a78fae8c356223245c63
> for an example of a profile that triggers the bug when used as a stress 
> profile on trunk. It contains a number of old, now unused, configuration 
> options in the table schema. The error raised when this schema is executed 
> isn't propagated because of improper error handling.
> To reproduce this error with CCM you can save the file in the gist above as 
> {{8-columns.yaml}} and run
> {code}
> ccm create -v git:trunk reproduce-error -n 1
> ccm start --wait-for-binary-proto
> ccm stress user profile=8-columns.yaml ops\(insert=1\) n=5K
> {code}



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

[jira] [Updated] (CASSANDRA-10544) Make cqlsh tests work when authentication is configured

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10544:
--
Issue Type: Improvement  (was: Bug)

> Make cqlsh tests work when authentication is configured
> ---
>
> Key: CASSANDRA-10544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tests, Tools
>Reporter: Adam Holmberg
>Assignee: Stefania
>Priority: Trivial
>  Labels: cqlsh, test
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> cqlsh tests break if the runner has an authentication section in their 
> ~/.cassandra/cqlshrc, because cqlsh changes the prompt and the tests scan 
> output for a prompt. It manifests as read timeouts while waiting for a prompt 
> in test/run_cqlsh.py.
> [This 
> pattern|https://github.com/mambocab/cassandra/blob/1c27f9be1ba8ea10dbe843d513e23de6238dede8/pylib/cqlshlib/test/run_cqlsh.py#L30]
>  could be generalized to match the "@cqlsh..." prompt that arises 
> with this config.



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

[jira] [Updated] (CASSANDRA-9984) Improve error reporting for malformed schemas in stress profile

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9984:
-
Issue Type: Improvement  (was: Bug)

> Improve error reporting for malformed schemas in stress profile
> ---
>
> Key: CASSANDRA-9984
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9984
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jim Witschey
>Assignee: T Jake Luciani
>Priority: Trivial
> Fix For: 3.x
>
>
> See this gist:
> https://gist.github.com/mambocab/a78fae8c356223245c63
> for an example of a profile that triggers the bug when used as a stress 
> profile on trunk. It contains a number of old, now unused, configuration 
> options in the table schema. The error raised when this schema is executed 
> isn't propagated because of improper error handling.
> To reproduce this error with CCM you can save the file in the gist above as 
> {{8-columns.yaml}} and run
> {code}
> ccm create -v git:trunk reproduce-error -n 1
> ccm start --wait-for-binary-proto
> ccm stress user profile=8-columns.yaml ops\(insert=1\) n=5K
> {code}



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

[jira] [Updated] (CASSANDRA-10544) Make cqlsh tests work when authentication is configured

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10544:
--
Fix Version/s: (was: 3.0.x)
   3.1

> Make cqlsh tests work when authentication is configured
> ---
>
> Key: CASSANDRA-10544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tests, Tools
>Reporter: Adam Holmberg
>Assignee: Stefania
>Priority: Trivial
>  Labels: cqlsh, test
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> cqlsh tests break if the runner has an authentication section in their 
> ~/.cassandra/cqlshrc, because cqlsh changes the prompt and the tests scan 
> output for a prompt. It manifests as read timeouts while waiting for a prompt 
> in test/run_cqlsh.py.
> [This 
> pattern|https://github.com/mambocab/cassandra/blob/1c27f9be1ba8ea10dbe843d513e23de6238dede8/pylib/cqlshlib/test/run_cqlsh.py#L30]
>  could be generalized to match the "@cqlsh..." prompt that arises 
> with this config.



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

[jira] [Updated] (CASSANDRA-8965) Cassandra retains a file handle to the directory its writing to for each writer instance

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-8965:
-
Fix Version/s: (was: 3.x)
   3.1

> Cassandra retains a file handle to the directory its writing to for each 
> writer instance
> 
>
> Key: CASSANDRA-8965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8965
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Benedict
>Priority: Trivial
> Fix For: 3.1
>
>
> We could either share this amongst the CF object, or have a shared 
> ref-counted cache that opens a reference and shares it amongst all writer 
> instances, closing it once they all close.



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

[jira] [Resolved] (CASSANDRA-7324) Strange warnings during pig-test

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko resolved CASSANDRA-7324.
--
   Resolution: Won't Fix
Fix Version/s: (was: 2.1.x)

> Strange warnings during pig-test
> 
>
> Key: CASSANDRA-7324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7324
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tests
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Minor
>
> Not present in 2.0, we have strange but seemingly harmless warnings when 
> running pig-test on 2.1: 
> {noformat}
> [junit] 14/05/29 22:21:53 WARN util.MBeans: 
> Hadoop:service=DataNode,name=FSDatasetState-UndefinedStorageId-1779863485
> [junit] javax.management.InstanceNotFoundException: 
> Hadoop:service=DataNode,name=FSDatasetState-UndefinedStorageId-1779863485
> [junit] at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
> [junit] at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
> [junit] at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
> [junit] at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546)
> [junit] at 
> org.apache.hadoop.metrics2.util.MBeans.unregister(MBeans.java:71)
> [junit] at 
> org.apache.hadoop.hdfs.server.datanode.FSDataset.shutdown(FSDataset.java:2067)
> [junit] at 
> org.apache.hadoop.hdfs.server.datanode.DataNode.shutdown(DataNode.java:799)
> [junit] at 
> org.apache.hadoop.hdfs.MiniDFSCluster.shutdownDataNodes(MiniDFSCluster.java:566)
> [junit] at 
> org.apache.hadoop.hdfs.MiniDFSCluster.shutdown(MiniDFSCluster.java:550)
> [junit] at 
> org.apache.pig.test.MiniGenericCluster.shutdownMiniDfsClusters(MiniGenericCluster.java:87)
> [junit] at 
> org.apache.pig.test.MiniGenericCluster.shutdownMiniDfsAndMrClusters(MiniGenericCluster.java:77)
> [junit] at 
> org.apache.pig.test.MiniGenericCluster.shutDown(MiniGenericCluster.java:68)
> [junit] at 
> org.apache.cassandra.pig.PigTestBase.oneTimeTearDown(PigTestBase.java:77)
> [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [junit] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit] at java.lang.reflect.Method.invoke(Method.java:606)
> [junit] at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> [junit] at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> [junit] at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> [junit] at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:37)
> [junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> [junit] at 
> junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
> [junit] at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
> [junit] at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
> [junit] at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906)
> [junit] 14/05/29 22:21:53 WARN datanode.FSDatasetAsyncDiskService: 
> AsyncDiskService has already shut down.
> {noformat}



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

[jira] [Resolved] (CASSANDRA-10441) Move stress tool into it's own repository and manage dependency on Cassandra externally

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis resolved CASSANDRA-10441.

Resolution: Won't Fix

I hear you, but since stress's primary purpose is to inform C* development, I 
don't think moving it out of tree makes sense.  Among other reasons, we play 
pretty fast and loose with compatibility and we'd like to keep it that way.

> Move stress tool into it's own repository and manage dependency on Cassandra 
> externally
> ---
>
> Key: CASSANDRA-10441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10441
> Project: Cassandra
>  Issue Type: Wish
>  Components: Tools
>Reporter: Nitsan Wakart
>Priority: Minor
>
> This will:
> 1. Allow distinct release/maintenance/contribution cycles
> 2. Prevent accidental dependencies from Cassandra into the stress tool
> 3. Isolate performance changes in Cassandra from changes to stress tool
>  



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

[jira] [Updated] (CASSANDRA-10249) Make buffered read size configurable

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10249:
--
Fix Version/s: (was: 2.1.x)
   2.1.12

> Make buffered read size configurable
> 
>
> Key: CASSANDRA-10249
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10249
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Albert P Tobey
>Assignee: Albert P Tobey
> Fix For: 2.1.12
>
> Attachments: Screenshot 2015-09-11 09.32.04.png, Screenshot 
> 2015-09-11 09.34.10.png, patched-2.1.9-dstat-lvn10.png, 
> stock-2.1.9-dstat-lvn10.png, yourkit-screenshot.png
>
>
> On read workloads, Cassandra 2.1 reads drastically more data than it emits 
> over the network. This causes problems throughput the system by wasting disk 
> IO and causing unnecessary GC.
> I have reproduce the issue on clusters and locally with a single instance. 
> The only requirement to reproduce the issue is enough data to blow through 
> the page cache. The default schema and data size with cassandra-stress is 
> sufficient for exposing the issue.
> With stock 2.1.9 I regularly observed anywhere from 300:1  to 500 
> disk:network ratio. That is to say, for 1MB/s of network IO, Cassandra was 
> doing 300-500MB/s of disk reads, saturating the drive.
> After applying this patch for standard IO mode 
> https://gist.github.com/tobert/10c307cf3709a585a7cf the ratio fell to around 
> 100:1 on my local test rig. Latency improved considerably and GC became a lot 
> less frequent.
> I tested with 512 byte reads as well, but got the same performance, which 
> makes sense since all HDD and SSD made in the last few years have a 4K block 
> size (many of them lie and say 512).
> I'm re-running the numbers now and will post them tomorrow.



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

[jira] [Updated] (CASSANDRA-9912) SizeEstimatesRecorder has assertions after decommission sometimes

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9912:
-
Fix Version/s: (was: 2.1.x)
   2.1.12

> SizeEstimatesRecorder has assertions after decommission sometimes
> -
>
> Key: CASSANDRA-9912
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9912
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jeremiah Jordan
> Fix For: 2.1.12
>
>
> Doing some testing with 2.1.8 adding and decommissioning nodes.  Sometimes 
> after decommissioning the following starts being thrown by the 
> SizeEstimatesRecorder.
> {noformat}
> java.lang.AssertionError: -9223372036854775808 not found in 
> -9223372036854775798, 10
> at 
> org.apache.cassandra.locator.TokenMetadata.getPredecessor(TokenMetadata.java:683)
>  ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at 
> org.apache.cassandra.locator.TokenMetadata.getPrimaryRangesFor(TokenMetadata.java:627)
>  ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at 
> org.apache.cassandra.db.SizeEstimatesRecorder.run(SizeEstimatesRecorder.java:68)
>  ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_40]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_40]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_40]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_40]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_40]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]
> {noformat}



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

[jira] [Commented] (CASSANDRA-8653) Upgrading to trunk with auth throws exception

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-8653:


b.q This ticket mentions trunk, but any reason to think 3.0 is immune to that?
It's actually the 3.0 that the test upgrades to, or it would be except it's 
currently skipped (waiting on CASSANDRA-9704, so should be re-enabled). When I 
run locally I see no auth problems and the test completes as expected. It fails 
though because of an unexpected ERROR in the log of node1, which is thrown just 
after the last node is upgraded:

{noformat}
RROR [HintsDispatcher:2] 2015-10-23 17:18:53,942 CassandraDaemon.java:195 - 
Exception in thread Thread[HintsDispatcher:2,1,main]
java.lang.RuntimeException: java.nio.file.NoSuchFileException: 
/home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints
at 
org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55) 
~[main/:na]
at org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66) 
~[main/:na]
at 
org.apache.cassandra.hints.ChecksummedDataInput.open(ChecksummedDataInput.java:63)
 ~[main/:na]
at org.apache.cassandra.hints.HintsReader.open(HintsReader.java:77) 
~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatcher.create(HintsDispatcher.java:71) 
~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
 ~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
 ~[main/:na]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
 ~[main/:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
Caused by: java.nio.file.NoSuchFileException: 
/home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) 
~[na:1.8.0_60]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) 
~[na:1.8.0_60]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) 
~[na:1.8.0_60]
at 
sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
 ~[na:1.8.0_60]
at java.nio.channels.FileChannel.open(FileChannel.java:287) ~[na:1.8.0_60]
at java.nio.channels.FileChannel.open(FileChannel.java:335) ~[na:1.8.0_60]
at 
org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:51) 
~[main/:na]
... 12 common frames omitted
{noformat}

> Upgrading to trunk with auth throws exception
> -
>
> Key: CASSANDRA-8653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8653
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.0
>
> Attachments: node1.log, node2.log, node3.log
>
>
> When running Sam's upgrade_internal_auth_dtest, I am seeing the following 
> exception (amongst others) in the log file of the second node to be upgraded 
> to trunk from 2.1:
> {code}
> ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java:170 - 
> Exception in thread Thread[GossipStage:1,5,main]
> java.lang.NoClassDefFoundError: 
> org/apache/cassandra/transport/Event$TopologyChange$Change
> at 
> org.apache.cassandra.transport.Server$EventNotifier.onJoinCluster(Server.java:374)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1668)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1384)
>  ~[main/:na]
> at 
> org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1094) 
> ~[main/:na]
> at 
> org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1076) 
> ~[main/:na]
> at 
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1034) 
> ~[main/:na]
> at 
> org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:58)
>  ~[main/:na]
> 1554 - Node /127.0.0.1 state jump to normal
> ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java
> :170 - Exception in thread Thread[GossipStage:1,5,main]
> java.lang.NoClassDefFoundError: 

[jira] [Updated] (CASSANDRA-8653) Upgrading to trunk with auth throws exception

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-8653:
-
Fix Version/s: (was: 3.x)
   3.0.0

> Upgrading to trunk with auth throws exception
> -
>
> Key: CASSANDRA-8653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8653
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.0
>
> Attachments: node1.log, node2.log, node3.log
>
>
> When running Sam's upgrade_internal_auth_dtest, I am seeing the following 
> exception (amongst others) in the log file of the second node to be upgraded 
> to trunk from 2.1:
> {code}
> ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java:170 - 
> Exception in thread Thread[GossipStage:1,5,main]
> java.lang.NoClassDefFoundError: 
> org/apache/cassandra/transport/Event$TopologyChange$Change
> at 
> org.apache.cassandra.transport.Server$EventNotifier.onJoinCluster(Server.java:374)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1668)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1384)
>  ~[main/:na]
> at 
> org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1094) 
> ~[main/:na]
> at 
> org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1076) 
> ~[main/:na]
> at 
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1034) 
> ~[main/:na]
> at 
> org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:58)
>  ~[main/:na]
> 1554 - Node /127.0.0.1 state jump to normal
> ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java
> :170 - Exception in thread Thread[GossipStage:1,5,main]
> java.lang.NoClassDefFoundError: org/apache/cassandra/transport/Eve
> nt$TopologyChange$Change
> at org.apache.cassandra.transport.Server$EventNotifier.onJ
> oinCluster(Server.java:374) ~[main/:na]
> at org.apache.cassandra.service.StorageService.handleState
> Normal(StorageService.java:1668) ~[main/:na]
> at org.apache.cassandra.service.StorageService.onChange(St
> orageService.java:1384) ~[main/:na]
> at org.apache.cassandra.gms.Gossiper.doOnChangeNotificatio
> ns(Gossiper.java:1094) ~[main/:na]
> at org.apache.cassandra.gms.Gossiper.applyNewStates(Gossip
> er.java:1076) ~[main/:na]
> at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gos
> siper.java:1034) ~[main/:na]
> at org.apache.cassandra.gms.GossipDigestAckVerbHandler.doV
> erb(GossipDigestAckVerbHandler.java:58) ~[main/:na]
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
> ~[main/:na]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_67]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  ~[na:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_67]
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.cassandra.transport.Event$TopologyChange$Change
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366) 
> ~[na:1.7.0_67]
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 
> ~[na:1.7.0_67]
> at java.security.AccessController.doPrivileged(Native Method) 
> ~[na:1.7.0_67]
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 
> ~[na:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 
> ~[na:1.7.0_67]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
> ~[na:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 
> ~[na:1.7.0_67]
> ... 11 common frames omitted
> WARN  [Thread-10] 2015-01-20 13:46:34,500 IncomingTcpConnection.java:91 - 
> UnknownColumnFamilyException reading from socket; closing
> org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find 
> cfId=5f2fbdad-91f1-3946-bd25-d5da3a5c35ec
> at 
> org.apache.cassandra.db.ColumnFamilySerializer.deserializeCfId(ColumnFamilySerializer.java:164)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:97)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.Mutation$MutationSerializer.deserializeOneCf(Mutation.java:322)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:302)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:330)
>  ~[main/:na]
> at 
> 

[jira] [Commented] (CASSANDRA-9813) cqlsh column header can be incorrect when no rows are returned

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-9813:
--

[~aholmber] Could you have a look at this? Thanks.

> cqlsh column header can be incorrect when no rows are returned
> --
>
> Key: CASSANDRA-9813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9813
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>  Labels: cqlsh
> Fix For: 3.x, 2.1.x, 2.2.x
>
> Attachments: Test-for-9813.txt
>
>
> Upon migration, we internally create a pair of surrogate clustering/regular 
> columns for compact static tables. These shouldn't be exposed to the user.
> That is, for the table
> {code}
> CREATE TABLE bar (k int, c int, PRIMARY KEY (k)) WITH COMPACT STORAGE;
> {code}
> {{SELECT * FROM bar}} should not be returning this result set:
> {code}
> cqlsh:test> select * from bar;
>  c | column1 | k | value
> ---+-+---+---
> (0 rows)
> {code}
> Should only contain the defined {{c}} and {{k}} columns.



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

[jira] [Updated] (CASSANDRA-10335) Collect flight recordings of canonical bulk read workload in CI

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-10335:
---
Assignee: Ryan McGuire

> Collect flight recordings of canonical bulk read workload in CI
> ---
>
> Key: CASSANDRA-10335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10335
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ryan McGuire
> Fix For: 3.x
>
>
> Flight recorder to track GC, IO stalls, lock contention, idle threads. Don't 
> need CPU profiling since that will be covered by flame graphs.



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

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

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9748:
-
Issue Type: Improvement  (was: Bug)

> 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] [Updated] (CASSANDRA-10333) Collect SAR metrics from CI jobs running canonical bulk reading workload

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-10333:
---
Assignee: Ryan McGuire

> Collect SAR metrics from CI jobs running canonical bulk reading workload
> 
>
> Key: CASSANDRA-10333
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10333
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ryan McGuire
> Fix For: 3.x
>
>
> sar to track block device metrics, interrupts, context switches etc.



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

[jira] [Updated] (CASSANDRA-10334) Generate flame graphs from canonical bulk reading workload running in CI

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-10334:
---
Assignee: Ryan McGuire

> Generate flame graphs from canonical bulk reading workload running in CI
> 
>
> Key: CASSANDRA-10334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10334
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ryan McGuire
> Fix For: 3.x
>
>
> Flame graphs for CPU utilization. Bonus points if we can get source code 
> annotated with cache misses or at least total counts of cache misses for the 
> entire run.



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

[jira] [Updated] (CASSANDRA-8460) Make it possible to move non-compacting sstables to slow/big storage in DTCS

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-8460:
--
Reviewer: Blake Eggleston  (was: Marcus Eriksson)

reassigning review to [~bdeggleston]

> Make it possible to move non-compacting sstables to slow/big storage in DTCS
> 
>
> Key: CASSANDRA-8460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8460
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Jeff Jirsa
>  Labels: dtcs
> Fix For: 3.x
>
>
> It would be nice if we could configure DTCS to have a set of extra data 
> directories where we move the sstables once they are older than 
> max_sstable_age_days. 
> This would enable users to have a quick, small SSD for hot, new data, and big 
> spinning disks for data that is rarely read and never compacted.



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

[jira] [Updated] (CASSANDRA-10143) Apparent counter overcount during certain network partitions

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10143:
--
Fix Version/s: (was: 3.0.x)
   3.1

> Apparent counter overcount during certain network partitions
> 
>
> Key: CASSANDRA-10143
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10143
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Aleksey Yeschenko
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> This issue is reproducible in this [Jepsen 
> Test|https://github.com/riptano/jepsen/blob/f45f5320db608d48de2c02c871aecc4910f4d963/cassandra/test/cassandra/counter_test.clj#L16].
> The test starts a five-node cluster and issues increments by one against a 
> single counter. It then checks that the counter is in the range [OKed 
> increments, OKed increments + Write Timeouts] at each read. Increments are 
> issued at CL.ONE and reads at CL.ALL.  Throughout the test, network failures 
> are induced that create halved network partitions. A halved network partition 
> splits the cluster into three connected nodes and two connected nodes, 
> randomly.
> This test started failing; bisects showed that it was actually a test change 
> that caused this failure. When the network partitions are induced in a cycle 
> of 15s healthy/45s partitioned or 20s healthy/45s partitioned, the test 
> failes. When network partitions are induced in a cycle of 15s healthy/60s 
> partitioned, 20s healthy/45s partitioned, or 20s healthy/60s partitioned, the 
> test passes.
> There is nothing unusual in the logs of the nodes for the failed tests. The 
> results are very reproducible.
> One noticeable trend is that more reads seem to get serviced during the 
> failed tests.
> Most testing has been done in 2.1.8 - the same issue appears to be present in 
> 2.2/3.0/trunk, but I haven't spent as much time reproducing.
> Ideas?



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

[jira] [Updated] (CASSANDRA-10512) We do not save an upsampled index summaries

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10512:
--
Fix Version/s: (was: 3.0.x)
   (was: 3.x)
   3.1

> We do not save an upsampled index summaries
> ---
>
> Key: CASSANDRA-10512
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10512
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Benedict
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> If we downsample an index summary, we overwrite the existing summary, despite 
> downsampling being inexpensive. However on upsampling (which is expensive) we 
> do not, so that on restart all of our index summaries are the smallest they 
> have ever been adjusted to.



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

[jira] [Updated] (CASSANDRA-9069) debug-cql broken in trunk

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9069:
-
Fix Version/s: (was: 3.x)
   3.1

> debug-cql broken in trunk
> -
>
> Key: CASSANDRA-9069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9069
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Minor
> Fix For: 3.1
>
>
> {{debug-cql}} is broken on trunk.
> At startup it just says:
> {code}
> Error: Exception thrown by the agent : java.lang.NullPointerException
> {code}
> That exception originates from JMX agent (which cannot bind).
> It can be reproduced by starting C* locally and starting {{debug-cql}}.
> Workaround is to comment out sourcing of {{cassandra-env.sh}}.



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

[jira] [Updated] (CASSANDRA-10257) InvertedIndex trigger example has not been updated post 8099

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10257:
--
Reviewer: Aleksey Yeschenko

> InvertedIndex trigger example has not been updated post 8099
> 
>
> Key: CASSANDRA-10257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10257
> Project: Cassandra
>  Issue Type: Bug
>  Components: Examples
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: 10257.txt
>
>
> The {{InvertedIndex}} example is still using pre-8099 code.



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

[jira] [Updated] (CASSANDRA-9510) assassinating an unknown endpoint could npe

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9510:
-
Fix Version/s: (was: 3.x)
   3.1

> assassinating an unknown endpoint could npe
> ---
>
> Key: CASSANDRA-9510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9510
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 3.1
>
> Attachments: assissinate_unknown.txt
>
>
> If the code assissinates an unknown endpoint, it doesn't generate a 'tokens' 
> collection, which then does
> epState.addApplicationState(ApplicationState.STATUS, 
> StorageService.instance.valueFactory.left(tokens, computeExpireTime()));
> and left(null, time); will npe



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

[jira] [Created] (CASSANDRA-10575) Refactor storage protocol to use Netty instead of BIO

[Robert Stupp (JIRA)]

Robert Stupp created CASSANDRA-10575:


 Summary: Refactor storage protocol to use Netty instead of BIO
 Key: CASSANDRA-10575
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10575
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Stupp


Current storage protocol (everything beneath o.a.c.net) currently uses Java 
blocking I/O. I.e. {{InboundTcpConnection}} and {{OutboundTcpConnection}} use a 
dedicated Java thread per connection.

Using NIO would reduce the number of threads as many threads can become a 
problem in bigger clusters.

Migrating the code to Netty seems to be a prerequisite for thread-per-core 
model.

The intention of this ticket is not to change the protocol itself as 
CASSANDRA-8971 would do.



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

[jira] [Updated] (CASSANDRA-6887) LOCAL_ONE read repair only does local repair, in spite of global digest queries

[Aleksey Yeschenko (JIRA)]

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

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

> LOCAL_ONE read repair only does local repair, in spite of global digest 
> queries
> ---
>
> Key: CASSANDRA-6887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6887
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.0.6, x86-64 ubuntu precise
>Reporter: Duncan Sands
> Fix For: 2.1.x
>
> Attachments: 6887-2.0.txt
>
>
> I have a cluster spanning two data centres.  Almost all of the writing (and a 
> lot of reading) is done in DC1.  DC2 is used for running the occasional 
> analytics query.  Reads in both data centres use LOCAL_ONE.  Read repair 
> settings are set to the defaults on all column families.
> I had a long network outage between the data centres; it lasted longer than 
> the hints window, so after it was over DC2 didn't have the latest 
> information.  Even after reading data many many times in DC2, the returned 
> data was still out of date: read repair was not correcting it.
> I then investigated using cqlsh in DC2, with tracing on.
> What I saw was:
>   - with consistency ONE, after about 10 read requests a digest request would 
> be sent to many nodes (spanning both data centres), and the data in DC2 would 
> be repaired.
>  - with consistency LOCAL_ONE, after about 10 read requests a digest request 
> would be sent to many nodes (spanning both data centres), but the data in DC2 
> would not be repaired.  This is in spite of digest requests being sent to 
> DC1, as shown by the tracing.
> So it looks like digest requests are being sent to both data centres, but 
> replies from outside the local data centre are ignored when using LOCAL_ONE.
> The same data is being queried all the time in DC1 with consistency 
> LOCAL_ONE, but this didn't result in the data in DC2 being read repaired 
> either.  This is a slightly different case to what I described above: in that 
> case the local node was out of date and the remote node had the latest data, 
> while here it is the other way round.
> It could be argued that you don't want cross data centre read repair when 
> using LOCAL_ONE.  But then why bother sending cross data centre digest 
> requests?  And if only doing local read repair is how it is supposed to work 
> then it would be good to document this somewhere.



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

[jira] [Updated] (CASSANDRA-8369) Better error handling in CQLSH for invalid password

[Aleksey Yeschenko (JIRA)]

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

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

> Better error handling in CQLSH for invalid password
> ---
>
> Key: CASSANDRA-8369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8369
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Johnny Miller
>Priority: Minor
>
> On C* 2.0.11/Cqlsh 4.1.1 when logging with an invalid password you get back a 
> stacktrace rather than a more user friendly error. It might be better if this 
> was more user friendly.
> For example - this is what you get back now:
> root@cass1:~# cqlsh -u cassandra -p johnny
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh", line 2113, in 
> main(*read_options(sys.argv[1:], os.environ))
>   File "/usr/bin/cqlsh", line 2093, in main
> single_statement=options.execute)
>   File "/usr/bin/cqlsh", line 505, in __init__
> password=password, cql_version=cqlver, transport=transport)
>   File 
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py",
>  line 143, in connect
>   File 
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py",
>  line 59, in __init__
>   File 
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/thrifteries.py",
>  line 157, in establish_connection
>   File 
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py",
>  line 465, in login
>   File 
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py",
>  line 486, in recv_login
> cql.cassandra.ttypes.AuthenticationException: 
> AuthenticationException(why='Username and/or password are incorrect')



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

[jira] [Updated] (CASSANDRA-7715) Add a credentials cache to the PasswordAuthenticator

[Aleksey Yeschenko (JIRA)]

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

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

> Add a credentials cache to the PasswordAuthenticator
> 
>
> Key: CASSANDRA-7715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7715
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Core
>Reporter: Mike Adamson
>Priority: Minor
> Fix For: 3.x
>
>
> If the PasswordAuthenticator cached credentials for a short time it would 
> reduce the overhead of user journeys when they need to do multiple 
> authentications in quick succession.
> This cache should work in the same way as the cache in CassandraAuthorizer in 
> that if it's TTL is set to 0 the cache will be disabled.



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

[jira] [Updated] (CASSANDRA-8655) Exception on upgrade to trunk

[Aleksey Yeschenko (JIRA)]

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

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

> Exception on upgrade to trunk
> -
>
> Key: CASSANDRA-8655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8655
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
> Fix For: 3.x
>
>
> The dtest 
> upgrade_through_versions_test.TestUpgrade_from_cassandra_2_1_latest_tag_to_trunk_HEAD.upgrade_test_mixed
>  is failing with the following exception:
> {code}
> ERROR [Thread-10] 2015-01-20 14:12:44,117 CassandraDaemon.java:170 - 
> Exception in thread Thread[Thread-10,5,main]
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.db.SliceFromReadCommandSerializer.deserialize(SliceFromReadCommand.java:153)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:157)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:131)
>  ~[main/:na]
> at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99) 
> ~[main/:na]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:168)
>  ~[main/:na]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:150)
>  ~[main/:na]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:82)
>  ~[main/:na]
> {code}
> It is trying to execute a simple "SELECT k,v FROM cf WHERE k=X" query on a 
> trunk node after upgrading from 2.1-HEAD.



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

[jira] [Updated] (CASSANDRA-10173) Compaction isn't cleaning out tombstones between hint deliveries

[Aleksey Yeschenko (JIRA)]

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

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

> Compaction isn't cleaning out tombstones between hint deliveries
> 
>
> Key: CASSANDRA-10173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10173
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jonathan Ellis
> Fix For: 2.2.x
>
> Attachments: system (3).log
>
>
> 3 node cluster, 100M writes.  Same scenario as 10172:
> Test Start: 00:00:00
> Node 1 Killed: 00:05:48
> Node 2 Killed: 00:13:33
> Node 1 Started: 00:24:20
> Node 2 Started: 00:32:23
> Test Done: 00:38:33
> Node 1 hints replay finished: 00:56:16
> Node 2 hints replay finished: 01:00:16
> Node 3 hints replay finished: 02:08:00
> Log attached.  Note the tombstone_failure_threshold errors.



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

[jira] [Updated] (CASSANDRA-8916) com.datastax.driver.core.exceptions.AlreadyExistsException: Keyspace already exists

[Aleksey Yeschenko (JIRA)]

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

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

> com.datastax.driver.core.exceptions.AlreadyExistsException: Keyspace 
>  already exists
> ---
>
> Key: CASSANDRA-8916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8916
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Joseph Samuel
> Attachments: client.log, system.log.1.node1a, system.log.1.node1b, 
> system.log.1.node2a, system.log.1.node2b
>
>
> As part of our continuos delivery pipeline, in some environments we drop and 
> recreate our schema on every build.  This occasionally fails with the 
> following error from the client: 
> com.datastax.driver.core.exceptions.AlreadyExistsException: Keyspace 
>  already exists
> When looking into each node individually after this exception, one node still 
> contains the keyspace and all other nodes no longer show it.  After 
> restarting all cassandra nodes, none of them have the keyspace.
> We have attached the logs we get from our client and the nodes.  We have seen 
> this problem with cassandra 2.0.8 and 2.0.12



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

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

[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:
-
Assignee: (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
> 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)

[1/2] cassandra git commit: Support encrypted and plain traffic on the same port

[snazy]

Repository: cassandra
Updated Branches:
  refs/heads/trunk e43fbe0a7 -> 71d9dba06


Support encrypted and plain traffic on the same port

patch by Norman Maurer; reviewed by Robert Stupp for CASSANDRA-10559


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

Branch: refs/heads/trunk
Commit: 535c3ac759ffd24d2324027bce3d0d6228823ba5
Parents: a639808
Author: Norman Maurer 
Authored: Fri Oct 23 14:44:18 2015 +0200
Committer: Robert Stupp 
Committed: Fri Oct 23 14:44:18 2015 +0200

--
 CHANGES.txt |  1 +
 conf/cassandra.yaml |  2 +
 .../cassandra/config/EncryptionOptions.java |  1 +
 .../org/apache/cassandra/transport/Server.java  | 75 ++--
 .../service/NativeTransportServiceTest.java | 18 +
 5 files changed, 90 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0529dd8..67e06ca 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Support encrypted and plain traffic on the same port (CASSANDRA-10559)
  * Fix handling of range tombstones when reading old format sstables 
(CASSANDRA-10360)
  * Aggregate with Initial Condition fails with C* 3.0 (CASSANDRA-10367)
 Merged from 2.2:

http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index bf5149f..fa9ea47 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -884,6 +884,8 @@ server_encryption_options:
 # enable or disable client/server encryption.
 client_encryption_options:
 enabled: false
+# If enabled and optional is set to true encrypted and unencrypted 
connections are handled.
+optional: false
 keystore: conf/.keystore
 keystore_password: cassandra
 # require_client_auth: false

http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/src/java/org/apache/cassandra/config/EncryptionOptions.java
--
diff --git a/src/java/org/apache/cassandra/config/EncryptionOptions.java 
b/src/java/org/apache/cassandra/config/EncryptionOptions.java
index 945a15b..31f8b4a 100644
--- a/src/java/org/apache/cassandra/config/EncryptionOptions.java
+++ b/src/java/org/apache/cassandra/config/EncryptionOptions.java
@@ -36,6 +36,7 @@ public abstract class EncryptionOptions
 public static class ClientEncryptionOptions extends EncryptionOptions
 {
 public boolean enabled = false;
+public boolean optional = false;
 }
 
 public static class ServerEncryptionOptions extends EncryptionOptions

http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/src/java/org/apache/cassandra/transport/Server.java
--
diff --git a/src/java/org/apache/cassandra/transport/Server.java 
b/src/java/org/apache/cassandra/transport/Server.java
index a3cefcd..b786436 100644
--- a/src/java/org/apache/cassandra/transport/Server.java
+++ b/src/java/org/apache/cassandra/transport/Server.java
@@ -33,9 +33,11 @@ import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
 import io.netty.bootstrap.ServerBootstrap;
+import io.netty.buffer.ByteBuf;
 import io.netty.channel.*;
 import io.netty.channel.epoll.EpollEventLoopGroup;
 import io.netty.channel.epoll.EpollServerSocketChannel;
+import io.netty.handler.codec.ByteToMessageDecoder;
 import io.netty.channel.group.ChannelGroup;
 import io.netty.channel.group.DefaultChannelGroup;
 import io.netty.channel.nio.NioEventLoopGroup;
@@ -139,8 +141,16 @@ public class Server implements CassandraDaemon.Server
 final EncryptionOptions.ClientEncryptionOptions clientEnc = 
DatabaseDescriptor.getClientEncryptionOptions();
 if (this.useSSL)
 {
-logger.info("Enabling encrypted CQL connections between client and 
server");
-bootstrap.childHandler(new SecureInitializer(this, clientEnc));
+if (clientEnc.optional)
+{
+logger.info("Enabling optionally encrypted CQL connections 
between client and server");
+bootstrap.childHandler(new OptionalSecureInitializer(this, 
clientEnc));
+}
+else
+{
+logger.info("Enabling encrypted CQL connections between client 
and server");
+bootstrap.childHandler(new 

[jira] [Commented] (CASSANDRA-10544) Make cqlsh tests work when authentication is configured

[Adam Holmberg (JIRA)]

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

Adam Holmberg commented on CASSANDRA-10544:
---

+1 tested with several different usernames, with/without an auth section in the 
config.

> Make cqlsh tests work when authentication is configured
> ---
>
> Key: CASSANDRA-10544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10544
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tests, Tools
>Reporter: Adam Holmberg
>Assignee: Stefania
>Priority: Trivial
>  Labels: cqlsh, test
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> cqlsh tests break if the runner has an authentication section in their 
> ~/.cassandra/cqlshrc, because cqlsh changes the prompt and the tests scan 
> output for a prompt. It manifests as read timeouts while waiting for a prompt 
> in test/run_cqlsh.py.
> [This 
> pattern|https://github.com/mambocab/cassandra/blob/1c27f9be1ba8ea10dbe843d513e23de6238dede8/pylib/cqlshlib/test/run_cqlsh.py#L30]
>  could be generalized to match the "@cqlsh..." prompt that arises 
> with this config.



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

[jira] [Updated] (CASSANDRA-8779) Add type code to binary query parameters in QUERY messages

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-8779:

Issue Type: Sub-task  (was: Improvement)
Parent: CASSANDRA-9362

> Add type code to binary query parameters in QUERY messages
> --
>
> Key: CASSANDRA-8779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8779
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: API
> Environment: Linux Mint 64-bit | ruby-driver 2.1 | java-driver 2.1 | 
> C* 2.1.2
>Reporter: Kishan Karunaratne
>Assignee: Tyler Hobbs
>  Labels: client-impacting, protocolv5
> Fix For: 3.x
>
>
> If I insert a tuple using an extra pair of ()'s, C* will let me do the 
> insert, but (incorrectly) creates a nested tuple as the first tuple value. 
> Upon doing a select statement, the result is jumbled and has weird binary in 
> it (which I wasn't able to copy into here).
> Example using ruby-driver:
> {noformat}
> session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b 
> frozen>)")
> complete = Cassandra::Tuple.new('foo', 123, true)
> session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", arguments: 
> [complete])# extra ()'s here
> result = session.execute("SELECT b FROM mytable WHERE a=0").first
> p result['b']
> {noformat}
> Output:
> {noformat}
> #
> {noformat}
> Bug also confirmed using java-driver. 
> Example using java-driver:
> {noformat}
> session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b 
> frozen>)");
> TupleType t = TupleType.of(DataType.ascii(), DataType.cint(), 
> DataType.cboolean());
> TupleValue complete = t.newValue("foo", 123, true);
> session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", complete); // 
> extra ()'s here
> TupleValue r = session.execute("SELECT b FROM mytable WHERE 
> a=0").one().getTupleValue("b");
> System.out.println(r);
> {noformat}
> Output:
> {noformat}
> ('foo{

', null, null)
> {noformat}



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

[jira] [Commented] (CASSANDRA-8655) Exception on upgrade to trunk

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-8655:
-

[~philipthompson] Does that affect 3.0 or just trunk? Is this still a thing?

> Exception on upgrade to trunk
> -
>
> Key: CASSANDRA-8655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8655
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
> Fix For: 3.x
>
>
> The dtest 
> upgrade_through_versions_test.TestUpgrade_from_cassandra_2_1_latest_tag_to_trunk_HEAD.upgrade_test_mixed
>  is failing with the following exception:
> {code}
> ERROR [Thread-10] 2015-01-20 14:12:44,117 CassandraDaemon.java:170 - 
> Exception in thread Thread[Thread-10,5,main]
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.db.SliceFromReadCommandSerializer.deserialize(SliceFromReadCommand.java:153)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:157)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:131)
>  ~[main/:na]
> at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99) 
> ~[main/:na]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:168)
>  ~[main/:na]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:150)
>  ~[main/:na]
> at 
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:82)
>  ~[main/:na]
> {code}
> It is trying to execute a simple "SELECT k,v FROM cf WHERE k=X" query on a 
> trunk node after upgrading from 2.1-HEAD.



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

[jira] [Resolved] (CASSANDRA-8394) Cassandra 3.0 Auth changes

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe resolved CASSANDRA-8394.

Resolution: Fixed

> Cassandra 3.0 Auth changes
> --
>
> Key: CASSANDRA-8394
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8394
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>  Labels: docs-impacting
> Fix For: 3.x
>
>
> This will be the task that will group all the 3.0 Auth changes, of which we 
> need quite some:
> 1. Implement Roles (CASSANDRA-7653)
> 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator 
> SASL-only, and support full SASL capabilities (incl. proxy authentication - 
> see CASSANDRA-7686, CASSANDRA-8068)
> 3. Remove the current simplistic permissions cache with 
> implementation-specific user/credentials/permissions caches, at least in the 
> implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194)
> 4. Consider adding a way to split superuser-ness and the rights to manage 
> users (CASSANDRA-7216, CASSANDRA-8650)
> 5. Add permissions for types and functions (CASSANDRA-7557)
> 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082)
> 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163)



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

[jira] [Updated] (CASSANDRA-8779) Add type code to binary query parameters in QUERY messages

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-8779:

Labels: client-impacting protocolv5  (was: client-impacting protocolv4)

> Add type code to binary query parameters in QUERY messages
> --
>
> Key: CASSANDRA-8779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8779
> Project: Cassandra
>  Issue Type: Improvement
>  Components: API
> Environment: Linux Mint 64-bit | ruby-driver 2.1 | java-driver 2.1 | 
> C* 2.1.2
>Reporter: Kishan Karunaratne
>Assignee: Tyler Hobbs
>  Labels: client-impacting, protocolv5
> Fix For: 3.x
>
>
> If I insert a tuple using an extra pair of ()'s, C* will let me do the 
> insert, but (incorrectly) creates a nested tuple as the first tuple value. 
> Upon doing a select statement, the result is jumbled and has weird binary in 
> it (which I wasn't able to copy into here).
> Example using ruby-driver:
> {noformat}
> session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b 
> frozen>)")
> complete = Cassandra::Tuple.new('foo', 123, true)
> session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", arguments: 
> [complete])# extra ()'s here
> result = session.execute("SELECT b FROM mytable WHERE a=0").first
> p result['b']
> {noformat}
> Output:
> {noformat}
> #
> {noformat}
> Bug also confirmed using java-driver. 
> Example using java-driver:
> {noformat}
> session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b 
> frozen>)");
> TupleType t = TupleType.of(DataType.ascii(), DataType.cint(), 
> DataType.cboolean());
> TupleValue complete = t.newValue("foo", 123, true);
> session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", complete); // 
> extra ()'s here
> TupleValue r = session.execute("SELECT b FROM mytable WHERE 
> a=0").one().getTupleValue("b");
> System.out.println(r);
> {noformat}
> Output:
> {noformat}
> ('foo{

', null, null)
> {noformat}



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

cassandra git commit: Support encrypted and plain traffic on the same port

[snazy]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 a63980868 -> 535c3ac75


Support encrypted and plain traffic on the same port

patch by Norman Maurer; reviewed by Robert Stupp for CASSANDRA-10559


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

Branch: refs/heads/cassandra-3.0
Commit: 535c3ac759ffd24d2324027bce3d0d6228823ba5
Parents: a639808
Author: Norman Maurer 
Authored: Fri Oct 23 14:44:18 2015 +0200
Committer: Robert Stupp 
Committed: Fri Oct 23 14:44:18 2015 +0200

--
 CHANGES.txt |  1 +
 conf/cassandra.yaml |  2 +
 .../cassandra/config/EncryptionOptions.java |  1 +
 .../org/apache/cassandra/transport/Server.java  | 75 ++--
 .../service/NativeTransportServiceTest.java | 18 +
 5 files changed, 90 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0529dd8..67e06ca 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Support encrypted and plain traffic on the same port (CASSANDRA-10559)
  * Fix handling of range tombstones when reading old format sstables 
(CASSANDRA-10360)
  * Aggregate with Initial Condition fails with C* 3.0 (CASSANDRA-10367)
 Merged from 2.2:

http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index bf5149f..fa9ea47 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -884,6 +884,8 @@ server_encryption_options:
 # enable or disable client/server encryption.
 client_encryption_options:
 enabled: false
+# If enabled and optional is set to true encrypted and unencrypted 
connections are handled.
+optional: false
 keystore: conf/.keystore
 keystore_password: cassandra
 # require_client_auth: false

http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/src/java/org/apache/cassandra/config/EncryptionOptions.java
--
diff --git a/src/java/org/apache/cassandra/config/EncryptionOptions.java 
b/src/java/org/apache/cassandra/config/EncryptionOptions.java
index 945a15b..31f8b4a 100644
--- a/src/java/org/apache/cassandra/config/EncryptionOptions.java
+++ b/src/java/org/apache/cassandra/config/EncryptionOptions.java
@@ -36,6 +36,7 @@ public abstract class EncryptionOptions
 public static class ClientEncryptionOptions extends EncryptionOptions
 {
 public boolean enabled = false;
+public boolean optional = false;
 }
 
 public static class ServerEncryptionOptions extends EncryptionOptions

http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/src/java/org/apache/cassandra/transport/Server.java
--
diff --git a/src/java/org/apache/cassandra/transport/Server.java 
b/src/java/org/apache/cassandra/transport/Server.java
index a3cefcd..b786436 100644
--- a/src/java/org/apache/cassandra/transport/Server.java
+++ b/src/java/org/apache/cassandra/transport/Server.java
@@ -33,9 +33,11 @@ import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
 import io.netty.bootstrap.ServerBootstrap;
+import io.netty.buffer.ByteBuf;
 import io.netty.channel.*;
 import io.netty.channel.epoll.EpollEventLoopGroup;
 import io.netty.channel.epoll.EpollServerSocketChannel;
+import io.netty.handler.codec.ByteToMessageDecoder;
 import io.netty.channel.group.ChannelGroup;
 import io.netty.channel.group.DefaultChannelGroup;
 import io.netty.channel.nio.NioEventLoopGroup;
@@ -139,8 +141,16 @@ public class Server implements CassandraDaemon.Server
 final EncryptionOptions.ClientEncryptionOptions clientEnc = 
DatabaseDescriptor.getClientEncryptionOptions();
 if (this.useSSL)
 {
-logger.info("Enabling encrypted CQL connections between client and 
server");
-bootstrap.childHandler(new SecureInitializer(this, clientEnc));
+if (clientEnc.optional)
+{
+logger.info("Enabling optionally encrypted CQL connections 
between client and server");
+bootstrap.childHandler(new OptionalSecureInitializer(this, 
clientEnc));
+}
+else
+{
+logger.info("Enabling encrypted CQL connections between client 
and server");
+

[jira] [Resolved] (CASSANDRA-7791) Consider re-allowing to refer to UDT outside of their keyspace

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne resolved CASSANDRA-7791.
-
Resolution: Not A Problem

We went with making functions keyspace-scoped in the end, so this is kind of 
moot.

> Consider re-allowing to refer to UDT outside of their keyspace
> --
>
> Key: CASSANDRA-7791
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7791
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>  Labels: cql
> Fix For: 3.x
>
>
> In CASSANDRA-6643 we decided to make UDT inaccessible outside of their 
> keyspace of definition. Doing so mainly has the advantage that when we drop a 
> keyspace, we don't have to worry its UDT being used in another keyspace. 
> However, this directly conflict with functions (UDF) being global: we can't 
> have functions working on UDT if functions are global and we don't allow UDT 
> access outside their keyspace. Which, I believe, leave us with the following 
> possible options:
> # we make UDT accessible anywhere (though their fully qualified name).
> # we don't support functions on UDT at all.
> # we make functions keyspace-scoped, either always, or only if they apply to 
> UDT.
> # we revert CASSANDRA-6438 and make UDT global.
> In a perfect world I would lean towards 4: the arguments to make UDT 
> keyspace-scoped where not wrong per-se but weak in hindsight given the other 
> options here. It is however basically too late: changing it would be a 
> breaking change so we can't reasonably change this post-2.1.0, and while it's 
> not released yet, it's not a change we can make without substantially 
> delaying the final.
> Option 2 feels rather lame in my book.
> Option 3 feels pretty messy. Having 2 types of UDF, some keyspace-scoped and 
> some that are not would be super confusing. Saying that ll UDF are 
> keyspace-scoped feels limiting, and we would still be somewhat inconsistent 
> with our existing hard-coded functions that are global.
> Which leaves option 1 which might be the most pragmatic. Having to check that 
> UDTs are not used before allowing keyspace drop don't sound like a huge deal 
> to me.



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

[jira] [Commented] (CASSANDRA-9304) COPY TO improvements

[Brian Hess (JIRA)]

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

 Brian Hess commented on CASSANDRA-9304:


[~Stefania] have you re-run the benchmark that [~dkua] performed above (or 
something similar) - specifically, comparing the "old version" to this new 
version (and to the cassandra-unloader 
(https://github.com/brianmhess/cassandra-loader))?  What performance 
improvement do we see?

> COPY TO improvements
> 
>
> Key: CASSANDRA-9304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9304
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jonathan Ellis
>Assignee: Stefania
>Priority: Minor
>  Labels: cqlsh
> Fix For: 3.x, 2.1.x, 2.2.x
>
>
> COPY FROM has gotten a lot of love.  COPY TO not so much.  One obvious 
> improvement could be to parallelize reading and writing (write one page of 
> data while fetching the next).



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

[jira] [Commented] (CASSANDRA-8394) Cassandra 3.0 Auth changes

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-8394:


sounds reasonable to me

> Cassandra 3.0 Auth changes
> --
>
> Key: CASSANDRA-8394
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8394
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>  Labels: docs-impacting
> Fix For: 3.x
>
>
> This will be the task that will group all the 3.0 Auth changes, of which we 
> need quite some:
> 1. Implement Roles (CASSANDRA-7653)
> 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator 
> SASL-only, and support full SASL capabilities (incl. proxy authentication - 
> see CASSANDRA-7686, CASSANDRA-8068)
> 3. Remove the current simplistic permissions cache with 
> implementation-specific user/credentials/permissions caches, at least in the 
> implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194)
> 4. Consider adding a way to split superuser-ness and the rights to manage 
> users (CASSANDRA-7216, CASSANDRA-8650)
> 5. Add permissions for types and functions (CASSANDRA-7557)
> 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082)
> 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163)



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

[jira] [Created] (CASSANDRA-10576) Thrift CAS on static columns doesn't work as expected

[Sam Tunnicliffe (JIRA)]

Sam Tunnicliffe created CASSANDRA-10576:
---

 Summary: Thrift CAS on static columns doesn't work as expected
 Key: CASSANDRA-10576
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10576
 Project: Cassandra
  Issue Type: Bug
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
 Fix For: 3.0.0


Although the thrift cas call works as expected for dynamic column families, 
using it on tables with statically defined columns produces unexpected results. 
The problem, in {{ThriftCASRequest}}, is that while the {{expected}} partition 
contains a static row, the {{current}} partition has been processed by 
{{ThriftResultsMerger}} during the read, converting the static columns to 
clusterings. If {{expected}} contains only a static row, no further checking is 
carried out, {{appliesTo}} erroneously returns true and the conditional update 
is performed regardless of the current state of the partition.




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

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

[snazy]

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/71d9dba0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71d9dba0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71d9dba0

Branch: refs/heads/trunk
Commit: 71d9dba063b0e669f12afef9fbb3efcb9cfacdd3
Parents: e43fbe0 535c3ac
Author: Robert Stupp 
Authored: Fri Oct 23 14:44:32 2015 +0200
Committer: Robert Stupp 
Committed: Fri Oct 23 14:44:32 2015 +0200

--
 CHANGES.txt |  1 +
 conf/cassandra.yaml |  2 +
 .../cassandra/config/EncryptionOptions.java |  1 +
 .../org/apache/cassandra/transport/Server.java  | 75 ++--
 .../service/NativeTransportServiceTest.java | 18 +
 5 files changed, 90 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/71d9dba0/CHANGES.txt
--
diff --cc CHANGES.txt
index 789a9d7,67e06ca..2ecad90
--- 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
+  * Support encrypted and plain traffic on the same port (CASSANDRA-10559)
   * Fix handling of range tombstones when reading old format sstables 
(CASSANDRA-10360)
   * Aggregate with Initial Condition fails with C* 3.0 (CASSANDRA-10367)
  Merged from 2.2:

[jira] [Commented] (CASSANDRA-8653) Upgrading to trunk with auth throws exception

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-8653:
-

This ticket mentions trunk, but any reason to think 3.0 is immune to that? If 
not, we should mark that for 3.0.0 (and figure out if there is a real problem 
or not).

> Upgrading to trunk with auth throws exception
> -
>
> Key: CASSANDRA-8653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8653
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
> Attachments: node1.log, node2.log, node3.log
>
>
> When running Sam's upgrade_internal_auth_dtest, I am seeing the following 
> exception (amongst others) in the log file of the second node to be upgraded 
> to trunk from 2.1:
> {code}
> ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java:170 - 
> Exception in thread Thread[GossipStage:1,5,main]
> java.lang.NoClassDefFoundError: 
> org/apache/cassandra/transport/Event$TopologyChange$Change
> at 
> org.apache.cassandra.transport.Server$EventNotifier.onJoinCluster(Server.java:374)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1668)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1384)
>  ~[main/:na]
> at 
> org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1094) 
> ~[main/:na]
> at 
> org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1076) 
> ~[main/:na]
> at 
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1034) 
> ~[main/:na]
> at 
> org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:58)
>  ~[main/:na]
> 1554 - Node /127.0.0.1 state jump to normal
> ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java
> :170 - Exception in thread Thread[GossipStage:1,5,main]
> java.lang.NoClassDefFoundError: org/apache/cassandra/transport/Eve
> nt$TopologyChange$Change
> at org.apache.cassandra.transport.Server$EventNotifier.onJ
> oinCluster(Server.java:374) ~[main/:na]
> at org.apache.cassandra.service.StorageService.handleState
> Normal(StorageService.java:1668) ~[main/:na]
> at org.apache.cassandra.service.StorageService.onChange(St
> orageService.java:1384) ~[main/:na]
> at org.apache.cassandra.gms.Gossiper.doOnChangeNotificatio
> ns(Gossiper.java:1094) ~[main/:na]
> at org.apache.cassandra.gms.Gossiper.applyNewStates(Gossip
> er.java:1076) ~[main/:na]
> at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gos
> siper.java:1034) ~[main/:na]
> at org.apache.cassandra.gms.GossipDigestAckVerbHandler.doV
> erb(GossipDigestAckVerbHandler.java:58) ~[main/:na]
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
> ~[main/:na]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_67]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  ~[na:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_67]
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.cassandra.transport.Event$TopologyChange$Change
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366) 
> ~[na:1.7.0_67]
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 
> ~[na:1.7.0_67]
> at java.security.AccessController.doPrivileged(Native Method) 
> ~[na:1.7.0_67]
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 
> ~[na:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 
> ~[na:1.7.0_67]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
> ~[na:1.7.0_67]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 
> ~[na:1.7.0_67]
> ... 11 common frames omitted
> WARN  [Thread-10] 2015-01-20 13:46:34,500 IncomingTcpConnection.java:91 - 
> UnknownColumnFamilyException reading from socket; closing
> org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find 
> cfId=5f2fbdad-91f1-3946-bd25-d5da3a5c35ec
> at 
> org.apache.cassandra.db.ColumnFamilySerializer.deserializeCfId(ColumnFamilySerializer.java:164)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:97)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.Mutation$MutationSerializer.deserializeOneCf(Mutation.java:322)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:302)
>  ~[main/:na]
> at 
> 

[jira] [Created] (CASSANDRA-10577) Fix cqlsh COPY commands that use NULL

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10577:


 Summary: Fix cqlsh COPY commands that use NULL
 Key: CASSANDRA-10577
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10577
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey
Assignee: Stefania
 Fix For: 3.0.0


Looks like this commit:

https://github.com/apache/cassandra/commit/806378c8c295fb062f94eb8bf0f719b398d27745

broke some of the behavior of cqlsh COPY:

http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/280/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_null_as_null_indicator/history/
http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/280/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_undefined_as_null_indicator/history/

The NULL tests are the only ones that fail, so it doesn't look like any other 
parts of it are broken:

http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/280/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/



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

[jira] [Commented] (CASSANDRA-8394) Cassandra 3.0 Auth changes

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-8394:
-

All the subtasks for this are closed and the remaining ones from the 
description are not gonna make 3.0 at this point. Should we just close this 
(and deal with CASSANDRA-8163 and CASSANDRA-7715 on their own).

> Cassandra 3.0 Auth changes
> --
>
> Key: CASSANDRA-8394
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8394
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>  Labels: docs-impacting
> Fix For: 3.x
>
>
> This will be the task that will group all the 3.0 Auth changes, of which we 
> need quite some:
> 1. Implement Roles (CASSANDRA-7653)
> 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator 
> SASL-only, and support full SASL capabilities (incl. proxy authentication - 
> see CASSANDRA-7686, CASSANDRA-8068)
> 3. Remove the current simplistic permissions cache with 
> implementation-specific user/credentials/permissions caches, at least in the 
> implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194)
> 4. Consider adding a way to split superuser-ness and the rights to manage 
> users (CASSANDRA-7216, CASSANDRA-8650)
> 5. Add permissions for types and functions (CASSANDRA-7557)
> 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082)
> 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163)



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

[jira] [Updated] (CASSANDRA-8959) More efficient frozen UDT, tuple and collection serialization format

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-8959:

Summary: More efficient frozen UDT, tuple and collection serialization 
format  (was: More efficient frozen UDT and tuple serialization format)

> More efficient frozen UDT, tuple and collection serialization format
> 
>
> Key: CASSANDRA-8959
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8959
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>  Labels: performance
> Fix For: 3.x
>
>
> The current serialization format for UDTs has a fixed overhead of 4 bytes per 
> defined field (encoding the size of the field).
> It is inefficient for sparse UDTs - ones with many defined fields, but few of 
> them present. We could keep a bitset to indicate the missing fields, if any.
> It's sub-optimal for encoding UDTs with all the values present as well. We 
> could use varint encoding for the field sizes of blob/text fields and encode 
> 'fixed' sized types directly, without the 4-bytes size prologue.
> That or something more brilliant. Any improvement right now is lhf.



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

[jira] [Resolved] (CASSANDRA-10344) Optimize ReadResponse

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne resolved CASSANDRA-10344.
--
Resolution: Later

While we'll want to continue looking at optimizing ReadResponse, the method 
proposed by this ticket/patch doesn't clearly show a benefit (at least not on 
some basic workload) and it implies changes to inter-node serialization format, 
which makes it harder to do in some minor release. So for now, closing as 
"later".

> Optimize ReadResponse
> -
>
> Key: CASSANDRA-10344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10344
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
>
> The handling of {{ReadResponse}} has quite a bit of inefficiencies. The way 
> it works is based on constraints from early version of CASSANDRA-8099, but 
> this doesn't make sense anymore. This is particularly true for local response 
> where we fully serialize the response in memory to deserialize it a short 
> time later.  But
> # serialization/deserialization takes times, more than necessary in that case
> # we serialize in a {{DataInputBuffer}} with a default initial size, which 
> for largish response might require a few somewhat costly resizing.
> So, since we're materializing the full result in memory anyway, it should 
> quite a lot more efficient to materialize it in a simple list of 
> {{ImmutableBTreePartition}} in that case.
> To a lesser extend, the serialization of {{ReadResponse}} that go over the 
> wire is probably not ideal either. Due to current assumptions of 
> {{MessagingService}}, we need to know the full serialized size of every 
> response upfront, which means we do have to materialize results in memory in 
> this case too. Currently, we do so by serialializing the full response in 
> memory first, and then writing that result. Here again, the serialization in 
> memory might require some resizing/copying, and we're fundamentally copying 
> things twice (this could be especially costly with largish user values).  So 
> here too I suggest to materialize the result in a list of 
> {{ImmutableBTreePartition}}, compute the serialized size from it and then 
> serialize it. This also allow to do better sizing of our data structures on 
> the receiving side.



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