[jira] [Commented] (CASSANDRA-10513) Update cqlsh for new driver execution API

[Adam Holmberg (JIRA)]

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

Adam Holmberg commented on CASSANDRA-10513:
---

In addition to the issues Sam mentioned, there are the linked issues 
CASSANDRA-7645 (which this resolves), and CASSANDRA-9813 (which depends on 
these changes). The urgency of the 2.2 patch here would be the same as the 
dependent tickets mentioned here and above. I don't see any issue waiting for 
the driver release to integrate for Cassandra 2.2. We will need to patch 3.0 
sooner in support of CASSANDRA-10365 (this may be applied at the same time as 
the driver is updated for that ticket).

> Update cqlsh for new driver execution API
> -
>
> Key: CASSANDRA-10513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10513
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Adam Holmberg
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: cqlsh
> Fix For: 2.2.x, 3.0.x
>
> Attachments: 10513-2.1.txt, 10513-2.2.txt, 10513.txt
>
>
> The 3.0 Python driver will have a few tweaks to the execution API. We'll need 
> to update cqlsh in a couple of minor ways.
> [Results are always returned as an iterable 
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-368]
> [Trace data is always attached to the 
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-318] (instead of 
> being attached to a statement)



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

[jira] [Comment Edited] (CASSANDRA-10515) Commit logs back up with move to 2.1.10

[Jeff Griffith (JIRA)]

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

Jeff Griffith edited comment on CASSANDRA-10515 at 10/29/15 12:58 PM:
--

[~blambov] [~benedict]

See image: Killed two birds with one stone here it seems. Looking at he logs 
before the commit log growth, it looks like the IndexOutOfBounds exceptions 
affected all nodes in this small cluster of 3 at the same time, with with RF=3 
that probably makes sense, doesn't it?

https://issues.apache.org/jira/secure/attachment/12769525/CASSANDRA-19579.jpg


was (Author: jeffery.griffith):
[~blambov] [~benedict]

Killed two birds with one stone here it seems. Looking at he logs before the 
commit log growth, it looks like the IndexOutOfBounds exceptions affected all 
nodes in this small cluster of 3 at the same time, with with RF=3 that probably 
makes sense, doesn't it?


> Commit logs back up with move to 2.1.10
> ---
>
> Key: CASSANDRA-10515
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10515
> Project: Cassandra
>  Issue Type: Bug
> Environment: redhat 6.5, cassandra 2.1.10
>Reporter: Jeff Griffith
>Assignee: Branimir Lambov
>Priority: Critical
>  Labels: commitlog, triage
> Attachments: C5commitLogIncrease.jpg, CASSANDRA-19579.jpg, 
> CommitLogProblem.jpg, CommitLogSize.jpg, 
> MultinodeCommitLogGrowth-node1.tar.gz, RUN3tpstats.jpg, cassandra.yaml, 
> cfstats-clean.txt, stacktrace.txt, system.log.clean
>
>
> After upgrading from cassandra 2.0.x to 2.1.10, we began seeing problems 
> where some nodes break the 12G commit log max we configured and go as high as 
> 65G or more before it restarts. Once it reaches the state of more than 12G 
> commit log files, "nodetool compactionstats" hangs. Eventually C* restarts 
> without errors (not sure yet whether it is crashing but I'm checking into it) 
> and the cleanup occurs and the commit logs shrink back down again. Here is 
> the nodetool compactionstats immediately after restart.
> {code}
> jgriffith@prod1xc1.c2.bf1:~$ ndc
> pending tasks: 2185
>compaction type   keyspace  table completed
>   totalunit   progress
> Compaction   SyncCore  *cf1*   61251208033   
> 170643574558   bytes 35.89%
> Compaction   SyncCore  *cf2*   19262483904
> 19266079916   bytes 99.98%
> Compaction   SyncCore  *cf3*6592197093
>  6592316682   bytes100.00%
> Compaction   SyncCore  *cf4*3411039555
>  3411039557   bytes100.00%
> Compaction   SyncCore  *cf5*2879241009
>  2879487621   bytes 99.99%
> Compaction   SyncCore  *cf6*   21252493623
> 21252635196   bytes100.00%
> Compaction   SyncCore  *cf7*   81009853587
> 81009854438   bytes100.00%
> Compaction   SyncCore  *cf8*3005734580
>  3005768582   bytes100.00%
> Active compaction remaining time :n/a
> {code}
> I was also doing periodic "nodetool tpstats" which were working but not being 
> logged in system.log on the StatusLogger thread until after the compaction 
> started working again.



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

[jira] [Created] (CASSANDRA-10619) disallow streaming operations while upgrading

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-10619:
--

 Summary: disallow streaming operations while upgrading
 Key: CASSANDRA-10619
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10619
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jon Haddad


Cassandra should prevent users from doing streaming operations in the middle of 
a cluster upgrade.  



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

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

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-10365:
--

[~adutra] yes, that's a know issue in Aleksey's branch AFAIK.

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



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

[jira] [Updated] (CASSANDRA-10515) Commit logs back up with move to 2.1.10

[Jeff Griffith (JIRA)]

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

Jeff Griffith updated CASSANDRA-10515:
--
Attachment: CASSANDRA-19579.jpg

[~blambov] [~benedict]

Killed two birds with one stone here it seems. Looking at he logs before the 
commit log growth, it looks like the IndexOutOfBounds exceptions affected all 
nodes in this small cluster of 3 at the same time, with with RF=3 that probably 
makes sense, doesn't it?


> Commit logs back up with move to 2.1.10
> ---
>
> Key: CASSANDRA-10515
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10515
> Project: Cassandra
>  Issue Type: Bug
> Environment: redhat 6.5, cassandra 2.1.10
>Reporter: Jeff Griffith
>Assignee: Branimir Lambov
>Priority: Critical
>  Labels: commitlog, triage
> Attachments: C5commitLogIncrease.jpg, CASSANDRA-19579.jpg, 
> CommitLogProblem.jpg, CommitLogSize.jpg, 
> MultinodeCommitLogGrowth-node1.tar.gz, RUN3tpstats.jpg, cassandra.yaml, 
> cfstats-clean.txt, stacktrace.txt, system.log.clean
>
>
> After upgrading from cassandra 2.0.x to 2.1.10, we began seeing problems 
> where some nodes break the 12G commit log max we configured and go as high as 
> 65G or more before it restarts. Once it reaches the state of more than 12G 
> commit log files, "nodetool compactionstats" hangs. Eventually C* restarts 
> without errors (not sure yet whether it is crashing but I'm checking into it) 
> and the cleanup occurs and the commit logs shrink back down again. Here is 
> the nodetool compactionstats immediately after restart.
> {code}
> jgriffith@prod1xc1.c2.bf1:~$ ndc
> pending tasks: 2185
>compaction type   keyspace  table completed
>   totalunit   progress
> Compaction   SyncCore  *cf1*   61251208033   
> 170643574558   bytes 35.89%
> Compaction   SyncCore  *cf2*   19262483904
> 19266079916   bytes 99.98%
> Compaction   SyncCore  *cf3*6592197093
>  6592316682   bytes100.00%
> Compaction   SyncCore  *cf4*3411039555
>  3411039557   bytes100.00%
> Compaction   SyncCore  *cf5*2879241009
>  2879487621   bytes 99.99%
> Compaction   SyncCore  *cf6*   21252493623
> 21252635196   bytes100.00%
> Compaction   SyncCore  *cf7*   81009853587
> 81009854438   bytes100.00%
> Compaction   SyncCore  *cf8*3005734580
>  3005768582   bytes100.00%
> Active compaction remaining time :n/a
> {code}
> I was also doing periodic "nodetool tpstats" which were working but not being 
> logged in system.log on the StatusLogger thread until after the compaction 
> started working again.



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

[jira] [Comment Edited] (CASSANDRA-10515) Commit logs back up with move to 2.1.10

[Jeff Griffith (JIRA)]

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

Jeff Griffith edited comment on CASSANDRA-10515 at 10/29/15 12:59 PM:
--

[~blambov] [~benedict]

See image: Killed two birds with one stone here it seems. Looking at the logs 
before the commit log growth, it looks like the IndexOutOfBounds exceptions 
affected all nodes in this small cluster of 3 at the same time, with with RF=3 
that probably makes sense, doesn't it?

https://issues.apache.org/jira/secure/attachment/12769525/CASSANDRA-19579.jpg


was (Author: jeffery.griffith):
[~blambov] [~benedict]

See image: Killed two birds with one stone here it seems. Looking at he logs 
before the commit log growth, it looks like the IndexOutOfBounds exceptions 
affected all nodes in this small cluster of 3 at the same time, with with RF=3 
that probably makes sense, doesn't it?

https://issues.apache.org/jira/secure/attachment/12769525/CASSANDRA-19579.jpg

> Commit logs back up with move to 2.1.10
> ---
>
> Key: CASSANDRA-10515
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10515
> Project: Cassandra
>  Issue Type: Bug
> Environment: redhat 6.5, cassandra 2.1.10
>Reporter: Jeff Griffith
>Assignee: Branimir Lambov
>Priority: Critical
>  Labels: commitlog, triage
> Attachments: C5commitLogIncrease.jpg, CASSANDRA-19579.jpg, 
> CommitLogProblem.jpg, CommitLogSize.jpg, 
> MultinodeCommitLogGrowth-node1.tar.gz, RUN3tpstats.jpg, cassandra.yaml, 
> cfstats-clean.txt, stacktrace.txt, system.log.clean
>
>
> After upgrading from cassandra 2.0.x to 2.1.10, we began seeing problems 
> where some nodes break the 12G commit log max we configured and go as high as 
> 65G or more before it restarts. Once it reaches the state of more than 12G 
> commit log files, "nodetool compactionstats" hangs. Eventually C* restarts 
> without errors (not sure yet whether it is crashing but I'm checking into it) 
> and the cleanup occurs and the commit logs shrink back down again. Here is 
> the nodetool compactionstats immediately after restart.
> {code}
> jgriffith@prod1xc1.c2.bf1:~$ ndc
> pending tasks: 2185
>compaction type   keyspace  table completed
>   totalunit   progress
> Compaction   SyncCore  *cf1*   61251208033   
> 170643574558   bytes 35.89%
> Compaction   SyncCore  *cf2*   19262483904
> 19266079916   bytes 99.98%
> Compaction   SyncCore  *cf3*6592197093
>  6592316682   bytes100.00%
> Compaction   SyncCore  *cf4*3411039555
>  3411039557   bytes100.00%
> Compaction   SyncCore  *cf5*2879241009
>  2879487621   bytes 99.99%
> Compaction   SyncCore  *cf6*   21252493623
> 21252635196   bytes100.00%
> Compaction   SyncCore  *cf7*   81009853587
> 81009854438   bytes100.00%
> Compaction   SyncCore  *cf8*3005734580
>  3005768582   bytes100.00%
> Active compaction remaining time :n/a
> {code}
> I was also doing periodic "nodetool tpstats" which were working but not being 
> logged in system.log on the StatusLogger thread until after the compaction 
> started working again.



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

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

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10365:
---

bq. In SchemaKeyspace.fetchKeyspacesOnly, the initial query looks unecessary. 
If it's there as a way to exclude any unexisting keyspace, a comment explaining 
so would be welcome. But it's only used after having applied mutation that we 
knew applied to the keyspace passed to this method, so really, I'm not 
convinced it's useful.

It does look a bit silly, doesn't it. Retroactively, it kind of makes sense - 
it's possible that one of the mutation involved in merging drops a keyspace, so 
we need to exclude them. But I don't think I put it there for any particular 
reason. Its presence doesn't bother me much - it's still huge savings all over 
- now that we don't need to read the previous state at all, and with reload 
changes, but I'll have a look.

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



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

[jira] [Commented] (CASSANDRA-10070) Automatic repair scheduling

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-10070:


[~amandava] I just opened CASSANDRA-10619

> Automatic repair scheduling
> ---
>
> Key: CASSANDRA-10070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10070
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Minor
> Fix For: 3.x
>
>
> Scheduling and running repairs in a Cassandra cluster is most often a 
> required task, but this can both be hard for new users and it also requires a 
> bit of manual configuration. There are good tools out there that can be used 
> to simplify things, but wouldn't this be a good feature to have inside of 
> Cassandra? To automatically schedule and run repairs, so that when you start 
> up your cluster it basically maintains itself in terms of normal 
> anti-entropy, with the possibility for manual configuration.



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

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

[Alexandre Dutra (JIRA)]

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

Alexandre Dutra commented on CASSANDRA-10365:
-

Thanks for the quick reply.

Second nit: it seems that initconds of type text are broken, not sure if it's 
due to CASSANDRA-10617:

{code}
cqlsh:test> CREATE FUNCTION concat(s1 text, s2 text) RETURNS NULL ON NULL INPUT 
RETURNS text LANGUAGE java AS 'return s1 + s2;';
cqlsh:test> CREATE AGGREGATE group(text) SFUNC concat STYPE text INITCOND 
'Hello';
ServerError: 
{code}

{noformat}
Caused by: org.apache.cassandra.exceptions.SyntaxException: Failed parsing CQL 
term: [Hello] reason: SyntaxException line 0:-1 no viable alternative at input 
''
at 
org.apache.cassandra.cql3.CQLFragmentParser.parseAny(CQLFragmentParser.java:65) 
~[main/:na]
at org.apache.cassandra.cql3.Terms.asBytes(Terms.java:51) ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.createAggregateFromRow(SchemaKeyspace.java:1229)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchUDAs(SchemaKeyspace.java:1208) 
~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1133)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:891)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesOnly(SchemaKeyspace.java:881)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1281)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1260)
 ~[main/:na]
at 
org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:491)
 ~[main/:na]
{noformat}



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



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

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

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10608:
-

while [~mike_tr_adamson] gets set on with cassci I've pushed his branches to my 
fork to get a CI run going:

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

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



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

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

[Alexandre Dutra (JIRA)]

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

Alexandre Dutra commented on CASSANDRA-10365:
-

[~snazy] While testing the Java driver against your branch I came across this 
bug, also reproducible via cqlsh:

{code}
cqlsh> create keyspace test with replication = { 'class' : 'SimpleStrategy', 
'replication_factor' : 1 };
cqlsh> use test;
cqlsh:test> create type "Foo" (f1 int);
cqlsh:test> describe type "Foo";

CREATE TYPE test."Foo" (
f1 'int'
);

cqlsh:test> create table t1 (pk int primary key, c1 frozen<"Foo">);
ServerError: 
{code}

It seems that mixed-case identifiers are being lower-cased somewhere.

The server logs show:

{noformat}
Caused by: org.apache.cassandra.exceptions.InvalidRequestException: Unknown 
type test.foo
at 
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:536) 
~[main/:na]
at 
org.apache.cassandra.cql3.CQL3Type$Raw$RawTuple.prepare(CQL3Type.java:596) 
~[main/:na]
at 
org.apache.cassandra.schema.CQLTypeParser.parse(CQLTypeParser.java:55) 
~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.createColumnFromColumnRow(SchemaKeyspace.java:1024)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.lambda$fetchColumns$242(SchemaKeyspace.java:1008)
 ~[main/:na]
