[jira] [Commented] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete

[Michael Edge (JIRA)]

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

Michael Edge commented on CASSANDRA-10733:
--

OK - I've added tests and test data to cover both issues raised in this JIRA

> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
>  Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt, 
> CASSANDRA-2.2-10733-CQLSH-Auto.patch, CASSANDRA-2.2-10733-tests.patch, 
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some 
> inconsistent behaviour when completing part of the statement and hitting the 
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}} 
> works correctly. We see a list of all tables (or functions, types) in the 
> current keyspace plus a list of all available keyspaces followed by a full 
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE 
>  minutedata   system_distributed.
> ;rawtickdatabylp  system_traces.
>   rawtickdatabysymbol  tickdata
> daydata  system.  
> fxaggr.  system_auth. 
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in 
> this case, only 1, called 'average') but does not display a list of available 
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate 
>  ;  average  fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type 
> .'}} works correctly. We see a list of all tables (or types) in the 
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata  rawtickdatabylp  tickdata
> minutedata   rawtickdatabysymbol  
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate 
> .'}} works inconsistently. In a keyspace with 2 functions, both 
> beginning with the letters 'avg', if I type {{'desc function '}} 
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg 
> '}} and will not display the matching functions. If I type {{'desc function 
> .'}} (note the trailing full stop) and hit tab, auto-complete will 
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal  avgstate  
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns  
> {{'desc aggregate  '}}  (it adds a space) and does not show me the 
> list of available aggregates. If I type {{'desc aggregate .'}} 
> (note the trailing full stop) and hit tab, auto-complete will work correctly.



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

[jira] [Created] (CASSANDRA-11088) Tab completion for mixed-case keyspaces/tables or quotes

[Xian Yi Teng (JIRA)]

Xian Yi Teng created CASSANDRA-11088:


 Summary: Tab completion for mixed-case keyspaces/tables or quotes
 Key: CASSANDRA-11088
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11088
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: Xian Yi Teng


On versions
{code}
[cqlsh 5.0.1 | Cassandra 3.0.1.816 | DSE 5.0.0 | CQL spec 3.4.0 | Native 
protocol v4]
[cqlsh 5.0.1 | Cassandra 2.1.11.872 | DSE 4.7.4 | CQL spec 3.2.1 | Native 
protocol v3]
{code}

{code}
cqlsh> CREATE KEYSPACE "HerMajesty" WITH replication = {'class': 
'SimpleStrategy', 'replication_factor': '1'}  AND durable_writes = true;
cqlsh> create table "HerMajesty"."HerHighness" (pk int primary key);
cqlsh> select * from "HerMajesty"."HerHighness";

 pk


(0 rows)
cqlsh> select * from H //tab here doesn't work
cqlsh> select * from " //tab here doesn't work
cqlsh> select * from "Her //tab here doesn't work
cqlsh> select * from "HerMajesty"." //tab here doesn't work
{code}



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

[jira] [Commented] (CASSANDRA-10563) Integrate new upgrade test into dtest upgrade suite

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10563:
-

On CASSANDRA-11087, [~thobbs] suggests

bq. Should we add a flag to the upgrade tests to control flushing before 
upgrading? It seems like we want to test both behaviors (to ensure commitlog 
replay is also covered), but there could easily be other legacy sstable reading 
bugs out there.

Which seems eminently sensible (apologies in advance if that's already on the 
table, I haven't been through [~slebresne]'s dtest branch yet).