at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_66]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchColumns(SchemaKeyspace.java:1008)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchTable(SchemaKeyspace.java:962) 
~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchTables(SchemaKeyspace.java:941) 
~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:889)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesOnly(SchemaKeyspace.java:881)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1281)
 ~[main/:na]
at 
org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1260)
 ~[main/:na]
{noformat}

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



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

[jira] [Commented] (CASSANDRA-10602) 2 upgrade test failures: static_columns_paging_test and multi_list_set_test

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-10602:


I used the patch for CASSANDRA-10476 and it was working fine for {{2.2 HEAD}} 
to {{3.0 HEAD}} but not for {{2.2.3}} to {{3.0 HEAD}}.
It was still failing with a {{NPE}} when the old node was querying the new one. 
Was it expected? 

> 2 upgrade test failures: static_columns_paging_test and multi_list_set_test
> ---
>
> Key: CASSANDRA-10602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10602
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.0
>
>
> The two following test throws a NPE:
> * 
> http://cassci.datastax.com/job/cassandra-3.0_dtest/293/testReport/junit/upgrade_tests.paging_test/TestPagingDataNodes2RF1/static_columns_paging_test/
> * 
> http://cassci.datastax.com/job/cassandra-3.0_dtest/293/testReport/junit/upgrade_tests.cql_tests/TestCQLNodes3RF3/multi_list_set_test/



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

[jira] [Comment Edited] (CASSANDRA-10602) 2 upgrade test failures: static_columns_paging_test and multi_list_set_test

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer edited comment on CASSANDRA-10602 at 10/29/15 2:31 PM:
--

I used the patch for CASSANDRA-10476 and it was working fine for {{2.2 HEAD}} 
to {{3.0 HEAD}} but not for {{2.2.3}} to {{3.0 HEAD}}.
It was still failing with a {{NPE}} when the old node was querying the new one. 
Was it expected? 

I tried to check if the same problem occured on cassci but it seems that you 
did not run CI on your branch.


was (Author: blerer):
I used the patch for CASSANDRA-10476 and it was working fine for {{2.2 HEAD}} 
to {{3.0 HEAD}} but not for {{2.2.3}} to {{3.0 HEAD}}.
It was still failing with a {{NPE}} when the old node was querying the new one. 
Was it expected? 

> 2 upgrade test failures: static_columns_paging_test and multi_list_set_test
> ---
>
> Key: CASSANDRA-10602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10602
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.0
>
>
> The two following test throws a NPE:
> * 
> http://cassci.datastax.com/job/cassandra-3.0_dtest/293/testReport/junit/upgrade_tests.paging_test/TestPagingDataNodes2RF1/static_columns_paging_test/
> * 
> http://cassci.datastax.com/job/cassandra-3.0_dtest/293/testReport/junit/upgrade_tests.cql_tests/TestCQLNodes3RF3/multi_list_set_test/



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

[jira] [Commented] (CASSANDRA-10602) 2 upgrade test failures: static_columns_paging_test and multi_list_set_test

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10602:
--

bq. It was still failing with a NPE when the old node was querying the new one.

Do you have the stack? It might not be failing for the same reason. 

> 2 upgrade test failures: static_columns_paging_test and multi_list_set_test
> ---
>
> Key: CASSANDRA-10602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10602
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.0
>
>
> The two following test throws a NPE:
> * 
> http://cassci.datastax.com/job/cassandra-3.0_dtest/293/testReport/junit/upgrade_tests.paging_test/TestPagingDataNodes2RF1/static_columns_paging_test/
> * 
> http://cassci.datastax.com/job/cassandra-3.0_dtest/293/testReport/junit/upgrade_tests.cql_tests/TestCQLNodes3RF3/multi_list_set_test/



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

[jira] [Commented] (CASSANDRA-10614) AssertionError while flushing memtables

[Alan Boudreault (JIRA)]

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

Alan Boudreault commented on CASSANDRA-10614:
-

[~thobbs] I confirm that your patch fixes my performance regression issue.

> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace 
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
>   at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49) 
> ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
>  ~[main/:na]
>   at 
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352) 
> ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
>  ~[guava-18.0.jar:na]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
>  ~[main/:na]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_45]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_45]
>   at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100 
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}



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

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

[Mike Adamson (JIRA)]

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

Mike Adamson commented on CASSANDRA-10608:
--

[~slebresne] I have incorporated your suggestions in [~beobal]'s branch.

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



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

[jira] [Commented] (CASSANDRA-8927) Mark libjna-java + libjna-jni as incompatible in debian package

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-8927:
---

I see three different {{cassandra.in.sh}} files in bin/, debian/, and 
tools/bin/ - is this relevant to all of them?

> Mark libjna-java + libjna-jni as incompatible in debian package
> ---
>
> Key: CASSANDRA-8927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8927
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
> Environment: Debian
>Reporter: Robert Stupp
>Assignee: Michael Shuler
> Fix For: 2.1.x
>
>
> Current Debian (Wheezy) might bring {{libjna-java}} in version 3.2.7-4, which 
> has incompatible {{libjnadispatch.so}} because since C* 2.1 we use JNA 4.0.0 
> (the native stuff changed):
> jna.jar includes all binaries for all supported platforms - so there's no 
> need for libjna installed separately.
> Since CASSANDRA-8714 has been committed, the incompatibility manifests in 
> {{java.lang.NoClassDefFoundError: Could not initialize class 
> com.sun.jna.Native}} (which is caused by outdated libjna-java installed via 
> apt).
> Note: Debian jessie adds new package {{libjna-jni}} (4.1.0-1) in addition to 
> {{libjna-java}} (4.1.0-1) - both contain the {{libjnidispatch.so}}. Although 
> these seem to work, we might hit the same issue when there's a need to 
> upgrade JNA to 4.2.x sometime.



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

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

[Alexandre Dutra (JIRA)]

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

Alexandre Dutra commented on CASSANDRA-10365:
-

Up-to-date Java driver version 
[here|https://github.com/datastax/java-driver/pull/467].

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



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

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

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10365:
--

bq.  Its presence doesn't bother me much - it's still huge savings all over - 
now that we don't need to read the previous state at all

I don't dispute that, and while I suspect we might be able to avoid it, it 
actually doesn't really bother me. The lack of comment does bother me however 
given that it looks fishy without context.

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



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

[jira] [Commented] (CASSANDRA-10598) Unable to use same index name on column families which have different names in different keyspaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-10598:


Github user mshuler commented on the pull request:

https://github.com/apache/cassandra/pull/56#issuecomment-152204490
  
The Apache Cassandra project does not use this github mirror for 
development, nor does it have a way to process pull requests.

If you would like to contribute your suggested code changes, please post a 
patch directly to the referenced JIRA ticket and close this PR.


> Unable to use same index name on column families which have different names 
> in different keyspaces
> --
>
> Key: CASSANDRA-10598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10598
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Yeh Sheng Hsiung
>
> Expected:
> The same index name can be used in different keyspaces without conflict
> Actual:
> Unable to use same index name on column families which have different names 
> in different keyspaces
> Steps to Reproduce:
> {code}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 
> 'NetworkTopologyStrategy', 'DC1' : 1};
> cqlsh> CREATE KEYSPACE ks2 WITH replication = {'class': 
> 'NetworkTopologyStrategy', 'DC1' : 1};
> cqlsh> use ks1;
> cqlsh:ks1> CREATE TABLE t1 (c1 int PRIMARY KEY, c2 int);
> cqlsh:ks1> create index c2_idx on t1 (c2);
> cqlsh:ks1> use ks2;
> cqlsh:ks2> CREATE TABLE t2 (c1 int PRIMARY KEY, c2 int);
> cqlsh:ks2> create index c2_idx on t2 (c2);
> ConfigurationException:  configuration issue] message="Duplicate index name c2_idx">
> {code}



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

[jira] [Commented] (CASSANDRA-6246) EPaxos

[Jim Meyer (JIRA)]

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

Jim Meyer commented on CASSANDRA-6246:
--

Does anyone know if this patch will help with CASSANDRA-9328 (i.e. outcome of 
LWT not reported to client when there is contention).  There's a suggestion to 
that effect in the comments of 9328, but I don't know if anyone has tried 
running the test code in 9328 to see if this patch has an effect on that issue.

Is this patch compatible with rc2 of Cassandra 3.0.0 or does it need to be 
updated?  When is it planned to add epaxos to an official build?  Thanks for 
any info.

> EPaxos
> --
>
> Key: CASSANDRA-6246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Blake Eggleston
> Fix For: 3.x
>
>
> One reason we haven't optimized our Paxos implementation with Multi-paxos is 
> that Multi-paxos requires leader election and hence, a period of 
> unavailability when the leader dies.
> EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
> (2) is particularly useful across multiple datacenters, and (3) allows any 
> node to act as coordinator: 
> http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
> However, there is substantial additional complexity involved if we choose to 
> implement it.



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg reassigned CASSANDRA-10422:
--

Assignee: Ariel Weisberg

> 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
>Assignee: Ariel Weisberg
> 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] [Commented] (CASSANDRA-8927) Mark libjna-java + libjna-jni as incompatible in debian package

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-8927:
---

I see quite a few reverse dependencies on the libjna-java package. I'm really 
wary of adding a package conflict, which might mean a user cannot 
install/upgrade cassandra because they may not be able to uninstall libjna-*, 
since it's needed by gradle, libc-6-dev, jitsi, spring, and more.

> Mark libjna-java + libjna-jni as incompatible in debian package
> ---
>
> Key: CASSANDRA-8927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8927
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
> Environment: Debian
>Reporter: Robert Stupp
>Assignee: Michael Shuler
> Fix For: 2.1.x
>
>
> Current Debian (Wheezy) might bring {{libjna-java}} in version 3.2.7-4, which 
> has incompatible {{libjnadispatch.so}} because since C* 2.1 we use JNA 4.0.0 
> (the native stuff changed):
> jna.jar includes all binaries for all supported platforms - so there's no 
> need for libjna installed separately.
> Since CASSANDRA-8714 has been committed, the incompatibility manifests in 
> {{java.lang.NoClassDefFoundError: Could not initialize class 
> com.sun.jna.Native}} (which is caused by outdated libjna-java installed via 
> apt).
> Note: Debian jessie adds new package {{libjna-jni}} (4.1.0-1) in addition to 
> {{libjna-java}} (4.1.0-1) - both contain the {{libjnidispatch.so}}. Although 
> these seem to work, we might hit the same issue when there's a need to 
> upgrade JNA to 4.2.x sometime.



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10422:


[~krummas] Is this as simple as having a repair that has a start/end token(s) 
specified ignoring (or rejecting) the incremental repair flag? Say [here in 
RepairOption.parse|https://github.com/apache/cassandra/blob/ef1b4c0f5a8e0677efd3ec25fa735782ce1b1480/src/java/org/apache/cassandra/repair/messages/RepairOption.java#L143]?

> 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
>Assignee: Ariel Weisberg
> 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] [Commented] (CASSANDRA-8927) Mark libjna-java + libjna-jni as incompatible in debian package

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-8927:
---

I'm not clear on what I'm being asked. Is this a modification of just adding 
{{-Djna.nosys=true}} in {{cassandra.in.sh}}? Is that file also used in a tar 
installation startup of C*, or is this just deb installations? Got a patch, or 
is this something we need to create a deb-only dpatch patch for?

> Mark libjna-java + libjna-jni as incompatible in debian package
> ---
>
> Key: CASSANDRA-8927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8927
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
> Environment: Debian
>Reporter: Robert Stupp
>Assignee: Michael Shuler
> Fix For: 2.1.x
>
>
> Current Debian (Wheezy) might bring {{libjna-java}} in version 3.2.7-4, which 
> has incompatible {{libjnadispatch.so}} because since C* 2.1 we use JNA 4.0.0 
> (the native stuff changed):
> jna.jar includes all binaries for all supported platforms - so there's no 
> need for libjna installed separately.
> Since CASSANDRA-8714 has been committed, the incompatibility manifests in 
> {{java.lang.NoClassDefFoundError: Could not initialize class 
> com.sun.jna.Native}} (which is caused by outdated libjna-java installed via 
> apt).
> Note: Debian jessie adds new package {{libjna-jni}} (4.1.0-1) in addition to 
> {{libjna-java}} (4.1.0-1) - both contain the {{libjnidispatch.so}}. Although 
> these seem to work, we might hit the same issue when there's a need to 
> upgrade JNA to 4.2.x sometime.



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

[jira] [Commented] (CASSANDRA-10476) Fix upgrade paging dtest failures on 2.2->3.0 path

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-10476:


For 
{{upgrade_tests/paging_test.py:TestPagingDataNodes2RF1.static_columns_paging_test}},
 I used [~slebresne] patch for CASSANDRA-10602.
For {{2.2 HEAD}} to {{3.0 HEAD}} the test was running fine and I could not 
reproduce the data-validation error.
For {{2.2.3}} to {{3.0 HEAD}} I was still running in a {{NPE}}.

For the flapping test they all fail on cassci due to a timeout. I looked on the 
way the test are implemented and they use exclusive connection to each nodes. 
By consequence the problem does not seems to be fluctuating based on the 
queried node.
My guess is that the timeout is a bit too low for a RF3 test. We should 
probably increase it to see if it removes the problem.



> Fix upgrade paging dtest failures on 2.2->3.0 path
> --
>
> Key: CASSANDRA-10476
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10476
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Benjamin Lerer
> Fix For: 3.0.0
>
>
> EDIT: this list of failures is no longer current; see comments for current 
> failures.
> The following upgrade tests for paging features fail or flap on the upgrade 
> path from 2.2 to 3.0:
> - {{upgrade_tests/paging_test.py:TestPagingData.static_columns_paging_test}}
> - 
> {{upgrade_tests/paging_test.py:TestPagingSize.test_undefined_page_size_default}}
> - 
> {{upgrade_tests/paging_test.py:TestPagingSize.test_with_more_results_than_page_size}}
> - 
> {{upgrade_tests/paging_test.py:TestPagingWithDeletions.test_failure_threshold_deletions}}
> - 
> {{upgrade_tests/paging_test.py:TestPagingWithDeletions.test_multiple_cell_deletions}}
> - 
> {{upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_cell_deletions}}
> - 
> {{upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_row_deletions}}
> - 
> {{upgrade_tests/paging_test.py:TestPagingDatasetChanges.test_cell_TTL_expiry_during_paging/}}
> I've grouped them all together because I don't know how to tell if they're 
> related; once someone triages them, it may be appropriate to break this out 
> into multiple tickets.
> The failures can be found here:
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingData/static_columns_paging_test/history/
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingSize/test_undefined_page_size_default/history/
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/42/testReport/upgrade_tests.paging_test/TestPagingSize/test_with_more_results_than_page_size/history/
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_failure_threshold_deletions/history/
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_multiple_cell_deletions/history/
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_single_cell_deletions/history/
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_single_row_deletions/history/
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingDatasetChanges/test_cell_TTL_expiry_during_paging/
> Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
> merged, these tests should also run with this upgrade path on normal 3.0 
> jobs. Until then, you can run them with the following command:
> {code}
> SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
> nosetests 
> upgrade_tests/paging_test.py:TestPagingData.static_columns_paging_test 
> upgrade_tests/paging_test.py:TestPagingSize.test_undefined_page_size_default 
> upgrade_tests/paging_test.py:TestPagingSize.test_with_more_results_than_page_size
>  
> upgrade_tests/paging_test.py:TestPagingWithDeletions.test_failure_threshold_deletions
>  
> upgrade_tests/paging_test.py:TestPagingWithDeletions.test_multiple_cell_deletions
>  
> upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_cell_deletions
>  
> upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_row_deletions
> 

[jira] [Commented] (CASSANDRA-10609) MV performance regression

[Alan Boudreault (JIRA)]

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

Alan Boudreault commented on CASSANDRA-10609:
-

This issue will be fix with CASSANDRA-10614

> MV performance regression
> -
>
> Key: CASSANDRA-10609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10609
> Project: Cassandra
>  Issue Type: Bug
> Environment: EC2
>Reporter: Alan Boudreault
>Assignee: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> I've noticed an important MV performance regression that has been introduced 
> in 3.0.0-rc1. The issue has been introduced by CASSANDRA-9664.
> * I'm using mvbench to test with RF=3
> * I confirm it's not a driver issue.
> {code}
> EC2 RF=3 (i2.2xlarge, also tried on i2.4xlarge)
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100 
> --num-artists 1 -n 50 --endpoint node1"
> 3.0.0-beta2 (alpha2 java driver)
> ---
> total
>  count = 461601
>  mean rate = 1923.21 calls/second
>  1-minute rate = 1937.82 calls/second
>  5-minute rate = 1424.09 calls/second
> 15-minute rate = 1058.28 calls/second
>min = 1.90 milliseconds
>max = 3707.76 milliseconds
>   mean = 516.42 milliseconds
> stddev = 457.41 milliseconds
> median = 390.07 milliseconds
>   75% <= 775.95 milliseconds
>   95% <= 1417.67 milliseconds
>   98% <= 1728.05 milliseconds
>   99% <= 1954.55 milliseconds
> 99.9% <= 2566.91 milliseconds
> 3.0.0-rc1 (alpha3 java driver)
> -
> total
>  count = 310373
>  mean rate = 272.25 calls/second
>  1-minute rate = 0.00 calls/second
>  5-minute rate = 45.47 calls/second
> 15-minute rate = 295.94 calls/second
>min = 1.05 milliseconds
>max = 10468.98 milliseconds
>   mean = 492.99 milliseconds
> stddev = 510.42 milliseconds
> median = 281.02 milliseconds
>   75% <= 696.25 milliseconds
>   95% <= 1434.45 milliseconds
>   98% <= 1820.33 milliseconds
>   99% <= 2080.37 milliseconds
> 99.9% <= 4362.08 milliseconds
> {code}



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

[jira] [Commented] (CASSANDRA-10092) Generalize PerRowSecondaryIndex validation

[JIRA]

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

Andrés de la Peña commented on CASSANDRA-10092:
---

Great! Thanks for your help!

> Generalize PerRowSecondaryIndex validation
> --
>
> Key: CASSANDRA-10092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10092
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Minor
>  Labels: 2i, secondary_index, validation
> Fix For: 2.2.4, 2.1.12
>
> Attachments: CASSANDRA-10092_v2.patch, CASSANDRA-10092_v3.patch, 
> improve_2i_validation.patch
>
>
> Index validation is currently done in a per-cell basis. However, per-row 
> secondary index developers can be interested in validating all the written 
> columns at once, because some implementations need to check the validity of a 
> row write by comparing some column values against others. For example, a per 
> row 2i implementation indexing time ranges (composed by a start date column 
> and an end date column) should check that the start date is before the stop 
> date.
> I'm attaching a patch adding a new method to {{PerRowSecondaryIndex}}:
> {code:java}
> public void validate(ByteBuffer key, ColumnFamily cf) throws 
> InvalidRequestException {}
> {code}
> and a new method to {{SecondaryIndexManager}}:
> {code:java}
> public void validateRowLevelIndexes(ByteBuffer key, ColumnFamily cf) throws 
> InvalidRequestException
>   {
>   for (SecondaryIndex index : rowLevelIndexMap.values())
>   {
>   ((PerRowSecondaryIndex) index).validate(key, cf);
>   }
>   }
> {code}
> This method is invoked in CQL {{UpdateStatement#validateIndexedColumns}}. 
> This way, {{PerRowSecondaryIndex}} could perform complex write validation.
> I have tried to do the patch in the least invasive way possible. Maybe the 
> current method {{SecondaryIndex#validate(ByteBuffer, Cell)}} should be moved 
> to {{PerColumnSecondaryIndex}}, and the {{InvalidRequestException}} that 
> informs about the particular 64k limitation should be thrown by 
> {{AbstractSimplePerColumnSecondaryIndex}}. However, given the incoming  
> [CASSANDRA-9459|https://issues.apache.org/jira/browse/CASSANDRA-9459], I 
> think that the proposed patch is more than enough to provide rich validation 
> features to 2i implementations based on 2.1.x and 2.2.x.



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

[jira] [Comment Edited] (CASSANDRA-10513) Update cqlsh for new driver execution API

[Adam Holmberg (JIRA)]

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

Adam Holmberg edited comment on CASSANDRA-10513 at 10/29/15 4:04 PM:
-

In addition to the issues Sam mentioned, there are the linked issues 
CASSANDRA-7645 -(which this resolves)-, and CASSANDRA-9813 (which depends on 
these changes). The urgency of the 2.2 patch here would be the same as the 
dependent tickets mentioned here and above. I don't see any issue waiting for 
the driver release to integrate for Cassandra 2.2. We will need to patch 3.0 
sooner in support of CASSANDRA-10365 (this may be applied at the same time as 
the driver is updated for that ticket).


was (Author: aholmber):
In addition to the issues Sam mentioned, there are the linked issues 
CASSANDRA-7645 (which this resolves), and CASSANDRA-9813 (which depends on 
these changes). The urgency of the 2.2 patch here would be the same as the 
dependent tickets mentioned here and above. I don't see any issue waiting for 
the driver release to integrate for Cassandra 2.2. We will need to patch 3.0 
sooner in support of CASSANDRA-10365 (this may be applied at the same time as 
the driver is updated for that ticket).

> Update cqlsh for new driver execution API
> -
>
> Key: CASSANDRA-10513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10513
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Adam Holmberg
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: cqlsh
> Fix For: 2.2.x, 3.0.x
>
> Attachments: 10513-2.1.txt, 10513-2.2.txt, 10513.txt
>
>
> The 3.0 Python driver will have a few tweaks to the execution API. We'll need 
> to update cqlsh in a couple of minor ways.
> [Results are always returned as an iterable 
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-368]
> [Trace data is always attached to the 
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-318] (instead of 
> being attached to a statement)



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

[jira] [Commented] (CASSANDRA-9328) WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration taking MUCH less than cas_contention_timeout_in_ms

[Jim Meyer (JIRA)]

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

Jim Meyer commented on CASSANDRA-9328:
--

I'm not sure I understand the proposed workaround. For example, suppose two 
clients are trying to create the same username in a table.  If one of them gets 
a WTE, then they can't do a simple read to see if their insert was successful 
since the other client may have been the one that created it.

So it seems that each client would need to set the data in a unique way, such 
that it can do a simple read and determine that its specific transaction was 
applied.  For example, the client could set a UUID field as a transaction id, 
and then on the extra read, check if the UUID matched what they wrote to 
differentiate their LWT from those of other clients.  I guess that would work, 
but besides being slow, it would waste quite a bit of space to store 
transaction ID's.  Is there a better way?


> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms
> 
>
> Key: CASSANDRA-9328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9328
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aaron Whiteside
>Priority: Critical
> Fix For: 2.1.x
>
> Attachments: CassandraLWTTest.java, CassandraLWTTest2.java
>
>
> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms.
> Unit test attached, run against a 3 node cluster running 2.1.5.
> If you reduce the threadCount to 1, you never see a WriteTimeoutException. If 
> the WTE is due to not being able to communicate with other nodes, why does 
> the concurrency >1 cause inter-node communication to fail?



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

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

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10365:
--

Remarks on the 3rd patch (understanding that it's not 100% complete):
* Bit of a nitpick, but I don't love the addition of the keyspace to {{Types}} 
because it's not consistent with it's siblings ({{Tables}} and {{Functions}}). 
It seems to be there just because we need it, along with the types, in some of 
{{CQL3Type.Raw.prepare(Types)}} implementations. Can't we just pass the 
keyspace name as a first argument to that method instead? If you care about 
leaving it in {{Types}} however, lets at least take it into account in 
{{equals}} and {{hashCode}}.
* {{CQL3Type.UserDefined.toString()}} doesn't quote stuffs properly (if the udt 
name is a quoted name). {{SchemaKeyspace.bbToString()}} has the same problem.  
There is a {{ColumnIdentifier.maybeQuote()}} method that could be reused for 
info.
* Can you add a comment to fetchDroppedColumns to remind the reader why using 
Types.none() is ok (just a pointer to expandUserTypes is fine).
* The use of {{Types.none()}} in {{CQLSSTableWriter}} striked me as weird. That 
made realize however that I wasn't sure if UDT were actually usable with 
{{CQLSSTableWriter}} at all, and how if they are. Do you know more?

(side-note: making the remaining change in a new commit would be appreciated :))

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



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

[jira] [Commented] (CASSANDRA-10602) 2 upgrade test failures: static_columns_paging_test and multi_list_set_test

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-10602:


{code}AssertionError: Unexpected error in node2 node log: ['ERROR 
[SharedPool-Worker-1] 2015-10-29 16:02:15,409 QueryMessage.java:136 - 
Unexpected error during query
java.lang.NullPointerException: null \n\r 
org.apache.cassandra.service.pager.RangeSliceQueryPager.containsPreviousLast(RangeSliceQueryPager.java:103)
 ~[main/:na
] \tat 
org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:119)
 ~[main/:na] \tat org.apache.cassandra.service.pager.RangeSli
ceQueryPager.fetchPage(RangeSliceQueryPager.java:39) ~[main/:na] \tat 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:239)
 ~[m
ain/:na] \tat 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:179)
 ~[main/:na] \tat org.apache.cassandra.cql3.statements.Selec
tStatement.execute(SelectStatement.java:76) ~[main/:na] \tat 
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
 ~[main/:na] \tat
 org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256) 
~[main/:na] \tat 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java
:241) ~[main/:na] \tat 
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:123)
 ~[main/:na] \tat org.apache.cassandra.transport.Messa
ge$Dispatcher.channelRead0(Message.java:507) [main/:na] \tat 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
 [main/:na] \tat io
.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
 [netty-all-4.0.23.Final.jar:4.0.23.Final] \tat io.netty.channel.Abs
tractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
 [netty-all-4.0.23.Final.jar:4.0.23.Final] \\r io.netty.channel.AbstractCha
nnelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) 
[netty-all-4.0.23.Final.jar:4.0.23.Final] \\r 
io.netty.channel.AbstractChannelHandlerConte
xt$8.run(AbstractChannelHandlerContext.java:324) 
[netty-all-4.0.23.Final.jar:4.0.23.Final] \tat 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.ja
va:511) [na:1.8.0_40] \tat 
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
 [mai
n/:na] \tat org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
[main/:na] \tat java.lang.Thread.run(Thread.java:745) [na:1.8.0_40] ERROR 
[SharedP
ool-Worker-1] 2015-10-29 16:02:15,409 QueryMessage.java:136 - Unexpected error 
during query java.lang.NullPointerException: null \tat 
org.apache.cassandra.servi
ce.pager.RangeSliceQueryPager.containsPreviousLast(RangeSliceQueryPager.java:103)
 ~[main/:na] \tat org.apache.cassandra.service.pager.AbstractQueryPager.fetchPa
ge(AbstractQueryPager.java:119) ~[main/:na] \tat 
org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:39)
 ~[main/:na] \ta
t 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:239)
 ~[main/:na] \tat org.apache.cassandra.cql3.statements.SelectStatement.e
xecute(SelectStatement.java:179) ~[main/:na] \tat 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
 ~[main/:na] \tat org.apa
che.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225) 
~[main/:na] \tat 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.jav
a:256) ~[main/:na] \tat 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241) 
~[main/:na] \tat org.apache.cassandra.transport.messages.Query
Message.execute(QueryMessage.java:123) ~[main/:na] \tat 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
 [main/:na] \tat org.apa
che.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401) 
[main/:na] \tat 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannel
InboundHandler.java:105) [netty-all-4.0.23.Final.jar:4.0.23.Final] \tat 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerC
ontext.java:333) [netty-all-4.0.23.Final.jar:4.0.23.Final] \tat 
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
 [netty-all-4.0.23.Final.jar:4.0.23.Final] \tat 
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
 [netty-all-4.0.23.F
inal.jar:4.0.23.Final] \tat 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_40] \tat org.apache.cassandra.concurrent.AbstractT
racingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
 [main/:na] \tat org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.
java:105) [main/:na] 

[jira] [Commented] (CASSANDRA-6246) EPaxos

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-6246:


bq. Does anyone know if this patch will help with CASSANDRA-9328

it should, yes

bq. Is this patch compatible with rc2 of Cassandra 3.0.0 or does it need to be 
updated?

it needs to be rebased onto cassandra-3.0, there are a few parts where it 
interacts directly with the cell timestamps

bq. When is it planned to add epaxos to an official build?

There are no plans at the moment, the patch still needs to be reviewed.

> EPaxos
> --
>
> Key: CASSANDRA-6246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Blake Eggleston
> Fix For: 3.x
>
>
> One reason we haven't optimized our Paxos implementation with Multi-paxos is 
> that Multi-paxos requires leader election and hence, a period of 
> unavailability when the leader dies.
> EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
> (2) is particularly useful across multiple datacenters, and (3) allows any 
> node to act as coordinator: 
> http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
> However, there is substantial additional complexity involved if we choose to 
> implement it.



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

[jira] [Commented] (CASSANDRA-8505) Invalid results are returned while secondary index are being build

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-8505:
---

Secondary index and their build/not build status are node-local. By consequence 
it is not possible to know on a coordinator node if the index is fully build. 
It can be built on the coordinator but still building on other nodes. Further 
more an index rebuild can be triggered at any time.
Therefore the only moment where we can check if the index is ready is at query 
execution time.