> Integrate new upgrade test into dtest upgrade suite
> ---
>
> Key: CASSANDRA-10563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10563
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Jim Witschey
>Assignee: Jim Witschey
>Priority: Critical
> Fix For: 3.0.x
>
>
> This is a follow-up ticket for CASSANDRA-10360, specifically [~slebresne]'s 
> comment here:
> https://issues.apache.org/jira/browse/CASSANDRA-10360?focusedCommentId=14966539=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14966539
> These tests should be incorporated into the [{{upgrade_tests}} in 
> dtest|https://github.com/riptano/cassandra-dtest/tree/master/upgrade_tests]. 
> I'll take this on; [~nutbunnies] is also a good person for it, but I'll 
> likely get to it first.



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

[jira] [Commented] (CASSANDRA-11026) OOM

[Benedict (JIRA)]

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

Benedict commented on CASSANDRA-11026:
--

Yup; +1

> OOM
> ---
>
> Key: CASSANDRA-11026
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11026
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Maxim Podkolzine
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.x
>
> Attachments: Screenshot.png, dump.png
>
>
> Cassandra 3.0.2 fails with OOM. The heapdump shows large number of 
> HeapByteBuffer instances, each retaining 1Mb (see the details on the 
> screenshot). Overall retained size is ~2Gb.
> We can provide the additional info and the whole heapdump if necessary.



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

[jira] [Commented] (CASSANDRA-10736) TestTopology.simple_decommission_test failing due to assertion triggered by SizeEstimatesRecorder

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-10736:
---

I have patches for this and just need to verify if the changes in behavior to 
{{getPredecessor}} and {{getSuccessor}} are necessary.

[~blambov] It looks like these changes went in as part of [CASSANDRA-7032]. 
Prior to this, in {{TokenMetadata}}, {{getPredecessor}} and {{getSuccessor}} 
threw errors if tokens weren't in the endpoint map. After [CASSANDRA-7032], the 
first token is selected. Is this an intended change? Tests continue to pass 
with this reverted.

> TestTopology.simple_decommission_test failing due to assertion triggered by 
> SizeEstimatesRecorder
> -
>
> Key: CASSANDRA-10736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10736
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>Priority: Minor
>
> Example 
> [here|http://cassci.datastax.com/job/cassandra-2.2_dtest/369/testReport/junit/topology_test/TestTopology/simple_decommission_test/].
> {{SizeEstimatesRecorder}} can race with decommission when it tries to get the 
> primary ranges for a node.
> This is because {{getPredecessor}} in {{TokenMetadata}} hits an assertion if 
> the token is no longer in {{TokenMetadata}}.
> This no longer occurs in 3.0 because this assertion has been removed and 
> replace with different data.
> In both cases, the relationship between the set of tokens in 
> {{getPrimaryRangesFor}} (passed in as an argument) and the set of tokens used 
> in calls by {{getPredecessor}} (the system ones) should be investigated.



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

[jira] [Commented] (CASSANDRA-11087) Queries on compact storage tables in mixed version clusters can return incorrect results

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-11087:
-

That sounds a good idea, perhaps that could be added under CASSANDRA-10563

> Queries on compact storage tables in mixed version clusters can return 
> incorrect results
> 
>
> Key: CASSANDRA-11087
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11087
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.x, 3.x
>
>
> Whilst writing a dtest for CASSANDRA-11045, it becomes apparent that queries 
> on compact storage tables are broken during the 3.0 upgrade (and this has 
> probably been the case since day 1). 
> tl;dr In a cluster with a mix of < 3.0 and 3.0 nodes, reads on COMPACT 
> STORAGE tables may not include all results. 
> To repro: tables are created and data written before any nodes are upgraded 
> to 3.0+, some nodes are then upgraded putting the cluster into a mixed state.
> Now, when a query is run where the coordinator is a < 3.0 node, any 3.0+ 
> replica which has not yet run upgradesstables always returns 0 results.  Once 
> upgradesstables is run, the replica returns the correct results. Likewise, if 
> the data is inserted after the node is upgraded, the results are correct. If 
> the 3.0 node acts as the coordinator, the results are also correct and so 
> once all nodes are upgraded, the problem goes away.
> The behaviour can be seen for both single partition and range requests as 
> [this 
> dtest|https://github.com/beobal/cassandra-dtest/commit/91bb9ffd8fb761ad3454187d2f05f05a6e7af930]
>  demonstrates.



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

[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete

[Michael Edge (JIRA)]

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

Michael Edge updated CASSANDRA-10733:
-
Attachment: CASSANDRA-2.2-10733-added-tests-for-describe.patch

> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
>  Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt, 
> CASSANDRA-2.2-10733-CQLSH-Auto.patch, 
> CASSANDRA-2.2-10733-added-tests-for-describe.patch, 
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some 
> inconsistent behaviour when completing part of the statement and hitting the 
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}} 
> works correctly. We see a list of all tables (or functions, types) in the 
> current keyspace plus a list of all available keyspaces followed by a full 
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE 
>  minutedata   system_distributed.
> ;rawtickdatabylp  system_traces.
>   rawtickdatabysymbol  tickdata
> daydata  system.  
> fxaggr.  system_auth. 
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in 
> this case, only 1, called 'average') but does not display a list of available 
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate 
>  ;  average  fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type 
> .'}} works correctly. We see a list of all tables (or types) in the 
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata  rawtickdatabylp  tickdata
> minutedata   rawtickdatabysymbol  
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate 
> .'}} works inconsistently. In a keyspace with 2 functions, both 
> beginning with the letters 'avg', if I type {{'desc function '}} 
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg 
> '}} and will not display the matching functions. If I type {{'desc function 
> .'}} (note the trailing full stop) and hit tab, auto-complete will 
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal  avgstate  
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns  
> {{'desc aggregate  '}}  (it adds a space) and does not show me the 
> list of available aggregates. If I type {{'desc aggregate .'}} 
> (note the trailing full stop) and hit tab, auto-complete will work correctly.



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

[jira] [Created] (CASSANDRA-11089) cassandra-stress should allow specifying the Java driver's protocol version to be used

[Eduard Tudenhoefner (JIRA)]

Eduard Tudenhoefner created CASSANDRA-11089:
---

 Summary: cassandra-stress should allow specifying the Java 
driver's protocol version to be used
 Key: CASSANDRA-11089
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11089
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Eduard Tudenhoefner
Assignee: Eduard Tudenhoefner
 Fix For: 3.x


It would be useful to use *cassandra-stress* that is coming with C* 3.x against 
a C* 2.x cluster. In order for that to work, we should allow specifying the 
Java driver's protocol version to be used for the connection.

See also 
https://github.com/apache/cassandra/blob/cassandra-3.0/tools/stress/src/org/apache/cassandra/stress/util/JavaDriverClient.java#L118-118



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

[jira] [Updated] (CASSANDRA-11088) Tab completion for mixed-case keyspaces/tables or quotes in cqlsh

[Xian Yi Teng (JIRA)]

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

Xian Yi Teng updated CASSANDRA-11088:
-
Summary: Tab completion for mixed-case keyspaces/tables or quotes in cqlsh  
(was: Tab completion for mixed-case keyspaces/tables or quotes)

> Tab completion for mixed-case keyspaces/tables or quotes in cqlsh
> -
>
> Key: CASSANDRA-11088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11088
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Xian Yi Teng
>  Labels: cqlsh
>
> On versions
> {code}
> [cqlsh 5.0.1 | Cassandra 3.0.1.816 | DSE 5.0.0 | CQL spec 3.4.0 | Native 
> protocol v4]
> [cqlsh 5.0.1 | Cassandra 2.1.11.872 | DSE 4.7.4 | CQL spec 3.2.1 | Native 
> protocol v3]
> {code}
> {code}
> cqlsh> CREATE KEYSPACE "HerMajesty" WITH replication = {'class': 
> 'SimpleStrategy', 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh> create table "HerMajesty"."HerHighness" (pk int primary key);
> cqlsh> select * from "HerMajesty"."HerHighness";
>  pk
> 
> (0 rows)
> cqlsh> select * from H //tab here doesn't work
> cqlsh> select * from " //tab here doesn't work
> cqlsh> select * from "Her //tab here doesn't work
> cqlsh> select * from "HerMajesty"." //tab here doesn't work
> {code}



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

[jira] [Commented] (CASSANDRA-11087) Queries on compact storage tables in mixed version clusters can return incorrect results

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-11087:
-

Should we add a flag to the upgrade tests to control flushing before upgrading? 
 It seems like we want to test both behaviors (to ensure commitlog replay is 
also covered), but there could easily be other legacy sstable reading bugs out 
there.

> Queries on compact storage tables in mixed version clusters can return 
> incorrect results
> 
>
> Key: CASSANDRA-11087
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11087
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.x, 3.x
>
>
> Whilst writing a dtest for CASSANDRA-11045, it becomes apparent that queries 
> on compact storage tables are broken during the 3.0 upgrade (and this has 
> probably been the case since day 1). 
> tl;dr In a cluster with a mix of < 3.0 and 3.0 nodes, reads on COMPACT 
> STORAGE tables may not include all results. 
> To repro: tables are created and data written before any nodes are upgraded 
> to 3.0+, some nodes are then upgraded putting the cluster into a mixed state.
> Now, when a query is run where the coordinator is a < 3.0 node, any 3.0+ 
> replica which has not yet run upgradesstables always returns 0 results.  Once 
> upgradesstables is run, the replica returns the correct results. Likewise, if 
> the data is inserted after the node is upgraded, the results are correct. If 
> the 3.0 node acts as the coordinator, the results are also correct and so 
> once all nodes are upgraded, the problem goes away.
> The behaviour can be seen for both single partition and range requests as 
> [this 
> dtest|https://github.com/beobal/cassandra-dtest/commit/91bb9ffd8fb761ad3454187d2f05f05a6e7af930]
>  demonstrates.



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

[09/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[marcuse]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.3
Commit: c1ae9d095c9fc8ccc277b04a8aff6b1328294571
Parents: fa2fa60 3b794f0
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:33 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:33 2016 +0100

--

--

[01/15] cassandra git commit: Backport CASSANDRA-10979 to 2.1

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 d5b6d1b63 -> 3b794f0a8
  refs/heads/cassandra-2.2 fa2fa602d -> c1ae9d095
  refs/heads/cassandra-3.0 414c1c577 -> 682812d1f
  refs/heads/cassandra-3.3 1a31958bf -> 573552c80
  refs/heads/trunk 7230a6631 -> 41f5d2279


Backport CASSANDRA-10979 to 2.1


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

Branch: refs/heads/cassandra-2.1
Commit: 3b794f0a82e26c7a6b3fd8baf5ebd6ae9ed814ea
Parents: d5b6d1b
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:20 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:20 2016 +0100

--
 .../db/compaction/LeveledManifest.java  | 34 ++--
 1 file changed, 24 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3b794f0a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java 
b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
index 1e67a9e..622d68b 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
@@ -313,15 +313,9 @@ public class LeveledManifest
 if (score > 1.001)
 {
 // before proceeding with a higher level, let's see if L0 is 
far enough behind to warrant STCS
-if (!DatabaseDescriptor.getDisableSTCSInL0() && 
getLevel(0).size() > MAX_COMPACTING_L0)
-{
-List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
-if (!mostInteresting.isEmpty())
-{
-logger.debug("L0 is too far behind, performing 
size-tiering there first");
-return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
-}
-}
+CompactionCandidate l0Compaction = 
getSTCSInL0CompactionCandidate();
+if (l0Compaction != null)
+return l0Compaction;
 
 // L0 is fine, proceed with this level
 Collection candidates = getCandidatesFor(i);
@@ -345,10 +339,30 @@ public class LeveledManifest
 return null;
 Collection candidates = getCandidatesFor(0);
 if (candidates.isEmpty())
-return null;
+{
+// Since we don't have any other compactions to do, see if there 
is a STCS compaction to perform in L0; if
+// there is a long running compaction, we want to make sure that 
we continue to keep the number of SSTables
+// small in L0.
+return getSTCSInL0CompactionCandidate();
+}
 return new CompactionCandidate(candidates, getNextLevel(candidates), 
cfs.getCompactionStrategy().getMaxSSTableBytes());
 }
 
+private CompactionCandidate getSTCSInL0CompactionCandidate()
+{
+if (!DatabaseDescriptor.getDisableSTCSInL0() && getLevel(0).size() > 
MAX_COMPACTING_L0)
+{
+List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
+if (!mostInteresting.isEmpty())
+{
+logger.debug("L0 is too far behind, performing size-tiering 
there first");
+return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
+}
+}
+
+return null;
+}
+
 private List getSSTablesForSTCS(Collection 
sstables)
 {
 Iterable candidates = 
cfs.getDataTracker().getUncompactingSSTables(sstables);

[02/15] cassandra git commit: Backport CASSANDRA-10979 to 2.1

[marcuse]

Backport CASSANDRA-10979 to 2.1


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

Branch: refs/heads/cassandra-2.2
Commit: 3b794f0a82e26c7a6b3fd8baf5ebd6ae9ed814ea
Parents: d5b6d1b
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:20 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:20 2016 +0100

--
 .../db/compaction/LeveledManifest.java  | 34 ++--
 1 file changed, 24 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3b794f0a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java 
b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
index 1e67a9e..622d68b 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
@@ -313,15 +313,9 @@ public class LeveledManifest
 if (score > 1.001)
 {
 // before proceeding with a higher level, let's see if L0 is 
far enough behind to warrant STCS
-if (!DatabaseDescriptor.getDisableSTCSInL0() && 
getLevel(0).size() > MAX_COMPACTING_L0)
-{
-List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
-if (!mostInteresting.isEmpty())
-{
-logger.debug("L0 is too far behind, performing 
size-tiering there first");
-return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
-}
-}
+CompactionCandidate l0Compaction = 
getSTCSInL0CompactionCandidate();
+if (l0Compaction != null)
+return l0Compaction;
 
 // L0 is fine, proceed with this level
 Collection candidates = getCandidatesFor(i);
@@ -345,10 +339,30 @@ public class LeveledManifest
 return null;
 Collection candidates = getCandidatesFor(0);
 if (candidates.isEmpty())
-return null;
+{
+// Since we don't have any other compactions to do, see if there 
is a STCS compaction to perform in L0; if
+// there is a long running compaction, we want to make sure that 
we continue to keep the number of SSTables
+// small in L0.
+return getSTCSInL0CompactionCandidate();
+}
 return new CompactionCandidate(candidates, getNextLevel(candidates), 
cfs.getCompactionStrategy().getMaxSSTableBytes());
 }
 
+private CompactionCandidate getSTCSInL0CompactionCandidate()
+{
+if (!DatabaseDescriptor.getDisableSTCSInL0() && getLevel(0).size() > 
MAX_COMPACTING_L0)
+{
+List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
+if (!mostInteresting.isEmpty())
+{
+logger.debug("L0 is too far behind, performing size-tiering 
there first");
+return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
+}
+}
+
+return null;
+}
+
 private List getSSTablesForSTCS(Collection 
sstables)
 {
 Iterable candidates = 
cfs.getDataTracker().getUncompactingSSTables(sstables);

[08/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[marcuse]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.0
Commit: c1ae9d095c9fc8ccc277b04a8aff6b1328294571
Parents: fa2fa60 3b794f0
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:33 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:33 2016 +0100

--

--

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

[marcuse]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-2.2
Commit: c1ae9d095c9fc8ccc277b04a8aff6b1328294571
Parents: fa2fa60 3b794f0
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:33 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:33 2016 +0100

--

--

[13/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.3

[marcuse]

Merge branch 'cassandra-3.0' into cassandra-3.3


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

Branch: refs/heads/cassandra-3.3
Commit: 573552c80cd76661cfe31a5855817aaa7b483089
Parents: 1a31958 682812d
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:14:08 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:14:08 2016 +0100

--

--

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

[marcuse]

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

Branch: refs/heads/cassandra-3.0
Commit: 682812d1f831c45546b8bf5c4cd39c2b664c70c9
Parents: 414c1c5 c1ae9d0
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:41 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:41 2016 +0100

--

--

[03/15] cassandra git commit: Backport CASSANDRA-10979 to 2.1

[marcuse]

Backport CASSANDRA-10979 to 2.1


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

Branch: refs/heads/trunk
Commit: 3b794f0a82e26c7a6b3fd8baf5ebd6ae9ed814ea
Parents: d5b6d1b
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:20 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:20 2016 +0100

--
 .../db/compaction/LeveledManifest.java  | 34 ++--
 1 file changed, 24 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3b794f0a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java 
b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
index 1e67a9e..622d68b 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
@@ -313,15 +313,9 @@ public class LeveledManifest
 if (score > 1.001)
 {
 // before proceeding with a higher level, let's see if L0 is 
far enough behind to warrant STCS
-if (!DatabaseDescriptor.getDisableSTCSInL0() && 
getLevel(0).size() > MAX_COMPACTING_L0)
-{
-List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
-if (!mostInteresting.isEmpty())
-{
-logger.debug("L0 is too far behind, performing 
size-tiering there first");
-return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
-}
-}
+CompactionCandidate l0Compaction = 
getSTCSInL0CompactionCandidate();
+if (l0Compaction != null)
+return l0Compaction;
 
 // L0 is fine, proceed with this level
 Collection candidates = getCandidatesFor(i);
@@ -345,10 +339,30 @@ public class LeveledManifest
 return null;
 Collection candidates = getCandidatesFor(0);
 if (candidates.isEmpty())
-return null;
+{
+// Since we don't have any other compactions to do, see if there 
is a STCS compaction to perform in L0; if
+// there is a long running compaction, we want to make sure that 
we continue to keep the number of SSTables
+// small in L0.
+return getSTCSInL0CompactionCandidate();
+}
 return new CompactionCandidate(candidates, getNextLevel(candidates), 
cfs.getCompactionStrategy().getMaxSSTableBytes());
 }
 
+private CompactionCandidate getSTCSInL0CompactionCandidate()
+{
+if (!DatabaseDescriptor.getDisableSTCSInL0() && getLevel(0).size() > 
MAX_COMPACTING_L0)
+{
+List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
+if (!mostInteresting.isEmpty())
+{
+logger.debug("L0 is too far behind, performing size-tiering 
there first");
+return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
+}
+}
+
+return null;
+}
+
 private List getSSTablesForSTCS(Collection 
sstables)
 {
 Iterable candidates = 
cfs.getDataTracker().getUncompactingSSTables(sstables);

[05/15] cassandra git commit: Backport CASSANDRA-10979 to 2.1

[marcuse]

Backport CASSANDRA-10979 to 2.1


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

Branch: refs/heads/cassandra-3.3
Commit: 3b794f0a82e26c7a6b3fd8baf5ebd6ae9ed814ea
Parents: d5b6d1b
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:20 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:20 2016 +0100

--
 .../db/compaction/LeveledManifest.java  | 34 ++--
 1 file changed, 24 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3b794f0a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java 
b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
index 1e67a9e..622d68b 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
@@ -313,15 +313,9 @@ public class LeveledManifest
 if (score > 1.001)
 {
 // before proceeding with a higher level, let's see if L0 is 
far enough behind to warrant STCS
-if (!DatabaseDescriptor.getDisableSTCSInL0() && 
getLevel(0).size() > MAX_COMPACTING_L0)
-{
-List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
-if (!mostInteresting.isEmpty())
-{
-logger.debug("L0 is too far behind, performing 
size-tiering there first");
-return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
-}
-}
+CompactionCandidate l0Compaction = 
getSTCSInL0CompactionCandidate();
+if (l0Compaction != null)
+return l0Compaction;
 
 // L0 is fine, proceed with this level
 Collection candidates = getCandidatesFor(i);
@@ -345,10 +339,30 @@ public class LeveledManifest
 return null;
 Collection candidates = getCandidatesFor(0);
 if (candidates.isEmpty())
-return null;
+{
+// Since we don't have any other compactions to do, see if there 
is a STCS compaction to perform in L0; if
+// there is a long running compaction, we want to make sure that 
we continue to keep the number of SSTables
+// small in L0.
+return getSTCSInL0CompactionCandidate();
+}
 return new CompactionCandidate(candidates, getNextLevel(candidates), 
cfs.getCompactionStrategy().getMaxSSTableBytes());
 }
 
+private CompactionCandidate getSTCSInL0CompactionCandidate()
+{
+if (!DatabaseDescriptor.getDisableSTCSInL0() && getLevel(0).size() > 
MAX_COMPACTING_L0)
+{
+List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
+if (!mostInteresting.isEmpty())
+{
+logger.debug("L0 is too far behind, performing size-tiering 
there first");
+return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
+}
+}
+
+return null;
+}
+
 private List getSSTablesForSTCS(Collection 
sstables)
 {
 Iterable candidates = 
cfs.getDataTracker().getUncompactingSSTables(sstables);

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

[marcuse]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/trunk
Commit: c1ae9d095c9fc8ccc277b04a8aff6b1328294571
Parents: fa2fa60 3b794f0
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:33 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:33 2016 +0100

--

--

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

[marcuse]

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

Branch: refs/heads/trunk
Commit: 682812d1f831c45546b8bf5c4cd39c2b664c70c9
Parents: 414c1c5 c1ae9d0
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:41 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:41 2016 +0100

--

--

[14/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.3

[marcuse]

Merge branch 'cassandra-3.0' into cassandra-3.3


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

Branch: refs/heads/trunk
Commit: 573552c80cd76661cfe31a5855817aaa7b483089
Parents: 1a31958 682812d
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:14:08 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:14:08 2016 +0100

--

--

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

[marcuse]

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

Branch: refs/heads/cassandra-3.3
Commit: 682812d1f831c45546b8bf5c4cd39c2b664c70c9
Parents: 414c1c5 c1ae9d0
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:41 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:41 2016 +0100

--

--

[04/15] cassandra git commit: Backport CASSANDRA-10979 to 2.1

[marcuse]

Backport CASSANDRA-10979 to 2.1


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

Branch: refs/heads/cassandra-3.0
Commit: 3b794f0a82e26c7a6b3fd8baf5ebd6ae9ed814ea
Parents: d5b6d1b
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:13:20 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:13:20 2016 +0100

--
 .../db/compaction/LeveledManifest.java  | 34 ++--
 1 file changed, 24 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3b794f0a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java 
b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
index 1e67a9e..622d68b 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
@@ -313,15 +313,9 @@ public class LeveledManifest
 if (score > 1.001)
 {
 // before proceeding with a higher level, let's see if L0 is 
far enough behind to warrant STCS
-if (!DatabaseDescriptor.getDisableSTCSInL0() && 
getLevel(0).size() > MAX_COMPACTING_L0)
-{
-List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
-if (!mostInteresting.isEmpty())
-{
-logger.debug("L0 is too far behind, performing 
size-tiering there first");
-return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
-}
-}
+CompactionCandidate l0Compaction = 
getSTCSInL0CompactionCandidate();
+if (l0Compaction != null)
+return l0Compaction;
 
 // L0 is fine, proceed with this level
 Collection candidates = getCandidatesFor(i);
@@ -345,10 +339,30 @@ public class LeveledManifest
 return null;
 Collection candidates = getCandidatesFor(0);
 if (candidates.isEmpty())
-return null;
+{
+// Since we don't have any other compactions to do, see if there 
is a STCS compaction to perform in L0; if
+// there is a long running compaction, we want to make sure that 
we continue to keep the number of SSTables
+// small in L0.
+return getSTCSInL0CompactionCandidate();
+}
 return new CompactionCandidate(candidates, getNextLevel(candidates), 
cfs.getCompactionStrategy().getMaxSSTableBytes());
 }
 
+private CompactionCandidate getSTCSInL0CompactionCandidate()
+{
+if (!DatabaseDescriptor.getDisableSTCSInL0() && getLevel(0).size() > 
MAX_COMPACTING_L0)
+{
+List mostInteresting = 
getSSTablesForSTCS(getLevel(0));
+if (!mostInteresting.isEmpty())
+{
+logger.debug("L0 is too far behind, performing size-tiering 
there first");
+return new CompactionCandidate(mostInteresting, 0, 
Long.MAX_VALUE);
+}
+}
+
+return null;
+}
+
 private List getSSTablesForSTCS(Collection 
sstables)
 {
 Iterable candidates = 
cfs.getDataTracker().getUncompactingSSTables(sstables);

[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete

[Michael Edge (JIRA)]

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

Michael Edge updated CASSANDRA-10733:
-
Attachment: (was: CASSANDRA-2.2-10733-added-tests-for-describe.patch)

> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
>  Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt, 
> CASSANDRA-2.2-10733-CQLSH-Auto.patch, CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some 
> inconsistent behaviour when completing part of the statement and hitting the 
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}} 
> works correctly. We see a list of all tables (or functions, types) in the 
> current keyspace plus a list of all available keyspaces followed by a full 
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE 
>  minutedata   system_distributed.
> ;rawtickdatabylp  system_traces.
>   rawtickdatabysymbol  tickdata
> daydata  system.  
> fxaggr.  system_auth. 
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in 
> this case, only 1, called 'average') but does not display a list of available 
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate 
>  ;  average  fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type 
> .'}} works correctly. We see a list of all tables (or types) in the 
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata  rawtickdatabylp  tickdata
> minutedata   rawtickdatabysymbol  
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate 
> .'}} works inconsistently. In a keyspace with 2 functions, both 
> beginning with the letters 'avg', if I type {{'desc function '}} 
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg 
> '}} and will not display the matching functions. If I type {{'desc function 
> .'}} (note the trailing full stop) and hit tab, auto-complete will 
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal  avgstate  
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns  
> {{'desc aggregate  '}}  (it adds a space) and does not show me the 
> list of available aggregates. If I type {{'desc aggregate .'}} 
> (note the trailing full stop) and hit tab, auto-complete will work correctly.



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

[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete

[Michael Edge (JIRA)]

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

Michael Edge updated CASSANDRA-10733:
-
Attachment: CASSANDRA-2.2-10733-tests.patch

> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
>  Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt, 
> CASSANDRA-2.2-10733-CQLSH-Auto.patch, CASSANDRA-2.2-10733-tests.patch, 
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some 
> inconsistent behaviour when completing part of the statement and hitting the 
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}} 
> works correctly. We see a list of all tables (or functions, types) in the 
> current keyspace plus a list of all available keyspaces followed by a full 
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE 
>  minutedata   system_distributed.
> ;rawtickdatabylp  system_traces.
>   rawtickdatabysymbol  tickdata
> daydata  system.  
> fxaggr.  system_auth. 
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in 
> this case, only 1, called 'average') but does not display a list of available 
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate 
>  ;  average  fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type 
> .'}} works correctly. We see a list of all tables (or types) in the 
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata  rawtickdatabylp  tickdata
> minutedata   rawtickdatabysymbol  
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate 
> .'}} works inconsistently. In a keyspace with 2 functions, both 
> beginning with the letters 'avg', if I type {{'desc function '}} 
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg 
> '}} and will not display the matching functions. If I type {{'desc function 
> .'}} (note the trailing full stop) and hit tab, auto-complete will 
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal  avgstate  
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns  
> {{'desc aggregate  '}}  (it adds a space) and does not show me the 
> list of available aggregates. If I type {{'desc aggregate .'}} 
> (note the trailing full stop) and hit tab, auto-complete will work correctly.



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

[jira] [Comment Edited] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement

[Amit Singh Chowdhery (JIRA)]

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

Amit Singh Chowdhery edited comment on CASSANDRA-10411 at 1/29/16 7:37 AM:
---

As communicated , please find the attached Patch for Trunk. In case of any 
issue , please let me know.


was (Author: achowdhe):
Patch for Trunk.

> Add/drop multiple columns in one ALTER TABLE statement
> --
>
> Key: CASSANDRA-10411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10411
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Bryn Cooke
>Assignee: Amit Singh Chowdhery
>Priority: Minor
>  Labels: patch
> Attachments: Cassandra-10411-trunk.diff, cassandra-10411.diff
>
>
> Currently it is only possible to add one column at a time in an alter table 
> statement. It would be great if we could add multiple columns at a time.
> The primary reason for this is that adding each column individually seems to 
> take a significant amount of time (at least on my development machine), I 
> know all the columns I want to add, but don't know them until after the 
> initial table is created.
> As a secondary consideration it brings CQL slightly closer to SQL where most 
> databases can handle adding multiple columns in one statement.



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

[jira] [Updated] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement

[Amit Singh Chowdhery (JIRA)]

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

Amit Singh Chowdhery updated CASSANDRA-10411:
-
Attachment: Cassandra-10411-trunk.diff

Patch for Trunk.

> Add/drop multiple columns in one ALTER TABLE statement
> --
>
> Key: CASSANDRA-10411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10411
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Bryn Cooke
>Assignee: Amit Singh Chowdhery
>Priority: Minor
>  Labels: patch
> Attachments: Cassandra-10411-trunk.diff, cassandra-10411.diff
>
>
> Currently it is only possible to add one column at a time in an alter table 
> statement. It would be great if we could add multiple columns at a time.
> The primary reason for this is that adding each column individually seems to 
> take a significant amount of time (at least on my development machine), I 
> know all the columns I want to add, but don't know them until after the 
> initial table is created.
> As a secondary consideration it brings CQL slightly closer to SQL where most 
> databases can handle adding multiple columns in one statement.



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

[jira] [Updated] (CASSANDRA-10979) LCS doesn't do L0 STC on new tables while an L0->L1 compaction is in progress

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-10979:

Fix Version/s: 2.1.13

> LCS doesn't do L0 STC on new tables while an L0->L1 compaction is in progress
> -
>
> Key: CASSANDRA-10979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10979
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: 2.1.11 / 4.8.3 DSE.
>Reporter: Jeff Ferland
>Assignee: Carl Yeksigian
>  Labels: compaction, leveled
> Fix For: 2.1.13, 2.2.5, 3.0.3, 3.3
>
> Attachments: 10979-2.1.txt
>
>
> Reading code from 
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java
>  and comparing with behavior shown in 
> https://gist.github.com/autocracy/c95aca6b00e42215daaf, the following happens:
> Score for L1,L2,and L3 is all < 1 (paste shows 20/10 and 200/100, due to 
> incremental repair).
> Relevant code from here is
> if (Sets.intersection(l1overlapping, compacting).size() > 0)
> return Collections.emptyList();
> Since there will be overlap between what is compacting and L1 (in my case, 
> pushing over 1,000 tables in to L1 from L0 SCTS), I get a pile up of 1,000 
> smaller tables in L0 while awaiting the transition from L0 to L1 and destroy 
> my performance.
> Requested outcome is to continue to perform SCTS on non-compacting L0 tables.



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

[15/15] cassandra git commit: Merge branch 'cassandra-3.3' into trunk

[marcuse]

Merge branch 'cassandra-3.3' into trunk


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

Branch: refs/heads/trunk
Commit: 41f5d22797f1d82554645d02b585186a7a4d393b
Parents: 7230a66 573552c
Author: Marcus Eriksson 
Authored: Fri Jan 29 08:14:20 2016 +0100
Committer: Marcus Eriksson 
Committed: Fri Jan 29 08:14:20 2016 +0100

--

--

[jira] [Commented] (CASSANDRA-11087) Queries on compact storage tables in mixed version clusters can return incorrect results

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-11087:
-

The problem is that {{AbstractSSTableReader::readStaticRow}} doesn't interact 
well (in this case) with {{ReadCommand::isForThrift}} always being set to true 
when a command is deserialized from a 2.x node. This causes an empty static row 
to be returned on the replica, whereas it should contain all of the compact 
columns (as it does when the 3.0 node is the coordinator).

> Queries on compact storage tables in mixed version clusters can return 
> incorrect results
> 
>
> Key: CASSANDRA-11087
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11087
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.x, 3.x
>
>
> Whilst writing a dtest for CASSANDRA-11045, it becomes apparent that queries 
> on compact storage tables are broken during the 3.0 upgrade (and this has 
> probably been the case since day 1). 
> tl;dr In a cluster with a mix of < 3.0 and 3.0 nodes, reads on COMPACT 
> STORAGE tables may not include all results. 
> To repro: tables are created and data written before any nodes are upgraded 
> to 3.0+, some nodes are then upgraded putting the cluster into a mixed state.
> Now, when a query is run where the coordinator is a < 3.0 node, any 3.0+ 
> replica which has not yet run upgradesstables always returns 0 results.  Once 
> upgradesstables is run, the replica returns the correct results. Likewise, if 
> the data is inserted after the node is upgraded, the results are correct. If 
> the 3.0 node acts as the coordinator, the results are also correct and so 
> once all nodes are upgraded, the problem goes away.
> The behaviour can be seen for both single partition and range requests as 
> [this 
> dtest|https://github.com/beobal/cassandra-dtest/commit/91bb9ffd8fb761ad3454187d2f05f05a6e7af930]
>  demonstrates.



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

[jira] [Commented] (CASSANDRA-11034) consistent_reads_after_move_test is failing on trunk

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11034:
-

This is actually caused by CASSANDRA-10887 we don't see the same pending ranges 
during the move as we did before, trying to figure out why

> consistent_reads_after_move_test is failing on trunk
> 
>
> Key: CASSANDRA-11034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11034
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Marcus Eriksson
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> The novnode dtest 
> {{consistent_bootstrap_test.TestBootstrapConsistency.consistent_reads_after_move_test}}
>  is failing on trunk. See an example failure 
> [here|http://cassci.datastax.com/job/trunk_novnode_dtest/274/testReport/consistent_bootstrap_test/TestBootstrapConsistency/consistent_reads_after_move_test/].
> On trunk I am getting an OOM of one of my C* nodes [node3], which is what 
> causes the nodetool move to fail. Logs are attached.



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

[jira] [Commented] (CASSANDRA-10779) Mutations do not block for completion under view lock contention

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10779:


I put together a limited change to use completable futures only from the 
Mutation Verb handler, which seems to allow other mutations through while 
fixing the issue of not blocking with contention.

[branch|https://github.com/carlyeks/cassandra/tree/ticket/10779/completableFuture]
 
[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10779-completableFuture-testall/]
 
[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10779-completableFuture-dtest/]

> Mutations do not block for completion under view lock contention
> 
>
> Key: CASSANDRA-10779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10779
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: Windows 7 64-bit, Cassandra v3.0.0, Java 1.8u60
>Reporter: Will Zhang
>Assignee: Tyler Hobbs
> Fix For: 3.0.x, 3.x
>
>
> Hi guys,
> I encountered the following warning message when I was testing to upgrade 
> from v2.2.2 to v3.0.0. 
> It looks like a write time-out but in an uncaught exception. Could this be an 
> easy fix?
> Log file section below. Thank you!
> {code}
>   WARN  [SharedPool-Worker-64] 2015-11-26 14:04:24,678 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-64,10,main]: {}
> org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out - 
> received only 0 responses.
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:427) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:386) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:205) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.Keyspace.lambda$apply$59(Keyspace.java:435) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.0.jar:3.0.0]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
>   INFO  [IndexSummaryManager:1] 2015-11-26 14:41:10,527 
> IndexSummaryManager.java:257 - Redistributing index summaries
> {code}



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

[jira] [Commented] (CASSANDRA-11073) Cannot contact other nodes on Windows 7 ccm

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-11073:
---

I don't hit this issue and the dtest runs fine on Windows 10, 2.2HEAD for me. 
This is a fresh install configured only to run dtests as described on the wiki. 

I don't have any great suggestions as to the cause.

> Cannot contact other nodes on Windows 7 ccm
> ---
>
> Key: CASSANDRA-11073
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11073
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: windows 7
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: windows
>
> Before CASSANDRA-9309 was fixed the {{OutboundTcpConnectionPool}} did not 
> bind the client socket to a specific ip/port, so the Windows kernel always 
> picked {{127.0.0.1:random_port}} as client socket address for ccm nodes, 
> regardless of the {{listen_address}} value.
> After fixing CASSANDRA-9309 the {{OutboundTcpConnectionPool}} now binds 
> outgoing client sockets to {{listen_address:random_port}}.
> So any ccm cluster with more than one node will bind client sockets to 
> {{127.0.0.n}} where n is the node id.
> However, the nodes cannot contact each other because connections remain in 
> the {{SYN_SENT}} state on Windows 7, as shown by netstats:
> {noformat}
>   TCP127.0.0.2:50908127.0.0.1:7000 SYN_SENT
> {noformat}
> This bug is preventing the execution of dtests on Windows 7, and was also 
> experienced by [~Stefania].
> I suspect its a configuration/environment problem, but firewall and group 
> policies are disabled. The funny thing is that it does not happen on cassci, 
> but afaik there are no Windows 7 nodes there
> Commenting [this 
> line|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java#L139]
>  fixes the issue, but it's definitely not a solution.



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

[jira] [Created] (CASSANDRA-11090) Hinted Handoff loop

[Blake Eggleston (JIRA)]

Blake Eggleston created CASSANDRA-11090:
---

 Summary: Hinted Handoff loop
 Key: CASSANDRA-11090
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11090
 Project: Cassandra
  Issue Type: Bug
Reporter: Blake Eggleston


After the hints executor finishes sending hints, another hints file is created 
for the same host, which is then processed on the next go around. This 
continues indefinitely. The new hint files are empty, so there shouldn't be any 
network traffic. However, there's still unnecessary hint activity, and the hint 
crc file isn't deleted in the 3.0 branch after hints are dispatched (but is in 
trunk), so any hint activity will trigger ~8640 files being created per day 
until the node is restarted. Restarting the node fixes the problem, after the 
existing hint files are processed. 

This can be duplicated on cassandra-3.0 to trunk with this script: 
https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7



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

[jira] [Commented] (CASSANDRA-11086) trunk eclipse-warnings

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich commented on CASSANDRA-11086:
-

[~blerer] Regarding those 2 warnings - they shouldn't be a problem since we 
have a fail-safe mechanism built-in in QueryController, which tracks all of the 
resources associated with query and closes the ones which weren't e.g. because 
of an exception or something similar.

> trunk eclipse-warnings
> --
>
> Key: CASSANDRA-11086
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11086
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.x
>
>
> REF = origin/trunk 
> COMMIT = 7230a66318ce8add742959d095900d5870689f0c
> {noformat}
> # 1/27/16 8:50:25 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> --
> 1. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/metrics/TableMetrics.java
>  (at line 338)
>   return 
> computeCompressionRatio(Iterables.concat(Iterables.transform(Keyspace.all(),
>  ^^^
> The method computeCompressionRatio(Iterable) in the type 
> TableMetrics is not applicable for the arguments (Iterable)
> --
> --
> 2. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> --
> 3. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskBlock.java
>  (at line 93)
>   return cast(dup);
>   ^
> Potential resource leak: 'dup' may not be closed at this location
> --
> --
> 4. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 142)
>   indexFile = new MappedBuffer(new ChannelProxy(indexPath, 
> backingFile.getChannel()));
>
> ^
> Potential resource leak: '' may not be closed
> --
> 5. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 161)
>   throw new FSReadError(e, index);
>   
> Potential resource leak: 'backingFile' may not be closed at this location
> --
> 6. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 249)
>   RangeIterator range = searchRange(e);
>  ^
> Potential resource leak: 'range' may not be closed
> --
> --
> 7. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java
>  (at line 286)
>   throw new FSWriteError(e, file);
>   
> Potential resource leak: 'out' may not be closed at this location
> --
> --
> 8. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
>  (at line 284)
>   OnDiskIndex last = scheduleSegmentFlush(false).call();
>   
> Potential resource leak: 'last' may not be closed
> --
> 9. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
>  (at line 293)
>   OnDiskIndex part = Futures.getUnchecked(f);
>   
> Potential resource leak: 'part' may not be closed
> --
> --
> 10. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 118)
>   RangeIterator keyIterator = index.search(e);
>  ^^^
> Potential resource leak: 'keyIterator' may not be closed
> --
> 11. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 148)
>   return ranges == null ? null : new TermIterator(e, ranges, 
> referencedIndexes);
>   
> ^^
> Potential resource leak: 'ranges' may not be closed at this location
> --
> 12. ERROR in 
> 

[jira] [Commented] (CASSANDRA-10779) Mutations do not block for completion under view lock contention

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-10779:


I ran highly contended mvbench runs with 3.0 branch, Tyler's v2 branch and 
Carl's completable future test.  

Both thobbs and carls fixes the timeout issue, but when I add a stress write 
workload running along side the view benchmark Tylers branch causes stress to 
timeout because the write stage is blocked waiting on the contended locks. In 
Carl's version this doesn't happen since the mutations are put back on the 
queue freeing threads to work on other things. So I think we should go with 
Carl's version.

In the case of an uncontended mvbench run (no lock contention) there is no 
difference in performance between the current 3.0 branch and Carl's branch.

In the highly contended case as we are now waiting before acking the write the 
performance has dropped to be 50% worse than non-mv.  However I think we can 
fix this by improving lock contention CASSANDRA-10307







> Mutations do not block for completion under view lock contention
> 
>
> Key: CASSANDRA-10779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10779
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: Windows 7 64-bit, Cassandra v3.0.0, Java 1.8u60
>Reporter: Will Zhang
>Assignee: Tyler Hobbs
> Fix For: 3.0.x, 3.x
>
>
> Hi guys,
> I encountered the following warning message when I was testing to upgrade 
> from v2.2.2 to v3.0.0. 
> It looks like a write time-out but in an uncaught exception. Could this be an 
> easy fix?
> Log file section below. Thank you!
> {code}
>   WARN  [SharedPool-Worker-64] 2015-11-26 14:04:24,678 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-64,10,main]: {}
> org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out - 
> received only 0 responses.
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:427) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:386) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:205) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.Keyspace.lambda$apply$59(Keyspace.java:435) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.0.jar:3.0.0]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
>   INFO  [IndexSummaryManager:1] 2015-11-26 14:41:10,527 
> IndexSummaryManager.java:257 - Redistributing index summaries
> {code}



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

[jira] [Commented] (CASSANDRA-10726) Read repair inserts should not be blocking

[Richard Low (JIRA)]

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

Richard Low commented on CASSANDRA-10726:
-

Actually, isn't the real problem here that speculative retry doesn't include 
the RR write? We should give up waiting for the write to complete and retry on 
another replica. A slow RR insert is just as bad as a slow read.

> Read repair inserts should not be blocking
> --
>
> Key: CASSANDRA-10726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Richard Low
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert 
> to update out of date replicas is blocking. This means, if it fails, the read 
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or 
> the mutation stage is backed up for some other reason), all reads to a 
> replica set could fail. Further, replicas dropping writes get more out of 
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any 
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in 
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not 
> be blocking or we should return success for the read even if the write times 
> out.



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

[jira] [Created] (CASSANDRA-11091) Insufficient disk space in memtable flush should trigger disk fail policy

[Richard Low (JIRA)]

Richard Low created CASSANDRA-11091:
---

 Summary: Insufficient disk space in memtable flush should trigger 
disk fail policy
 Key: CASSANDRA-11091
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11091
 Project: Cassandra
  Issue Type: Bug
Reporter: Richard Low


If there's insufficient disk space to flush, 
DiskAwareRunnable.getWriteDirectory throws and the flush fails. The commitlogs 
then grow indefinitely because the latch is never counted down.

This should be an FSError so the disk fail policy is triggered. 



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

[jira] [Updated] (CASSANDRA-11090) Hinted Handoff loop

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-11090:

Fix Version/s: 3.x
   3.0.x

> Hinted Handoff loop
> ---
>
> Key: CASSANDRA-11090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11090
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
> Fix For: 3.0.x, 3.x
>
>
> After the hints executor finishes sending hints, another hints file is 
> created for the same host, which is then processed on the next go around. 
> This continues indefinitely. The new hint files are empty, so there shouldn't 
> be any network traffic. However, there's still unnecessary hint activity, and 
> the hint crc file isn't deleted in the 3.0 branch after hints are dispatched 
> (but is in trunk), so any hint activity will trigger ~8640 files being 
> created per day until the node is restarted. Restarting the node fixes the 
> problem, after the existing hint files are processed. 
> This can be duplicated on cassandra-3.0 to trunk with this script: 
> https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7



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

[jira] [Commented] (CASSANDRA-10368) Support Restricting non-PK Cols in Materialized View Select Statements

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on CASSANDRA-10368:


I just stumbled on this issue as kind of a loose end. Is there any intent to 
support this feature any time soon, assuming that the implementation is not a 
big deal?

> Support Restricting non-PK Cols in Materialized View Select Statements
> --
>
> Key: CASSANDRA-10368
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10368
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Priority: Minor
> Fix For: 3.x
>
>
> CASSANDRA-9664 allows materialized views to restrict primary key columns in 
> the select statement.  Due to CASSANDRA-10261, the patch did not include 
> support for restricting non-PK columns.  Now that the timestamp issue has 
> been resolved, we can add support for this.



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

[jira] [Commented] (CASSANDRA-11030) utf-8 characters incorrectly displayed/inserted on cqlsh on Windows

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11030:
--

+1, thanks! 

Just one note: {{patch by pauloricardomg; reviewed by stef1927 for 
CASSANDRA-11030}}, I think they normally use the git users rather than the GH 
handles, so it should be {{patch by Paulo Motta; reviewed by Stefania 
Alborghetti for CASSANDRA-11030}}.

I leave it to you to move the ticket to ready for commit once you have 
indicated which patches automatically merge up.

> utf-8 characters incorrectly displayed/inserted on cqlsh on Windows
> ---
>
> Key: CASSANDRA-11030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11030
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: cqlsh, windows
>
> {noformat}
> C:\Users\Paulo\Repositories\cassandra [2.2-10948 +6 ~1 -0 !]> .\bin\cqlsh.bat 
> --encoding utf-8
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.2.4-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
> Use HELP for help.
> cqlsh> INSERT INTO bla.test (bla ) VALUES  ('não') ;
> cqlsh> select * from bla.test;
>  bla
> -
>  n?o
> (1 rows)
> {noformat}



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

[jira] [Commented] (CASSANDRA-10944) ERROR [CompactionExecutor] CassandraDaemon.java Exception in thread

[Nimi Wariboko Jr. (JIRA)]

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

Nimi Wariboko Jr. commented on CASSANDRA-10944:
---

I got this error as well running a snapshot that should have this patch 
applied. The snapshot I'm running is @ e66dcc70c510eacfc2e906e1a6f4d9a2708653b3 
(Build #49 http://cassci.datastax.com/job/cassandra-3.3/49) 

{code}
ERROR [CompactionExecutor:647] 2016-01-28 14:47:37,562 CassandraDaemon.java:195 
- Exception in thread Thread[CompactionExecutor:647,1,main]
java.lang.AssertionError: null
at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:49) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.BufferCell.tombstone(BufferCell.java:88) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.BufferCell.tombstone(BufferCell.java:83) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at org.apache.cassandra.db.rows.BufferCell.purge(BufferCell.java:175) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.ComplexColumnData.lambda$purge$107(ComplexColumnData.java:165)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.ComplexColumnData$$Lambda$78/211947336.apply(Unknown
 Source) ~[na:na]
at 
org.apache.cassandra.utils.btree.BTree$FiltrationTracker.apply(BTree.java:650) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.utils.btree.BTree.transformAndFilter(BTree.java:693) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.utils.btree.BTree.transformAndFilter(BTree.java:668) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.ComplexColumnData.transformAndFilter(ComplexColumnData.java:170)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.ComplexColumnData.purge(ComplexColumnData.java:165)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.ComplexColumnData.purge(ComplexColumnData.java:43) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.BTreeRow.lambda$purge$102(BTreeRow.java:333) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.BTreeRow$$Lambda$77/1008858370.apply(Unknown 
Source) ~[na:na]
at 
org.apache.cassandra.utils.btree.BTree$FiltrationTracker.apply(BTree.java:650) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.utils.btree.BTree.transformAndFilter(BTree.java:693) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.utils.btree.BTree.transformAndFilter(BTree.java:668) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.rows.BTreeRow.transformAndFilter(BTreeRow.java:338) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at org.apache.cassandra.db.rows.BTreeRow.purge(BTreeRow.java:333) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.partitions.PurgeFunction.applyToRow(PurgeFunction.java:88)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:64)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:24)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:76)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:177)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
at 
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:255)
 ~[apache-cassandra-3.2.jar:3.2-SNAPSHOT]
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 

[jira] [Comment Edited] (CASSANDRA-11030) utf-8 characters incorrectly displayed/inserted on cqlsh on Windows

[Stefania (JIRA)]

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

Stefania edited comment on CASSANDRA-11030 at 1/29/16 1:32 AM:
---

+1, thanks! 

Just one note: {{patch by pauloricardomg; reviewed by stef1927 for 
CASSANDRA-11030}}, I think we normally use the git users rather than the GH 
handles, so it should be {{patch by Paulo Motta; reviewed by Stefania 
Alborghetti for CASSANDRA-11030}}.

I leave it to you to move the ticket to ready for commit once you have 
indicated which patches automatically merge up.


was (Author: stefania):
+1, thanks! 

Just one note: {{patch by pauloricardomg; reviewed by stef1927 for 
CASSANDRA-11030}}, I think they normally use the git users rather than the GH 
handles, so it should be {{patch by Paulo Motta; reviewed by Stefania 
Alborghetti for CASSANDRA-11030}}.

I leave it to you to move the ticket to ready for commit once you have 
indicated which patches automatically merge up.

> utf-8 characters incorrectly displayed/inserted on cqlsh on Windows
> ---
>
> Key: CASSANDRA-11030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11030
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: cqlsh, windows
>
> {noformat}
> C:\Users\Paulo\Repositories\cassandra [2.2-10948 +6 ~1 -0 !]> .\bin\cqlsh.bat 
> --encoding utf-8
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.2.4-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
> Use HELP for help.
> cqlsh> INSERT INTO bla.test (bla ) VALUES  ('não') ;
> cqlsh> select * from bla.test;
>  bla
> -
>  n?o
> (1 rows)
> {noformat}



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

[jira] [Comment Edited] (CASSANDRA-11067) Improve SASI syntax

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich edited comment on CASSANDRA-11067 at 1/28/16 8:09 AM:
--

[~beobal] I've updated doc/SASI.md with LIKE support and fixed a typo in Cql.g, 
also I've noticed that loading of the SASI indexes on startup is missing so 
I've pushed that too into CASSANDRA-11067 branch (and fixed use of IntervalTree 
on the way) and rebased everything with the latest trunk.

Edit: I've also (just) added ByteBufferUtil.\{startsWith, endsWith\} to 
complement ByteBufferUtil.contains for LIKE_\{PREFIX, SUFFIX\} accordingly.


was (Author: xedin):
[~beobal] I've updated doc/SASI.md with LIKE support and fixed a typo in Cql.g, 
also I've noticed that loading of the SASI indexes on startup is missing so 
I've pushed that too into CASSANDRA-11067 branch (and fixed use of IntervalTree 
on the way) and rebased everything with the latest trunk.

> Improve SASI syntax
> ---
>
> Key: CASSANDRA-11067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11067
> Project: Cassandra
>  Issue Type: Task
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Pavel Yaskevich
> Fix For: 3.4
>
>
> I think everyone agrees that a LIKE operator would be ideal, but that's 
> probably not in scope for an initial 3.4 release.
> Still, I'm uncomfortable with the initial approach of overloading = to mean 
> "satisfies index expression."  The problem is that it will be very difficult 
> to back out of this behavior once people are using it.
> I propose adding a new operator in the interim instead.  Call it MATCHES, 
> maybe.  With the exact same behavior that SASI currently exposes, just with a 
> separate operator rather than being rolled into =.



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

[jira] [Commented] (CASSANDRA-11075) Consider making SASI the default index implementation

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-11075:
--

bq.  I think we are still some distance away from making SASI a "default" 
implementation

Absolutely. I created the ticket because there was some discussion about it and 
I wanted us to have a clear place for such discussion, but I totally agree that 
there is no rush for this and would prefer that we take our time to do this 
right. And we certainly won't move ahead with it until you are yourself 
comfortable with it.

bq. If you want you can assign this ticket to me since I'm working on all of 
this anyway

Will do but again, I didn't meant that anyone should start working on this 
immediately. In fact, I think a first step is to discuss what data we need to 
convince ourselves that it's the good move, after which we need to discuss what 
is the upgrade path.

bq.  #1 - SASI currently handles all of the cases of native indexes expect 
collections and #2 - SASI doesn't require read-before-write

Great, thanks for the info.

> Consider making SASI the default index implementation
> -
>
> Key: CASSANDRA-11075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11075
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>
> We now have 2 secondary index implementation in tree: the old native ones and 
> SASI. Moving forward, that feels like one too much to maintain, especially 
> since it seems that SASI is an overall better implementation.
> So we should gather enough data to decide if SASI is indeed always better (or 
> at least sufficiently better than we're convinced no-one would want to stick 
> with the native implementation), and if that's the case, we should consider 
> making it the default (and ultimately get rid of the current implementation).
> So first, we should at least:
> # double check that SASI handles all cases that the native implementation 
> handles. A good start would probably be run all our dtest and utests on a 
> version where SASI is hard-coded as default.
> # compare the performance of SASI and native indexes. In particular our 
> native indexes, in all their weaknesses, have the advantage of not doing a 
> read-before-write. Haven't looked at SASI much so I don't know if it's the 
> case but anyway, we need numbers on both reads and writes.
> Once we have that, if we do decide to make SASI the default, then we need to 
> figure out what is the upgrade path (and whether we add extra syntax for SASI 
> specific options).



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

[jira] [Commented] (CASSANDRA-11075) Consider making SASI the default index implementation

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich commented on CASSANDRA-11075:
-

bq. Will do but again, I didn't meant that anyone should start working on this 
immediately. In fact, I think a first step is to discuss what data we need to 
convince ourselves that it's the good move, after which we need to discuss what 
is the upgrade path.

We are on the same page :) What I meant was I'm working on "all things SASI" 
anyway so might as well take on assignment of this one...