The first problem of rejecting index queries at execution time is that some 
{{ALLOW FILTERING}} queries that could have been processed without an index 
will be rejected. As the {{ALLOW FILTERING}} information is not passed with the 
command we have no way to know if the query should be executed or not using 
filtering. On the other hand, currently, if an index exists but is not built 
Cassandra might silently return the wrong results. By consequence rejecting the 
query is still an improvement, in my opinion, and we can create a new ticket to 
improve the situation in the future.

The second problem if about communicating back the error to the coordinator 
node. CASSANDRA-7886 added a mechanism for that but it is not perfect. The user 
will receive a {{ReadFailureException}} but would have to look within the logs 
to find the root cause of the problem. Ideally this mechanism should be 
improved to be able to pass the error message to the {{ReadFailureException}}. 
The other problem of the mechanism is that it is only available since {{2.2}}, 
so I could not create a patch for {{2.1}}.

The patch for {{2.2}} is 
[here|https://github.com/apache/cassandra/compare/trunk...blerer:8505-2.2] and 
the patch for {{3.0}} is 
[here|https://github.com/apache/cassandra/compare/trunk...blerer:8505-3.0]

Both patches keep the index state in memory and throw an Exception if the index 
is not ready when a request arrive.
The paches also shortcut the building of a index if the base table is empty. 
This optimisation prevent a lot of the existing index tests to fail.

*The unit test results for {{2.2}} are 
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-8505-2.2-testall/3/]
   
*The dtest results for {{2.2}} are 
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-8505-2.2-dtest/3/]
   
*The unit test results for {{3.0}} are 
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-8505-3.0-testall/1/]
   
*The dtest results for {{3.0}} are 
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-8505-3.0-dtest/1/]
   

The 
{{secondary_indexes_test.TestSecondaryIndexesOnCollections.test_map_indexes}} 
dtest fails in {{2.2}} because it is not waiting for the index to be built 
before querying the index. I will provide a patch for the DTest. 

   

> Invalid results are returned while secondary index are being build
> --
>
> Key: CASSANDRA-8505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8505
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 2.1.x
>
>
> If you request an index creation and then execute a query that use the index 
> the results returned might be invalid until the index is fully build. This is 
> caused by the fact that the table column will be marked as indexed before the 
> index is ready.
> The following unit tests can be use to reproduce the problem:
> {code}
> @Test
> public void testIndexCreatedAfterInsert() throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, c int, primary key((a, 
> b)))");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 0, 0);");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 1, 1);");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 2, 2);");
> execute("INSERT INTO %s (a, b, c) VALUES (1, 0, 3);");
> execute("INSERT INTO %s (a, b, c) VALUES (1, 1, 4);");
> 
> createIndex("CREATE INDEX ON %s(b)");
> 
> assertRows(execute("SELECT * FROM %s WHERE b = ?;", 1),
>row(0, 1, 1),
>row(1, 1, 4));
> }
> 
> @Test
> public void testIndexCreatedBeforeInsert() throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, c int, primary key((a, 
> b)))");
> createIndex("CREATE INDEX ON %s(b)");
> 
> execute("INSERT INTO %s (a, b, c) VALUES (0, 0, 0);");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 1, 1);");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 2, 2);");
> execute("INSERT INTO %s (a, b, c) VALUES (1, 0, 3);");
> execute("INSERT INTO %s (a, b, c) VALUES (1, 1, 4);");
>  

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

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10365:
---

bq. That made realize however that I wasn't sure if UDT were actually usable 
with CQLSSTableWriter at all, and how if they are. Do you know more?

They weren't usable before, and I do not really care to fix it in this ticket, 
so I just retained the current behavior.

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



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

[jira] [Commented] (CASSANDRA-10508) Remove hard-coded SSL cipher suites and protocols

[Sean Thornton (JIRA)]

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

Sean Thornton commented on CASSANDRA-10508:
---

It would be nice to see the ordering bug in filterCipherSuites addressed prior 
to the specified 3.x fix version.  The order the suites are specified in 
cassandra.yaml needs to be respected.  Maybe backport that part of the change 
to 2.1 forwards.

> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
> Fix For: 3.x
>
>
> Currently each SSL connections will be initialized using a hard-coded list of 
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
> now require Java 8 which comes with solid defaults for these kind of SSL 
> settings and I'm wondering if the current behavior shouldn't be re-evaluated. 
> In my impression the way cipher suites are currently whitelisted is 
> problematic, as this will prevent the JVM from using more recent and more 
> secure suites that haven't been added to the hard-coded list. JVM updates may 
> also cause issues in case the limited number of ciphers cannot be used, e.g. 
> see CASSANDRA-6613.
> Looking at the source I've also stumbled upon a bug in the 
> {{filterCipherSuites()}} method that would return the filtered list of 
> ciphers in undetermined order where the result is passed to 
> {{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
> order of preference 
> ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) and therefore you 
> may end up with weaker algorithms on the top. Currently it's not that 
> critical, as we only whitelist a couple of ciphers anyway. But it adds to the 
> question if it still really makes sense to work with the cipher list at all 
> in the Cassandra code base.
> Another way to effect used ciphers is by changing the security properties. 
> This is a more versatile way to work with cipher lists instead of relying on 
> hard-coded values, see 
> [here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
>  for details.
> The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
> SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted 
> anyway and will stop using safer protocol sets on new JVM releases or user 
> request. Again, we should stick with the JVM defaults. Using the 
> {{jdk.tls.client.protocols}} systems property will always allow to restrict 
> the set of protocols in case another emergency fix is needed. 
> You can find a patch with where I ripped out the mentioned options here:
> [Diff 
> trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:fix/ssloptions]



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

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

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10089:
-

While writing a dtest for another issue I found a bizarre, and somewhat 
unlikely, but valid situation where the same exception is thrown:
{noformat}
def do_not_join_ring_test(self):
cluster = self.cluster.populate(1)
node1, = cluster.nodelist()
node1.start(wait_for_binary_proto=True, join_ring=False) 
node1.stop()
{noformat}
This tests fails with this exception when stopping the node:
{noformat}
java.lang.NullPointerException: null
at 
org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1624)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1632)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1686)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1510) 
~[main/:na]
at 
org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1185) 
~[main/:na]
at 
org.apache.cassandra.gms.Gossiper.addLocalApplicationStateInternal(Gossiper.java:1415)
 ~[main/:na]
at 
org.apache.cassandra.gms.Gossiper.addLocalApplicationStates(Gossiper.java:1430) 
~[main/:na]
at 
org.apache.cassandra.gms.Gossiper.addLocalApplicationState(Gossiper.java:1420) 
~[main/:na]
at org.apache.cassandra.gms.Gossiper.stop(Gossiper.java:1446) 
~[main/:na]
at 
org.apache.cassandra.service.StorageService$1.runMayThrow(StorageService.java:678)
 ~[main/:na]
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
~[main/:na]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
{noformat}

I wonder if we should just leave it, or special case this situation where the 
local node has not joined the ring and does an orderly shutdown.

> 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] [Resolved] (CASSANDRA-10603) Fix CQL syntax errors in upgrade_through_versions_test

[Andrew Hust (JIRA)]

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

Andrew Hust resolved CASSANDRA-10603.
-
Resolution: Fixed

> Fix CQL syntax errors in upgrade_through_versions_test
> --
>
> Key: CASSANDRA-10603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10603
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Andrew Hust
>
> In the {{cassandra_upgrade_2.1_to_3.0_proto_v3}} upgrade tests on CassCI, 
> some of the tests are failing with the following error:
> {code}
> 
> {code}
> The tests that fail this way [(at least as of this 
> run)|http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/]
>  are the following:
> {code}
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.parallel_upgrade_with_internode_ssl_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.parallel_upgrade_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.bootstrap_multidc_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.bootstrap_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.bootstrap_multidc_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.bootstrap_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.parallel_upgrade_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.parallel_upgrade_with_internode_ssl_test
> {code}
> There may be other tests in other protocol upgrade jobs that fail this way, 
> but I haven't dug through yet to see.
> Assigning to [~rhatch] since, afaik, you're the most likely person to 
> understand the problem. Feel free to reassign, of course.



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

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

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-9912:


Created a simple 
[dest|https://github.com/pauloricardomg/cassandra-dtest/blob/7ef7520206d2ebc355f5ae4d0e64dba64481e057/topology_test.py#L32]
 reproducing the issue. Basically when the node is decommissioned his tokens 
are wiped from {{TokenMetadata}} but not from the system keyspace, so 
{{SizeEstimatesRecorder}} tries to fetch the primary ranges of the 
decommissioned local node's token, which are not in the ring anymore.

Simple fix is to not run {{SizeEstimatesRecorder}} when the node is not a 
member of the ring, generalizing the check that was put by CASSANDRA-9034 to 
not run {{SizeEstimatesRecorder}} when the node has never joined the ring. In 
order to guarantee this generalization will not cause a regression of 
CASSANDRA-9034, I also added a 
[dtest|https://github.com/pauloricardomg/cassandra-dtest/blob/7ef7520206d2ebc355f5ae4d0e64dba64481e057/topology_test.py#L17]
 that reproduces that issue.

I also removed some related dead code from {{StorageService}} and 
{{SystemKeyspace}}.

Test results will be available shortly:

||2.1||2.2||3.0||trunk||dtest||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-9912]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-9912]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-9912]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-9912]|[PR|https://github.com/riptano/cassandra-dtest/pull/637]|
|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-9912-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-9912-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-9912-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-9912-testall/lastCompletedBuild/testReport/]|
|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-9912-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-9912-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-9912-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-9912-dtest/lastCompletedBuild/testReport/]|

> SizeEstimatesRecorder has assertions after decommission sometimes
> -
>
> Key: CASSANDRA-9912
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9912
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Paulo Motta
> 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] [Updated] (CASSANDRA-9912) SizeEstimatesRecorder has assertions after decommission sometimes

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-9912:
---
Fix Version/s: (was: 2.1.12)
   3.0.x
   2.2.x
   2.1.x
  Component/s: Core

> 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
>Assignee: Paulo Motta
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> 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-10422) Avoid anticompaction when doing subrange repair

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-10422:
-

Just had a very quick look, in 2.2+ we do incremental repair by default (and we 
also anticompact after full repairs) so we need to tell the other nodes whether 
this is a 'global' repair or not: 
https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/repair/messages/PrepareMessage.java#L45

> 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
>Assignee: Ariel Weisberg
> 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] [Commented] (CASSANDRA-10611) Upgrade test on 2.1->3.0 path fails with configuration problems

[Andrew Hust (JIRA)]

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

Andrew Hust commented on CASSANDRA-10611:
-

Fixed with PR: https://github.com/riptano/cassandra-dtest/pull/633

> Upgrade test on 2.1->3.0 path fails with configuration problems
> ---
>
> Key: CASSANDRA-10611
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10611
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Andrew Hust
> Fix For: 3.0.0
>
>
> The following test fails on the uprgrade path from 2.1 to 3.0:
> http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/upgrade_through_versions_test/TestUpgrade_from_3_0_latest_tag_to_3_0_HEAD/bootstrap_multidc_test/
> I believe it's basically a configuration error; the cluster likely just needs 
> to be reconfigured in the test:
> {code}
> code=2200 [Invalid query] message="User-defined functions are disabled in 
> cassandra.yaml - set enable_user_defined_functions=true to enable"
> {code}
> Assigning to [~rhatch] for now.



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

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

[Alan Boudreault (JIRA)]

Alan Boudreault created CASSANDRA-10621:
---

 Summary: Error while bootstraping a new node with Materialized 
Views
 Key: CASSANDRA-10621
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10621
 Project: Cassandra
  Issue Type: Bug
Reporter: Alan Boudreault
Assignee: Joel Knighton
Priority: Critical
 Fix For: 3.0.0


If I try to add a new node in a cluster that has materialized views, I get the 
following error:

{code}
 ERROR 19:05:15 Unknown exception caught while attempting to update 
MaterializedView! mview.user_playlists
java.lang.RuntimeException: Trying to get the view natural endpoint on a 
non-data replica
at 
org.apache.cassandra.db.view.ViewUtils.getViewNaturalEndpoint(ViewUtils.java:103)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:693) 
~[main/:na]
at 
org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:145)
 ~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:482) [main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:387) [main/:na]
at org.apache.cassandra.db.Mutation.applyUnsafe(Mutation.java:215) 
[main/:na]
at 
org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:162)
 [main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
[na:1.8.0_45]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_45]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_45]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
ERROR 19:05:15 Error applying streamed sstable: 
java.lang.RuntimeException: Trying to get the view natural endpoint on a 
non-data replica
at 
org.apache.cassandra.db.view.ViewUtils.getViewNaturalEndpoint(ViewUtils.java:103)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:693) 
~[main/:na]
at 
org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:145)
 ~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:482) ~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:387) ~[main/:na]
at org.apache.cassandra.db.Mutation.applyUnsafe(Mutation.java:215) 
~[main/:na]
at 
org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:162)
 ~[main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
[na:1.8.0_45]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_45]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_45]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
WARN  19:05:18 Writing large partition mview/genre_to_user:genre_3 (116986142 
bytes)
WARN  19:05:21 Writing large partition mview/genre_to_user:genre_2 (116985746 
bytes)
WARN  19:05:24 Writing large partition mview/genre_to_user:genre_5 (116986337 
bytes)
ERROR 19:05:33 Unknown exception caught while attempting to update 
MaterializedView! mview.user_playlists
java.lang.RuntimeException: Trying to get the view natural endpoint on a 
non-data replica
at 
org.apache.cassandra.db.view.ViewUtils.getViewNaturalEndpoint(ViewUtils.java:103)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:693) 
~[main/:na]
at 
org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:145)
 ~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:482) [main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:387) [main/:na]
at org.apache.cassandra.db.Mutation.applyUnsafe(Mutation.java:215) 
[main/:na]
at 
org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:162)
 [main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
[na:1.8.0_45]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_45]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_45]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
ERROR 19:05:33 Error applying streamed sstable: 
java.lang.RuntimeException: Trying to get the view natural endpoint on a 
non-data replica
at 

[jira] [Created] (CASSANDRA-10622) Add all options in cqlshrc sample as commented out choices

[Lorina Poland (JIRA)]

Lorina Poland created CASSANDRA-10622:
-

 Summary: Add all options in cqlshrc sample as commented out choices
 Key: CASSANDRA-10622
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10622
 Project: Cassandra
  Issue Type: Improvement
  Components: CQL
Reporter: Lorina Poland
Priority: Minor


All the options should be added to the sample cqlshrc file as commented out 
options. This will provide users with the 15 or so options that can be used in 
cqlshrc.



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

[jira] [Commented] (CASSANDRA-8927) Mark libjna-java + libjna-jni as incompatible in debian package

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-8927:
-

Hm - yes, adding a package conflict might not be the best solution.
Need to reproduce it to see how it manifests and can be fixed (but need to 
rebuild my linux box first).

> Mark libjna-java + libjna-jni as incompatible in debian package
> ---
>
> Key: CASSANDRA-8927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8927
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
> Environment: Debian
>Reporter: Robert Stupp
>Assignee: Michael Shuler
> Fix For: 2.1.x
>
>
> Current Debian (Wheezy) might bring {{libjna-java}} in version 3.2.7-4, which 
> has incompatible {{libjnadispatch.so}} because since C* 2.1 we use JNA 4.0.0 
> (the native stuff changed):
> jna.jar includes all binaries for all supported platforms - so there's no 
> need for libjna installed separately.
> Since CASSANDRA-8714 has been committed, the incompatibility manifests in 
> {{java.lang.NoClassDefFoundError: Could not initialize class 
> com.sun.jna.Native}} (which is caused by outdated libjna-java installed via 
> apt).
> Note: Debian jessie adds new package {{libjna-jni}} (4.1.0-1) in addition to 
> {{libjna-java}} (4.1.0-1) - both contain the {{libjnidispatch.so}}. Although 
> these seem to work, we might hit the same issue when there's a need to 
> upgrade JNA to 4.2.x sometime.



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

[jira] [Commented] (CASSANDRA-9328) WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration taking MUCH less than cas_contention_timeout_in_ms

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-9328:
--

Even with CASSANDRA-6246, you might still get an exception back in case the 
co-ordinator crashes just before returning success or failure. You still won't 
know whether your commit was applied or someone else won just before you. Does 
this sound reasonable? 

> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms
> 
>
> Key: CASSANDRA-9328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9328
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aaron Whiteside
>Priority: Critical
> Fix For: 2.1.x
>
> Attachments: CassandraLWTTest.java, CassandraLWTTest2.java
>
>
> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms.
> Unit test attached, run against a 3 node cluster running 2.1.5.
> If you reduce the threadCount to 1, you never see a WriteTimeoutException. If 
> the WTE is due to not being able to communicate with other nodes, why does 
> the concurrency >1 cause inter-node communication to fail?



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

[jira] [Created] (CASSANDRA-10620) Debian package build broken.

[Michael Shuler (JIRA)]

Michael Shuler created CASSANDRA-10620:
--

 Summary: Debian package build broken.
 Key: CASSANDRA-10620
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10620
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Reporter: Michael Shuler
Assignee: Michael Shuler
Priority: Blocker
 Fix For: 3.0.0
 Attachments: cassandra-tools_debfix.txt

Debian package build is broken post- CASSANDRA-5261 with the removal of 
token-generator. tools/bin/sstableofflinerelevel added, as well, since it was 
missing.



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

[jira] [Resolved] (CASSANDRA-10611) Upgrade test on 2.1->3.0 path fails with configuration problems

[Andrew Hust (JIRA)]

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

Andrew Hust resolved CASSANDRA-10611.
-
Resolution: Fixed

> Upgrade test on 2.1->3.0 path fails with configuration problems
> ---
>
> Key: CASSANDRA-10611
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10611
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Andrew Hust
> Fix For: 3.0.0
>
>
> The following test fails on the uprgrade path from 2.1 to 3.0:
> http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/upgrade_through_versions_test/TestUpgrade_from_3_0_latest_tag_to_3_0_HEAD/bootstrap_multidc_test/
> I believe it's basically a configuration error; the cluster likely just needs 
> to be reconfigured in the test:
> {code}
> code=2200 [Invalid query] message="User-defined functions are disabled in 
> cassandra.yaml - set enable_user_defined_functions=true to enable"
> {code}
> Assigning to [~rhatch] for now.



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

[jira] [Assigned] (CASSANDRA-10611) Upgrade test on 2.1->3.0 path fails with configuration problems

[Andrew Hust (JIRA)]

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

Andrew Hust reassigned CASSANDRA-10611:
---

Assignee: Andrew Hust  (was: Russ Hatch)

> Upgrade test on 2.1->3.0 path fails with configuration problems
> ---
>
> Key: CASSANDRA-10611
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10611
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Andrew Hust
> Fix For: 3.0.0
>
>
> The following test fails on the uprgrade path from 2.1 to 3.0:
> http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/upgrade_through_versions_test/TestUpgrade_from_3_0_latest_tag_to_3_0_HEAD/bootstrap_multidc_test/
> I believe it's basically a configuration error; the cluster likely just needs 
> to be reconfigured in the test:
> {code}
> code=2200 [Invalid query] message="User-defined functions are disabled in 
> cassandra.yaml - set enable_user_defined_functions=true to enable"
> {code}
> Assigning to [~rhatch] for now.



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg reassigned CASSANDRA-10246:
--

Assignee: Ariel Weisberg

> 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: CQL
>Reporter: Michael Penick
>Assignee: Ariel Weisberg
>  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] [Assigned] (CASSANDRA-10603) Fix CQL syntax errors in upgrade_through_versions_test

[Andrew Hust (JIRA)]

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

Andrew Hust reassigned CASSANDRA-10603:
---

Assignee: Andrew Hust  (was: Russ Hatch)

> Fix CQL syntax errors in upgrade_through_versions_test
> --
>
> Key: CASSANDRA-10603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10603
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Andrew Hust
>
> In the {{cassandra_upgrade_2.1_to_3.0_proto_v3}} upgrade tests on CassCI, 
> some of the tests are failing with the following error:
> {code}
> 
> {code}
> The tests that fail this way [(at least as of this 
> run)|http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/]
>  are the following:
> {code}
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.parallel_upgrade_with_internode_ssl_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.parallel_upgrade_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.bootstrap_multidc_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.bootstrap_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.bootstrap_multidc_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.bootstrap_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.parallel_upgrade_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.parallel_upgrade_with_internode_ssl_test
> {code}
> There may be other tests in other protocol upgrade jobs that fail this way, 
> but I haven't dug through yet to see.
> Assigning to [~rhatch] since, afaik, you're the most likely person to 
> understand the problem. Feel free to reassign, of course.



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

[jira] [Updated] (CASSANDRA-10622) Add all options in cqlshrc sample as commented out choices

[Lorina Poland (JIRA)]

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

Lorina Poland updated CASSANDRA-10622:
--
Labels: doc-impacting  (was: )

> Add all options in cqlshrc sample as commented out choices
> --
>
> Key: CASSANDRA-10622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10622
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Lorina Poland
>Assignee: Tyler Hobbs
>Priority: Minor
>  Labels: doc-impacting
>
> All the options should be added to the sample cqlshrc file as commented out 
> options. This will provide users with the 15 or so options that can be used 
> in cqlshrc.



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

[jira] [Created] (CASSANDRA-10623) Text Functions

[Markus Stephanides (JIRA)]

Markus Stephanides created CASSANDRA-10623:
--

 Summary: Text Functions
 Key: CASSANDRA-10623
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10623
 Project: Cassandra
  Issue Type: New Feature
Reporter: Markus Stephanides


In SQL, there are functions that make comparing texts easier e.g UPPER() and 
LOWER()

I need this to compare a text in a WHERE clause of a SELECT statement with 
case-insensitvity.

Thank you in advance!



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg edited comment on CASSANDRA-10246 at 10/29/15 7:53 PM:
--

It seems like existing clients will never be able to use named values in 
batches without updating the protocol. There is no way to correctly decode far 
enough to get to the flags to find out how to correctly decode the lists.

--It seems like there is nothing we can do to save old clients and give them a 
good error.-- My mistake, this is an enhancement, and not something that is 
broken now?

What is the story with protocol changes like this? It seems like we need a 
version bump otherwise newer versions of the client library can't identify that 
the server is unable to correctly handle the suggestion in CASSANDRA-10247.

Speaking of clients this also means we need to update all the client libraries 
to refuse to used named values in batches when the server is a version that 
doesn't support CASSANDRA-10247 as well as to encode using that approach (or 
some other).


was (Author: aweisberg):
It seems like existing clients will never be able to use named values in 
batches without updating the protocol. There is no way to correctly decode far 
enough to get to the flags to find out how to correctly decode the lists.

It seems like there is nothing we can do to save old clients and give them a 
good error.

What is the story with protocol changes like this? It seems like we need a 
version bump otherwise newer versions of the client library can't identify that 
the server is unable to correctly handle the suggestion in CASSANDRA-10247.

Speaking of clients this also means we need to update all the client libraries 
to refuse to used named values in batches when the server is a version that 
doesn't support CASSANDRA-10247 as well as to encode using that approach (or 
some other).

> 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: CQL
>Reporter: Michael Penick
>Assignee: Ariel Weisberg
>  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] [Commented] (CASSANDRA-10603) Fix CQL syntax errors in upgrade_through_versions_test

[Andrew Hust (JIRA)]

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

Andrew Hust commented on CASSANDRA-10603:
-

Fixed with PR: https://github.com/riptano/cassandra-dtest/pull/633

> Fix CQL syntax errors in upgrade_through_versions_test
> --
>
> Key: CASSANDRA-10603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10603
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Andrew Hust
>
> In the {{cassandra_upgrade_2.1_to_3.0_proto_v3}} upgrade tests on CassCI, 
> some of the tests are failing with the following error:
> {code}
> 
> {code}
> The tests that fail this way [(at least as of this 
> run)|http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/]
>  are the following:
> {code}
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.parallel_upgrade_with_internode_ssl_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.parallel_upgrade_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.bootstrap_multidc_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_2_1_HEAD.bootstrap_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.bootstrap_multidc_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.bootstrap_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.parallel_upgrade_test
> upgrade_through_versions_test.TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.parallel_upgrade_with_internode_ssl_test
> {code}
> There may be other tests in other protocol upgrade jobs that fail this way, 
> but I haven't dug through yet to see.
> Assigning to [~rhatch] since, afaik, you're the most likely person to 
> understand the problem. Feel free to reassign, of course.



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

[jira] [Assigned] (CASSANDRA-10622) Add all options in cqlshrc sample as commented out choices

[Brandon Williams (JIRA)]

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

Brandon Williams reassigned CASSANDRA-10622:


Assignee: Tyler Hobbs

> Add all options in cqlshrc sample as commented out choices
> --
>
> Key: CASSANDRA-10622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10622
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Lorina Poland
>Assignee: Tyler Hobbs
>Priority: Minor
>
> All the options should be added to the sample cqlshrc file as commented out 
> options. This will provide users with the 15 or so options that can be used 
> in cqlshrc.



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10246:


It seems like existing clients will never be able to use named values in 
batches without updating the protocol. There is no way to correctly decode far 
enough to get to the flags to find out how to correctly decode the lists.

It seems like there is nothing we can do to save old clients and give them a 
good error.

What is the story with protocol changes like this? It seems like we need a 
version bump otherwise newer versions of the client library can't identify that 
the server is unable to correctly handle the suggestion in CASSANDRA-10247.

Speaking of clients this also means we need to update all the client libraries 
to refuse to used named values in batches when the server is a version that 
doesn't support CASSANDRA-10247 as well as to encode using that approach (or 
some other).

> 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: CQL
>Reporter: Michael Penick
>Assignee: Ariel Weisberg
>  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] [Commented] (CASSANDRA-9328) WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration taking MUCH less than cas_contention_timeout_in_ms

[Aaron Whiteside (JIRA)]

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

Aaron Whiteside commented on CASSANDRA-9328:


Completely agree here, if you need to add some sort of versioning/transaction 
id to detect changes then using CAS/LWT is pointless and you can achieve the 
same result with Cassandra's default eventual consistency behavior + 
versioning/transaction id. 

Which means CAS/LWT are completely broken and meaningless.

> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms
> 
>
> Key: CASSANDRA-9328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9328
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aaron Whiteside
>Priority: Critical
> Fix For: 2.1.x
>
> Attachments: CassandraLWTTest.java, CassandraLWTTest2.java
>
>
> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms.
> Unit test attached, run against a 3 node cluster running 2.1.5.
> If you reduce the threadCount to 1, you never see a WriteTimeoutException. If 
> the WTE is due to not being able to communicate with other nodes, why does 
> the concurrency >1 cause inter-node communication to fail?



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg edited comment on CASSANDRA-10422 at 10/29/15 9:22 PM:
--

--[~krummas] do we do incremental repair + subrange repair outside of that path 
via nodetool? 

I am not following why additional work is necessary if there is no path to 
start this problematic repair combination? When you say full repair what do you 
mean? Not a repair of a subrange? I thought that is the situation where we want 
to anti-compact.--

Nevermind figured out what you are talking about.






was (Author: aweisberg):
[~krummas] do we do incremental repair + subrange repair outside of that path 
via nodetool? 

I am not following why additional work is necessary if there is no path to 
start this problematic repair combination? When you say full repair what do you 
mean? Not a repair of a subrange? I thought that is the situation where we want 
to anti-compact.



> 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
>Assignee: Ariel Weisberg
> 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] [Commented] (CASSANDRA-9328) WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration taking MUCH less than cas_contention_timeout_in_ms

[Aaron Whiteside (JIRA)]

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

Aaron Whiteside commented on CASSANDRA-9328:


Personally I think this is acceptable. As you will retry the CAS operation and 
it will fail again (already applied, or someone else won).

The behavior should be correct under ideal conditions, currently it's 
non-deterministic under ideal conditions.

> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms
> 
>
> Key: CASSANDRA-9328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9328
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aaron Whiteside
>Priority: Critical
> Fix For: 2.1.x
>
> Attachments: CassandraLWTTest.java, CassandraLWTTest2.java
>
>
> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms.
> Unit test attached, run against a 3 node cluster running 2.1.5.
> If you reduce the threadCount to 1, you never see a WriteTimeoutException. If 
> the WTE is due to not being able to communicate with other nodes, why does 
> the concurrency >1 cause inter-node communication to fail?



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg edited comment on CASSANDRA-10422 at 10/29/15 9:22 PM:
--

--[~krummas] do we do incremental repair + subrange repair outside of that path 
via nodetool?--

--I am not following why additional work is necessary if there is no path to 
start this problematic repair combination? When you say full repair what do you 
mean? Not a repair of a subrange? I thought that is the situation where we want 
to anti-compact.--

Nevermind figured out what you are talking about.






was (Author: aweisberg):
--[~krummas] do we do incremental repair + subrange repair outside of that path 
via nodetool? 

I am not following why additional work is necessary if there is no path to 
start this problematic repair combination? When you say full repair what do you 
mean? Not a repair of a subrange? I thought that is the situation where we want 
to anti-compact.--

Nevermind figured out what you are talking about.





> 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
>Assignee: Ariel Weisberg
> 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] [Resolved] (CASSANDRA-10527) Specify encoding=utf-8 in javac task

[Robert Stupp (JIRA)]

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

Robert Stupp resolved CASSANDRA-10527.
--
Resolution: Duplicate