> Consider making SASI the default index implementation
> -
>
> Key: CASSANDRA-11075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11075
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Pavel Yaskevich
>
> We now have 2 secondary index implementation in tree: the old native ones and 
> SASI. Moving forward, that feels like one too much to maintain, especially 
> since it seems that SASI is an overall better implementation.
> So we should gather enough data to decide if SASI is indeed always better (or 
> at least sufficiently better than we're convinced no-one would want to stick 
> with the native implementation), and if that's the case, we should consider 
> making it the default (and ultimately get rid of the current implementation).
> So first, we should at least:
> # double check that SASI handles all cases that the native implementation 
> handles. A good start would probably be run all our dtest and utests on a 
> version where SASI is hard-coded as default.
> # compare the performance of SASI and native indexes. In particular our 
> native indexes, in all their weaknesses, have the advantage of not doing a 
> read-before-write. Haven't looked at SASI much so I don't know if it's the 
> case but anyway, we need numbers on both reads and writes.
> Once we have that, if we do decide to make SASI the default, then we need to 
> figure out what is the upgrade path (and whether we add extra syntax for SASI 
> specific options).



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

[jira] [Assigned] (CASSANDRA-11083) cassandra-2.2 eclipse-warnings

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer reassigned CASSANDRA-11083:
--