> Specify encoding=utf-8 in javac task
> 
>
> Key: CASSANDRA-10527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10527
> Project: Cassandra
>  Issue Type: Task
> Environment: Windows with MS949
>Reporter: Jin Kwon
>Priority: Trivial
>
> some {{javac}} tasks omitting {{encoding}} attribute fail in Windows.
> {code}
> build-test:
> [javac] Compiling 374 source files to 
> E:\gitcl\git.apache.org\cassandra\build\test\classes
> [javac] 
> E:\gitcl\git.apache.org\cassandra\test\unit\org\apache\cassandra\security\CipherFactoryTest.java:22:
>  error: unmappable character for encoding MS949
> [javac]"?봊ntroibo ad altare Dei.";
> [javac] ^
> [javac] 1 error
> {code}



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

[1/3] cassandra git commit: Fix debian package build

[brandonwilliams]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 3d986936f -> ad007f012
  refs/heads/trunk ef1b4c0f5 -> 551b68e0d


Fix debian package build

Patch by Michael Shuler, reviewed by brandonwilliams for CASSANDRA-10620


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

Branch: refs/heads/cassandra-3.0
Commit: ad007f01243898cc8a7bed87279064115a57371f
Parents: 3d98693
Author: Brandon Williams 
Authored: Thu Oct 29 16:06:21 2015 -0500
Committer: Brandon Williams 
Committed: Thu Oct 29 16:06:21 2015 -0500

--
 debian/cassandra-tools.install | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ad007f01/debian/cassandra-tools.install
--
diff --git a/debian/cassandra-tools.install b/debian/cassandra-tools.install
index 4d19df9..957f2c0 100644
--- a/debian/cassandra-tools.install
+++ b/debian/cassandra-tools.install
@@ -1,6 +1,6 @@
-tools/bin/sstableofflinerelevel usr/bin
+tools/bin/sstableexpiredblockers usr/bin
 tools/bin/sstablelevelreset usr/bin
 tools/bin/sstablemetadata usr/bin
+tools/bin/sstableofflinerelevel usr/bin
 tools/bin/sstablerepairedset usr/bin
 tools/bin/sstablesplit usr/bin
-tools/bin/token-generator usr/bin

[2/3] cassandra git commit: Fix debian package build

[brandonwilliams]

Fix debian package build

Patch by Michael Shuler, reviewed by brandonwilliams for CASSANDRA-10620


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

Branch: refs/heads/trunk
Commit: ad007f01243898cc8a7bed87279064115a57371f
Parents: 3d98693
Author: Brandon Williams 
Authored: Thu Oct 29 16:06:21 2015 -0500
Committer: Brandon Williams 
Committed: Thu Oct 29 16:06:21 2015 -0500

--
 debian/cassandra-tools.install | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ad007f01/debian/cassandra-tools.install
--
diff --git a/debian/cassandra-tools.install b/debian/cassandra-tools.install
index 4d19df9..957f2c0 100644
--- a/debian/cassandra-tools.install
+++ b/debian/cassandra-tools.install
@@ -1,6 +1,6 @@
-tools/bin/sstableofflinerelevel usr/bin
+tools/bin/sstableexpiredblockers usr/bin
 tools/bin/sstablelevelreset usr/bin
 tools/bin/sstablemetadata usr/bin
+tools/bin/sstableofflinerelevel usr/bin
 tools/bin/sstablerepairedset usr/bin
 tools/bin/sstablesplit usr/bin
-tools/bin/token-generator usr/bin

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

[brandonwilliams]

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

Branch: refs/heads/trunk
Commit: 551b68e0dedc2a6b03b49c15d81a5c7ded7c7144
Parents: ef1b4c0 ad007f0
Author: Brandon Williams 
Authored: Thu Oct 29 16:07:14 2015 -0500
Committer: Brandon Williams 
Committed: Thu Oct 29 16:07:14 2015 -0500

--
 debian/cassandra-tools.install | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10422:


[~krummas] do we do incremental repair + subrange repair outside of that path 
via nodetool? 

I am not following why additional work is necessary if there is no path to 
start this problematic repair combination? When you say full repair what do you 
mean? Not a repair of a subrange? I thought that is the situation where we want 
to anti-compact.



> 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
>Assignee: Ariel Weisberg
> 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] [Commented] (CASSANDRA-10365) Consider storing types by their CQL names in schema tables instead of fully-qualified internal class names

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-10365:
--

Yea - that's completely broken (until CASSANDRA-10617)

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



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg edited comment on CASSANDRA-10422 at 10/29/15 9:24 PM:
--

[~krummas] do we do incremental repair + subrange repair outside of that path 
via nodetool?

I am not following why additional work is necessary if there is no path to 
start this problematic repair combination? The isIncremental flag is propagated 
to the other nodes, and that is what drives anti-compaction on other nodes 
right? So if we don't allow a repair to start with the combination of 
incremental and subrange there shouldn't be an issue.

When you say full repair what do you mean? Not a repair of a subrange? I 
thought that is the situation where we want to anti-compact.







was (Author: aweisberg):
--[~krummas] do we do incremental repair + subrange repair outside of that path 
via nodetool?--

--I am not following why additional work is necessary if there is no path to 
start this problematic repair combination? When you say full repair what do you 
mean? Not a repair of a subrange? I thought that is the situation where we want 
to anti-compact.--

Nevermind figured out what you are talking about.





> 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
>Assignee: Ariel Weisberg
> 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] [Commented] (CASSANDRA-10246) Named values don't work with batches

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10246:


[~slebresne] [~iamaleksey] [~JoshuaMcKenzie]
How are we going to handle a version bump to the client protocol in tick-tock? 
Is the plan that 3.1 will bump the number and the server will start handling 
batches with named values correctly?

> 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: CQL
>Reporter: Michael Penick
>Assignee: Ariel Weisberg
>  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] [Commented] (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:comment-tabpanel=14981360#comment-14981360
 ] 

Aleksey Yeschenko commented on CASSANDRA-10246:
---

[~aweisberg] We create a new version (next one will be 5, CASSANDRA-9362), and 
fix it there. Clients that requested for v5 native protocol on connect will use 
it, and for them the issue will be fixed. Clients connecting using older 
versions (4 and down) will not have the fix.

> 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: CQL
>Reporter: Michael Penick
>Assignee: Ariel Weisberg
>  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-10621) Error while bootstraping a new node with Materialized Views

[Alan Boudreault (JIRA)]

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

Alan Boudreault updated CASSANDRA-10621:

Attachment: system.log

[~jkni] here is the system.log

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

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

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10365:
--
Summary: Store types by their CQL names in schema tables instead of 
fully-qualified internal class names  (was: Consider storing types by their CQL 
names in schema tables instead of fully-qualified internal class names)

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



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

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

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-10341:


Thanks for update.
It is getting close, but we need to handle counter cache and row cache each 
since we can use both.
Right now, your patch is clearing either one of them.

> Streaming does not guarantee cache invalidation
> ---
>
> Key: CASSANDRA-10341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10341
> Project: Cassandra
>  Issue Type: Bug
>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] [Commented] (CASSANDRA-10341) Streaming does not guarantee cache invalidation

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10341:
-

Tests seem OK (failures in pair with main branches)

> Streaming does not guarantee cache invalidation
> ---
>
> Key: CASSANDRA-10341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10341
> Project: Cassandra
>  Issue Type: Bug
>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] [Resolved] (CASSANDRA-10609) MV performance regression

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs resolved CASSANDRA-10609.
-
   Resolution: Duplicate
Fix Version/s: (was: 3.0.0)

> MV performance regression
> -
>
> Key: CASSANDRA-10609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10609
> Project: Cassandra
>  Issue Type: Bug
> Environment: EC2
>Reporter: Alan Boudreault
>Assignee: Tyler Hobbs
>Priority: Critical
>
> I've noticed an important MV performance regression that has been introduced 
> in 3.0.0-rc1. The issue has been introduced by CASSANDRA-9664.
> * I'm using mvbench to test with RF=3
> * I confirm it's not a driver issue.
> {code}
> EC2 RF=3 (i2.2xlarge, also tried on i2.4xlarge)
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100 
> --num-artists 1 -n 50 --endpoint node1"
> 3.0.0-beta2 (alpha2 java driver)
> ---
> total
>  count = 461601
>  mean rate = 1923.21 calls/second
>  1-minute rate = 1937.82 calls/second
>  5-minute rate = 1424.09 calls/second
> 15-minute rate = 1058.28 calls/second
>min = 1.90 milliseconds
>max = 3707.76 milliseconds
>   mean = 516.42 milliseconds
> stddev = 457.41 milliseconds
> median = 390.07 milliseconds
>   75% <= 775.95 milliseconds
>   95% <= 1417.67 milliseconds
>   98% <= 1728.05 milliseconds
>   99% <= 1954.55 milliseconds
> 99.9% <= 2566.91 milliseconds
> 3.0.0-rc1 (alpha3 java driver)
> -
> total
>  count = 310373
>  mean rate = 272.25 calls/second
>  1-minute rate = 0.00 calls/second
>  5-minute rate = 45.47 calls/second
> 15-minute rate = 295.94 calls/second
>min = 1.05 milliseconds
>max = 10468.98 milliseconds
>   mean = 492.99 milliseconds
> stddev = 510.42 milliseconds
> median = 281.02 milliseconds
>   75% <= 696.25 milliseconds
>   95% <= 1434.45 milliseconds
>   98% <= 1820.33 milliseconds
>   99% <= 2080.37 milliseconds
> 99.9% <= 4362.08 milliseconds
> {code}



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10422:


Looks like the 2.2 code merges to 3.0 and trunk without issue. Tests running 
now.
|[2.1 
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.1...aweisberg:CASSANDRA-10422-2.1?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10422-2.1-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10422-2.1-dtest/]|
|[2.2 
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.2...aweisberg:CASSANDRA-10422-2.2?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10422-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10422-2.2-dtest/]|

> 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
>Assignee: Ariel Weisberg
> 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] [Commented] (CASSANDRA-10541) cqlshlib tests cannot run on Windows

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10541:
-

I fixed the symlink problem quite easily with this 
[commit|https://github.com/pauloricardomg/cassandra/commit/a8b59ca76d454b6d5eedf49145833e4cb3ed7632],
 then I hit a dead end: the cqlsh tests are all based on the 
[pty|https://docs.python.org/2/library/pty.html] *linux-only* module to 
interact with the cqlsh terminal, and I didn't find any suitable replacement on 
WIndows. So, I see 3 bad options here:
# Do our own interacting with the shell via python ctypes and Win32 API 
(dangerous territory)
# Reimplement the tests using deprecated/unmaintained and possibly broken 
libraries [winpexpect|https://bitbucket.org/geertj/winpexpect/overview] or 
[WExpect|https://gist.github.com/anthonyeden/8488763]
# Run interactive pseudo-terminal based cqlsh tests only on linux, and use 
[cqlsh 
dtests|https://github.com/riptano/cassandra-dtest/tree/master/cqlsh_tests] for 
non-interactive tests on both platforms.

Any suggestions [~JoshuaMcKenzie] ?

> cqlshlib tests cannot run on Windows
> 
>
> Key: CASSANDRA-10541
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10541
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: cqlsh
>
> If I try to run the {{cqlshlib}} tests on Windows, I got the following error:
> {quote}
> ==
> ERROR: Failure: AttributeError ('module' object has no attribute 'symlink')
> --
> Traceback (most recent call last):
>   File "C:\Python27\lib\site-packages\nose\loader.py", line 414, in 
> loadTestsFromName
> addr.filename, addr.module)
>   File "C:\Python27\lib\site-packages\nose\importer.py", line 47, in 
> importFromPath
> return self.importFromDir(dir_path, fqname)
>   File "C:\Python27\lib\site-packages\nose\importer.py", line 94, in 
> importFromDir
> mod = load_module(part_fqname, fh, filename, desc)
>   File "[...]\pylib\cqlshlib\test\__init__.py", line 17, in 
> from .cassconnect import create_test_db, remove_test_db
>   File "[...]\pylib\cqlshlib\test\cassconnect.py", line 22, in 
> from .basecase import cql, cqlsh, cqlshlog, TEST_HOST, TEST_PORT, rundir
>   File "[...]\pylib\cqlshlib\test\basecase.py", line 43, in 
> os.symlink(path_to_cqlsh, modulepath)
> AttributeError: 'module' object has no attribute 'symlink'
> --
> Ran 1 test in 0.002s
> FAILED (errors=1)
> {quote}
> The problem comes from the fact tha Windows has no support for symlinks.



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

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

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10246:


[~iamaleksey] I don't understand the fix versions for this issue. It's "not a 
bug" in previous versions it simply doesn't work and the Java client library at 
least doesn't use named values at all. Native protocol v5 has a fix version of 
3.x not 2.1.x or 2.2.x so is the fix version here incorrect?

Should this or CASSANDRA-10247 be linked/subtasked to CASSANDRA-9362?

> 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: CQL
>Reporter: Michael Penick
>Assignee: Ariel Weisberg
>  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] [Commented] (CASSANDRA-8884) Opening a non-system keyspace before first accessing the system keyspace results in deadlock

[Xu Zhongxing (JIRA)]

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

Xu Zhongxing commented on CASSANDRA-8884:
-

Hi Piotr,

I had the same problem. After adding Keyspace.open("system"), the program does 
not exit.
What do I need to do to "close" the Keyspace?

> Opening a non-system keyspace before first accessing the system keyspace 
> results in deadlock
> 
>
> Key: CASSANDRA-8884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8884
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Piotr Kołaczkowski
>Assignee: Benjamin Lerer
> Attachments: bulk.jstack
>
>
> I created a writer like this:
> {code}
> val writer = CQLSSTableWriter.builder()
>   .forTable(tableDef.cql)
>   .using(insertStatement)
>   .withPartitioner(partitioner)
>   .inDirectory(outputDirectory)
>   .withBufferSizeInMB(bufferSizeInMB)
>   .build()
> {code}
> Then I'm trying to write a row with {{addRow}} and it blocks forever.
> Everything related to {{CQLSSTableWriter}}, including its creation, is 
> happening in only one thread.
> {noformat}
> "SSTableBatchOpen:3" daemon prio=10 tid=0x7f4b399d7000 nid=0x4778 waiting 
> for monitor entry [0x7f4b240a7000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
>   - waiting to lock <0xe35fd6d0> (a java.lang.Class for 
> org.apache.cassandra.db.Keyspace)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
>   at 
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   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:745)
> "SSTableBatchOpen:2" daemon prio=10 tid=0x7f4b399e7800 nid=0x4777 waiting 
> for monitor entry [0x7f4b23ca3000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
>   - waiting to lock <0xe35fd6d0> (a java.lang.Class for 
> org.apache.cassandra.db.Keyspace)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
>   at 
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   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:745)
> "SSTableBatchOpen:1" daemon prio=10 tid=0x7f4b399e7000 nid=0x4776 waiting 
> for monitor entry 

[jira] [Commented] (CASSANDRA-8884) Opening a non-system keyspace before first accessing the system keyspace results in deadlock

[Xu Zhongxing (JIRA)]

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

Xu Zhongxing commented on CASSANDRA-8884:
-

Hi Piotr,

I had the same problem. After adding Keyspace.open("system"), the program does 
not exit.
What do I need to do to "close" the Keyspace?

> Opening a non-system keyspace before first accessing the system keyspace 
> results in deadlock
> 
>
> Key: CASSANDRA-8884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8884
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Piotr Kołaczkowski
>Assignee: Benjamin Lerer
> Attachments: bulk.jstack
>
>
> I created a writer like this:
> {code}
> val writer = CQLSSTableWriter.builder()
>   .forTable(tableDef.cql)
>   .using(insertStatement)
>   .withPartitioner(partitioner)
>   .inDirectory(outputDirectory)
>   .withBufferSizeInMB(bufferSizeInMB)
>   .build()
> {code}
> Then I'm trying to write a row with {{addRow}} and it blocks forever.
> Everything related to {{CQLSSTableWriter}}, including its creation, is 
> happening in only one thread.
> {noformat}
> "SSTableBatchOpen:3" daemon prio=10 tid=0x7f4b399d7000 nid=0x4778 waiting 
> for monitor entry [0x7f4b240a7000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
>   - waiting to lock <0xe35fd6d0> (a java.lang.Class for 
> org.apache.cassandra.db.Keyspace)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
>   at 
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   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:745)
> "SSTableBatchOpen:2" daemon prio=10 tid=0x7f4b399e7800 nid=0x4777 waiting 
> for monitor entry [0x7f4b23ca3000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
>   - waiting to lock <0xe35fd6d0> (a java.lang.Class for 
> org.apache.cassandra.db.Keyspace)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
>   at 
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   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:745)
> "SSTableBatchOpen:1" daemon prio=10 tid=0x7f4b399e7000 nid=0x4776 waiting 
> for monitor entry 

[jira] [Issue Comment Deleted] (CASSANDRA-8884) Opening a non-system keyspace before first accessing the system keyspace results in deadlock

[Xu Zhongxing (JIRA)]

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

Xu Zhongxing updated CASSANDRA-8884:

Comment: was deleted

(was: Hi Piotr,

I had the same problem. After adding Keyspace.open("system"), the program does 
not exit.
What do I need to do to "close" the Keyspace?)

> Opening a non-system keyspace before first accessing the system keyspace 
> results in deadlock
> 
>
> Key: CASSANDRA-8884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8884
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Piotr Kołaczkowski
>Assignee: Benjamin Lerer
> Attachments: bulk.jstack
>
>
> I created a writer like this:
> {code}
> val writer = CQLSSTableWriter.builder()
>   .forTable(tableDef.cql)
>   .using(insertStatement)
>   .withPartitioner(partitioner)
>   .inDirectory(outputDirectory)
>   .withBufferSizeInMB(bufferSizeInMB)
>   .build()
> {code}
> Then I'm trying to write a row with {{addRow}} and it blocks forever.
> Everything related to {{CQLSSTableWriter}}, including its creation, is 
> happening in only one thread.
> {noformat}
> "SSTableBatchOpen:3" daemon prio=10 tid=0x7f4b399d7000 nid=0x4778 waiting 
> for monitor entry [0x7f4b240a7000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
>   - waiting to lock <0xe35fd6d0> (a java.lang.Class for 
> org.apache.cassandra.db.Keyspace)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
>   at 
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   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:745)
> "SSTableBatchOpen:2" daemon prio=10 tid=0x7f4b399e7800 nid=0x4777 waiting 
> for monitor entry [0x7f4b23ca3000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
>   - waiting to lock <0xe35fd6d0> (a java.lang.Class for 
> org.apache.cassandra.db.Keyspace)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
>   at 
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
>   at 
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   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:745)
> "SSTableBatchOpen:1" daemon prio=10 tid=0x7f4b399e7000 nid=0x4776 waiting 
> for monitor entry 

[jira] [Created] (CASSANDRA-10618) Read ghost data

[ZhaoYang (JIRA)]

ZhaoYang created CASSANDRA-10618:


 Summary: Read ghost data
 Key: CASSANDRA-10618
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10618
 Project: Cassandra
  Issue Type: Bug
 Environment: Windows 7, Cassandra 2.1.2
Reporter: ZhaoYang


In a table( pk, ck, value) with 1 partition key and 1 clustering key. 

SELECT * FROM table where pk='PK1' AND ck1='CK1' (full primary keys) -> will 
return a row that doesn't appear in range scan query (SELECT * FROM table where 
pk='PK1').

I tested it with Java Driver 2.1.5 as well as DevCenter. Our environment has 
only 1 node and replication factor 1. It's our development DB, multiple 
developers are accessing it. And we are using client-side timestamp generator.

If I use nodetool to compact this table, this ghost data will disappear. 

What can be the cause? because of un-order timestamp?

Thank you very much.





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

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

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10608:
--

I would strongly suspect that clustering columns are also affected so I think 
the patch should use {{def.isPrimaryKeyColumn()}} rather than 
{{def.isPartitionKey()}}.

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



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

[jira] [Commented] (CASSANDRA-10513) Update cqlsh for new driver execution API

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10513:
--

Are we sure we want to upgrade the python driver to an alpha version in 2.2 
(assuming here that cassandra-driver-internal-only-3.0.0a2.post0-95c6008.zip 
means alpha2)? That is, is there a tangible reason to do that upgrade in 2.2? 
If not, I'm in favor of sticking to 3.0.

> Update cqlsh for new driver execution API
> -
>
> Key: CASSANDRA-10513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10513
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Adam Holmberg
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: cqlsh
> Fix For: 2.2.x, 3.0.x
>
> Attachments: 10513-2.1.txt, 10513-2.2.txt, 10513.txt
>
>
> The 3.0 Python driver will have a few tweaks to the execution API. We'll need 
> to update cqlsh in a couple of minor ways.
> [Results are always returned as an iterable 
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-368]
> [Trace data is always attached to the 
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-318] (instead of 
> being attached to a statement)



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

cassandra git commit: For CASSANDRA-9526, change line separator to the platform independent version when formatting strings in nodetool

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 83fcc926e -> b154622b6


For CASSANDRA-9526, change line separator to the platform independent version 
when formatting strings in nodetool


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

Branch: refs/heads/cassandra-2.2
Commit: b154622b6cc78db4cbd1c4ce0c3ad34271d07a29
Parents: 83fcc92
Author: Ariel Weisberg 
Authored: Wed Oct 21 15:12:40 2015 -0400
Committer: Sylvain Lebresne 
Committed: Thu Oct 29 10:37:54 2015 +0100

--
 .../org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b154622b/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
--
diff --git 
a/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java 
b/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
index 72c109a..3c0303d 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
@@ -34,12 +34,12 @@ public class FailureDetectorInfo extends NodeToolCmd
 public void execute(NodeProbe probe)
 {
 TabularData data = probe.getFailureDetectorPhilValues();
-System.out.printf("%10s,%16s\n", "Endpoint", "Phi");
+System.out.printf("%10s,%16s%n", "Endpoint", "Phi");
 for (Object o : data.keySet())
 {
 @SuppressWarnings({ "rawtypes", "unchecked" })
 CompositeData datum = data.get(((List) o).toArray(new 
Object[((List) o).size()]));
-System.out.printf("%10s,%16.8f\n",datum.get("Endpoint"), 
datum.get("PHI"));
+System.out.printf("%10s,%16.8f%n",datum.get("Endpoint"), 
datum.get("PHI"));
 }
 }
 }

[1/2] cassandra git commit: For CASSANDRA-9526, change line separator to the platform independent version when formatting strings in nodetool

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 4b47d711e -> a8014bb7e


For CASSANDRA-9526, change line separator to the platform independent version 
when formatting strings in nodetool


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

Branch: refs/heads/cassandra-3.0
Commit: b154622b6cc78db4cbd1c4ce0c3ad34271d07a29
Parents: 83fcc92
Author: Ariel Weisberg 
Authored: Wed Oct 21 15:12:40 2015 -0400
Committer: Sylvain Lebresne 
Committed: Thu Oct 29 10:37:54 2015 +0100

--
 .../org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b154622b/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
--
diff --git 
a/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java 
b/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
index 72c109a..3c0303d 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
@@ -34,12 +34,12 @@ public class FailureDetectorInfo extends NodeToolCmd
 public void execute(NodeProbe probe)
 {
 TabularData data = probe.getFailureDetectorPhilValues();
-System.out.printf("%10s,%16s\n", "Endpoint", "Phi");
+System.out.printf("%10s,%16s%n", "Endpoint", "Phi");
 for (Object o : data.keySet())
 {
 @SuppressWarnings({ "rawtypes", "unchecked" })
 CompositeData datum = data.get(((List) o).toArray(new 
Object[((List) o).size()]));
-System.out.printf("%10s,%16.8f\n",datum.get("Endpoint"), 
datum.get("PHI"));
+System.out.printf("%10s,%16.8f%n",datum.get("Endpoint"), 
datum.get("PHI"));
 }
 }
 }

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

[slebresne]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: a8014bb7ec401d2517e0333c93dd6abb68479c4a
Parents: 4b47d71 b154622
Author: Sylvain Lebresne 
Authored: Thu Oct 29 10:39:05 2015 +0100
Committer: Sylvain Lebresne 
Committed: Thu Oct 29 10:39:05 2015 +0100

--
 .../org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--

[jira] [Commented] (CASSANDRA-10513) Update cqlsh for new driver execution API

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10513:
-

My understanding is that we also need the latest driver version for 
CASSANDRA-10390 (to include the fix for 
[PYTHON-413|https://datastax-oss.atlassian.net/browse/PYTHON-413]). 
See [this 
comment|https://datastax-oss.atlassian.net/browse/PYTHON-413?focusedCommentId=24609=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24609
 ] in particular.

> Update cqlsh for new driver execution API
> -
>
> Key: CASSANDRA-10513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10513
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Adam Holmberg
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: cqlsh
> Fix For: 2.2.x, 3.0.x
>
> Attachments: 10513-2.1.txt, 10513-2.2.txt, 10513.txt
>
>
> The 3.0 Python driver will have a few tweaks to the execution API. We'll need 
> to update cqlsh in a couple of minor ways.
> [Results are always returned as an iterable 
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-368]
> [Trace data is always attached to the 
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-318] (instead of 
> being attached to a statement)



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

[jira] [Commented] (CASSANDRA-4782) Commitlog not replayed after restart

[JIRA]

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

Hervé Toulan commented on CASSANDRA-4782:
-

Hi Robert,

1) Thank you, I did know that, I almost never encountered issue with Cassandra 
(even with the 1.1.0)
2) That's what I thought. I plan to upgrade to 1.2.9.
3) Now, I lose data on all 1.1.0 platforms if I insert data and reboot servers 
(ring composed by 2 servers)... 
I can't believe we never saw that before. 
I am not sure I understand how Cassandra works with System.nanoTime() and 
replay position but couold we imagine current timestamp reaches a value for 
wich this bug is now reproducibke systematically?? 

Anyway you're right, and upgrade is mandatory.


Hervé
 

> Commitlog not replayed after restart
> 
>
> Key: CASSANDRA-4782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4782
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Fabien Rousseau
>Assignee: Jonathan Ellis
>Priority: Critical
> Fix For: 1.1.6
>
> Attachments: 4782.txt
>
>
> It seems that there are two corner cases where commitlog is not replayed 
> after a restart :
>  - After a reboot of a server + restart of cassandra (1.1.0 to 1.1.4)
>  - After doing an upgrade from cassandra 1.1.X to cassandra 1.1.5
> This is due to the fact that the commitlog segment id should always be an  
> incrementing number (see this condition : 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L247
>  )
> But this assertion can be broken :
> In the first case, it is generated by System.nanoTime() but it seems that 
> System.nanoTime() is using the boot time as the base/reference (at least on 
> java6 & linux), thus after a reboot, System.nanoTime() can return a lower 
> number than before the reboot (and the javadoc says the reference is a 
> relative point in time...)
> In the second case, this was introduced by #4601 (which changes 
> System.nanoTime() by System.currentTimeMillis() thus people starting with 
> 1.1.5 are safe)
> This could explain the following tickets : #4741 and #4481



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

[jira] [Commented] (CASSANDRA-10070) Automatic repair scheduling

[Marcus Olsson (JIRA)]

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

Marcus Olsson commented on CASSANDRA-10070:
---

Just to clarify, the automatic scheduling is done on a node level. The way it 
distributes is by "competing" with the other nodes with regards to who has the 
highest need for a repair and then uses a CAS lock to obtain the right to run a 
repair. So the repair process would continue during upgrade, but I assume it 
would fail as it is right now and that the repair job would be retried. The 
problem here is that this job would try to run until it succeeded since it has 
the highest priority, even if there are other repair jobs that could run (e.g. 
if only a part of the cluster was upgraded).

To allow repairs during an upgrade scenario I think we need to have both 
CASSANDRA-7530 & CASSANDRA-8110 in place.
Until then I see two options:
* Make it possible to "pause" all repair scheduling, e.g. during upgrade 
scenarios.
* Make the repair job recognize that it cannot run at this time and allow 
another repair job to run instead.

I wouldn't mind implementing both options, since there might be scenarios when 
both are needed, even if we can repair between versions.

> Automatic repair scheduling
> ---
>
> Key: CASSANDRA-10070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10070
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Minor
> Fix For: 3.x
>
>
> Scheduling and running repairs in a Cassandra cluster is most often a 
> required task, but this can both be hard for new users and it also requires a 
> bit of manual configuration. There are good tools out there that can be used 
> to simplify things, but wouldn't this be a good feature to have inside of 
> Cassandra? To automatically schedule and run repairs, so that when you start 
> up your cluster it basically maintains itself in terms of normal 
> anti-entropy, with the possibility for manual configuration.



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

[jira] [Issue Comment Deleted] (CASSANDRA-10070) Automatic repair scheduling

[Marcus Olsson (JIRA)]

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

Marcus Olsson updated CASSANDRA-10070:
--
Comment: was deleted

(was: Just to clarify, the automatic scheduling is done on a node level. The 
way it distributes is by "competing" with the other nodes with regards to who 
has the highest need for a repair and then uses a CAS lock to obtain the right 
to run a repair. So the repair process would continue during upgrade, but I 
assume it would fail as it is right now and that the repair job would be 
retried. The problem here is that this job would try to run until it succeeded 
since it has the highest priority, even if there are other repair jobs that 
could run (e.g. if only a part of the cluster was upgraded).

To allow repairs during an upgrade scenario I think we need to have both 
CASSANDRA-7530 & CASSANDRA-8110 in place.
Until then I see two options:
* Make it possible to "pause" all repair scheduling, e.g. during upgrade 
scenarios.
* Make the repair job recognize that it cannot run at this time and allow 
another repair job to run instead.

I wouldn't mind implementing both options, since there might be scenarios when 
both are needed, even if we can repair between versions.)