Assignee: Benjamin Lerer

> cassandra-2.2 eclipse-warnings
> --
>
> Key: CASSANDRA-11083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11083
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 2.2.x
>
>
> REF = origin/cassandra-2.2 
> COMMIT = fa2fa602d989ed911b60247e3dd8f2d580188782
> {noformat}
> # 1/27/16 6:19:23 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> incorrect classpath: 
> /var/lib/jenkins/workspace/cassandra-2.2_eclipse-warnings/build/cobertura/classes
> --
> 1. ERROR in 
> /var/lib/jenkins/workspace/cassandra-2.2_eclipse-warnings/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> 1 problem (1 error)
> {noformat}
> Check latest job on 
> http://cassci.datastax.com/job/cassandra-2.2_eclipse-warnings/ for the most 
> recent artifact



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

[jira] [Assigned] (CASSANDRA-11085) cassandra-3.3 eclipse-warnings

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer reassigned CASSANDRA-11085:
--

Assignee: Benjamin Lerer

> cassandra-3.3 eclipse-warnings
> --
>
> Key: CASSANDRA-11085
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11085
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.x
>
>
> REF = origin/cassandra-3.3 
> COMMIT = 1a31958bfa2adb04ec965e6e2776862eee30ecf4
> {noformat}
> # 1/27/16 9:03:40 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> --
> 1. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/db/compaction/writers/MaxSSTableSizeWriter.java
>  (at line 86)
>   SSTableWriter writer = 
> SSTableWriter.create(Descriptor.fromFilename(cfs.getSSTablePath(getDirectories().getLocationForDisk(sstableDirectory))),
> ^^
> Potential resource leak: 'writer' may not be closed
> --
> --
> 2. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/db/compaction/writers/SplittingSizeTieredCompactionWriter.java
>  (at line 108)
>   SSTableWriter writer = 
> SSTableWriter.create(Descriptor.fromFilename(cfs.getSSTablePath(getDirectories().getLocationForDisk(location))),
> ^^
> Potential resource leak: 'writer' may not be closed
> --
> --
> 3. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
>  (at line 1073)
>   SSTableMultiWriter writer = writerIterator.next();
>  ^^
> Potential resource leak: 'writer' may not be closed
> --
> --
> 4. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> --
> 5. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/metrics/TableMetrics.java
>  (at line 335)
>   return 
> computeCompressionRatio(Iterables.concat(Iterables.transform(Keyspace.all(),
>  ^^^
> The method computeCompressionRatio(Iterable) in the type 
> TableMetrics is not applicable for the arguments (Iterable)
> --
> --
> 6. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/hints/CompressedChecksummedDataInput.java
>  (at line 156)
>   return builder.build();
>   ^^^
> Potential resource leak: '' may not 
> be closed at this location
> --
> 6 problems (6 errors)
> {noformat}
> Check latest build on 
> http://cassci.datastax.com/job/cassandra-3.3_eclipse-warnings/ for the most 
> current warnings



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

[jira] [Assigned] (CASSANDRA-11084) cassandra-3.0 eclipse-warnings

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer reassigned CASSANDRA-11084:
--

Assignee: Benjamin Lerer

> cassandra-3.0 eclipse-warnings
> --
>
> Key: CASSANDRA-11084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11084
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.0.x
>
>
> REF = origin/cassandra-3.0 
> COMMIT = 414c1c5771ca05c23c8c1279dbdb90a673dda040
> {noformat}
> # 1/27/16 10:00:17 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> --
> 1. ERROR in 
> /mnt/data/jenkins/workspace/cassandra-3.0_eclipse-warnings/src/java/org/apache/cassandra/hints/CompressedChecksummedDataInput.java
>  (at line 156)
>   return builder.build();
>   ^^^
> Potential resource leak: '' may not 
> be closed at this location
> --
> --
> 2. ERROR in 
> /mnt/data/jenkins/workspace/cassandra-3.0_eclipse-warnings/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> 2 problems (2 errors)
> {noformat}
> Check the latest job on 
> http://cassci.datastax.com/job/cassandra-3.0_eclipse-warnings/ for the most 
> recent warnings



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

[jira] [Assigned] (CASSANDRA-11086) trunk eclipse-warnings

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer reassigned CASSANDRA-11086:
--

Assignee: Benjamin Lerer

> trunk eclipse-warnings
> --
>
> Key: CASSANDRA-11086
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11086
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.x
>
>
> REF = origin/trunk 
> COMMIT = 7230a66318ce8add742959d095900d5870689f0c
> {noformat}
> # 1/27/16 8:50:25 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> --
> 1. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/metrics/TableMetrics.java
>  (at line 338)
>   return 
> computeCompressionRatio(Iterables.concat(Iterables.transform(Keyspace.all(),
>  ^^^
> The method computeCompressionRatio(Iterable) in the type 
> TableMetrics is not applicable for the arguments (Iterable)
> --
> --
> 2. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> --
> 3. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskBlock.java
>  (at line 93)
>   return cast(dup);
>   ^
> Potential resource leak: 'dup' may not be closed at this location
> --
> --
> 4. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 142)
>   indexFile = new MappedBuffer(new ChannelProxy(indexPath, 
> backingFile.getChannel()));
>
> ^
> Potential resource leak: '' may not be closed
> --
> 5. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 161)
>   throw new FSReadError(e, index);
>   
> Potential resource leak: 'backingFile' may not be closed at this location
> --
> 6. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 249)
>   RangeIterator range = searchRange(e);
>  ^
> Potential resource leak: 'range' may not be closed
> --
> --
> 7. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java
>  (at line 286)
>   throw new FSWriteError(e, file);
>   
> Potential resource leak: 'out' may not be closed at this location
> --
> --
> 8. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
>  (at line 284)
>   OnDiskIndex last = scheduleSegmentFlush(false).call();
>   
> Potential resource leak: 'last' may not be closed
> --
> 9. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
>  (at line 293)
>   OnDiskIndex part = Futures.getUnchecked(f);
>   
> Potential resource leak: 'part' may not be closed
> --
> --
> 10. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 118)
>   RangeIterator keyIterator = index.search(e);
>  ^^^
> Potential resource leak: 'keyIterator' may not be closed
> --
> 11. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 148)
>   return ranges == null ? null : new TermIterator(e, ranges, 
> referencedIndexes);
>   
> ^^
> Potential resource leak: 'ranges' may not be closed at this location
> --
> 12. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 156)
>   throw ex;
>   ^
> Potential resource leak: 'memtableIterator' may not be closed at this location
> --
> --
> 13. 

[jira] [Commented] (CASSANDRA-8099) Refactor and modernize the storage engine

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-8099:
-

bq. Is there any specification online with a detailed description of the new 
SSTable format byte by byte ?

There isn't, and as much as I would be the first to love seeing that exist, I 
doubt I'll find the time to provide it myself any time soon. Of course, it's 
open  source, so anyone with some free time and willingness could use the code 
to kick-start such documentation on the wiki. Which would be very much 
appreciated.  

> Refactor and modernize the storage engine
> -
>
> Key: CASSANDRA-8099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8099
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0 alpha 1
>
> Attachments: 8099-nit
>
>
> The current storage engine (which for this ticket I'll loosely define as "the 
> code implementing the read/write path") is suffering from old age. One of the 
> main problem is that the only structure it deals with is the cell, which 
> completely ignores the more high level CQL structure that groups cell into 
> (CQL) rows.
> This leads to many inefficiencies, like the fact that during a reads we have 
> to group cells multiple times (to count on replica, then to count on the 
> coordinator, then to produce the CQL resultset) because we forget about the 
> grouping right away each time (so lots of useless cell names comparisons in 
> particular). But outside inefficiencies, having to manually recreate the CQL 
> structure every time we need it for something is hindering new features and 
> makes the code more complex that it should be.
> Said storage engine also has tons of technical debt. To pick an example, the 
> fact that during range queries we update {{SliceQueryFilter.count}} is pretty 
> hacky and error prone. Or the overly complex ways {{AbstractQueryPager}} has 
> to go into to simply "remove the last query result".
> So I want to bite the bullet and modernize this storage engine. I propose to 
> do 2 main things:
> # Make the storage engine more aware of the CQL structure. In practice, 
> instead of having partitions be a simple iterable map of cells, it should be 
> an iterable list of row (each being itself composed of per-column cells, 
> though obviously not exactly the same kind of cell we have today).
> # Make the engine more iterative. What I mean here is that in the read path, 
> we end up reading all cells in memory (we put them in a ColumnFamily object), 
> but there is really no reason to. If instead we were working with iterators 
> all the way through, we could get to a point where we're basically 
> transferring data from disk to the network, and we should be able to reduce 
> GC substantially.
> Please note that such refactor should provide some performance improvements 
> right off the bat but it's not it's primary goal either. It's primary goal is 
> to simplify the storage engine and adds abstraction that are better suited to 
> further optimizations.



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

[jira] [Updated] (CASSANDRA-11084) cassandra-3.0 eclipse-warnings

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-11084:
---
Attachment: 11084-3.0.txt

In both cases the warning are not valid as the underlying resources will be 
closed with the wrappers.

The patch just adds some SuppressWarning annotations

> cassandra-3.0 eclipse-warnings
> --
>
> Key: CASSANDRA-11084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11084
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: 11084-3.0.txt
>
>
> REF = origin/cassandra-3.0 
> COMMIT = 414c1c5771ca05c23c8c1279dbdb90a673dda040
> {noformat}
> # 1/27/16 10:00:17 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> --
> 1. ERROR in 
> /mnt/data/jenkins/workspace/cassandra-3.0_eclipse-warnings/src/java/org/apache/cassandra/hints/CompressedChecksummedDataInput.java
>  (at line 156)
>   return builder.build();
>   ^^^
> Potential resource leak: '' may not 
> be closed at this location
> --
> --
> 2. ERROR in 
> /mnt/data/jenkins/workspace/cassandra-3.0_eclipse-warnings/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> 2 problems (2 errors)
> {noformat}
> Check the latest job on 
> http://cassci.datastax.com/job/cassandra-3.0_eclipse-warnings/ for the most 
> recent warnings



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

[jira] [Assigned] (CASSANDRA-10715) Filtering on NULL returns ReadFailure exception

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer reassigned CASSANDRA-10715:
--

Assignee: Benjamin Lerer

> Filtering on NULL returns ReadFailure exception
> ---
>
> Key: CASSANDRA-10715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10715
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: C* 3.0.0 | cqlsh | C# driver 3.0.0beta2 | Windows 2012 R2
>Reporter: Kishan Karunaratne
>Assignee: Benjamin Lerer
>
> This is an issue I first noticed through the C# driver, but I was able to 
> repro on cqlsh, leading me to believe this is a Cassandra bug.
> Given the following schema:
> {noformat}
> CREATE TABLE "TestKeySpace_4928dc892922"."coolMovies" (
> unique_movie_title text,
> movie_maker text,
> director text,
> list list,
> "mainGuy" text,
> "yearMade" int,
> PRIMARY KEY ((unique_movie_title, movie_maker), director)
> ) WITH CLUSTERING ORDER BY (director ASC)
> {noformat}
> Executing a SELECT with FILTERING on a non-PK column, using a NULL as the 
> argument:
> {noformat}
> SELECT "mainGuy", "movie_maker", "unique_movie_title", "list", "director", 
> "yearMade" FROM "coolMovies" WHERE "mainGuy" = null ALLOW FILTERING
> {noformat}
> returns a ReadFailure exception:
> {noformat}
> cqlsh:TestKeySpace_4c8f2cf8d5cc> SELECT "mainGuy", "movie_maker", 
> "unique_movie_title", "list", "director", "yearMade" FROM "coolMovies" WHERE 
> "mainGuy" = null ALLOW FILTERING;
> ←[0;1;31mTraceback (most recent call last):
>   File "C:\Users\Kishan\.ccm\repository\3.0.0\bin\\cqlsh.py", line 1216, in 
> perform_simple_statement
> result = future.result()
>   File 
> "C:\Users\Kishan\.ccm\repository\3.0.0\bin\..\lib\cassandra-driver-internal-only-3.0.0a3.post0-3f15725.zip\cassandra-driver-3.0.0a3.post0-3f15725\cassandra\cluster.py",
>  line 3118, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'cons
> istency': 'ONE'}
> ←[0m
> {noformat}
> Cassandra log shows:
> {noformat}
> WARN  [SharedPool-Worker-2] 2015-11-16 13:51:00,259 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-2,10,main]: {}
> java.lang.AssertionError: null
>   at 
> org.apache.cassandra.db.filter.RowFilter$SimpleExpression.isSatisfiedBy(RowFilter.java:581)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToRow(RowFilter.java:243)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.transform.BaseRows.applyOne(BaseRows.java:95) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:86) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:21) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.transform.Transformation.add(Transformation.java:136) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:102)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:233)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:227)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:76)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:293)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:288) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1692)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]