> Automatic repair scheduling
> ---
>
> Key: CASSANDRA-10070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10070
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Minor
> Fix For: 3.x
>
>
> Scheduling and running repairs in a Cassandra cluster is most often a 
> required task, but this can both be hard for new users and it also requires a 
> bit of manual configuration. There are good tools out there that can be used 
> to simplify things, but wouldn't this be a good feature to have inside of 
> Cassandra? To automatically schedule and run repairs, so that when you start 
> up your cluster it basically maintains itself in terms of normal 
> anti-entropy, with the possibility for manual configuration.



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

[jira] [Commented] (CASSANDRA-10070) Automatic repair scheduling

[Marcus Olsson (JIRA)]

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

Marcus Olsson commented on CASSANDRA-10070:
---

Just to clarify, the automatic scheduling is done on a node level. The way it 
distributes is by "competing" with the other nodes with regards to who has the 
highest need for a repair and then uses a CAS lock to obtain the right to run a 
repair. So the repair process would continue during upgrade, but I assume it 
would fail as it is right now and that the repair job would be retried. The 
problem here is that this job would try to run until it succeeded since it has 
the highest priority, even if there are other repair jobs that could run (e.g. 
if only a part of the cluster was upgraded).

To allow repairs during an upgrade scenario I think we need to have both 
CASSANDRA-7530 & CASSANDRA-8110 in place.
Until then I see two options:
* Make it possible to "pause" all repair scheduling, e.g. during upgrade 
scenarios.
* Make the repair job recognize that it cannot run at this time and allow 
another repair job to run instead.

I wouldn't mind implementing both options, since there might be scenarios when 
both are needed, even if we can repair between versions.

> Automatic repair scheduling
> ---
>
> Key: CASSANDRA-10070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10070
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Minor
> Fix For: 3.x
>
>
> Scheduling and running repairs in a Cassandra cluster is most often a 
> required task, but this can both be hard for new users and it also requires a 
> bit of manual configuration. There are good tools out there that can be used 
> to simplify things, but wouldn't this be a good feature to have inside of 
> Cassandra? To automatically schedule and run repairs, so that when you start 
> up your cluster it basically maintains itself in terms of normal 
> anti-entropy, with the possibility for manual configuration.



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

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

[slebresne]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: a8014bb7ec401d2517e0333c93dd6abb68479c4a
Parents: 4b47d71 b154622
Author: Sylvain Lebresne 
Authored: Thu Oct 29 10:39:05 2015 +0100
Committer: Sylvain Lebresne 
Committed: Thu Oct 29 10:39:05 2015 +0100

--
 .../org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--

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

[slebresne]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: 9df2139412db6c0290f9206184aba601cebd027b
Parents: 0df4953 a8014bb
Author: Sylvain Lebresne 
Authored: Thu Oct 29 10:39:44 2015 +0100
Committer: Sylvain Lebresne 
Committed: Thu Oct 29 10:39:44 2015 +0100

--
 .../org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--

[1/3] cassandra git commit: For CASSANDRA-9526, change line separator to the platform independent version when formatting strings in nodetool

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 0df49539f -> 9df213941


For CASSANDRA-9526, change line separator to the platform independent version 
when formatting strings in nodetool


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

Branch: refs/heads/trunk
Commit: b154622b6cc78db4cbd1c4ce0c3ad34271d07a29
Parents: 83fcc92
Author: Ariel Weisberg 
Authored: Wed Oct 21 15:12:40 2015 -0400
Committer: Sylvain Lebresne 
Committed: Thu Oct 29 10:37:54 2015 +0100

--
 .../org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b154622b/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
--
diff --git 
a/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java 
b/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
index 72c109a..3c0303d 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/FailureDetectorInfo.java
@@ -34,12 +34,12 @@ public class FailureDetectorInfo extends NodeToolCmd
 public void execute(NodeProbe probe)
 {
 TabularData data = probe.getFailureDetectorPhilValues();
-System.out.printf("%10s,%16s\n", "Endpoint", "Phi");
+System.out.printf("%10s,%16s%n", "Endpoint", "Phi");
 for (Object o : data.keySet())
 {
 @SuppressWarnings({ "rawtypes", "unchecked" })
 CompositeData datum = data.get(((List) o).toArray(new 
Object[((List) o).size()]));
-System.out.printf("%10s,%16.8f\n",datum.get("Endpoint"), 
datum.get("PHI"));
+System.out.printf("%10s,%16.8f%n",datum.get("Endpoint"), 
datum.get("PHI"));
 }
 }
 }

[jira] [Commented] (CASSANDRA-9071) CQLSSTableWriter gives java.lang.AssertionError: Empty partition

[Xu Zhongxing (JIRA)]

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

Xu Zhongxing commented on CASSANDRA-9071:
-

Could you please back port this fix to 2.0 branch? We use CQLsstablewriter 
heavily.

> CQLSSTableWriter gives java.lang.AssertionError: Empty partition
> 
>
> Key: CASSANDRA-9071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9071
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: java 7 / 8
> cassandra 2.1.3 snapshot build locally with last commit 
> https://github.com/apache/cassandra/commit/6ee4b0989d9a3ae3e704918622024fa57fdf63e7
> macos Yosemite 10.10.2
>Reporter: Ajit Joglekar
>Assignee: Fabien Rousseau
> Fix For: 2.1.6
>
> Attachments: EmailWriter.java, Screen Shot 2015-04-15 at 11.14.40 
> PM.png, cassandra-2.1-9071.txt, data.csv.gz
>
>
> I am always getting the following error:
> Exception in thread "main" java.lang.AssertionError: Empty partition
> at 
> org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:228)
> It happens at a certain point that seems to be repeatable. Only issue is I am 
> converting 400 million records into multiple SSTables and creating small test 
> is a challenge
> Last comment from Benedict looks relevant here 
> https://issues.apache.org/jira/browse/CASSANDRA-8619
> Is there a work around, quick fix, fix that I can try out locally?
> Thanks,
> -Ajit



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

[jira] [Updated] (CASSANDRA-10618) Read ghost data

[ZhaoYang (JIRA)]

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

ZhaoYang updated CASSANDRA-10618:
-
Environment: Cassandra 2.1.2  (was: Windows 7, Cassandra 2.1.2)

> Read ghost data
> ---
>
> Key: CASSANDRA-10618
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10618
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.1.2
>Reporter: ZhaoYang
>
> In a table( pk, ck, value) with 1 partition key and 1 clustering key. 
> SELECT * FROM table where pk='PK1' AND ck1='CK1' (full primary keys) -> will 
> return a row that doesn't appear in range scan query (SELECT * FROM table 
> where pk='PK1').
> I tested it with Java Driver 2.1.5 as well as DevCenter. Our environment has 
> only 1 node and replication factor 1. It's our development DB, multiple 
> developers are accessing it. And we are using client-side timestamp generator.
> If I use nodetool to compact this table, this ghost data will disappear. 
> What can be the cause? because of un-order timestamp?
> Thank you very much.



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

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

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10365:
--

A few early remarks on the 2 first patch (the 2nd patch really, the 1st one is 
fine):
* The naming of {{Schema.only()}} doesn't make it extra clear that it expects 
keyspace names. Maybe {{getKeyspaces()}} (that would also be more consistent 
with the rest of the class namings)?
* I tend to agree that the reloading in {{Keyspace.initCf}} shouldn't be 
necessary so I would maybe prefer removing it rather that leaving a TODO that 
will surely stay there a long time.
* In {{SchemaKeyspace.fetchKeyspacesOnly}}, the initial query looks unecessary. 
If it's there as a way to exclude any unexisting keyspace, a comment explaining 
so would be welcome. But it's only used after having applied mutation that we 
knew applied to the keyspace passed to this method, so really, I'm not 
convinced it's useful.
* There is minor inconsistencies in {{SchemaKeyspace}} method naming: you still 
have {{createColumnFromColumnRow}} for instance, but renamed 
{{createAggregateFromAggregateRow}} to {{createAggregateFromRow}}. I'd just 
rename them all to {{createXFromRow}} really as that's easier. On the 
functions/aggregates, you use {{fetchFunctions}} to mean both UDF and UDA, then 
{{fetchUDFs}} for UDF but then {{createFunctionFromRow}} for UDF (should rename 
the last one). Also, {{createAggregateFromRow}} would be more consistent as 
{{createUDAFromRow}}.
* Any reason for removing the {{testConversionsInverses}} in {{CFMetadataTest}} 
rather than converting it to the new code? I do feel this was a good test to 
have. At the very least, the test was testing the inversion of hrift 
conversions which isn't impacted by the patch and should be preserved.

I haven't looked at the 3rd patch yet at all so apologies if any of this is 
fixed by that 3rd patch.

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



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

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

[samt]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: 3d986936fc9564f15fe1f3cdfd46d30ca7b82a00
Parents: a8014bb ca8e9a9
Author: Sam Tunnicliffe 
Authored: Thu Oct 29 10:52:34 2015 +
Committer: Sam Tunnicliffe 
Committed: Thu Oct 29 10:54:54 2015 +

--
 CHANGES.txt | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3d986936/CHANGES.txt
--
diff --cc CHANGES.txt
index 3f2f493,ac997f2..ca017d4
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,25 -1,15 +1,26 @@@
 -2.2.4
 - * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581)
 +3.0
 + * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581)
 + * Execute the metadata reload task of all registered indexes on CFS::reload 
(CASSANDRA-10604)
 + * Fix thrift cas operations with defined columns (CASSANDRA-10576)
 + * Fix PartitionUpdate.operationCount()for updates with static column 
operations (CASSANDRA-10606)
 + * Fix thrift get() queries with defined columns (CASSANDRA-10586)
 + * Fix marking of indexes as built and removed (CASSANDRA-10601)
 + * Skip initialization of non-registered 2i instances, remove 
Index::getIndexName (CASSANDRA-10595)
 + * Fix batches on multiple tables (CASSANDRA-10554)
 + * Ensure compaction options are validated when updating KeyspaceMetadata 
(CASSANDRA-10569)
 + * Flatten Iterator Transformation Hierarchy (CASSANDRA-9975)
 + * Remove token generator (CASSANDRA-5261)
 + * RolesCache should not be created for any authenticator that does not 
requireAuthentication (CASSANDRA-10562)
 + * Fix LogTransaction checking only a single directory for files 
(CASSANDRA-10421)
 + * 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:
   * Expose phi values from failure detector via JMX and tweak debug
 and trace logging (CASSANDRA-9526)
 - * Fix RangeNamesQueryPager (CASSANDRA-10509)
 - * Deprecate Pig support (CASSANDRA-10542)
 - * Reduce contention getting instances of CompositeType (CASSANDRA-10433)
  Merged from 2.1:
+  * Add validation method to PerRowSecondaryIndex (CASSANDRA-10092)
   * Support encrypted and plain traffic on the same port (CASSANDRA-10559)
   * Do STCS in DTCS windows (CASSANDRA-10276)
 - * Don't try to get ancestors from half-renamed sstables (CASSANDRA-10501)
   * Avoid repetition of JVM_OPTS in debian package (CASSANDRA-10251)
   * Fix potential NPE from handling result of SIM.highestSelectivityIndex 
(CASSANDRA-10550)
   * Fix paging issues with partitions containing only static columns data 
(CASSANDRA-10381)

[02/10] cassandra git commit: Add validation method to PerRowSecondaryIndex

[samt]

Add validation method to PerRowSecondaryIndex

Patch by Andrés de la Peña; reviewed by Sam Tunnicliffe for
CASSANDRA-10092


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

Branch: refs/heads/cassandra-2.2
Commit: 7f1fec19080c423d89ce3af823e2b1532b755035
Parents: 32a6f20
Author: Andrés de la Peña 
Authored: Wed Oct 28 16:41:12 2015 +
Committer: Sam Tunnicliffe 
Committed: Thu Oct 29 10:49:19 2015 +

--
 CHANGES.txt |   1 +
 NEWS.txt|   2 +
 .../cql3/statements/UpdateStatement.java|   1 +
 .../db/index/PerRowSecondaryIndex.java  |   5 +
 .../db/index/SecondaryIndexManager.java |   8 +
 .../cassandra/thrift/CassandraServer.java   |  11 +
 .../db/index/PerRowSecondaryIndexTest.java  | 211 ++-
 7 files changed, 234 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7f1fec19/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 998dd22..3d22b91 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.12
+ * Add validation method to PerRowSecondaryIndex (CASSANDRA-10092)
  * Support encrypted and plain traffic on the same port (CASSANDRA-10559)
  * Do STCS in DTCS windows (CASSANDRA-10276)
  * Don't try to get ancestors from half-renamed sstables (CASSANDRA-10501)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7f1fec19/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index c6ea6c0..712a2c4 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -25,6 +25,8 @@ New features
   If moving from the SimpleSnitch, make sure the rack containing all 
current
   nodes is named "rack1". To override this behavior when manually wiping
   the node and bootstrapping, use -Dcassandra.ignore_rack=true.
+- a new validate(key, cf) method is added to PerRowSecondaryIndex. A 
default
+  implementation is provided, so no changes are required to custom 
implementations.
 
 
 2.1.11

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7f1fec19/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java
index 06282ad..bf9a059 100644
--- a/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java
@@ -141,6 +141,7 @@ public class UpdateStatement extends ModificationStatement
 
cfm.cfName));
 }
 }
+indexManager.validateRowLevelIndexes(key, cf);
 }
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7f1fec19/src/java/org/apache/cassandra/db/index/PerRowSecondaryIndex.java
--
diff --git a/src/java/org/apache/cassandra/db/index/PerRowSecondaryIndex.java 
b/src/java/org/apache/cassandra/db/index/PerRowSecondaryIndex.java
index f6f0e8d..5a3d457 100644
--- a/src/java/org/apache/cassandra/db/index/PerRowSecondaryIndex.java
+++ b/src/java/org/apache/cassandra/db/index/PerRowSecondaryIndex.java
@@ -20,6 +20,7 @@ package org.apache.cassandra.db.index;
 import java.nio.ByteBuffer;
 import java.nio.charset.CharacterCodingException;
 
+import org.apache.cassandra.exceptions.InvalidRequestException;
 import org.apache.cassandra.utils.FBUtilities;
 import org.apache.cassandra.utils.concurrent.OpOrder;
 import org.apache.cassandra.db.Cell;
@@ -69,4 +70,8 @@ public abstract class PerRowSecondaryIndex extends 
SecondaryIndex
 {
 return true;
 }
+
+public void validate(ByteBuffer key, ColumnFamily cf) throws 
InvalidRequestException
+{
+}
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7f1fec19/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --git a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java 
b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index 12a0a55..179126b 100644
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@ -683,6 +683,14 @@ public class