[jira] [Updated] (CASSANDRA-11083) cassandra-2.2 eclipse-warnings

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-11083:
---
Attachment: 11083-2.2.txt

> cassandra-2.2 eclipse-warnings
> --
>
> Key: CASSANDRA-11083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11083
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 11083-2.2.txt
>
>
> REF = origin/cassandra-2.2 
> COMMIT = fa2fa602d989ed911b60247e3dd8f2d580188782
> {noformat}
> # 1/27/16 6:19:23 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> incorrect classpath: 
> /var/lib/jenkins/workspace/cassandra-2.2_eclipse-warnings/build/cobertura/classes
> --
> 1. ERROR in 
> /var/lib/jenkins/workspace/cassandra-2.2_eclipse-warnings/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> 1 problem (1 error)
> {noformat}
> Check latest job on 
> http://cassci.datastax.com/job/cassandra-2.2_eclipse-warnings/ for the most 
> recent artifact



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

[jira] [Updated] (CASSANDRA-11075) Consider making SASI the default index implementation

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-11075:
-
Assignee: Pavel Yaskevich

> Consider making SASI the default index implementation
> -
>
> Key: CASSANDRA-11075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11075
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Pavel Yaskevich
>
> We now have 2 secondary index implementation in tree: the old native ones and 
> SASI. Moving forward, that feels like one too much to maintain, especially 
> since it seems that SASI is an overall better implementation.
> So we should gather enough data to decide if SASI is indeed always better (or 
> at least sufficiently better than we're convinced no-one would want to stick 
> with the native implementation), and if that's the case, we should consider 
> making it the default (and ultimately get rid of the current implementation).
> So first, we should at least:
> # double check that SASI handles all cases that the native implementation 
> handles. A good start would probably be run all our dtest and utests on a 
> version where SASI is hard-coded as default.
> # compare the performance of SASI and native indexes. In particular our 
> native indexes, in all their weaknesses, have the advantage of not doing a 
> read-before-write. Haven't looked at SASI much so I don't know if it's the 
> case but anyway, we need numbers on both reads and writes.
> Once we have that, if we do decide to make SASI the default, then we need to 
> figure out what is the upgrade path (and whether we add extra syntax for SASI 
> specific options).



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

[jira] [Commented] (CASSANDRA-7520) Permit sorting sstables by raw partition key, as opposed to token

[Benedict (JIRA)]

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

Benedict commented on CASSANDRA-7520:
-

Not if the sstables are split by token range, as they will be soon

> Permit sorting sstables by raw partition key, as opposed to token
> -
>
> Key: CASSANDRA-7520
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7520
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>
> At the moment we have some counter-intuitive behaviour, which is that with a 
> hashed partitioner (recommended) the more compacted the data is, the more 
> randomly distributed it is amongst the file. This means that data access 
> locality is made pretty much as bad as possible, and we rely on the OS to do 
> its best to fix that for us with its page cache.
> [~jasobrown] mentioned this at the NGCC, but thinking on it some more it 
> seems that many use cases may benefit from dropping the token at the storage 
> level and sorting based on the raw key data. For workloads where nearness of 
> key => likelihood of being coreferenced, this could improve data locality and 
> cache hit rate dramatically. Timeseries workloads spring to mind, but I doubt 
> this is constrained to them. Most likely any non-random access pattern could 
> benefit. A random access pattern would most likely suffer from this scheme, 
> as we can index more efficiently into the hashed data. However there's no 
> reason we could not support both schemes. 



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

[jira] [Commented] (CASSANDRA-11043) Secondary indexes doesn't properly validate custom expressions

[JIRA]

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

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

Any idea about this, [~beobal]? Where do you think is the best place to call to 
an hypothetical {{validate(Expression)}} method?

> Secondary indexes doesn't properly validate custom expressions
> --
>
> Key: CASSANDRA-11043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11043
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Local Write-Read Paths
>Reporter: Andrés de la Peña
>  Labels: 21, index, validation
> Attachments: test-index.zip
>
>
> It seems that 
> [CASSANDRA-7575|https://issues.apache.org/jira/browse/CASSANDRA-7575] is 
> broken in Cassandra 3.x. As stated in the secondary indexes' API 
> documentation, custom index implementations should perform any validation of 
> query expressions at {{Index#searcherFor(ReadCommand)}}, throwing an 
> {{InvalidRequestException}} if the expressions are not valid. I assume these 
> validation errors should produce an {{InvalidRequest}} error on cqlsh, or 
> raise an {{InvalidQueryException}} on Java driver. However, when 
> {{Index#searcherFor(ReadCommand)}} throws its {{InvalidRequestException}}, I 
> get this cqlsh output:
> {noformat}
> Traceback (most recent call last):
>   File "bin/cqlsh.py", line 1246, in perform_simple_statement
> result = future.result()
>   File 
> "/Users/adelapena/stratio/platform/src/cassandra-3.2.1/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
>  line 3122, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {noformat}
> I attach a dummy index implementation to reproduce the error:
> {noformat}
> CREATE KEYSPACE test with replication = {'class' : 'SimpleStrategy', 
> 'replication_factor' : '1' }; 
> CREATE TABLE test.test (id int PRIMARY KEY, value varchar); 
> CREATE CUSTOM INDEX test_index ON test.test() USING 'com.stratio.TestIndex'; 
> SELECT * FROM test.test WHERE expr(test_index,'ok');
> SELECT * FROM test.test WHERE expr(test_index,'error');
> {noformat}
> This is specially problematic when using Cassandra Java Driver, because one 
> of these server exceptions can produce subsequent queries fail (even if they 
> are valid) with a no host available exception.
> Maybe the validation method added with 
> [CASSANDRA-7575|https://issues.apache.org/jira/browse/CASSANDRA-7575] should 
> be restored, unless there is a way to properly manage the exception.



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

[jira] [Commented] (CASSANDRA-8180) Optimize disk seek using min/max column name meta data when the LIMIT clause is used

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-8180:
-

Latest commit available 
[here|https://github.com/stef1927/cassandra/commit/a0e779d5970b764f2732c387067218407617b4ab].

bq. I am worried about the partitionLevelDeletion > minTimestamp check for 
tables with tombstones, though. It seems that the code is still willing to skip 
a table with tombstones if it doesn't delete the whole partition. Could that be 
right?

You are right to be worried, this test fails on trunk:

{code}
createTable("CREATE TABLE %s (a int, b int, c text, primary key (a, b))");

for (int i = 0; i < 10; i++)
execute("INSERT INTO %s (a, b, c) VALUES(1, ?, 'abc')", i);
flush();

execute("DELETE FROM %s WHERE a=1 and b <= 3");
flush();

assertEmpty(execute("SELECT * FROM %s WHERE a=1 and b <= 2"));
{code}

I git-annotated the original code in 2.2, which is in {{CollationController}} 
at line 293 and traced it to CASSANDRA-5514. I think the comment explaining it 
is 
[this|https://issues.apache.org/jira/browse/CASSANDRA-5514?focusedCommentId=13645632=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13645632].
 However, perhaps back than range tombstones did not exist? BTW, [this 
comment|https://issues.apache.org/jira/browse/CASSANDRA-5514?focusedCommentId=13656934=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13656934]
 explains quite well the _raison d'être_ of the min and max clustering values 
in the stats.

bq. Shouldn't minTimestamp be updated only if shouldInclude()?

I agree and we should also update {{minTimestamp}} by looking at memtables as 
well now that CASSANDRA-9949 is available. 

bq. The trace on merging doesn't seem to be using the right value.

Done, thanks.

bq. You should use Transformation for withSSTablesIterated, and I'd actually do 
isEmpty() explicitly-- the new code is harder to read but I don't think it 
improves anything.

Done. Because {{BaseRows}} eagerly caches the static row in its constructor, I 
had to change one thing: rather than counting an sstable as iterated when the 
iterator is initialized, we do so when {{computeNext()}} is called. I think 
this is fair since the constructor only accesses the data partition in very 
limited cases as discussed above. However we do access the partition index, 
which prior to this we would only do for sstables with tombstones. If this is 
not acceptable then either we don't use {{Transformation}} or we change 
{{BaseRows}}.

I've also attached a boolean to the iterator itself rather than counting the 
tables via {{sstablesIterated}} and I was therefore able to get rid of 
{{QueryMemtableAndDiskStatus}}. It seems a bit cleaner like this. I called the 
method returning that boolean {{iterated()}} but perhaps we can find a better 
name.

bq. CQLTester.cfs() is redundant (use getCurrentColumnFamilyStore()).

Done, thanks.

> Optimize disk seek using min/max column name meta data when the LIMIT clause 
> is used
> 
>
> Key: CASSANDRA-8180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8180
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
> Environment: Cassandra 2.0.10
>Reporter: DOAN DuyHai
>Assignee: Stefania
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 8180_001.yaml, 8180_002.yaml
>
>
> I was working on an example of sensor data table (timeseries) and face a use 
> case where C* does not optimize read on disk.
> {code}
> cqlsh:test> CREATE TABLE test(id int, col int, val text, PRIMARY KEY(id,col)) 
> WITH CLUSTERING ORDER BY (col DESC);
> cqlsh:test> INSERT INTO test(id, col , val ) VALUES ( 1, 10, '10');
> ...
> >nodetool flush test test
> ...
> cqlsh:test> INSERT INTO test(id, col , val ) VALUES ( 1, 20, '20');
> ...
> >nodetool flush test test
> ...
> cqlsh:test> INSERT INTO test(id, col , val ) VALUES ( 1, 30, '30');
> ...
> >nodetool flush test test
> {code}
> After that, I activate request tracing:
> {code}
> cqlsh:test> SELECT * FROM test WHERE id=1 LIMIT 1;
>  activity  | 
> timestamp| source| source_elapsed
> ---+--+---+
> execute_cql3_query | 
> 23:48:46,498 | 127.0.0.1 |  0
> Parsing SELECT * FROM test WHERE id=1 LIMIT 1; | 
> 23:48:46,498 | 127.0.0.1 | 74
>Preparing statement | 
> 23:48:46,499 | 

[jira] [Updated] (CASSANDRA-11085) cassandra-3.3 eclipse-warnings

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-11085:
---
Attachment: 11085-3.3.txt

On my eclipse version (the latest Mars) I do not have any warning for the error 
5. It looks like a mistake to me.

Otherwise all the other errors were invalid so I added some SuppressWarning 
annotations

> cassandra-3.3 eclipse-warnings
> --
>
> Key: CASSANDRA-11085
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11085
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 11085-3.3.txt
>
>
> REF = origin/cassandra-3.3 
> COMMIT = 1a31958bfa2adb04ec965e6e2776862eee30ecf4
> {noformat}
> # 1/27/16 9:03:40 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> --
> 1. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/db/compaction/writers/MaxSSTableSizeWriter.java
>  (at line 86)
>   SSTableWriter writer = 
> SSTableWriter.create(Descriptor.fromFilename(cfs.getSSTablePath(getDirectories().getLocationForDisk(sstableDirectory))),
> ^^
> Potential resource leak: 'writer' may not be closed
> --
> --
> 2. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/db/compaction/writers/SplittingSizeTieredCompactionWriter.java
>  (at line 108)
>   SSTableWriter writer = 
> SSTableWriter.create(Descriptor.fromFilename(cfs.getSSTablePath(getDirectories().getLocationForDisk(location))),
> ^^
> Potential resource leak: 'writer' may not be closed
> --
> --
> 3. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
>  (at line 1073)
>   SSTableMultiWriter writer = writerIterator.next();
>  ^^
> Potential resource leak: 'writer' may not be closed
> --
> --
> 4. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> --
> 5. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/metrics/TableMetrics.java
>  (at line 335)
>   return 
> computeCompressionRatio(Iterables.concat(Iterables.transform(Keyspace.all(),
>  ^^^
> The method computeCompressionRatio(Iterable) in the type 
> TableMetrics is not applicable for the arguments (Iterable)
> --
> --
> 6. ERROR in 
> /var/lib/jenkins/workspace/cassandra-3.3_eclipse-warnings/src/java/org/apache/cassandra/hints/CompressedChecksummedDataInput.java
>  (at line 156)
>   return builder.build();
>   ^^^
> Potential resource leak: '' may not 
> be closed at this location
> --
> 6 problems (6 errors)
> {noformat}
> Check latest build on 
> http://cassci.datastax.com/job/cassandra-3.3_eclipse-warnings/ for the most 
> current warnings



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

[jira] [Created] (CASSANDRA-11093) processs restarts are failing becase native port and jmx ports are in use

[varun (JIRA)]

varun created CASSANDRA-11093:
-

 Summary: processs restarts are failing becase native port and jmx 
ports are in use
 Key: CASSANDRA-11093
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11093
 Project: Cassandra
  Issue Type: Bug
  Components: Configuration
 Environment: PROD
Reporter: varun
Priority: Minor


A process restart should automatically take care of this. But it is not and it 
is a problem.

The ports are are considered in use even if the process has quit/died/killed 
but the socket is in a TIME_WAIT state in the TCP FSM 
(http://tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm).

tcp 0 0 127.0.0.1:7199 0.0.0.0:* LISTEN 30099/java
tcp 0 0 192.168.1.2:9160 0.0.0.0:* LISTEN 30099/java
tcp 0 0 10.130.128.131:58263 10.130.128.131:9042 TIME_WAIT -
tcp 0 0 10.130.128.131:58262 10.130.128.131:9042 TIME_WAIT -
tcp 0 0 :::10.130.128.131:9042 :::* LISTEN 30099/java
tcp 0 0 :::10.130.128.131:9042 :::10.130.128.131:57191 ESTABLISHED 
30099/java
tcp 0 0 :::10.130.128.131:9042 :::10.130.128.131:57190 ESTABLISHED 
30099/java
tcp 0 0 :::10.130.128.131:9042 :::10.176.70.226:37105 ESTABLISHED 
30099/java
tcp 0 0 :::127.0.0.1:42562 :::127.0.0.1:7199 TIME_WAIT -
tcp 0 0 :::10.130.128.131:57190 :::10.130.128.131:9042 ESTABLISHED 
30138/java
tcp 0 0 :::10.130.128.131:57198 :::10.130.128.131:9042 ESTABLISHED 
30138/java
tcp 0 0 :::10.130.128.131:9042 :::10.176.70.226:37106 ESTABLISHED 
30099/java
tcp 0 0 :::10.130.128.131:57197 :::10.130.128.131:9042 ESTABLISHED 
30138/java
tcp 0 0 :::10.130.128.131:57191 :::10.130.128.131:9042 ESTABLISHED 
30138/java
tcp 0 0 :::10.130.128.131:9042 :::10.130.128.131:57198 ESTABLISHED 
30099/java
tcp 0 0 :::10.130.128.131:9042 :::10.130.128.131:57197 ESTABLISHED 
30099/java
tcp 0 0 :::127.0.0.1:42567 :::127.0.0.1:7199 TIME_WAIT -

I had to write a restart handler that does a netstat call and looks to make 
sure all the TIME_WAIT states exhaust before starting the node back up. This 
happened on 26 of the 56 when a rolling restart was performed. The issue was 
mostly around JMX port 7199. There was another rollling restart done on the 26 
nodes to remediate the JMX ports issue in that restart one node had the issue 
where port 9042 was considered used after the restart and the process died 
after a bit of time.

What needs to be done for port the native port 9042 and JMX port 7199 is to 
create the underlying TCP socket with SO_REUSEADDR. This eases the restriction 
and allows the port to be bound by process even if there are sockets open to 
that port in the TCP FSM, as long as there is no other process listening on 
that port. There is a Java method available to set this option in 
java.net.Socket 
https://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#setReuseAddress%28boolean%29.

native port 9042: 
https://github.com/apache/cassandra/blob/4a0d1caa262af3b6f2b6d329e45766b4df845a88/tools/stress/src/org/apache/cassandra/stress/settings/SettingsPort.java#L38
JMX port 7199: 
https://github.com/apache/cassandra/blob/4a0d1caa262af3b6f2b6d329e45766b4df845a88/tools/stress/src/org/apache/cassandra/stress/settings/SettingsPort.java#L40

Looking in the code itself this option is being set on thrift (9160 (default)) 
and internode communication ports, uncrypted (7000 (default)) and SSL encrypted 
(7001 (default)) .
https://github.com/apache/cassandra/search?utf8=%E2%9C%93=setReuseAddress

This needs to be set to native and jmx ports as well.

References:
https://unix.stackexchange.com/questions/258379/when-is-a-port-considered-being-used/258380?noredirect=1
https://stackoverflow.com/questions/23531558/allow-restarting-java-application-with-jmx-monitoring-enabled-immediately
https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/socketfactory/
https://github.com/apache/cassandra/search?utf8=%E2%9C%93=setReuseAddress
https://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#setReuseAddress%28boolean%293
https://github.com/apache/cassandra/blob/4a0d1caa262af3b6f2b6d329e45766b4df845a88/tools/stress/src/org/apache/cassandra/stress/settings/SettingsPort.java#L38
https://github.com/apache/cassandra/blob/4a0d1caa262af3b6f2b6d329e45766b4df845a88/tools/stress/src/org/apache/cassandra/stress/settings/SettingsPort.java#L40




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

[jira] [Commented] (CASSANDRA-11030) utf-8 characters incorrectly displayed/inserted on cqlsh on Windows

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11030:
--

I think we need to move the codec registration further up, I just stumbled into 
this:

{code}
C:\Users\stefania\git\cstar\cassandra>.\bin\cqlsh.bat --help
Traceback (most recent call last):
  File "C:\Users\stefania\git\cstar\cassandra\bin\\cqlsh.py", line 220, in 

(options, arguments) = parser.parse_args(sys.argv[1:], values=optvalues)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 1400, in 
parse_args
stop = self._process_args(largs, rargs, values)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 1440, in 
_process_args
self._process_long_opt(rargs, values)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 1515, in 
_process_long_opt
option.process(opt, value, values, self)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 789, in process
self.action, self.dest, opt, value, values, parser)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 811, in 
take_action
parser.print_help()
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 1670, in 
print_help
file.write(self.format_help().encode(encoding, "replace"))
LookupError: unknown encoding: cp65001
C:\Users\stefania\git\cstar\cassandra>.\bin\cqlsh.bat --encoding utf-8 --help
Traceback (most recent call last):
  File "C:\Users\stefania\git\cstar\cassandra\bin\\cqlsh.py", line 220, in 

(options, arguments) = parser.parse_args(sys.argv[1:], values=optvalues)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 1400, in 
parse_args
stop = self._process_args(largs, rargs, values)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 1440, in 
_process_args
self._process_long_opt(rargs, values)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 1515, in 
_process_long_opt
option.process(opt, value, values, self)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 789, in process
self.action, self.dest, opt, value, values, parser)
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 811, in 
take_action
parser.print_help()
  File "C:\Program Files\Python\2.7.11\lib\optparse.py", line 1670, in 
print_help
file.write(self.format_help().encode(encoding, "replace"))
LookupError: unknown encoding: cp65001
{code}

Also, on Windows 7 I still get the "?" even with cp650001

> utf-8 characters incorrectly displayed/inserted on cqlsh on Windows
> ---
>
> Key: CASSANDRA-11030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11030
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: cqlsh, windows
>
> {noformat}
> C:\Users\Paulo\Repositories\cassandra [2.2-10948 +6 ~1 -0 !]> .\bin\cqlsh.bat 
> --encoding utf-8
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.2.4-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
> Use HELP for help.
> cqlsh> INSERT INTO bla.test (bla ) VALUES  ('não') ;
> cqlsh> select * from bla.test;
>  bla
> -
>  n?o
> (1 rows)
> {noformat}



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

[jira] [Commented] (CASSANDRA-11030) utf-8 characters incorrectly displayed/inserted on cqlsh on Windows

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11030:
-

Oops, thanks for spotting those. Fixed!

bq. At this line here, now that we are using the extended self.is_using_utf8, 
which includes cp65001 but also utf-8, it means the lambda would be registered 
on all platforms. It's harmless but perhaps it should be limited to native 
Windows platforms only?

actually no need to check all utf-8 encodings, only cp65001, and also added 
check for windows-only

Resubmitted dtests.

> utf-8 characters incorrectly displayed/inserted on cqlsh on Windows
> ---
>
> Key: CASSANDRA-11030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11030
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: cqlsh, windows
>
> {noformat}
> C:\Users\Paulo\Repositories\cassandra [2.2-10948 +6 ~1 -0 !]> .\bin\cqlsh.bat 
> --encoding utf-8
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.2.4-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
> Use HELP for help.
> cqlsh> INSERT INTO bla.test (bla ) VALUES  ('não') ;
> cqlsh> select * from bla.test;
>  bla
> -
>  n?o
> (1 rows)
> {noformat}



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

[jira] [Commented] (CASSANDRA-11086) trunk eclipse-warnings

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-11086:


Most of the warning seems to be false alert. 6 of them have already been 
adressed in CASSANDRA-11086.

The only places where there might be some real problems are:
* In {{RangeIntersectionIterator}} (line 146) where it looks like the range can 
leak if it is not overlapping
* In {{Operation}} where the right and left operations are not closed within 
close.

[~xedin] could you check if those 2 points are some real leaks? I do not 
understand yet well enough the SASI code.

> trunk eclipse-warnings
> --
>
> Key: CASSANDRA-11086
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11086
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.x
>
>
> REF = origin/trunk 
> COMMIT = 7230a66318ce8add742959d095900d5870689f0c
> {noformat}
> # 1/27/16 8:50:25 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> --
> 1. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/metrics/TableMetrics.java
>  (at line 338)
>   return 
> computeCompressionRatio(Iterables.concat(Iterables.transform(Keyspace.all(),
>  ^^^
> The method computeCompressionRatio(Iterable) in the type 
> TableMetrics is not applicable for the arguments (Iterable)
> --
> --
> 2. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> --
> 3. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskBlock.java
>  (at line 93)
>   return cast(dup);
>   ^
> Potential resource leak: 'dup' may not be closed at this location
> --
> --
> 4. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 142)
>   indexFile = new MappedBuffer(new ChannelProxy(indexPath, 
> backingFile.getChannel()));
>
> ^
> Potential resource leak: '' may not be closed
> --
> 5. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 161)
>   throw new FSReadError(e, index);
>   
> Potential resource leak: 'backingFile' may not be closed at this location
> --
> 6. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 249)
>   RangeIterator range = searchRange(e);
>  ^
> Potential resource leak: 'range' may not be closed
> --
> --
> 7. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java
>  (at line 286)
>   throw new FSWriteError(e, file);
>   
> Potential resource leak: 'out' may not be closed at this location
> --
> --
> 8. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
>  (at line 284)
>   OnDiskIndex last = scheduleSegmentFlush(false).call();
>   
> Potential resource leak: 'last' may not be closed
> --
> 9. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
>  (at line 293)
>   OnDiskIndex part = Futures.getUnchecked(f);
>   
> Potential resource leak: 'part' may not be closed
> --
> --
> 10. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 118)
>   RangeIterator keyIterator = index.search(e);
>  ^^^
> Potential resource leak: 'keyIterator' may not be closed
> --
> 11. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 148)
>   return ranges == null ? null : new TermIterator(e, ranges, 
> 

[jira] [Commented] (CASSANDRA-11087) Queries on compact storage tables in mixed version clusters can return incorrect results

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11087:
-

Good catch! This would've probably been catch by the upgrade dtests of 
CASSANDRA-10563, once they're merged in the main upgrade suite which include an 
intermediate mixed-versions step (not included in the current version) (just 
letting you know so you can probably reuse those here).

> Queries on compact storage tables in mixed version clusters can return 
> incorrect results
> 
>
> Key: CASSANDRA-11087
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11087
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.x, 3.x
>
>
> Whilst writing a dtest for CASSANDRA-11045, it becomes apparent that queries 
> on compact storage tables are broken during the 3.0 upgrade (and this has 
> probably been the case since day 1). 
> tl;dr In a cluster with a mix of < 3.0 and 3.0 nodes, reads on COMPACT 
> STORAGE tables may not include all results. 
> To repro: tables are created and data written before any nodes are upgraded 
> to 3.0+, some nodes are then upgraded putting the cluster into a mixed state.
> Now, when a query is run where the coordinator is a < 3.0 node, any 3.0+ 
> replica which has not yet run upgradesstables always returns 0 results.  Once 
> upgradesstables is run, the replica returns the correct results. Likewise, if 
> the data is inserted after the node is upgraded, the results are correct. If 
> the 3.0 node acts as the coordinator, the results are also correct and so 
> once all nodes are upgraded, the problem goes away.
> The behaviour can be seen for both single partition and range requests as 
> [this 
> dtest|https://github.com/beobal/cassandra-dtest/commit/91bb9ffd8fb761ad3454187d2f05f05a6e7af930]
>  demonstrates.



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

[jira] [Created] (CASSANDRA-11092) EXPAND breaks when the result has 0 rows in cqlsh

[Kishan Karunaratne (JIRA)]

Kishan Karunaratne created CASSANDRA-11092:
--

 Summary: EXPAND breaks when the result has 0 rows in cqlsh
 Key: CASSANDRA-11092
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11092
 Project: Cassandra
  Issue Type: Bug
Reporter: Kishan Karunaratne


{noformat}
cqlsh> EXPAND ON;
Now Expanded output is enabled
cqlsh> select * from system.local;

@ Row 1
-+-
 key | local
 bootstrapped| COMPLETED
 broadcast_address   | 127.0.0.1
 cluster_name| dse_50_graph
 cql_version | 3.4.0
 data_center | Graph
 dse_version | 5.0.0
 gossip_generation   | 1454032824
 graph   | True
 host_id | ad30ccb2-04a1-4511-98b6-a72e4ea182c0
 listen_address  | 127.0.0.1
 native_protocol_version | 4
 partitioner | org.apache.cassandra.dht.Murmur3Partitioner
 rack| rack1
 release_version | 3.0.1.816
 rpc_address | 127.0.0.1
 schema_version  | 5667501a-4ac3-3f00-ab35-9040efb927ad
 server_id   | A0-CE-C8-01-CC-CA
 thrift_version  | 20.1.0
 tokens  | {'-9223372036854775808'}
 truncated_at| null
 workload| Cassandra

(1 rows)
cqlsh> select * from system.peers;

max() arg is an empty sequence
cqlsh> EXPAND OFF;
Disabled Expanded output.
cqlsh> select * from system.peers;

 peer | data_center | dse_version | graph | host_id | preferred_ip | rack | 
release_version | rpc_address | schema_version | server_id | tokens | workload
--+-+-+---+-+--+--+-+-++---++--

(0 rows)

{noformat}



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

[jira] [Commented] (CASSANDRA-10428) cqlsh: Include sub-second precision in timestamps by default

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10428:
--

The problem was that the timezone format for Windows was different, I changed 
it to use the same as on Linux now:

{code}
if not DEFAULT_TIMESTAMP_FORMAT:
-if platform.system() == 'Windows':
-DEFAULT_TIMESTAMP_FORMAT = '%Y-%m-%d %H:%M:%S.%f %Z'
-else:
-DEFAULT_TIMESTAMP_FORMAT = '%Y-%m-%d %H:%M:%S.%f%z'
+DEFAULT_TIMESTAMP_FORMAT = '%Y-%m-%d %H:%M:%S.%f%z'
{code}

Existing code sets {{DEFAULT_TIME_FORMAT}} to something different for Windows 
but this variable is actually not used, so it confused me into thinking Windows 
needed a different format for the timezone.

Branch updated and CI restarted.



> cqlsh: Include sub-second precision in timestamps by default
> 
>
> Key: CASSANDRA-10428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10428
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: OSX 10.10.2
>Reporter: Chandran Anjur Narasimhan
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 3.x
>
>
> Query with >= timestamp works. But the exact timestamp value is not working.
> {noformat}
> NCHAN-M-D0LZ:bin nchan$ ./cqlsh
> Connected to CCC Multi-Region Cassandra Cluster at :.
> [cqlsh 5.0.1 | Cassandra 2.1.7 | CQL spec 3.2.0 | Native protocol v3]
> Use HELP for help.
> cqlsh>
> {noformat}
> {panel:title=Schema|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> cqlsh:ccc> desc COLUMNFAMILY ez_task_result ;
> CREATE TABLE ccc.ez_task_result (
> submissionid text,
> ezid text,
> name text,
> time timestamp,
> analyzed_index_root text,
> ...
> ...
> PRIMARY KEY (submissionid, ezid, name, time)
> {panel}
> {panel:title=Working|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> cqlsh:ccc> select submissionid, ezid, name, time, state, status, 
> translated_criteria_status from ez_task_result where 
> submissionid='760dd154670811e58c04005056bb6ff0' and 
> ezid='760dd6de670811e594fc005056bb6ff0' and name='run-sanities' and 
> time>='2015-09-29 20:54:23-0700';
>  submissionid | ezid | name   
>   | time | state | status  | 
> translated_criteria_status
> --+--+--+--+---+-+
>  760dd154670811e58c04005056bb6ff0 | 760dd6de670811e594fc005056bb6ff0 | 
> run-sanities | 2015-09-29 20:54:23-0700 | EXECUTING | IN_PROGRESS |   
> run-sanities started
> (1 rows)
> cqlsh:ccc>
> {panel}
> {panel:title=Not 
> working|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> cqlsh:ccc> select submissionid, ezid, name, time, state, status, 
> translated_criteria_status from ez_task_result where 
> submissionid='760dd154670811e58c04005056bb6ff0' and 
> ezid='760dd6de670811e594fc005056bb6ff0' and name='run-sanities' and 
> time='2015-09-29 20:54:23-0700';
>  submissionid | ezid | name | time | analyzed_index_root | analyzed_log_path 
> | clientid | end_time | jenkins_path | log_file_path | path_available | 
> path_to_task | required_for_overall_status | start_time | state | status | 
> translated_criteria_status | type
> --+--+--+--+-+---+--+--+--+---++--+-++---+++--
> (0 rows)
> cqlsh:ccc>
> {panel}



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

[jira] [Created] (CASSANDRA-11087) Queries on compact storage tables in mixed version clusters can return incorrect results

[Sam Tunnicliffe (JIRA)]

Sam Tunnicliffe created CASSANDRA-11087:
---

 Summary: Queries on compact storage tables in mixed version 
clusters can return incorrect results
 Key: CASSANDRA-11087
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11087
 Project: Cassandra
  Issue Type: Bug
  Components: Local Write-Read Paths
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
 Fix For: 3.0.x, 3.x


Whilst writing a dtest for CASSANDRA-11045, it becomes apparent that queries on 
compact storage tables are broken during the 3.0 upgrade (and this has probably 
been the case since day 1). 

tl;dr In a cluster with a mix of < 3.0 and 3.0 nodes, reads on COMPACT STORAGE 
tables may not include all results. 

To repro: tables are created and data written before any nodes are upgraded to 
3.0+, some nodes are then upgraded putting the cluster into a mixed state.
Now, when a query is run where the coordinator is a < 3.0 node, any 3.0+ 
replica which has not yet run upgradesstables always returns 0 results.  Once 
upgradesstables is run, the replica returns the correct results. Likewise, if 
the data is inserted after the node is upgraded, the results are correct. If 
the 3.0 node acts as the coordinator, the results are also correct and so once 
all nodes are upgraded, the problem goes away.

The behaviour can be seen for both single partition and range requests as [this 
dtest|https://github.com/beobal/cassandra-dtest/commit/91bb9ffd8fb761ad3454187d2f05f05a6e7af930]
 demonstrates.




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

[jira] [Commented] (CASSANDRA-11040) Encrypted hints

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-11040:
-

[~bdeggleston] to review

> Encrypted hints
> ---
>
> Key: CASSANDRA-11040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11040
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>  Labels: encryption, hints, security
>
> When users enable system-wide encryption (which includes commit logs, 
> CASSANDRA-6018), we need to encrypt other assets, as well. Hence, let's 
> encrypt hints.



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

[jira] [Commented] (CASSANDRA-11086) trunk eclipse-warnings

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-11086:
-

I'll take a look at the commitlog/encryption related entries.

> trunk eclipse-warnings
> --
>
> Key: CASSANDRA-11086
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11086
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Shuler
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.x
>
>
> REF = origin/trunk 
> COMMIT = 7230a66318ce8add742959d095900d5870689f0c
> {noformat}
> # 1/27/16 8:50:25 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp 
> 2000, 2013. All rights reserved.
> --
> 1. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/metrics/TableMetrics.java
>  (at line 338)
>   return 
> computeCompressionRatio(Iterables.concat(Iterables.transform(Keyspace.all(),
>  ^^^
> The method computeCompressionRatio(Iterable) in the type 
> TableMetrics is not applicable for the arguments (Iterable)
> --
> --
> 2. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
>  (at line 141)
>   return channel.socket();
>   
> Potential resource leak: 'channel' may not be closed at this location
> --
> --
> 3. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskBlock.java
>  (at line 93)
>   return cast(dup);
>   ^
> Potential resource leak: 'dup' may not be closed at this location
> --
> --
> 4. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 142)
>   indexFile = new MappedBuffer(new ChannelProxy(indexPath, 
> backingFile.getChannel()));
>
> ^
> Potential resource leak: '' may not be closed
> --
> 5. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 161)
>   throw new FSReadError(e, index);
>   
> Potential resource leak: 'backingFile' may not be closed at this location
> --
> 6. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
>  (at line 249)
>   RangeIterator range = searchRange(e);
>  ^
> Potential resource leak: 'range' may not be closed
> --
> --
> 7. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java
>  (at line 286)
>   throw new FSWriteError(e, file);
>   
> Potential resource leak: 'out' may not be closed at this location
> --
> --
> 8. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
>  (at line 284)
>   OnDiskIndex last = scheduleSegmentFlush(false).call();
>   
> Potential resource leak: 'last' may not be closed
> --
> 9. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
>  (at line 293)
>   OnDiskIndex part = Futures.getUnchecked(f);
>   
> Potential resource leak: 'part' may not be closed
> --
> --
> 10. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 118)
>   RangeIterator keyIterator = index.search(e);
>  ^^^
> Potential resource leak: 'keyIterator' may not be closed
> --
> 11. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 148)
>   return ranges == null ? null : new TermIterator(e, ranges, 
> referencedIndexes);
>   
> ^^
> Potential resource leak: 'ranges' may not be closed at this location
> --
> 12. ERROR in 
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
>  (at line 156)
>   throw ex;
>   ^
> Potential resource leak: 'memtableIterator' may not 

[jira] [Updated] (CASSANDRA-11040) Encrypted hints

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11040:

Reviewer: Blake Eggleston

> Encrypted hints
> ---
>
> Key: CASSANDRA-11040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11040
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>  Labels: encryption, hints, security
>
> When users enable system-wide encryption (which includes commit logs, 
> CASSANDRA-6018), we need to encrypt other assets, as well. Hence, let's 
> encrypt hints.



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

[jira] [Commented] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete

[Michael Edge (JIRA)]

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

Michael Edge commented on CASSANDRA-10733:
--

[~thobbs] my apologies, I missed your earlier comment.

I've added a test for the first of the issues above - please see attached 
patch. I should hopefully have some time to add tests for the second issue 
tomorrow.

> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
>  Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt, 
> CASSANDRA-2.2-10733-CQLSH-Auto.patch, 
> CASSANDRA-2.2-10733-added-tests-for-describe.patch, 
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some 
> inconsistent behaviour when completing part of the statement and hitting the 
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}} 
> works correctly. We see a list of all tables (or functions, types) in the 
> current keyspace plus a list of all available keyspaces followed by a full 
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE 
>  minutedata   system_distributed.
> ;rawtickdatabylp  system_traces.
>   rawtickdatabysymbol  tickdata
> daydata  system.  
> fxaggr.  system_auth. 
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in 
> this case, only 1, called 'average') but does not display a list of available 
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate 
>  ;  average  fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type 
> .'}} works correctly. We see a list of all tables (or types) in the 
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata  rawtickdatabylp  tickdata
> minutedata   rawtickdatabysymbol  
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate 
> .'}} works inconsistently. In a keyspace with 2 functions, both 
> beginning with the letters 'avg', if I type {{'desc function '}} 
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg 
> '}} and will not display the matching functions. If I type {{'desc function 
> .'}} (note the trailing full stop) and hit tab, auto-complete will 
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal  avgstate  
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns  
> {{'desc aggregate  '}}  (it adds a space) and does not show me the 
> list of available aggregates. If I type {{'desc aggregate .'}} 
> (note the trailing full stop) and hit tab, auto-complete will work correctly.



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

[jira] [Commented] (CASSANDRA-11075) Consider making SASI the default index implementation

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on CASSANDRA-11075:


bq. A good start would probably be run all our dtest and utests on a version 
where SASI is hard-coded as default.

Maybe it would make sense to introduce a config setting to select the default 
indexing. I presume that it would mean the default mode would be SPARSE, which 
may make sense for the traditional use cases of Cassandra secondary indexes - 
cardinality is not too high and not too low.

Syntax-size, OPTIONS can only be specified when USING is specified. That would 
only be an issue if there weren't keywords for all the SASI options. I vaguely 
recall [~jbellis] objecting some time ago in some completely unrelated context 
about cluttering up the CQL syntax with lots of keywords for options, so it 
might make sense to loosen up the CREATE INDEX syntax to allow WITH OPTIONS 
even when a class is not specified. The mode might make sense as a keyword, but 
then we get to the analyzer class and case sensitivity and the keyword clutter 
would start getting out of hand.

> Consider making SASI the default index implementation
> -
>
> Key: CASSANDRA-11075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11075
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Pavel Yaskevich
>
> We now have 2 secondary index implementation in tree: the old native ones and 
> SASI. Moving forward, that feels like one too much to maintain, especially 
> since it seems that SASI is an overall better implementation.
> So we should gather enough data to decide if SASI is indeed always better (or 
> at least sufficiently better than we're convinced no-one would want to stick 
> with the native implementation), and if that's the case, we should consider 
> making it the default (and ultimately get rid of the current implementation).
> So first, we should at least:
> # double check that SASI handles all cases that the native implementation 
> handles. A good start would probably be run all our dtest and utests on a 
> version where SASI is hard-coded as default.
> # compare the performance of SASI and native indexes. In particular our 
> native indexes, in all their weaknesses, have the advantage of not doing a 
> read-before-write. Haven't looked at SASI much so I don't know if it's the 
> case but anyway, we need numbers on both reads and writes.
> Once we have that, if we do decide to make SASI the default, then we need to 
> figure out what is the upgrade path (and whether we add extra syntax for SASI 
> specific options).



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

[jira] [Commented] (CASSANDRA-10736) TestTopology.simple_decommission_test failing due to assertion triggered by SizeEstimatesRecorder

[Branimir Lambov (JIRA)]

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

Branimir Lambov commented on CASSANDRA-10736:
-

I don't believe these changes are necessary. I think I used them for tests but 
didn't really intend to keep the change.

> TestTopology.simple_decommission_test failing due to assertion triggered by 
> SizeEstimatesRecorder
> -
>
> Key: CASSANDRA-10736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10736
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>Priority: Minor
>
> Example 
> [here|http://cassci.datastax.com/job/cassandra-2.2_dtest/369/testReport/junit/topology_test/TestTopology/simple_decommission_test/].
> {{SizeEstimatesRecorder}} can race with decommission when it tries to get the 
> primary ranges for a node.
> This is because {{getPredecessor}} in {{TokenMetadata}} hits an assertion if 
> the token is no longer in {{TokenMetadata}}.
> This no longer occurs in 3.0 because this assertion has been removed and 
> replace with different data.
> In both cases, the relationship between the set of tokens in 
> {{getPrimaryRangesFor}} (passed in as an argument) and the set of tokens used 
> in calls by {{getPredecessor}} (the system ones) should be investigated.



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