[jira] [Commented] (CASSANDRA-10723) Rewrite INITCOND after renames and alters of UDT fields

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10723:
---

bq. Because it could break the UDA/UDF which the current user is maybe not 
allowed to change (break).

Not from perspective of this ticket, which is just about {{initcond}}. This 
breaks nothing by itself, it's an opaque change.

> Rewrite INITCOND after renames and alters of UDT fields
> ---
>
> Key: CASSANDRA-10723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10723
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> (Follow-up to CASSANDRA-10721)
> In order to re-write an INITCOND value when a UDT is changed (component 
> renamed or type altered), we will have to check for broken aggregates first 
> (as we do not know why _exactly_ these are broken; CASSANDRA-10721 added 
> {{Function.isBroken()}}).
> If one of the affected aggregates is broken, the request *must fail*.
> If none of the affected aggregates is broken, we can re-write the binary 
> representation of the INITCOND and push schema migrations for these 
> aggregates.
> Still unclear, if the user needs permissions on both the UDT _and_ the 
> affected UDAs for that.
> Further, the UDT change and all UDA changes should be migrated in a single 
> mutation, which feels to be the biggest change. This is not a strict 
> requirement but would keep that schema change atomic.



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

[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10477:


Good news is that I am at least partially correct and PAXOS is heading down the 
road to submitting hints for the local node.

[New failing utests from this 
assertion|https://github.com/apache/cassandra/compare/cassandra-2.1...aweisberg:CASSANDRA-10477-test?expand=1#diff-5e7d892105f1fa0706dbedf919b5dd99L46]
http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-test-testall/1/testReport/junit/org.apache.cassandra.triggers/TriggersTest/executeTriggerOnCqlInsertWithConditions/
http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-test-testall/1/testReport/junit/org.apache.cassandra.triggers/TriggersTest/executeTriggerOnCqlBatchWithConditions/
http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-test-testall/1/testReport/junit/org.apache.cassandra.triggers/TriggersTest/executeTriggerOnThriftCASOperation/

Also several [failing 
dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10477-test-dtest/1/#showFailuresLink]

I'll try getting the PAXOS code to do something similar to the insertLocal 
where it doesn't submit a real hint.


> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



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

[Cassandra Wiki] Trivial Update of "FrontPage" by JoshuaMcKenzie

[Apache Wiki]

Dear Wiki user,

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

The "FrontPage" page has been changed by JoshuaMcKenzie:
https://wiki.apache.org/cassandra/FrontPage?action=diff=108=109

   * [[TopLevelPackages|Top Level Packages]]
   * [[CLI%20Design|CLI Design]]
   * [[HowToContribute|How To Contribute]]?
+  * [[How to Review|How to Review]]
   * [[How To Commit?|HowToCommit]]
   * [[HowToPublishReleases|How To Release]] (Note: currently a work in 
progress) (Note: only relevant to Cassandra Committers)
   * [[Windows Development|WindowsDevelopment]]

[jira] [Commented] (CASSANDRA-7464) Replace sstable2json and json2sstable

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-7464:


So we removed these with CASSANDRA-9618 and never replaced them.

> Replace sstable2json and json2sstable
> -
>
> Key: CASSANDRA-7464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7464
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Priority: Minor
> Fix For: 3.x
>
>
> Both tools are pretty awful. They are primarily meant for debugging (there is 
> much more efficient and convenient ways to do import/export data), but their 
> output manage to be hard to handle both for humans and for tools (especially 
> as soon as you have modern stuff like composites).
> There is value to having tools to export sstable contents into a format that 
> is easy to manipulate by human and tools for debugging, small hacks and 
> general tinkering, but sstable2json and json2sstable are not that.  
> So I propose that we deprecate those tools and consider writing better 
> replacements. It shouldn't be too hard to come up with an output format that 
> is more aware of modern concepts like composites, UDTs, 



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

[Cassandra Wiki] Update of "How to Review" by JoshuaMcKenzie

[Apache Wiki]

Dear Wiki user,

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

The "How to Review" page has been changed by JoshuaMcKenzie:
https://wiki.apache.org/cassandra/How%20to%20Review

New page:
When reviewing tickets in Apache JIRA, the following items should be covered as 
part of the review process:

||General|| ||
|| || Does it conform to the [[CodeStyle|Code Style]] guidelines?||
|| || Is there any redundant or duplicate code? ||
|| || Is the code as modular as possible? ||
|| || Can any singletons be avoided? ||
|| || Can any of the code be replaced with library functions? ||
|| || Are units of measurement used in the code consistent, both internally and 
with the rest of the ecosystem? ||
|| || ||
|| Error-Handling || ||
|| || Are all data inputs and outputs checked (for the correct type, length, 
format, and range) and encoded? ||
|| || Where third-party utilities are used, are returning errors being caught? 
||
|| || Are invalid parameter values handled? ||
|| || Are any Throwable/Exceptions passed to the JVMStabilityInspector? ||
|| || Are errors well-documented?  Does the error message tell the user how to 
proceed? ||
|| || Do exceptions propagate to the appropriate level in the code? ||
|| || ||
|| Documentation || ||
|| || Do comments exist and describe the intent of the code (the "why", not the 
"how")? ||
|| || Are javadocs added where appropriate? ||
|| || Is any unusual behavior or edge-case handling described? ||
|| || Are data structures and units of measurement explained? ||
|| || Is there any incomplete code? If so, should it be removed or flagged with 
a suitable marker like ‘TODO’? ||
|| || Does the code self-document via clear naming, abstractions, and flow 
control? ||
|| || Have NEWS.txt, the cql3 docs, and the native protocol spec been updated 
if needed? ||
|| || Is the ticket tagged with "client-impacting" and "doc-impacting", where 
appropriate? ||
|| || Has lib/licences been updated for third-party libs? Are they Apache 
License compatible? ||
|| || Is the Component on the JIRA ticket set appropriately? ||
|| || ||
|| Testing || ||
|| || Is the code testable? i.e. don’t add too many or hide dependencies, 
unable to initialize objects, test frameworks can use methods etc. ||
|| || Do tests exist and are they comprehensive? ||
|| || Do unit tests actually test that the code is performing the intended 
functionality? ||
|| || Could any test code use common functionality (e.g. ccm, dtest, or 
CqlTester methods) or abstract it there for reuse? ||
|| || If the code may be affected by multi-node clusters, are there dtests? ||
|| || If the code may take a long time to test properly, are there CVH tests? ||
|| || Is the test passing on CI for all affected branches (up to trunk, if 
applicable)?  Are there any regressions? ||
|| || If patch affects read/write path, did we test for performance regressions 
w/multiple workloads? ||
|| || If adding a new feature, were tests added and performed confirming it 
meets the expected SLA/use-case requirements for the feature? ||
|| || ||
|| Logging || ||
|| || Are logging statements logged at the correct level? ||
|| || Are there logs in the critical path that could affect performance? ||
|| || Is there any log that could be added to communicate status or 
troubleshoot potential problems in this feature? ||
|| || Can any unnecessary logging statement be removed? ||

[jira] [Updated] (CASSANDRA-9830) Option to disable bloom filter in highest level of LCS sstables

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-9830:
---
Fix Version/s: (was: 3.x)
   3.2

> Option to disable bloom filter in highest level of LCS sstables
> ---
>
> Key: CASSANDRA-9830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9830
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Compaction
>Reporter: Jonathan Ellis
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: performance
> Fix For: 3.2
>
>
> We expect about 90% of data to be in the highest level of LCS in a fully 
> populated series.  (See also CASSANDRA-9829.)
> Thus if the user is primarily asking for data (partitions) that has actually 
> been inserted, the bloom filter on the highest level only helps reject 
> sstables about 10% of the time.
> We should add an option that suppresses bloom filter creation on top-level 
> sstables.  This will dramatically reduce memory usage for LCS and may even 
> improve performance as we no longer check a low-value filter.
> (This is also an idea from RocksDB.)



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

[jira] [Commented] (CASSANDRA-7225) cqlsh help for CQL3 is often incorrect and should be modernized

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-7225:
-

Thanks, updated all three branches with these changes:
* fixed broken links
* fixed os.path.exists thing
* changed {{HELP ASCII}} and {{HELP TEXT}} to open _#constants_ ; added new 
{{HELP UNICODE}} for help on unicode characters in cqlsh
* removed cqlsh output for {{HELP TYPES}} (it had no additional information 
anyway)
* removed {{HELP LIST}}
* like the idea with the {{browser}} preference - added that {{browser}} 
preference to {{[ui]}} section in {{cqlshrc}} (works at least with firefox on 
my Mac)


> cqlsh help for CQL3 is often incorrect and should be modernized
> ---
>
> Key: CASSANDRA-7225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7225
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website, Tools
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
>  Labels: cqlsh
> Fix For: 3.2, 2.2.x
>
> Attachments: 7225-add-cql-docs-to-debian-package.patch, 
> 7225-cqlhelp.txt, EXPAND.pdf
>
>
> Just a small line of text in cqlsh "help" command indicates that < is <= and 
> > is >= in CQL.
> This is confusing to many people (including me :) ) because I did not expect 
> < to return the "equals" portion.
> Please allow distinct behaviours for <, <=, > and >= in CQL queries. Maybe in 
> combination with CASSANDRA-5184 and/or CASSANDRA-4914 



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

[jira] [Created] (CASSANDRA-10730) periodic timeout errors in dtest

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10730:


 Summary: periodic timeout errors in dtest
 Key: CASSANDRA-10730
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10730
 Project: Cassandra
  Issue Type: Bug
Reporter: Jim Witschey
Assignee: Jim Witschey


Dtests often fail with connection timeout errors. For example:

http://cassci.datastax.com/job/cassandra-3.1_dtest/lastCompletedBuild/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3/deletion_test/

{code}
('Unable to connect to any servers', {'127.0.0.1': 
OperationTimedOut('errors=Timed out creating connection (10 seconds), 
last_host=None',)})
{code}

We've merged a PR to increase timeouts:

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

It doesn't look like this has improved things:

http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/363/testReport/

Next steps here are

* to scrape Jenkins history to see if and how the number of tests failing this 
way has increased (it feels like it has). From there we can bisect over the 
dtests, ccm, or C*, depending on what looks like the source of the problem.
* to better instrument the dtest/ccm/C* startup process to see why the nodes 
start but don't successfully make the CQL port available.



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

[jira] [Commented] (CASSANDRA-10723) Rewrite INITCOND after renames and alters of UDT fields

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-10723:
--

No, it's not paranoia. It will break UDFs/UDAs, if the changed UDT field is 
used.

Assume a UDF/UDA like this (no guarantee for correct syntax):
{code}
CREATE TYPE my_user_type ... udt_field int;

CREATE FUNCTION state_fun ( arg my_user_type, col int ) ... AS $$
   arg.setInt("udt_field", arg.getInt("udt_field") + col);
   return arg;
$$;

CREATE AGGREGATE user_aggr ... SFUNC state_fun INITCOND { udt_field: 0 };
{code}

When issuing {{ALTER TYPE my_user_type RENAME udt_field TO foo;}}, the 
{{setInt}} and {{getInt}} calls will fail, because the field does not exist.
Also for {{ALTER TYPE my_user_type ALTER udt_field DATE}}, the {{setInt}} and 
{{getInt}} calls will fail, because the field is not an {{int}}.


> Rewrite INITCOND after renames and alters of UDT fields
> ---
>
> Key: CASSANDRA-10723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10723
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> (Follow-up to CASSANDRA-10721)
> In order to re-write an INITCOND value when a UDT is changed (component 
> renamed or type altered), we will have to check for broken aggregates first 
> (as we do not know why _exactly_ these are broken; CASSANDRA-10721 added 
> {{Function.isBroken()}}).
> If one of the affected aggregates is broken, the request *must fail*.
> If none of the affected aggregates is broken, we can re-write the binary 
> representation of the INITCOND and push schema migrations for these 
> aggregates.
> Still unclear, if the user needs permissions on both the UDT _and_ the 
> affected UDAs for that.
> Further, the UDT change and all UDA changes should be migrated in a single 
> mutation, which feels to be the biggest change. This is not a strict 
> requirement but would keep that schema change atomic.



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

[jira] [Updated] (CASSANDRA-10690) Remove unclear indexes() method from 2ndary index API

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10690:
--
Fix Version/s: (was: 3.2)
   3.1
   3.0.1

> Remove unclear indexes() method from 2ndary index API
> -
>
> Key: CASSANDRA-10690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10690
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Tyler Hobbs
> Fix For: 3.0.1, 3.1
>
>
> The new secondary index API does not notify indexes of single-row or slice 
> deletions unless specific columns are deleted.  I believe the problem is that 
> in {{SecondaryIndexManager.newUpdateTransaction()}}, we skip indexes unless 
> {{index.indexes(update.columns())}}.  When no columns are specified in the 
> the deletion, {{update.columns()}} is empty, which causes all indexes to be 
> skipped.
> I think the correct fix is to do something like this in the 
> {{ModificationStatement}} constructor:
> {code}
> if (type == StatementType.DELETE && modifiedColumns.isEmpty())
> modifiedColumns = cfm.partitionColumns();
> {code}
> However, I'm not sure if that may have unintended side-effects.  What do you 
> think, [~slebresne]?



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

[jira] [Updated] (CASSANDRA-7225) cqlsh help for CQL3 is often incorrect and should be modernized

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-7225:

Labels: cqlsh doc-impacting  (was: cqlsh)

> cqlsh help for CQL3 is often incorrect and should be modernized
> ---
>
> Key: CASSANDRA-7225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7225
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website, Tools
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
>  Labels: cqlsh, doc-impacting
> Fix For: 3.2, 2.2.x
>
> Attachments: 7225-add-cql-docs-to-debian-package.patch, 
> 7225-cqlhelp.txt, EXPAND.pdf
>
>
> Just a small line of text in cqlsh "help" command indicates that < is <= and 
> > is >= in CQL.
> This is confusing to many people (including me :) ) because I did not expect 
> < to return the "equals" portion.
> Please allow distinct behaviours for <, <=, > and >= in CQL queries. Maybe in 
> combination with CASSANDRA-5184 and/or CASSANDRA-4914 



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

[jira] [Commented] (CASSANDRA-9830) Option to disable bloom filter in highest level of LCS sstables

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-9830:


Rebased to latest trunk and squased.

* 
[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:9830-trunk-rebased]
* 
[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9830-trunk-rebased-testall/lastCompletedBuild/testReport/]
* 
[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9830-trunk-rebased-dtest/lastCompletedBuild/testReport/]

> Option to disable bloom filter in highest level of LCS sstables
> ---
>
> Key: CASSANDRA-9830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9830
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Compaction
>Reporter: Jonathan Ellis
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: performance
> Fix For: 3.x
>
>
> We expect about 90% of data to be in the highest level of LCS in a fully 
> populated series.  (See also CASSANDRA-9829.)
> Thus if the user is primarily asking for data (partitions) that has actually 
> been inserted, the bloom filter on the highest level only helps reject 
> sstables about 10% of the time.
> We should add an option that suppresses bloom filter creation on top-level 
> sstables.  This will dramatically reduce memory usage for LCS and may even 
> improve performance as we no longer check a low-value filter.
> (This is also an idea from RocksDB.)



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

[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10477:


[~bdeggleston] [~slebresne] can you chime in on whether I am on the right track 
here?

Should 
{{[StorageProxy.commitPaxos|https://github.com/apache/cassandra/blob/cassandra-2.1.11/src/java/org/apache/cassandra/service/StorageProxy.java#L494]}}
 not be sending messages to the local node that are eligible for hinting on 
timeout?


> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



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

[jira] [Updated] (CASSANDRA-7464) Replace sstable2json and json2sstable

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-7464:
---
Summary: Replace sstable2json and json2sstable  (was: Retire/replace 
sstable2json and json2sstable)

> Replace sstable2json and json2sstable
> -
>
> Key: CASSANDRA-7464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7464
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Priority: Minor
> Fix For: 3.x
>
>
> Both tools are pretty awful. They are primarily meant for debugging (there is 
> much more efficient and convenient ways to do import/export data), but their 
> output manage to be hard to handle both for humans and for tools (especially 
> as soon as you have modern stuff like composites).
> There is value to having tools to export sstable contents into a format that 
> is easy to manipulate by human and tools for debugging, small hacks and 
> general tinkering, but sstable2json and json2sstable are not that.  
> So I propose that we deprecate those tools and consider writing better 
> replacements. It shouldn't be too hard to come up with an output format that 
> is more aware of modern concepts like composites, UDTs, 



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

[jira] [Updated] (CASSANDRA-7464) Replace sstable2json and json2sstable

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-7464:
---
Fix Version/s: 3.x

> Replace sstable2json and json2sstable
> -
>
> Key: CASSANDRA-7464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7464
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Priority: Minor
> Fix For: 3.x
>
>
> Both tools are pretty awful. They are primarily meant for debugging (there is 
> much more efficient and convenient ways to do import/export data), but their 
> output manage to be hard to handle both for humans and for tools (especially 
> as soon as you have modern stuff like composites).
> There is value to having tools to export sstable contents into a format that 
> is easy to manipulate by human and tools for debugging, small hacks and 
> general tinkering, but sstable2json and json2sstable are not that.  
> So I propose that we deprecate those tools and consider writing better 
> replacements. It shouldn't be too hard to come up with an output format that 
> is more aware of modern concepts like composites, UDTs, 



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

[jira] [Comment Edited] (CASSANDRA-9830) Option to disable bloom filter in highest level of LCS sstables

[Paulo Motta (JIRA)]

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

Paulo Motta edited comment on CASSANDRA-9830 at 11/18/15 5:43 PM:
--

Rebased to latest trunk and squashed.

* 
[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:9830-trunk-rebased]
* 
[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9830-trunk-rebased-testall/lastCompletedBuild/testReport/]
* 
[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9830-trunk-rebased-dtest/lastCompletedBuild/testReport/]


was (Author: pauloricardomg):
Rebased to latest trunk and squased.

* 
[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:9830-trunk-rebased]
* 
[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9830-trunk-rebased-testall/lastCompletedBuild/testReport/]
* 
[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9830-trunk-rebased-dtest/lastCompletedBuild/testReport/]

> Option to disable bloom filter in highest level of LCS sstables
> ---
>
> Key: CASSANDRA-9830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9830
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Compaction
>Reporter: Jonathan Ellis
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: performance
> Fix For: 3.x
>
>
> We expect about 90% of data to be in the highest level of LCS in a fully 
> populated series.  (See also CASSANDRA-9829.)
> Thus if the user is primarily asking for data (partitions) that has actually 
> been inserted, the bloom filter on the highest level only helps reject 
> sstables about 10% of the time.
> We should add an option that suppresses bloom filter creation on top-level 
> sstables.  This will dramatically reduce memory usage for LCS and may even 
> improve performance as we no longer check a low-value filter.
> (This is also an idea from RocksDB.)



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

cassandra git commit: Improve NTS endpoints calculation

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 29ec013c2 -> c000da135


Improve NTS endpoints calculation

patch by Branimir Lambov; reviewed by Aleksey Yeschenko for
CASSANDRA-10200


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

Branch: refs/heads/trunk
Commit: c000da13563907b99fe220a7c8bde3c1dec74ad5
Parents: 29ec013
Author: Branimir Lambov 
Authored: Wed Aug 26 16:08:57 2015 +0300
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 15:44:21 2015 +

--
 CHANGES.txt |   1 +
 .../locator/NetworkTopologyStrategy.java| 157 --
 .../apache/cassandra/locator/TokenMetadata.java |  21 +-
 .../locator/NetworkTopologyStrategyTest.java| 213 ++-
 4 files changed, 317 insertions(+), 75 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c000da13/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 2710ed3..77034ef 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.2
+ * Improve NTS endpoints calculation (CASSANDRA-10200)
  * Improve performance of the folderSize function (CASSANDRA-10677)
  * Add support for type casting in selection clause (CASSANDRA-10310)
  * Added graphing option to cassandra-stress (CASSANDRA-7918)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c000da13/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java
--
diff --git a/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java 
b/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java
index 307a07f..9f74dcc 100644
--- a/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java
+++ b/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java
@@ -28,6 +28,7 @@ import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.dht.Token;
 import org.apache.cassandra.locator.TokenMetadata.Topology;
 import org.apache.cassandra.utils.FBUtilities;
+import org.apache.cassandra.utils.Pair;
 
 import com.google.common.collect.Multimap;
 
@@ -48,14 +49,12 @@ import com.google.common.collect.Multimap;
  */
 public class NetworkTopologyStrategy extends AbstractReplicationStrategy
 {
-private final IEndpointSnitch snitch;
 private final Map datacenters;
 private static final Logger logger = 
LoggerFactory.getLogger(NetworkTopologyStrategy.class);
 
 public NetworkTopologyStrategy(String keyspaceName, TokenMetadata 
tokenMetadata, IEndpointSnitch snitch, Map configOptions) 
throws ConfigurationException
 {
 super(keyspaceName, tokenMetadata, snitch, configOptions);
-this.snitch = snitch;
 
 Map newDatacenters = new HashMap();
 if (configOptions != null)
@@ -75,17 +74,78 @@ public class NetworkTopologyStrategy extends 
AbstractReplicationStrategy
 }
 
 /**
- * calculate endpoints in one pass through the tokens by tracking our 
progress in each DC, rack etc.
+ * Endpoint adder applying the replication rules for a given DC.
+ */
+private static final class DatacenterEndpoints
+{
+/** List accepted endpoints get pushed into. */
+Set endpoints;
+/**
+ * Racks encountered so far. Replicas are put into separate racks 
while possible.
+ * For efficiency the set is shared between the instances, using the 
location pair (dc, rack) to make sure
+ * clashing names aren't a problem.
+ */
+Set> racks;
+
+/** Number of replicas left to fill from this DC. */
+int rfLeft;
+int acceptableRackRepeats;
+
+DatacenterEndpoints(int rf, int rackCount, int nodeCount, 
Set endpoints, Set> racks)
+{
+this.endpoints = endpoints;
+this.racks = racks;
+// If there aren't enough nodes in this DC to fill the RF, the 
number of nodes is the effective RF.
+this.rfLeft = Math.min(rf, nodeCount);
+// If there aren't enough racks in this DC to fill the RF, we'll 
still use at least one node from each rack,
+// and the difference is to be filled by the first encountered 
nodes.
+acceptableRackRepeats = rf - rackCount;
+}
+
+/**
+ * Attempts to add an endpoint to the replicas for this datacenter, 
adding to the endpoints set if successful.
+ * 

[jira] [Comment Edited] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg edited comment on CASSANDRA-10477 at 11/18/15 4:06 PM:
--

Theory time. [There is a path by which tasks that are supposed to go through 
the local hint process for inserts need to 
use.|https://github.com/apache/cassandra/blob/cassandra-2.1.9/src/java/org/apache/cassandra/service/StorageProxy.java#L1027]
 Since we have a case where an insert does not go down this path it kind of 
implies that one of the other call sites for inserts is incorrect and is going 
through the remote message service path.

It only happens when the node is overloaded and local inserts start timing out. 
The reason you don't normally see it is that local inserts probably don't time 
out most of the time. One thing you could do is increase the mutation timeouts 
to see if you can get past the low performance period without timing out and 
hitting this.

However I think that the assertion is a symptom of a different problem and not 
the cause for the performance/availability issues. It's the canary in the coal 
mine letting you know this broken path is being taken due timeouts of local 
mutations.

I think the thing to do is search the call hierarchy of 
{{[StorageProxy.submitHint|https://github.com/apache/cassandra/blob/cassandra-2.1.9/src/java/org/apache/cassandra/service/StorageProxy.java#L944]}}
 to find a  path where it can be reached when timing out a local write. We know 
it's coming through MessageService in this instance which makes it a little 
trickier because the type of the callback isn't known. It looks like PAXOS 
might in some cases go down this path incorrectly.

I am going to try running a few things locally with some assertions to see if I 
can get it to send a message with hint delivery to itself.


was (Author: aweisberg):
Theory time. [There is a path by which tasks that are supposed to go through 
the local hint process for inserts need to 
use.|https://github.com/apache/cassandra/blob/cassandra-2.1.9/src/java/org/apache/cassandra/service/StorageProxy.java#L1027]
 Since we have a case where an insert does not go down this path it kind of 
implies that one of the other call sites for inserts is incorrect and is going 
through the remote message service path.

It only happens when the node is overloaded and local inserts start timing out. 
The reason you don't normally see it is that local inserts probably don't time 
out most of the time. One thing you could do is increase the mutation timeouts 
to see if you can get past the low performance period without timing out and 
hitting this.

However I think that the assertion is a symptom of a different problem and not 
the cause for the performance/availability issues. It's the canary in the coal 
mine letting you know this broken path is being taken due timeouts of local 
mutations.

I think the thing to do is search the call hierarchy of 
{{[StorageProxy.submitHint|https://github.com/apache/cassandra/blob/cassandra-2.1.9/src/java/org/apache/cassandra/service/StorageProxy.java#L944}}
 to find a  path where it can be reached when timing out a local write. We know 
it's coming through MessageService in this instance which makes it a little 
trickier because the type of the callback isn't known. It looks like PAXOS 
might in some cases go down this path incorrectly.

I am going to try running a few things locally with some assertions to see if I 
can get it to send a message with hint delivery to itself.

> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> 

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

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-10271:


[~bsnyder788] I need to fix similar issue for the group by clause 
(CASSANDRA-10707). If you can wait for it, it will simplify the work needed for 
this ticket.

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



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

[jira] [Commented] (CASSANDRA-10690) Remove unclear indexes() method from 2ndary index API

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10690:
---

Pragmatically, in this one particular case, yes. We've done it multiple times 
before on my memory (.1 of 2.0 and/or 2.1, maybe even later in the game) where 
going by the rules we shouldn't have.

Which is to say that I'm fine with committing to 3.0.1/3.1 if we are putting 
this in 3.x at all (the sooner the change is visible, the better).

But later (starting with 3.3? 3.5?) - once we stabilise, we should absolutely 
not break the rule.

FWIW, we have *some* freedom now with default interface method in Java 8, so 
that's something.



> Remove unclear indexes() method from 2ndary index API
> -
>
> Key: CASSANDRA-10690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10690
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Tyler Hobbs
> Fix For: 3.2
>
>
> The new secondary index API does not notify indexes of single-row or slice 
> deletions unless specific columns are deleted.  I believe the problem is that 
> in {{SecondaryIndexManager.newUpdateTransaction()}}, we skip indexes unless 
> {{index.indexes(update.columns())}}.  When no columns are specified in the 
> the deletion, {{update.columns()}} is empty, which causes all indexes to be 
> skipped.
> I think the correct fix is to do something like this in the 
> {{ModificationStatement}} constructor:
> {code}
> if (type == StatementType.DELETE && modifiedColumns.isEmpty())
> modifiedColumns = cfm.partitionColumns();
> {code}
> However, I'm not sure if that may have unintended side-effects.  What do you 
> think, [~slebresne]?



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

[jira] [Commented] (CASSANDRA-10200) NetworkTopologyStrategy.calculateNaturalEndpoints is rather inefficient

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10200:
---

Committed as 
[c000da13563907b99fe220a7c8bde3c1dec74ad5|https://github.com/apache/cassandra/commit/c000da13563907b99fe220a7c8bde3c1dec74ad5]
 to 3.2, thanks.

testall looks the same as vanilla trunk, dtests are utterly useless on trunk at 
the moment.

> NetworkTopologyStrategy.calculateNaturalEndpoints is rather inefficient
> ---
>
> Key: CASSANDRA-10200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10200
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Minor
> Fix For: 3.2
>
>
> The method is much more complicated than it needs to be and creates too many 
> maps and sets. The code is easy to simplify if we use the known number of 
> racks and nodes per datacentre to choose what to do in advance.



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

[jira] [Commented] (CASSANDRA-10723) Rewrite INITCOND after renames and alters of UDT fields

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-10723:
--

Changing the name of a UDT field or changing its type may or may not break a 
UDF/UDA functions.
For complete safety, we should reject all these changes - for all UDT used by a 
UDF (and UDA INITCOND).

bq. require any permissions on UDA itself

Because it could break the UDA/UDF which the current user is maybe not allowed 
to change (break).

> Rewrite INITCOND after renames and alters of UDT fields
> ---
>
> Key: CASSANDRA-10723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10723
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> (Follow-up to CASSANDRA-10721)
> In order to re-write an INITCOND value when a UDT is changed (component 
> renamed or type altered), we will have to check for broken aggregates first 
> (as we do not know why _exactly_ these are broken; CASSANDRA-10721 added 
> {{Function.isBroken()}}).
> If one of the affected aggregates is broken, the request *must fail*.
> If none of the affected aggregates is broken, we can re-write the binary 
> representation of the INITCOND and push schema migrations for these 
> aggregates.
> Still unclear, if the user needs permissions on both the UDT _and_ the 
> affected UDAs for that.
> Further, the UDT change and all UDA changes should be migrated in a single 
> mutation, which feels to be the biggest change. This is not a strict 
> requirement but would keep that schema change atomic.



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

[jira] [Commented] (CASSANDRA-10690) Remove unclear indexes() method from 2ndary index API

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-10690:
-

bq. 'll give my very personal opinion for what it's worth: the 2ndary API has 
been entirely rewritten for 3.0 with a fair emphasis on custom indexes and, to 
the best of my knowledge, no realistic implementation using it has yet been 
finished. So I think it's silly to call that API anything else that a beta and 
we'll be lucky if this is the only "problem" found by people actually trying to 
use it in real life.

Agreed.  I think we should get this interface right now, and not leave 
something ambiguous in 3.0.

bq. But later (starting with 3.3? 3.5?) - once we stabilise, we should 
absolutely not break the rule.

Also agreed.  If we want to do this we need to do it now.

> Remove unclear indexes() method from 2ndary index API
> -
>
> Key: CASSANDRA-10690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10690
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Tyler Hobbs
> Fix For: 3.2
>
>
> The new secondary index API does not notify indexes of single-row or slice 
> deletions unless specific columns are deleted.  I believe the problem is that 
> in {{SecondaryIndexManager.newUpdateTransaction()}}, we skip indexes unless 
> {{index.indexes(update.columns())}}.  When no columns are specified in the 
> the deletion, {{update.columns()}} is empty, which causes all indexes to be 
> skipped.
> I think the correct fix is to do something like this in the 
> {{ModificationStatement}} constructor:
> {code}
> if (type == StatementType.DELETE && modifiedColumns.isEmpty())
> modifiedColumns = cfm.partitionColumns();
> {code}
> However, I'm not sure if that may have unintended side-effects.  What do you 
> think, [~slebresne]?



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

[jira] [Commented] (CASSANDRA-10723) Rewrite INITCOND after renames and alters of UDT fields

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10723:
--

bq. Changing the name of a UDT field or changing its type may or may not break 
a UDF/UDA functions.

Maybe I'm being paranoid, but that's a problem in my opinion. I do think we 
might want to stick to what is done in CASSANDRA-10721 and forbid renames in 
UDT that is used in declared UDF/UDA completely. If people really want to 
rename, they'll have to drop the UDF/UDA, do the rename, and re-declare the 
UDF/UDA, which isn't super convenient, but it's still better imo than having 
the rename silently breaking functions (which will force you to re-declare the 
functions anyway).

> Rewrite INITCOND after renames and alters of UDT fields
> ---
>
> Key: CASSANDRA-10723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10723
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> (Follow-up to CASSANDRA-10721)
> In order to re-write an INITCOND value when a UDT is changed (component 
> renamed or type altered), we will have to check for broken aggregates first 
> (as we do not know why _exactly_ these are broken; CASSANDRA-10721 added 
> {{Function.isBroken()}}).
> If one of the affected aggregates is broken, the request *must fail*.
> If none of the affected aggregates is broken, we can re-write the binary 
> representation of the INITCOND and push schema migrations for these 
> aggregates.
> Still unclear, if the user needs permissions on both the UDT _and_ the 
> affected UDAs for that.
> Further, the UDT change and all UDA changes should be migrated in a single 
> mutation, which feels to be the biggest change. This is not a strict 
> requirement but would keep that schema change atomic.



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

[jira] [Commented] (CASSANDRA-10326) Performance is worse in 3.0

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10326:


I re-ran [Benedict's 
workload|http://cstar.datastax.com/graph?command=one_job=2082790c-8caf-11e5-b2c0-0256e416528f=99.9th_latency=1_user=1_aggregates=true=0=957.22=0=96.25]
 against the released 3.0.0 and 2.2.3. 3.0.0 did quite well being the same or 
faster/better in latency and throughput than 2.2.3 for 3 for three of the 
workloads.

The summary 99.9th percentile numbers on 1_user is odd with a latency spike in 
the last 100 seconds that causes the overall number to come out worse. Until 
that point 3.0.0 warms up a little slower than 2.2.3, but doesn't slow down 
quite as quickly.

For 2_user 3.0.0 is consistently a hair slower than 2.2.3, but 99.9th 
percentile latency is almost the same.

For 3_user 3.0.0 has significantly higher throughput and slightly better 99.9th 
percentile latency.

For 4_user 3.0.0 has significantly higher throughput and significantly better 
99.9th percentile latency.

I am not totally comfortable with the peak throughput of stress client relative 
to the potential throughput of a 3 node cluster. When I was running stress on 
my desktop I found that it saturated four cores, and that is more heavyweight 
than I would like from a benchmark client. I will run with a mocked out server 
to find out what the peak throughput of the client is on the cluster so we can 
have some idea of when we are approaching it.

> Performance is worse in 3.0
> ---
>
> Key: CASSANDRA-10326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10326
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Benedict
>Assignee: Ariel Weisberg
> Fix For: 3.0.x
>
>
> Performance is generally turning out to be worse after 8099, despite a number 
> of unrelated performance enhancements being delivered. This isn't entirely 
> unexpected, given a great deal of time was spent optimising the old code, 
> however things appear worse than we had hoped.
> My expectation was that workloads making extensive use of CQL constructs 
> would be faster post-8099, however the latest tests performed with very large 
> CQL rows, including use of collections, still exhibit performance below that 
> of 2.1 and 2.2. 
> Eventually, as the dataset size grows large enough and the locality of access 
> is just right, the reduction in size of our dataset will yield a window 
> during which some users will perform better due simply to improved page cache 
> hit rates. We seem to see this in some of the tests. However we should be at 
> least as fast (and really faster) off the bat.
> The following are some large partition benchmark results, with as many as 40K 
> rows per partition, running LCS. There are a number of parameters we can 
> modify to see how behaviour changes and under what scenarios we might still 
> be faster, but the picture painted isn't brilliant, and is consistent, so we 
> should really try and figure out what's up before GA.
> [trades-with-flags (collections), 
> blade11b|http://cstar.datastax.com/graph?stats=f0a17292-5a13-11e5-847a-42010af0688f=op_rate=1_user=1_aggregates=true=0=4387.02=0=122951.4]
> [trades-with-flags (collections), 
> blade11|http://cstar.datastax.com/graph?stats=e250-5a13-11e5-ae0d-42010af0688f=op_rate=1_user=1_aggregates=true=0=4424.75=0=130158.6]
> [trades (no collections), 
> blade11|http://cstar.datastax.com/graph?stats=9b7da48e-570c-11e5-90fe-42010af0688f=op_rate=1_user=1_aggregates=true=0=2682.46=0=142547.9]
> [~slebresne]: will you have time to look into this before GA?



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

[jira] [Created] (CASSANDRA-10729) SELECT statement with IN restrictions on partition key + ORDER BY + LIMIT return wrong results

[Benjamin Lerer (JIRA)]

Benjamin Lerer created CASSANDRA-10729:
--

 Summary: SELECT statement with IN restrictions on partition key + 
ORDER BY + LIMIT return wrong results
 Key: CASSANDRA-10729
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10729
 Project: Cassandra
  Issue Type: Bug
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer


If we execute a request with paging turned off, an IN restriction on the 
partition key, ORDER BY and LIMIT the result returned are not the expected ones.

The following test can be used to reproduce the problem.
{code}
createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, v text, PRIMARY 
KEY ((pk1, pk2), c) )");
execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1, 2, 
"A");
execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 2, 1, 
"B");
execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 3, 3, 
"C");
execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1, 4, 
"D");

assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN (?, 
?) ORDER BY c; ", 1, 1, 2),
   row("B"),
   row("A"),
   row("D"));

assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN (?, 
?) ORDER BY c LIMIT 2; ", 1, 1, 2),
   row("B"),
   row("A"));
{code}



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

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

[Andrew Hust (JIRA)]

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

Andrew Hust updated CASSANDRA-10715:

Component/s: CQL

> 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
>
> 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]
>   at 
> 

[jira] [Commented] (CASSANDRA-7225) cqlsh help for CQL3 is often incorrect and should be modernized

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-7225:


Thanks for the feedback. Looks good overall. Some minor comments:
* Please fix broken links
** #counter -> #counters
** #usingdate -> #usingdates
* It's always opening "https://cassandra.apache.org/doc/; because 
{{os.path.exists("file:///whatever")}} always returns False (you should 
probably remove the {{file://}} before verifying if it exist)
* HELP ASCII and HELP LIST are listed in "CQL help topics" but their help is on 
CQLSH, should they be listed as "Documented shell commands" instead?
* HELP TYPES shows help in both cqlsh and on the browser, should we keep just 
one of them?
* The default browser on debian (xdg-open) prints some strange characters on 
stderr, and there's no way to supress that on the webbrowser module:
{noformat}
cqlsh> help aggregates;
cqlsh> kioclient(4188) KMimeTypeRepository::parents: 
"/usr/share/mime/subclasses"  refers to unknown mimetype  
"application/vnd.ms-excel.sheet.binary.macroEnabled.12" 
kioclient(4188) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-excel.addin.macroEnabled.12" 
kioclient(4188) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  
"application/vnd.ms-powerpoint.slideshow.macroEnabled.12" 
kioclient(4188) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-excel.sheet.macroEnabled.12" 
kioclient(4188) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  
"application/vnd.ms-powerpoint.presentation.macroEnabled.12" 
kioclient(4188) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-word.template.macroEnabled.12" 
kioclient(4188) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-excel.template.macroEnabled.12" 
kioclient(4188) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  
"application/vnd.ms-powerpoint.template.macroEnabled.12" 
kioclient(4188) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-word.document.macroEnabled.12" 
kioclient(4188) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  
"application/vnd.ms-powerpoint.slide.macroEnabled.12"
{noformat}
I couldn't find alternatives to this problem. Should we at least provide a way 
to change the default browser on cqlshrc? If I switch to firefox this doesn't 
happen. We could maybe have "browser = default", and be able to change to 
"browser = firefox" via cqlshrc or options. It's possible to easily switch the 
browser on webbrowser module:
{{webbrowser.get(None).open_new_tab("https://cassandra.apache.org/doc/cql3/CQL-2.2.html#selectJson;)}}
 (None is the default, 'firefox' will open firefox, etc).

I'm not sure this will make to 3.1/3.0.1, since it's an improvement and not a 
bug fix, but on the other hand the documentation will become obsolete if we 
don't update there. Any thoughts [~iamaleksey]?

I will try on Windows and post the results later.

> cqlsh help for CQL3 is often incorrect and should be modernized
> ---
>
> Key: CASSANDRA-7225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7225
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website, Tools
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
>  Labels: cqlsh
> Fix For: 3.2, 2.2.x
>
> Attachments: 7225-add-cql-docs-to-debian-package.patch, 
> 7225-cqlhelp.txt, EXPAND.pdf
>
>
> Just a small line of text in cqlsh "help" command indicates that < is <= and 
> > is >= in CQL.
> This is confusing to many people (including me :) ) because I did not expect 
> < to return the "equals" portion.
> Please allow distinct behaviours for <, <=, > and >= in CQL queries. Maybe in 
> combination with CASSANDRA-5184 and/or CASSANDRA-4914 



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

[jira] [Commented] (CASSANDRA-10690) Remove unclear indexes() method from 2ndary index API

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10690:
--

I'll give my very personal opinion for what it's worth: the 2ndary API has been 
entirely rewritten for 3.0 with a fair emphasis on custom indexes and, to the 
best of my knowledge, no realistic implementation using it has yet been 
finished. So I think it's silly to call that API anything else that a beta and 
we'll be lucky if this is the only "problem" found by people actually trying to 
use it in real life.

So, _in theory_, I agree that if we want to provide meaningful backward 
compatibility, then no (breaking) change should be done before 4.0. But in 
practice, I don't think promising compatibility on that API for a relatively 
long period of time when no-one has used/tried it yet is really a service to 
our users. So that I'd personally prefer not trying to provide backward 
compatibility just yet and wait until it's been actually used to promise more 
than that (of course, we can still avoid doing change there for no good 
reason). Which is why I'd be equally fine pushing in 3.1 than 3.2 really.

But with that said, I don't really care all that much and if that opinion 
doesn't resonate and we prefer letting things as is and not changing anything 
until 4.0, so be it.


> Remove unclear indexes() method from 2ndary index API
> -
>
> Key: CASSANDRA-10690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10690
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Tyler Hobbs
> Fix For: 3.2
>
>
> The new secondary index API does not notify indexes of single-row or slice 
> deletions unless specific columns are deleted.  I believe the problem is that 
> in {{SecondaryIndexManager.newUpdateTransaction()}}, we skip indexes unless 
> {{index.indexes(update.columns())}}.  When no columns are specified in the 
> the deletion, {{update.columns()}} is empty, which causes all indexes to be 
> skipped.
> I think the correct fix is to do something like this in the 
> {{ModificationStatement}} constructor:
> {code}
> if (type == StatementType.DELETE && modifiedColumns.isEmpty())
> modifiedColumns = cfm.partitionColumns();
> {code}
> However, I'm not sure if that may have unintended side-effects.  What do you 
> think, [~slebresne]?



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

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

[Brett Snyder (JIRA)]

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

Brett Snyder commented on CASSANDRA-10271:
--

[~blerer]Sounds good, let me know when finished with the 10707 one, and thanks 
for the heads up!

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



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

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

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-8505:
---

I have pushed the fixes for 2.2 and 3.0 
[here|https://github.com/apache/cassandra/compare/trunk...blerer:8505-2.2] and 
[here|https://github.com/apache/cassandra/compare/trunk...blerer:8505-3.0].

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

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



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

[jira] [Updated] (CASSANDRA-10703) backport test parallelization build tasks

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-10703:
---
Reviewer: Ariel Weisberg

> backport test parallelization build tasks
> -
>
> Key: CASSANDRA-10703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10703
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Russ Hatch
>Assignee: Russ Hatch
> Fix For: 2.2.4, 3.0.1, 3.1
>
> Attachments: cassandra-2.2-10703.txt, cassandra-3.0-10703.txt, 
> cassandra-3.1-10703.txt
>
>
> CASSANDRA-10616 and CASSANDRA-10651 introduced some helpful changes to the 
> trunk build file which make it easier to run unit tests across multiple 
> machines, and to optionally create combined jacoco coverage reporting of the 
> same.
> These build tasks would be useful in future testing of 2.2, 3.0, and 3.1. 
> (2.1 has been omitted because we have no jacoco support there presently).



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

[jira] [Updated] (CASSANDRA-10704) remove cobertura from build file

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-10704:
---
Reviewer: Ariel Weisberg

> remove cobertura from build file
> 
>
> Key: CASSANDRA-10704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10704
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>Priority: Minor
> Fix For: 3.0.1, 3.1
>
> Attachments: trunk-10704.txt
>
>
> Since the project has adopted Jacoco, I don't believe the cobertura tasks are 
> in use any longer, and it's not certain if they still function. I don't think 
> there's any benefit from trying to keep both coverage tools working, and also 
> have the impression that cobertura development has slowed (or been slow to 
> support new versions of java). Jacoco's other advantage is it's simpler usage 
> (via a java agent), as compared to cobertura's offline code instrumentation 
> requiring more complexity.



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

[jira] [Updated] (CASSANDRA-10731) Bootstrap starts before migration responses have completed

[Mike Adamson (JIRA)]

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

Mike Adamson updated CASSANDRA-10731:
-
Reviewer: Sergio Bossa

> Bootstrap starts before migration responses have completed
> --
>
> Key: CASSANDRA-10731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10731
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Mike Adamson
>Assignee: Mike Adamson
> Fix For: 3.0.x
>
>
> We have a number of failing tests running on slow VMs that are failing 
> because {{MigrationManager.isReadyForBootstrap}} is return {{true}} when 
> there are still inflight responses being processed to migration requests. 
> This is happening because the {{MigrationTask.runMayThrow}} has completed but 
> the {{IAsyncCallback.response}} is still running.



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

[jira] [Commented] (CASSANDRA-10731) Bootstrap starts before migration responses have completed

[Mike Adamson (JIRA)]

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

Mike Adamson commented on CASSANDRA-10731:
--

The proposed solution for this is as follows. 

{{MigrationTask}} maintains a queue of {{CountdownLatch}} that complete as each 
response callback completes. {{MigrationManager.isReadyForBootstrap}} returns 
{{true}} if the queue is empty. If the queue is not empty then a new method 
{{MigrationManager.waitTillReadyForBootstrap}} is called by {{StorageService}}. 
This waits on each latch in the queue until they complete. The wait uses a 
system property {{cassandra.migration_task_wait_in_seconds}} defined timeout 
which defaults to 1 second.
 
||3.0||3.1||trunk||
|[branch|https://github.com/mike-tr-adamson/cassandra/tree/10731-3.0]|[branch|https://github.com/mike-tr-adamson/cassandra/tree/10731-3.1]|[branch|https://github.com/mike-tr-adamson/cassandra/tree/10731-trunk]|
|[testall|http://cassci.datastax.com/view/Dev/view/madamson/job/mike-tr-adamson-10731-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/madamson/job/mike-tr-adamson-10731-3.1-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/madamson/job/mike-tr-adamson-10731-trunk-testall/]|
|[dtests|http://cassci.datastax.com/view/Dev/view/madamson/job/mike-tr-adamson-10731-3.0-dtest/]|[dtests|http://cassci.datastax.com/view/Dev/view/madamson/job/mike-tr-adamson-10731-3.1-dtest/]|[dtests|http://cassci.datastax.com/view/Dev/view/madamson/job/mike-tr-adamson-10731-trunk-dtest/]|


> Bootstrap starts before migration responses have completed
> --
>
> Key: CASSANDRA-10731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10731
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Mike Adamson
>Assignee: Mike Adamson
> Fix For: 3.0.x
>
>
> We have a number of failing tests running on slow VMs that are failing 
> because {{MigrationManager.isReadyForBootstrap}} is return {{true}} when 
> there are still inflight responses being processed to migration requests. 
> This is happening because the {{MigrationTask.runMayThrow}} has completed but 
> the {{IAsyncCallback.response}} is still running.



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

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

[aleksey]

Merge branch 'cassandra-3.1' into trunk


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

Branch: refs/heads/trunk
Commit: b42afc424a6e12d8d7ae5b7cf44e139379ac6514
Parents: c000da1 02a12fa
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 18:05:07 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 18:05:07 2015 +

--
 build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b42afc42/build.xml
--
diff --cc build.xml
index b20ee71,e6c3217..d574e32
--- a/build.xml
+++ b/build.xml
@@@ -25,7 -25,7 +25,7 @@@
  
  
  
- 
 -
++
  
  
  http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

[1/2] cassandra git commit: Set base.version to 3.1

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk c000da135 -> b42afc424


Set base.version to 3.1


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

Branch: refs/heads/trunk
Commit: 02a12fa1e901257a16a4e677d3c2d4c86ffa3575
Parents: b0f159c
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 18:04:13 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 18:04:13 2015 +

--
 build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/02a12fa1/build.xml
--
diff --git a/build.xml b/build.xml
index 577506e..e6c3217 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

[jira] [Created] (CASSANDRA-10731) Bootstrap starts before migration responses have completed

[Mike Adamson (JIRA)]

Mike Adamson created CASSANDRA-10731:


 Summary: Bootstrap starts before migration responses have completed
 Key: CASSANDRA-10731
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10731
 Project: Cassandra
  Issue Type: Bug
  Components: Streaming and Messaging
Reporter: Mike Adamson
Assignee: Mike Adamson
 Fix For: 3.0.x


We have a number of failing tests running on slow VMs that are failing because 
{{MigrationManager.isReadyForBootstrap}} is return {{true}} when there are 
still inflight responses being processed to migration requests. This is 
happening because the {{MigrationTask.runMayThrow}} has completed but the 
{{IAsyncCallback.response}} is still running.



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

[jira] [Commented] (CASSANDRA-10678) add SSTable flush observer

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich commented on CASSANDRA-10678:
-

I will rename startRow to startPartition in new terminology, remove Source for 
now and add getFlushObserver doc.

> add SSTable flush observer
> --
>
> Key: CASSANDRA-10678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10678
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
> Fix For: 3.x
>
>
> Add general interface which can intercept per SSTable flush events e.g. - 
> start of the key, columns etc. Make Index interface return such observer on 
> request, which couples index with corresponding SSTable file if needed.



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

[jira] [Commented] (CASSANDRA-10731) Bootstrap starts before migration responses have completed

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-10731:
-

Do we really want to continue at all if this hasn't completed?  Does it make 
more sense to fail the bootstrap?

> Bootstrap starts before migration responses have completed
> --
>
> Key: CASSANDRA-10731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10731
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Mike Adamson
>Assignee: Mike Adamson
> Fix For: 3.0.x
>
>
> We have a number of failing tests running on slow VMs that are failing 
> because {{MigrationManager.isReadyForBootstrap}} is return {{true}} when 
> there are still inflight responses being processed to migration requests. 
> This is happening because the {{MigrationTask.runMayThrow}} has completed but 
> the {{IAsyncCallback.response}} is still running.



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

cassandra git commit: Set base.version to 3.1

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.1 b0f159c4a -> 02a12fa1e


Set base.version to 3.1


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

Branch: refs/heads/cassandra-3.1
Commit: 02a12fa1e901257a16a4e677d3c2d4c86ffa3575
Parents: b0f159c
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 18:04:13 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 18:04:13 2015 +

--
 build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/02a12fa1/build.xml
--
diff --git a/build.xml b/build.xml
index 577506e..e6c3217 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

[jira] [Updated] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-10477:
---
Fix Version/s: 3.x
   3.0.x
   2.2.x

> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



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

[jira] [Commented] (CASSANDRA-10681) make index building pluggable via IndexBuildTask

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich commented on CASSANDRA-10681:
-

Let me clarify a bit - it serializes a compilation of all of the indexes not 
building them. That's what I have already mentioned, Indexes are built separate 
but it's just a nature of the Index API since PerRowIndex is no more we have to 
build all of the indexes independently, this requires to pass through a data 
multiple times but I don't think it's necessary a problem if we list the 
assumption that indexes are build in one and only way  - by merging sstables 
together and feeding index collated row - and let API implementers decide how 
to build indexes based on the set of sstables. When the SSTable is added via 
streaming for example CASSANDRA-10678 would take care of creating indexes for 
it in case of SASI and Indexer API in case of standard indexes, so I don't 
really see a problem there, in case of side loading new compaction task per 
index is going to be triggered to build such indexes in necessary but we can't 
really go around that.

> make index building pluggable via IndexBuildTask
> 
>
> Key: CASSANDRA-10681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10681
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Local Write-Read Paths
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
>Priority: Minor
>  Labels: sasi
> Fix For: 3.x
>
>
> Currently index building assumes one and only way to build all of the indexes 
> - through SecondaryIndexBuilder - which merges all of the sstables together, 
> collates columns etc. Such works fine for built-in indexes but not for SASI 
> since it's attaches to every SSTable individually. We need a "IndexBuildTask" 
> interface (based on CompactionInfo.Holder) to be returned from Index on 
> demand to give power to SI interface implementers to decide how build should 
> work. This might be less effective for CassandraIndex, since this effectively 
> means that collation will have to be done multiple times on the same data, 
> but  nevertheless is a good compromise for clean interface to outside world.



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

[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-10477:
-

It seems like adding a paxos commit equivalent of StorageProxy.insertLocal, and 
submitting local commits that way would be the safest thing to do here. In 
theory, you should be able to add a check against the local address to 
StorageProxy.shouldHint and just drop the commit message if the node is 
overloaded, it should get back up to speed on the next paxos round. However 
there may be subtleties and edge cases that I'm not thinking of, so I don't 
want to recommend that without giving this more thought.

> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log 
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at 
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98) 
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.1.9.jar:2.1.9]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes 
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients 
> get a lot of timeouts. We need to restart the affected Cassandra node to get 
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the 
> assert from being logged. At some point the read latency becomes bad again. 
> Restarting the node where hinted handoff was disabled results in the read 
> latency being better again.



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

[jira] [Updated] (CASSANDRA-10678) add SSTable flush observer

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich updated CASSANDRA-10678:

Attachment: 0001-add-sstable-flush-observer.patch

Here is the patch with changes (rebased with trunk).

> add SSTable flush observer
> --
>
> Key: CASSANDRA-10678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10678
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
> Fix For: 3.x
>
> Attachments: 0001-add-sstable-flush-observer.patch
>
>
> Add general interface which can intercept per SSTable flush events e.g. - 
> start of the key, columns etc. Make Index interface return such observer on 
> request, which couples index with corresponding SSTable file if needed.



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

[jira] [Commented] (CASSANDRA-9465) No client warning on tombstone threshold

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-9465:


First off - sorry for the delay on review.

Feedback:
* Update comment on DebuggableThreadPoolExecutor.LocalSessionWrapper
* I'm concerned about null check in ExecutorLocals:
{code:title=ExecutorLocals.create}
if (traceState == null && clientWarnState == null)
return null;
else
return new ExecutorLocals(traceState, clientWarnState);
{code}
That's propagated into the thread local w/ExecutorLocals.set, so we're 
expecting all users of the ExecutorLocals to always check for null before 
accessing either of these? While I see us doing that with TraceState, I don't 
see the same for ClientWarn.State. If the relationship is "Both are set or both 
are null", the code in ExecutorLocals.create should reflect that relationship.

Also: I could be missing something here so feel free to clue me in; assigning 
and passing around ThreadLocal state between threads in an executor service 
isn't the clearest thing I've ever reviewed.

> No client warning on tombstone threshold
> 
>
> Key: CASSANDRA-9465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9465
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Adam Holmberg
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 2.2.x
>
>
> It appears that a client warning is not coming back for the tombstone 
> threshold case. The batch warning works.
> Repro:
> Create a data condition with tombstone_warn_threshold < tombstones < 
> tombstone_failure_threshold
> Query the row
> Expected:
> Warning in server log, warning returned to client
> I'm basing this expectation on what I see 
> [here|https://github.com/apache/cassandra/blob/68722e7e594d228b4bf14c8cd8cbee19b50835ec/src/java/org/apache/cassandra/db/filter/SliceQueryFilter.java#L235-L247]
> Observed:
> Warning in server log, no warning flag in response message.



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

[jira] [Comment Edited] (CASSANDRA-10681) make index building pluggable via IndexBuildTask

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich edited comment on CASSANDRA-10681 at 11/18/15 8:17 PM:
---

Let me clarify a bit - it serializes a compilation of all of the indexes not 
building them. That's what I have already mentioned, Indexes are built separate 
but it's just a nature of the Index API since PerRowIndex is no more we have to 
build all of the indexes independently, this requires to pass through a data 
multiple times but I don't think it's necessary a problem if we list the 
assumption that indexes are build in one and only way  - by merging sstables 
together and feeding index collated row - and let API implementers decide how 
to build indexes based on the set of sstables. When the SSTable is added via 
streaming for example CASSANDRA-10678 would take care of creating indexes for 
it in case of SASI and Indexer API in case of standard indexes, so I don't 
really see a problem there, in case of side loading new compaction task per 
index is going to be triggered to build such indexes if necessary but we can't 
really go around that.


was (Author: xedin):
Let me clarify a bit - it serializes a compilation of all of the indexes not 
building them. That's what I have already mentioned, Indexes are built separate 
but it's just a nature of the Index API since PerRowIndex is no more we have to 
build all of the indexes independently, this requires to pass through a data 
multiple times but I don't think it's necessary a problem if we list the 
assumption that indexes are build in one and only way  - by merging sstables 
together and feeding index collated row - and let API implementers decide how 
to build indexes based on the set of sstables. When the SSTable is added via 
streaming for example CASSANDRA-10678 would take care of creating indexes for 
it in case of SASI and Indexer API in case of standard indexes, so I don't 
really see a problem there, in case of side loading new compaction task per 
index is going to be triggered to build such indexes in necessary but we can't 
really go around that.

> make index building pluggable via IndexBuildTask
> 
>
> Key: CASSANDRA-10681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10681
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Local Write-Read Paths
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
>Priority: Minor
>  Labels: sasi
> Fix For: 3.x
>
>
> Currently index building assumes one and only way to build all of the indexes 
> - through SecondaryIndexBuilder - which merges all of the sstables together, 
> collates columns etc. Such works fine for built-in indexes but not for SASI 
> since it's attaches to every SSTable individually. We need a "IndexBuildTask" 
> interface (based on CompactionInfo.Holder) to be returned from Index on 
> demand to give power to SI interface implementers to decide how build should 
> work. This might be less effective for CassandraIndex, since this effectively 
> means that collation will have to be done multiple times on the same data, 
> but  nevertheless is a good compromise for clean interface to outside world.



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

[jira] [Commented] (CASSANDRA-10703) backport test parallelization build tasks

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10703:


LGTM, +1

> backport test parallelization build tasks
> -
>
> Key: CASSANDRA-10703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10703
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Russ Hatch
>Assignee: Russ Hatch
> Fix For: 2.2.4, 3.0.1, 3.1
>
> Attachments: cassandra-2.2-10703.txt, cassandra-3.0-10703.txt, 
> cassandra-3.1-10703.txt
>
>
> CASSANDRA-10616 and CASSANDRA-10651 introduced some helpful changes to the 
> trunk build file which make it easier to run unit tests across multiple 
> machines, and to optionally create combined jacoco coverage reporting of the 
> same.
> These build tasks would be useful in future testing of 2.2, 3.0, and 3.1. 
> (2.1 has been omitted because we have no jacoco support there presently).



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

[jira] [Commented] (CASSANDRA-10587) sstablemetadata NPE on cassandra 2.2

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10587:


When you upgraded did you run upgradesstables? Can you provide instructions to 
reproduce this?

> sstablemetadata NPE on cassandra 2.2
> 
>
> Key: CASSANDRA-10587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Tiago Batista
>Assignee: Ariel Weisberg
> Fix For: 2.2.x, 3.x
>
>
> I have recently upgraded my cassandra cluster to 2.2, currently running 
> 2.2.3. After running the first repair, cassandra renames the sstables to the 
> new naming schema that does not contain the keyspace name.
>  This causes sstablemetadata to fail with the following stack trace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:275)
> at 
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:172)
> at 
> org.apache.cassandra.tools.SSTableMetadataViewer.main(SSTableMetadataViewer.java:52)
> {noformat}



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

[jira] [Updated] (CASSANDRA-10678) add SSTable flush observer

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich updated CASSANDRA-10678:

Attachment: (was: 0001-add-sstable-flush-observer.patch)

> add SSTable flush observer
> --
>
> Key: CASSANDRA-10678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10678
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
> Fix For: 3.x
>
> Attachments: 0001-Add-sstable-flush-observer.patch
>
>
> Add general interface which can intercept per SSTable flush events e.g. - 
> start of the key, columns etc. Make Index interface return such observer on 
> request, which couples index with corresponding SSTable file if needed.



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

[jira] [Updated] (CASSANDRA-10678) add SSTable flush observer

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich updated CASSANDRA-10678:

Attachment: 0001-Add-sstable-flush-observer.patch

> add SSTable flush observer
> --
>
> Key: CASSANDRA-10678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10678
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
> Fix For: 3.x
>
> Attachments: 0001-Add-sstable-flush-observer.patch
>
>
> Add general interface which can intercept per SSTable flush events e.g. - 
> start of the key, columns etc. Make Index interface return such observer on 
> request, which couples index with corresponding SSTable file if needed.



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

[jira] [Commented] (CASSANDRA-10541) cqlshlib tests cannot run on Windows

[Jim Witschey (JIRA)]

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

Jim Witschey commented on CASSANDRA-10541:
--

[~pauloricardomg] I've set up jobs for your branch on on Windows and Linux

- 
[Windows|http://cassci.datastax.com/view/All_Jobs/job/mambocab-scratch_cqlshlib_tests-windows-paulomotta/]
- 
[Linux|http://cassci.datastax.com/job/mambocab-scratch_cqlshlib_tests-linux-paulomotta/]

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



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

[jira] [Commented] (CASSANDRA-10704) remove cobertura from build file

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10704:


[~rhatch] when you submit patches can you do it as a branch that runs in 
Cassci? Just to sanity check that the Cassci jobs are using the build scripts 
the same way we do when we run it manually and we don't break that.

> remove cobertura from build file
> 
>
> Key: CASSANDRA-10704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10704
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>Priority: Minor
> Fix For: 3.0.1, 3.1
>
> Attachments: trunk-10704.txt
>
>
> Since the project has adopted Jacoco, I don't believe the cobertura tasks are 
> in use any longer, and it's not certain if they still function. I don't think 
> there's any benefit from trying to keep both coverage tools working, and also 
> have the impression that cobertura development has slowed (or been slow to 
> support new versions of java). Jacoco's other advantage is it's simpler usage 
> (via a java agent), as compared to cobertura's offline code instrumentation 
> requiring more complexity.



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

[jira] [Comment Edited] (CASSANDRA-10681) make index building pluggable via IndexBuildTask

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich edited comment on CASSANDRA-10681 at 11/18/15 8:35 PM:
---

Let me clarify a bit - it serializes a compilation of all of the indexes not 
building them. That's what I have already mentioned, Indexes are built separate 
but it's just a nature of the Index API since PerRowIndex is no more we have to 
build all of the indexes independently, this requires to pass through the data 
multiple times but I don't think it's necessary a problem if we remove the 
assumption that indexes are built in one and only way  - by merging sstables 
together and feeding index collated row - and let API implementers decide how 
to build indexes based on the set of sstables. When SSTable is added via 
streaming for example CASSANDRA-10678 would take care of creating indexes for 
it in case of SASI and Indexer API in case of standard indexes, so I don't 
really see a problem there, in case of sideloading new compaction task per 
index is going to be triggered to build such indexes if necessary but we can't 
really go around that.


was (Author: xedin):
Let me clarify a bit - it serializes a compilation of all of the indexes not 
building them. That's what I have already mentioned, Indexes are built separate 
but it's just a nature of the Index API since PerRowIndex is no more we have to 
build all of the indexes independently, this requires to pass through a data 
multiple times but I don't think it's necessary a problem if we list the 
assumption that indexes are build in one and only way  - by merging sstables 
together and feeding index collated row - and let API implementers decide how 
to build indexes based on the set of sstables. When the SSTable is added via 
streaming for example CASSANDRA-10678 would take care of creating indexes for 
it in case of SASI and Indexer API in case of standard indexes, so I don't 
really see a problem there, in case of side loading new compaction task per 
index is going to be triggered to build such indexes if necessary but we can't 
really go around that.

> make index building pluggable via IndexBuildTask
> 
>
> Key: CASSANDRA-10681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10681
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Local Write-Read Paths
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
>Priority: Minor
>  Labels: sasi
> Fix For: 3.x
>
>
> Currently index building assumes one and only way to build all of the indexes 
> - through SecondaryIndexBuilder - which merges all of the sstables together, 
> collates columns etc. Such works fine for built-in indexes but not for SASI 
> since it's attaches to every SSTable individually. We need a "IndexBuildTask" 
> interface (based on CompactionInfo.Holder) to be returned from Index on 
> demand to give power to SI interface implementers to decide how build should 
> work. This might be less effective for CassandraIndex, since this effectively 
> means that collation will have to be done multiple times on the same data, 
> but  nevertheless is a good compromise for clean interface to outside world.



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

[jira] [Assigned] (CASSANDRA-10587) sstablemetadata NPE on cassandra 2.2

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg reassigned CASSANDRA-10587:
--

Assignee: Ariel Weisberg

> sstablemetadata NPE on cassandra 2.2
> 
>
> Key: CASSANDRA-10587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Tiago Batista
>Assignee: Ariel Weisberg
> Fix For: 2.2.x, 3.x
>
>
> I have recently upgraded my cassandra cluster to 2.2, currently running 
> 2.2.3. After running the first repair, cassandra renames the sstables to the 
> new naming schema that does not contain the keyspace name.
>  This causes sstablemetadata to fail with the following stack trace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:275)
> at 
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:172)
> at 
> org.apache.cassandra.tools.SSTableMetadataViewer.main(SSTableMetadataViewer.java:52)
> {noformat}



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

[jira] [Commented] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'

[Michael Edge (JIRA)]

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

Michael Edge commented on CASSANDRA-10719:
--

Sure, no worries. I'll provide a total of 3 patches, for the latest versions of 
2.1, 2,2 and 3.0

> Inconsistencies within CQL 'describe', and CQL docs/'help describe'
> ---
>
> Key: CASSANDRA-10719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10719
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL, Documentation and Website
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Minor
>  Labels: cqlsh, docs
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10719-Describe.patch
>
>
> While investigating the issue CASSANDRA-9678 I noticed a number of 
> inconsistencies in the way 'describe' operates, so I'm opening a new issue to 
> address these. This issue will also address CASSANDRA-9678.
> I'd be happy to work on this.
> There are a number of inconsistencies in the way 'describe' operates within 
> cqlsh, and also in the 'help describe' description within cqlsh compared to 
> the CQL documentation (at 
> http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html)
> For example, 'desc functions' will list all functions for all keyspaces 
> regardless of whether there is a current keyspace or not, whereas 'desc 
> tables' or 'desc types' will list only the tables or types for the current 
> keyspace.
> Some commands exist in cqlsh that are not in the CQL documentation, nor in 
> the 'help describe' description. For example, 'desc functions' is a valid 
> CQLSH command but does not appear in either the CQL docs or 'help describe'.
> I suggest we align the way the 'describe' command works so that it works 
> consistently regardless of whether it is describing a table, type, function 
> or any other database object, and also update the CQL and 'help describe' 
> docs to match. Since 'describe tables' and it's variants has been around the 
> longest we should probably align other 'describe' commands to 'describe 
> tables'.
> My preliminary analysis has shown at least the following inconsistencies:
> - 'desc functions' (with current keyspace), differs from 'desc tables' and 
> 'desc types'.
> - a number of commands are missing from the CQL docs or 'help describe, such 
> as: desc table ., desc functions (no current keyspace), 
> desc function , desc type ., etc.



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

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

[aleksey]

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

Branch: refs/heads/trunk
Commit: 2753f95e61d01f25360e1610b63319acde304c3c
Parents: 5cc02dd 077f9bf
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:53:39 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:53:39 2015 +

--

--

[jira] [Updated] (CASSANDRA-10681) make index building pluggable via IndexBuildTask

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10681:
--
Reviewer: Sam Tunnicliffe  (was: Jason Brown)

> make index building pluggable via IndexBuildTask
> 
>
> Key: CASSANDRA-10681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10681
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Local Write-Read Paths
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
>Priority: Minor
>  Labels: sasi
> Fix For: 3.x
>
>
> Currently index building assumes one and only way to build all of the indexes 
> - through SecondaryIndexBuilder - which merges all of the sstables together, 
> collates columns etc. Such works fine for built-in indexes but not for SASI 
> since it's attaches to every SSTable individually. We need a "IndexBuildTask" 
> interface (based on CompactionInfo.Holder) to be returned from Index on 
> demand to give power to SI interface implementers to decide how build should 
> work. This might be less effective for CassandraIndex, since this effectively 
> means that collation will have to be done multiple times on the same data, 
> but  nevertheless is a good compromise for clean interface to outside world.



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

cassandra git commit: Add file path to CorruptSSTableException message

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 8385bb639 -> 5a665b805


Add file path to CorruptSSTableException message

patch by Jeremiah D Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-10582


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

Branch: refs/heads/cassandra-2.1
Commit: 5a665b805ea8755112a5f1d0d81e8cbc41915eb0
Parents: 8385bb6
Author: Jeremiah D Jordan 
Authored: Wed Nov 11 14:30:11 2015 -0600
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:45:45 2015 +

--
 .../org/apache/cassandra/io/sstable/CorruptSSTableException.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5a665b80/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java 
b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
index a71daaf..0fe316d 100644
--- a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
+++ b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
@@ -25,7 +25,7 @@ public class CorruptSSTableException extends RuntimeException
 
 public CorruptSSTableException(Exception cause, File path)
 {
-super(cause);
+super("Corrupted: " + path, cause);
 this.path = path;
 }
 

[2/3] 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/d09b6c69
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d09b6c69
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d09b6c69

Branch: refs/heads/cassandra-3.0
Commit: d09b6c69e0e0c6adff8e679f2286a335d883f1bd
Parents: 077f9bf 246cb88
Author: Marcus Eriksson 
Authored: Wed Nov 18 13:59:09 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 13:59:09 2015 +0100

--
 CHANGES.txt |  1 +
 .../compaction/WrappingCompactionStrategy.java  | 16 +
 .../LeveledCompactionStrategyTest.java  | 35 
 3 files changed, 52 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d09b6c69/CHANGES.txt
--
diff --cc CHANGES.txt
index 572afc2,6ccde28..c3dacc2
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,17 -1,5 +1,18 @@@
 -2.1.12
 +2.2.4
 + * Don't do anticompaction after subrange repair (CASSANDRA-10422)
 + * Fix SimpleDateType type compatibility (CASSANDRA-10027)
 + * (Hadoop) fix splits calculation (CASSANDRA-10640)
 + * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058)
 + * (cqlsh) show partial trace if incomplete after max_trace_wait 
(CASSANDRA-7645)
 + * Use most up-to-date version of schema for system tables (CASSANDRA-10652)
 + * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628)
 + * Expose phi values from failure detector via JMX and tweak debug
 +   and trace logging (CASSANDRA-9526)
 + * Fix RangeNamesQueryPager (CASSANDRA-10509)
 + * Deprecate Pig support (CASSANDRA-10542)
 + * Reduce contention getting instances of CompositeType (CASSANDRA-10433)
 +Merged from 2.1:
+  * Don't remove level info when running upgradesstables (CASSANDRA-10692)
   * Create compression chunk for sending file only (CASSANDRA-10680)
   * Make buffered read size configurable (CASSANDRA-10249)
   * Forbid compact clustering column type changes in ALTER TABLE 
(CASSANDRA-8879)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d09b6c69/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
--
diff --cc 
src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
index 9daa0c5,71a6bc1..8555432
--- 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
@@@ -32,10 -32,10 +32,11 @@@ import org.slf4j.LoggerFactory
  
  import org.apache.cassandra.config.CFMetaData;
  import org.apache.cassandra.db.ColumnFamilyStore;
++import org.apache.cassandra.db.lifecycle.LifecycleTransaction;
  import org.apache.cassandra.dht.Range;
  import org.apache.cassandra.dht.Token;
 +import org.apache.cassandra.io.sstable.format.SSTableReader;
  import org.apache.cassandra.io.sstable.ISSTableScanner;
 -import org.apache.cassandra.io.sstable.SSTableReader;
  import org.apache.cassandra.notifications.INotification;
  import org.apache.cassandra.notifications.INotificationConsumer;
  import org.apache.cassandra.notifications.SSTableAddedNotification;
@@@ -123,6 -123,21 +124,21 @@@ public final class WrappingCompactionSt
  }
  
  @Override
 -public AbstractCompactionTask getCompactionTask(Collection 
sstables, final int gcBefore, long maxSSTableBytes)
++public AbstractCompactionTask getCompactionTask(LifecycleTransaction txn, 
final int gcBefore, long maxSSTableBytes)
+ {
 -assert sstables.size() > 0;
 -boolean repairedSSTables = sstables.iterator().next().isRepaired();
 -for (SSTableReader sstable : sstables)
++assert txn.originals().size() > 0;
++boolean repairedSSTables = 
txn.originals().iterator().next().isRepaired();
++for (SSTableReader sstable : txn.originals())
+ if (repairedSSTables != sstable.isRepaired())
+ throw new RuntimeException("Can't mix repaired and unrepaired 
sstables in a compaction");
+ 
+ if (repairedSSTables)
 -return repaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
++return repaired.getCompactionTask(txn, gcBefore, maxSSTableBytes);
+ else
 -return unrepaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
++return unrepaired.getCompactionTask(txn, gcBefore, 
maxSSTableBytes);
+ }
+ 
+ @Override
  public synchronized AbstractCompactionTask 
getUserDefinedTask(Collection sstables, int gcBefore)
  {
  assert !sstables.isEmpty();

[3/3] 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/12fd5d27
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/12fd5d27
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/12fd5d27

Branch: refs/heads/cassandra-3.0
Commit: 12fd5d270a8de2bcf34b082b410448eba02be4c4
Parents: 2753f95 d09b6c6
Author: Marcus Eriksson 
Authored: Wed Nov 18 14:00:02 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 14:00:02 2015 +0100

--

--

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

Branch: refs/heads/cassandra-2.2
Commit: d09b6c69e0e0c6adff8e679f2286a335d883f1bd
Parents: 077f9bf 246cb88
Author: Marcus Eriksson 
Authored: Wed Nov 18 13:59:09 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 13:59:09 2015 +0100

--
 CHANGES.txt |  1 +
 .../compaction/WrappingCompactionStrategy.java  | 16 +
 .../LeveledCompactionStrategyTest.java  | 35 
 3 files changed, 52 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d09b6c69/CHANGES.txt
--
diff --cc CHANGES.txt
index 572afc2,6ccde28..c3dacc2
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,17 -1,5 +1,18 @@@
 -2.1.12
 +2.2.4
 + * Don't do anticompaction after subrange repair (CASSANDRA-10422)
 + * Fix SimpleDateType type compatibility (CASSANDRA-10027)
 + * (Hadoop) fix splits calculation (CASSANDRA-10640)
 + * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058)
 + * (cqlsh) show partial trace if incomplete after max_trace_wait 
(CASSANDRA-7645)
 + * Use most up-to-date version of schema for system tables (CASSANDRA-10652)
 + * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628)
 + * Expose phi values from failure detector via JMX and tweak debug
 +   and trace logging (CASSANDRA-9526)
 + * Fix RangeNamesQueryPager (CASSANDRA-10509)
 + * Deprecate Pig support (CASSANDRA-10542)
 + * Reduce contention getting instances of CompositeType (CASSANDRA-10433)
 +Merged from 2.1:
+  * Don't remove level info when running upgradesstables (CASSANDRA-10692)
   * Create compression chunk for sending file only (CASSANDRA-10680)
   * Make buffered read size configurable (CASSANDRA-10249)
   * Forbid compact clustering column type changes in ALTER TABLE 
(CASSANDRA-8879)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d09b6c69/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
--
diff --cc 
src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
index 9daa0c5,71a6bc1..8555432
--- 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
@@@ -32,10 -32,10 +32,11 @@@ import org.slf4j.LoggerFactory
  
  import org.apache.cassandra.config.CFMetaData;
  import org.apache.cassandra.db.ColumnFamilyStore;
++import org.apache.cassandra.db.lifecycle.LifecycleTransaction;
  import org.apache.cassandra.dht.Range;
  import org.apache.cassandra.dht.Token;
 +import org.apache.cassandra.io.sstable.format.SSTableReader;
  import org.apache.cassandra.io.sstable.ISSTableScanner;
 -import org.apache.cassandra.io.sstable.SSTableReader;
  import org.apache.cassandra.notifications.INotification;
  import org.apache.cassandra.notifications.INotificationConsumer;
  import org.apache.cassandra.notifications.SSTableAddedNotification;
@@@ -123,6 -123,21 +124,21 @@@ public final class WrappingCompactionSt
  }
  
  @Override
 -public AbstractCompactionTask getCompactionTask(Collection 
sstables, final int gcBefore, long maxSSTableBytes)
++public AbstractCompactionTask getCompactionTask(LifecycleTransaction txn, 
final int gcBefore, long maxSSTableBytes)
+ {
 -assert sstables.size() > 0;
 -boolean repairedSSTables = sstables.iterator().next().isRepaired();
 -for (SSTableReader sstable : sstables)
++assert txn.originals().size() > 0;
++boolean repairedSSTables = 
txn.originals().iterator().next().isRepaired();
++for (SSTableReader sstable : txn.originals())
+ if (repairedSSTables != sstable.isRepaired())
+ throw new RuntimeException("Can't mix repaired and unrepaired 
sstables in a compaction");
+ 
+ if (repairedSSTables)
 -return repaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
++return repaired.getCompactionTask(txn, gcBefore, maxSSTableBytes);
+ else
 -return unrepaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
++return unrepaired.getCompactionTask(txn, gcBefore, 
maxSSTableBytes);
+ }
+ 
+ @Override
  public synchronized AbstractCompactionTask 
getUserDefinedTask(Collection sstables, int gcBefore)
  {
  assert !sstables.isEmpty();

[1/3] cassandra git commit: Don't remove level info when running upgradesstables

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 2753f95e6 -> 12fd5d270


Don't remove level info when running upgradesstables

Patch by marcuse; reviewed by yukim for CASSANDRA-10692


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

Branch: refs/heads/cassandra-3.0
Commit: 246cb883ab09bc69e842b8124c1537b38bb54335
Parents: 5a665b8
Author: Marcus Eriksson 
Authored: Thu Nov 12 08:12:01 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 13:58:08 2015 +0100

--
 CHANGES.txt |  1 +
 .../compaction/WrappingCompactionStrategy.java  | 15 +
 .../LeveledCompactionStrategyTest.java  | 35 
 3 files changed, 51 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 008d4d4..6ccde28 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.12
+ * Don't remove level info when running upgradesstables (CASSANDRA-10692)
  * Create compression chunk for sending file only (CASSANDRA-10680)
  * Make buffered read size configurable (CASSANDRA-10249)
  * Forbid compact clustering column type changes in ALTER TABLE 
(CASSANDRA-8879)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
index ae67599..71a6bc1 100644
--- 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
@@ -123,6 +123,21 @@ public final class WrappingCompactionStrategy extends 
AbstractCompactionStrategy
 }
 
 @Override
+public AbstractCompactionTask getCompactionTask(Collection 
sstables, final int gcBefore, long maxSSTableBytes)
+{
+assert sstables.size() > 0;
+boolean repairedSSTables = sstables.iterator().next().isRepaired();
+for (SSTableReader sstable : sstables)
+if (repairedSSTables != sstable.isRepaired())
+throw new RuntimeException("Can't mix repaired and unrepaired 
sstables in a compaction");
+
+if (repairedSSTables)
+return repaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+else
+return unrepaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+}
+
+@Override
 public synchronized AbstractCompactionTask 
getUserDefinedTask(Collection sstables, int gcBefore)
 {
 assert !sstables.isEmpty();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
index da54eee..cb9cbb4 100644
--- 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
+++ 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
@@ -23,6 +23,7 @@ import java.util.Collection;
 import java.util.List;
 import java.util.Random;
 import java.util.UUID;
+import java.util.concurrent.ExecutionException;
 
 import org.junit.After;
 import org.junit.Before;
@@ -278,4 +279,38 @@ public class LeveledCompactionStrategyTest extends 
SchemaLoader
 assertTrue(unrepaired.manifest.getLevel(1).contains(sstable2));
 assertFalse(repaired.manifest.getLevel(1).contains(sstable2));
 }
+
+@Test
+public void testDontRemoveLevelInfoUpgradeSSTables() throws 
InterruptedException, ExecutionException
+{
+byte [] b = new byte[100 * 1024];
+new Random().nextBytes(b);
+ByteBuffer value = ByteBuffer.wrap(b); // 100 KB value, make it easy 
to have multiple files
+
+// Enough data to have a level 1 and 2
+int rows = 20;
+int columns = 10;
+
+// Adds enough data to trigger multiple sstable per level
+for (int r = 0; r < rows; r++)
+{
+DecoratedKey key = Util.dk(String.valueOf(r));
+Mutation rm = new Mutation(ksname, key.getKey());
+for (int c = 0; c < columns; c++)
+   

[1/4] cassandra git commit: Don't remove level info when running upgradesstables

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.1 7d3185059 -> b0f159c4a


Don't remove level info when running upgradesstables

Patch by marcuse; reviewed by yukim for CASSANDRA-10692


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

Branch: refs/heads/cassandra-3.1
Commit: 246cb883ab09bc69e842b8124c1537b38bb54335
Parents: 5a665b8
Author: Marcus Eriksson 
Authored: Thu Nov 12 08:12:01 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 13:58:08 2015 +0100

--
 CHANGES.txt |  1 +
 .../compaction/WrappingCompactionStrategy.java  | 15 +
 .../LeveledCompactionStrategyTest.java  | 35 
 3 files changed, 51 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 008d4d4..6ccde28 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.12
+ * Don't remove level info when running upgradesstables (CASSANDRA-10692)
  * Create compression chunk for sending file only (CASSANDRA-10680)
  * Make buffered read size configurable (CASSANDRA-10249)
  * Forbid compact clustering column type changes in ALTER TABLE 
(CASSANDRA-8879)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
index ae67599..71a6bc1 100644
--- 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
@@ -123,6 +123,21 @@ public final class WrappingCompactionStrategy extends 
AbstractCompactionStrategy
 }
 
 @Override
+public AbstractCompactionTask getCompactionTask(Collection 
sstables, final int gcBefore, long maxSSTableBytes)
+{
+assert sstables.size() > 0;
+boolean repairedSSTables = sstables.iterator().next().isRepaired();
+for (SSTableReader sstable : sstables)
+if (repairedSSTables != sstable.isRepaired())
+throw new RuntimeException("Can't mix repaired and unrepaired 
sstables in a compaction");
+
+if (repairedSSTables)
+return repaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+else
+return unrepaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+}
+
+@Override
 public synchronized AbstractCompactionTask 
getUserDefinedTask(Collection sstables, int gcBefore)
 {
 assert !sstables.isEmpty();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
index da54eee..cb9cbb4 100644
--- 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
+++ 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
@@ -23,6 +23,7 @@ import java.util.Collection;
 import java.util.List;
 import java.util.Random;
 import java.util.UUID;
+import java.util.concurrent.ExecutionException;
 
 import org.junit.After;
 import org.junit.Before;
@@ -278,4 +279,38 @@ public class LeveledCompactionStrategyTest extends 
SchemaLoader
 assertTrue(unrepaired.manifest.getLevel(1).contains(sstable2));
 assertFalse(repaired.manifest.getLevel(1).contains(sstable2));
 }
+
+@Test
+public void testDontRemoveLevelInfoUpgradeSSTables() throws 
InterruptedException, ExecutionException
+{
+byte [] b = new byte[100 * 1024];
+new Random().nextBytes(b);
+ByteBuffer value = ByteBuffer.wrap(b); // 100 KB value, make it easy 
to have multiple files
+
+// Enough data to have a level 1 and 2
+int rows = 20;
+int columns = 10;
+
+// Adds enough data to trigger multiple sstable per level
+for (int r = 0; r < rows; r++)
+{
+DecoratedKey key = Util.dk(String.valueOf(r));
+Mutation rm = new Mutation(ksname, key.getKey());
+for (int c = 0; c < columns; c++)
+   

[3/4] 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/12fd5d27
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/12fd5d27
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/12fd5d27

Branch: refs/heads/cassandra-3.1
Commit: 12fd5d270a8de2bcf34b082b410448eba02be4c4
Parents: 2753f95 d09b6c6
Author: Marcus Eriksson 
Authored: Wed Nov 18 14:00:02 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 14:00:02 2015 +0100

--

--

[4/4] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.1

[marcuse]

Merge branch 'cassandra-3.0' into cassandra-3.1


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

Branch: refs/heads/cassandra-3.1
Commit: b0f159c4a5d232e6aaaf302938dd41f9e59a2236
Parents: 7d31850 12fd5d2
Author: Marcus Eriksson 
Authored: Wed Nov 18 14:00:17 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 14:00:17 2015 +0100

--

--

[2/4] 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/d09b6c69
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d09b6c69
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d09b6c69

Branch: refs/heads/cassandra-3.1
Commit: d09b6c69e0e0c6adff8e679f2286a335d883f1bd
Parents: 077f9bf 246cb88
Author: Marcus Eriksson 
Authored: Wed Nov 18 13:59:09 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 13:59:09 2015 +0100

--
 CHANGES.txt |  1 +
 .../compaction/WrappingCompactionStrategy.java  | 16 +
 .../LeveledCompactionStrategyTest.java  | 35 
 3 files changed, 52 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d09b6c69/CHANGES.txt
--
diff --cc CHANGES.txt
index 572afc2,6ccde28..c3dacc2
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,17 -1,5 +1,18 @@@
 -2.1.12
 +2.2.4
 + * Don't do anticompaction after subrange repair (CASSANDRA-10422)
 + * Fix SimpleDateType type compatibility (CASSANDRA-10027)
 + * (Hadoop) fix splits calculation (CASSANDRA-10640)
 + * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058)
 + * (cqlsh) show partial trace if incomplete after max_trace_wait 
(CASSANDRA-7645)
 + * Use most up-to-date version of schema for system tables (CASSANDRA-10652)
 + * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628)
 + * Expose phi values from failure detector via JMX and tweak debug
 +   and trace logging (CASSANDRA-9526)
 + * Fix RangeNamesQueryPager (CASSANDRA-10509)
 + * Deprecate Pig support (CASSANDRA-10542)
 + * Reduce contention getting instances of CompositeType (CASSANDRA-10433)
 +Merged from 2.1:
+  * Don't remove level info when running upgradesstables (CASSANDRA-10692)
   * Create compression chunk for sending file only (CASSANDRA-10680)
   * Make buffered read size configurable (CASSANDRA-10249)
   * Forbid compact clustering column type changes in ALTER TABLE 
(CASSANDRA-8879)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d09b6c69/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
--
diff --cc 
src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
index 9daa0c5,71a6bc1..8555432
--- 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
@@@ -32,10 -32,10 +32,11 @@@ import org.slf4j.LoggerFactory
  
  import org.apache.cassandra.config.CFMetaData;
  import org.apache.cassandra.db.ColumnFamilyStore;
++import org.apache.cassandra.db.lifecycle.LifecycleTransaction;
  import org.apache.cassandra.dht.Range;
  import org.apache.cassandra.dht.Token;
 +import org.apache.cassandra.io.sstable.format.SSTableReader;
  import org.apache.cassandra.io.sstable.ISSTableScanner;
 -import org.apache.cassandra.io.sstable.SSTableReader;
  import org.apache.cassandra.notifications.INotification;
  import org.apache.cassandra.notifications.INotificationConsumer;
  import org.apache.cassandra.notifications.SSTableAddedNotification;
@@@ -123,6 -123,21 +124,21 @@@ public final class WrappingCompactionSt
  }
  
  @Override
 -public AbstractCompactionTask getCompactionTask(Collection 
sstables, final int gcBefore, long maxSSTableBytes)
++public AbstractCompactionTask getCompactionTask(LifecycleTransaction txn, 
final int gcBefore, long maxSSTableBytes)
+ {
 -assert sstables.size() > 0;
 -boolean repairedSSTables = sstables.iterator().next().isRepaired();
 -for (SSTableReader sstable : sstables)
++assert txn.originals().size() > 0;
++boolean repairedSSTables = 
txn.originals().iterator().next().isRepaired();
++for (SSTableReader sstable : txn.originals())
+ if (repairedSSTables != sstable.isRepaired())
+ throw new RuntimeException("Can't mix repaired and unrepaired 
sstables in a compaction");
+ 
+ if (repairedSSTables)
 -return repaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
++return repaired.getCompactionTask(txn, gcBefore, maxSSTableBytes);
+ else
 -return unrepaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
++return unrepaired.getCompactionTask(txn, gcBefore, 
maxSSTableBytes);
+ }
+ 
+ @Override
  public synchronized AbstractCompactionTask 
getUserDefinedTask(Collection sstables, int gcBefore)
  {
  assert !sstables.isEmpty();

[1/2] cassandra git commit: Don't remove level info when running upgradesstables

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 077f9bf5f -> d09b6c69e


Don't remove level info when running upgradesstables

Patch by marcuse; reviewed by yukim for CASSANDRA-10692


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

Branch: refs/heads/cassandra-2.2
Commit: 246cb883ab09bc69e842b8124c1537b38bb54335
Parents: 5a665b8
Author: Marcus Eriksson 
Authored: Thu Nov 12 08:12:01 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 13:58:08 2015 +0100

--
 CHANGES.txt |  1 +
 .../compaction/WrappingCompactionStrategy.java  | 15 +
 .../LeveledCompactionStrategyTest.java  | 35 
 3 files changed, 51 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 008d4d4..6ccde28 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.12
+ * Don't remove level info when running upgradesstables (CASSANDRA-10692)
  * Create compression chunk for sending file only (CASSANDRA-10680)
  * Make buffered read size configurable (CASSANDRA-10249)
  * Forbid compact clustering column type changes in ALTER TABLE 
(CASSANDRA-8879)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
index ae67599..71a6bc1 100644
--- 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
@@ -123,6 +123,21 @@ public final class WrappingCompactionStrategy extends 
AbstractCompactionStrategy
 }
 
 @Override
+public AbstractCompactionTask getCompactionTask(Collection 
sstables, final int gcBefore, long maxSSTableBytes)
+{
+assert sstables.size() > 0;
+boolean repairedSSTables = sstables.iterator().next().isRepaired();
+for (SSTableReader sstable : sstables)
+if (repairedSSTables != sstable.isRepaired())
+throw new RuntimeException("Can't mix repaired and unrepaired 
sstables in a compaction");
+
+if (repairedSSTables)
+return repaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+else
+return unrepaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+}
+
+@Override
 public synchronized AbstractCompactionTask 
getUserDefinedTask(Collection sstables, int gcBefore)
 {
 assert !sstables.isEmpty();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
index da54eee..cb9cbb4 100644
--- 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
+++ 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
@@ -23,6 +23,7 @@ import java.util.Collection;
 import java.util.List;
 import java.util.Random;
 import java.util.UUID;
+import java.util.concurrent.ExecutionException;
 
 import org.junit.After;
 import org.junit.Before;
@@ -278,4 +279,38 @@ public class LeveledCompactionStrategyTest extends 
SchemaLoader
 assertTrue(unrepaired.manifest.getLevel(1).contains(sstable2));
 assertFalse(repaired.manifest.getLevel(1).contains(sstable2));
 }
+
+@Test
+public void testDontRemoveLevelInfoUpgradeSSTables() throws 
InterruptedException, ExecutionException
+{
+byte [] b = new byte[100 * 1024];
+new Random().nextBytes(b);
+ByteBuffer value = ByteBuffer.wrap(b); // 100 KB value, make it easy 
to have multiple files
+
+// Enough data to have a level 1 and 2
+int rows = 20;
+int columns = 10;
+
+// Adds enough data to trigger multiple sstable per level
+for (int r = 0; r < rows; r++)
+{
+DecoratedKey key = Util.dk(String.valueOf(r));
+Mutation rm = new Mutation(ksname, key.getKey());
+for (int c = 0; c < columns; c++)
+   

cassandra git commit: Don't remove level info when running upgradesstables

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 5a665b805 -> 246cb883a


Don't remove level info when running upgradesstables

Patch by marcuse; reviewed by yukim for CASSANDRA-10692


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

Branch: refs/heads/cassandra-2.1
Commit: 246cb883ab09bc69e842b8124c1537b38bb54335
Parents: 5a665b8
Author: Marcus Eriksson 
Authored: Thu Nov 12 08:12:01 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 13:58:08 2015 +0100

--
 CHANGES.txt |  1 +
 .../compaction/WrappingCompactionStrategy.java  | 15 +
 .../LeveledCompactionStrategyTest.java  | 35 
 3 files changed, 51 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 008d4d4..6ccde28 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.12
+ * Don't remove level info when running upgradesstables (CASSANDRA-10692)
  * Create compression chunk for sending file only (CASSANDRA-10680)
  * Make buffered read size configurable (CASSANDRA-10249)
  * Forbid compact clustering column type changes in ALTER TABLE 
(CASSANDRA-8879)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
index ae67599..71a6bc1 100644
--- 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
@@ -123,6 +123,21 @@ public final class WrappingCompactionStrategy extends 
AbstractCompactionStrategy
 }
 
 @Override
+public AbstractCompactionTask getCompactionTask(Collection 
sstables, final int gcBefore, long maxSSTableBytes)
+{
+assert sstables.size() > 0;
+boolean repairedSSTables = sstables.iterator().next().isRepaired();
+for (SSTableReader sstable : sstables)
+if (repairedSSTables != sstable.isRepaired())
+throw new RuntimeException("Can't mix repaired and unrepaired 
sstables in a compaction");
+
+if (repairedSSTables)
+return repaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+else
+return unrepaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+}
+
+@Override
 public synchronized AbstractCompactionTask 
getUserDefinedTask(Collection sstables, int gcBefore)
 {
 assert !sstables.isEmpty();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
index da54eee..cb9cbb4 100644
--- 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
+++ 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
@@ -23,6 +23,7 @@ import java.util.Collection;
 import java.util.List;
 import java.util.Random;
 import java.util.UUID;
+import java.util.concurrent.ExecutionException;
 
 import org.junit.After;
 import org.junit.Before;
@@ -278,4 +279,38 @@ public class LeveledCompactionStrategyTest extends 
SchemaLoader
 assertTrue(unrepaired.manifest.getLevel(1).contains(sstable2));
 assertFalse(repaired.manifest.getLevel(1).contains(sstable2));
 }
+
+@Test
+public void testDontRemoveLevelInfoUpgradeSSTables() throws 
InterruptedException, ExecutionException
+{
+byte [] b = new byte[100 * 1024];
+new Random().nextBytes(b);
+ByteBuffer value = ByteBuffer.wrap(b); // 100 KB value, make it easy 
to have multiple files
+
+// Enough data to have a level 1 and 2
+int rows = 20;
+int columns = 10;
+
+// Adds enough data to trigger multiple sstable per level
+for (int r = 0; r < rows; r++)
+{
+DecoratedKey key = Util.dk(String.valueOf(r));
+Mutation rm = new Mutation(ksname, key.getKey());
+for (int c = 0; c < columns; c++)
+   

[jira] [Commented] (CASSANDRA-10723) Rewrite INITCOND after renames and alters of UDT fields

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10723:
---

bq. Still unclear, if the user needs permissions on both the UDT and the 
affected UDAs for that.

Why would you require any permissions on UDA itself, I don't follow. You aren't 
altering the UDA itself, just changing the internal schema representation, 
something that's under the hood.

> Rewrite INITCOND after renames and alters of UDT fields
> ---
>
> Key: CASSANDRA-10723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10723
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> (Follow-up to CASSANDRA-10721)
> In order to re-write an INITCOND value when a UDT is changed (component 
> renamed or type altered), we will have to check for broken aggregates first 
> (as we do not know why _exactly_ these are broken; CASSANDRA-10721 added 
> {{Function.isBroken()}}).
> If one of the affected aggregates is broken, the request *must fail*.
> If none of the affected aggregates is broken, we can re-write the binary 
> representation of the INITCOND and push schema migrations for these 
> aggregates.
> Still unclear, if the user needs permissions on both the UDT _and_ the 
> affected UDAs for that.
> Further, the UDT change and all UDA changes should be migrated in a single 
> mutation, which feels to be the biggest change. This is not a strict 
> requirement but would keep that schema change atomic.



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

[1/5] cassandra git commit: Don't remove level info when running upgradesstables

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/trunk fa25b0a91 -> 29ec013c2


Don't remove level info when running upgradesstables

Patch by marcuse; reviewed by yukim for CASSANDRA-10692


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

Branch: refs/heads/trunk
Commit: 246cb883ab09bc69e842b8124c1537b38bb54335
Parents: 5a665b8
Author: Marcus Eriksson 
Authored: Thu Nov 12 08:12:01 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 13:58:08 2015 +0100

--
 CHANGES.txt |  1 +
 .../compaction/WrappingCompactionStrategy.java  | 15 +
 .../LeveledCompactionStrategyTest.java  | 35 
 3 files changed, 51 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 008d4d4..6ccde28 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.12
+ * Don't remove level info when running upgradesstables (CASSANDRA-10692)
  * Create compression chunk for sending file only (CASSANDRA-10680)
  * Make buffered read size configurable (CASSANDRA-10249)
  * Forbid compact clustering column type changes in ALTER TABLE 
(CASSANDRA-8879)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
index ae67599..71a6bc1 100644
--- 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
@@ -123,6 +123,21 @@ public final class WrappingCompactionStrategy extends 
AbstractCompactionStrategy
 }
 
 @Override
+public AbstractCompactionTask getCompactionTask(Collection 
sstables, final int gcBefore, long maxSSTableBytes)
+{
+assert sstables.size() > 0;
+boolean repairedSSTables = sstables.iterator().next().isRepaired();
+for (SSTableReader sstable : sstables)
+if (repairedSSTables != sstable.isRepaired())
+throw new RuntimeException("Can't mix repaired and unrepaired 
sstables in a compaction");
+
+if (repairedSSTables)
+return repaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+else
+return unrepaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
+}
+
+@Override
 public synchronized AbstractCompactionTask 
getUserDefinedTask(Collection sstables, int gcBefore)
 {
 assert !sstables.isEmpty();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/246cb883/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
index da54eee..cb9cbb4 100644
--- 
a/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
+++ 
b/test/unit/org/apache/cassandra/db/compaction/LeveledCompactionStrategyTest.java
@@ -23,6 +23,7 @@ import java.util.Collection;
 import java.util.List;
 import java.util.Random;
 import java.util.UUID;
+import java.util.concurrent.ExecutionException;
 
 import org.junit.After;
 import org.junit.Before;
@@ -278,4 +279,38 @@ public class LeveledCompactionStrategyTest extends 
SchemaLoader
 assertTrue(unrepaired.manifest.getLevel(1).contains(sstable2));
 assertFalse(repaired.manifest.getLevel(1).contains(sstable2));
 }
+
+@Test
+public void testDontRemoveLevelInfoUpgradeSSTables() throws 
InterruptedException, ExecutionException
+{
+byte [] b = new byte[100 * 1024];
+new Random().nextBytes(b);
+ByteBuffer value = ByteBuffer.wrap(b); // 100 KB value, make it easy 
to have multiple files
+
+// Enough data to have a level 1 and 2
+int rows = 20;
+int columns = 10;
+
+// Adds enough data to trigger multiple sstable per level
+for (int r = 0; r < rows; r++)
+{
+DecoratedKey key = Util.dk(String.valueOf(r));
+Mutation rm = new Mutation(ksname, key.getKey());
+for (int c = 0; c < columns; c++)
+{
+

[3/5] 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/12fd5d27
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/12fd5d27
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/12fd5d27

Branch: refs/heads/trunk
Commit: 12fd5d270a8de2bcf34b082b410448eba02be4c4
Parents: 2753f95 d09b6c6
Author: Marcus Eriksson 
Authored: Wed Nov 18 14:00:02 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 14:00:02 2015 +0100

--

--

[4/5] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.1

[marcuse]

Merge branch 'cassandra-3.0' into cassandra-3.1


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

Branch: refs/heads/trunk
Commit: b0f159c4a5d232e6aaaf302938dd41f9e59a2236
Parents: 7d31850 12fd5d2
Author: Marcus Eriksson 
Authored: Wed Nov 18 14:00:17 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 14:00:17 2015 +0100

--

--

[2/5] 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/d09b6c69
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d09b6c69
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d09b6c69

Branch: refs/heads/trunk
Commit: d09b6c69e0e0c6adff8e679f2286a335d883f1bd
Parents: 077f9bf 246cb88
Author: Marcus Eriksson 
Authored: Wed Nov 18 13:59:09 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 13:59:09 2015 +0100

--
 CHANGES.txt |  1 +
 .../compaction/WrappingCompactionStrategy.java  | 16 +
 .../LeveledCompactionStrategyTest.java  | 35 
 3 files changed, 52 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d09b6c69/CHANGES.txt
--
diff --cc CHANGES.txt
index 572afc2,6ccde28..c3dacc2
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,17 -1,5 +1,18 @@@
 -2.1.12
 +2.2.4
 + * Don't do anticompaction after subrange repair (CASSANDRA-10422)
 + * Fix SimpleDateType type compatibility (CASSANDRA-10027)
 + * (Hadoop) fix splits calculation (CASSANDRA-10640)
 + * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058)
 + * (cqlsh) show partial trace if incomplete after max_trace_wait 
(CASSANDRA-7645)
 + * Use most up-to-date version of schema for system tables (CASSANDRA-10652)
 + * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628)
 + * Expose phi values from failure detector via JMX and tweak debug
 +   and trace logging (CASSANDRA-9526)
 + * Fix RangeNamesQueryPager (CASSANDRA-10509)
 + * Deprecate Pig support (CASSANDRA-10542)
 + * Reduce contention getting instances of CompositeType (CASSANDRA-10433)
 +Merged from 2.1:
+  * Don't remove level info when running upgradesstables (CASSANDRA-10692)
   * Create compression chunk for sending file only (CASSANDRA-10680)
   * Make buffered read size configurable (CASSANDRA-10249)
   * Forbid compact clustering column type changes in ALTER TABLE 
(CASSANDRA-8879)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d09b6c69/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
--
diff --cc 
src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
index 9daa0c5,71a6bc1..8555432
--- 
a/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/WrappingCompactionStrategy.java
@@@ -32,10 -32,10 +32,11 @@@ import org.slf4j.LoggerFactory
  
  import org.apache.cassandra.config.CFMetaData;
  import org.apache.cassandra.db.ColumnFamilyStore;
++import org.apache.cassandra.db.lifecycle.LifecycleTransaction;
  import org.apache.cassandra.dht.Range;
  import org.apache.cassandra.dht.Token;
 +import org.apache.cassandra.io.sstable.format.SSTableReader;
  import org.apache.cassandra.io.sstable.ISSTableScanner;
 -import org.apache.cassandra.io.sstable.SSTableReader;
  import org.apache.cassandra.notifications.INotification;
  import org.apache.cassandra.notifications.INotificationConsumer;
  import org.apache.cassandra.notifications.SSTableAddedNotification;
@@@ -123,6 -123,21 +124,21 @@@ public final class WrappingCompactionSt
  }
  
  @Override
 -public AbstractCompactionTask getCompactionTask(Collection 
sstables, final int gcBefore, long maxSSTableBytes)
++public AbstractCompactionTask getCompactionTask(LifecycleTransaction txn, 
final int gcBefore, long maxSSTableBytes)
+ {
 -assert sstables.size() > 0;
 -boolean repairedSSTables = sstables.iterator().next().isRepaired();
 -for (SSTableReader sstable : sstables)
++assert txn.originals().size() > 0;
++boolean repairedSSTables = 
txn.originals().iterator().next().isRepaired();
++for (SSTableReader sstable : txn.originals())
+ if (repairedSSTables != sstable.isRepaired())
+ throw new RuntimeException("Can't mix repaired and unrepaired 
sstables in a compaction");
+ 
+ if (repairedSSTables)
 -return repaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
++return repaired.getCompactionTask(txn, gcBefore, maxSSTableBytes);
+ else
 -return unrepaired.getCompactionTask(sstables, gcBefore, 
maxSSTableBytes);
++return unrepaired.getCompactionTask(txn, gcBefore, 
maxSSTableBytes);
+ }
+ 
+ @Override
  public synchronized AbstractCompactionTask 
getUserDefinedTask(Collection sstables, int gcBefore)
  {
  assert !sstables.isEmpty();

[5/5] cassandra git commit: Merge branch 'cassandra-3.1' into trunk

[marcuse]

Merge branch 'cassandra-3.1' into trunk


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

Branch: refs/heads/trunk
Commit: 29ec013c2c42dc603c07ca1295b4e1844df01dd5
Parents: fa25b0a b0f159c
Author: Marcus Eriksson 
Authored: Wed Nov 18 14:00:25 2015 +0100
Committer: Marcus Eriksson 
Committed: Wed Nov 18 14:00:25 2015 +0100

--

--

[jira] [Commented] (CASSANDRA-10582) CorruptSSTableException should print the SS Table Name

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10582:
---

Committed as 
[5a665b805ea8755112a5f1d0d81e8cbc41915eb0|https://github.com/apache/cassandra/commit/5a665b805ea8755112a5f1d0d81e8cbc41915eb0]
 to 2.1, merged with 2.2, 3.0, 3.1, and trunk. Thanks.

> CorruptSSTableException should print the SS Table Name
> --
>
> Key: CASSANDRA-10582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10582
> Project: Cassandra
>  Issue Type: Bug
> Environment: Azure
>Reporter: Anubhav Kale
>Assignee: Jeremiah Jordan
>Priority: Minor
> Fix For: 2.1.12, 2.2.4, 3.0.1, 3.1
>
> Attachments: 
> 0001-Add-file-path-to-CorruptSSTableException-message.patch
>
>
> We should print the SS Table name that's being reported as corrupt to help 
> with quick recovery.
> INFO  16:32:15  Opening 
> /mnt/cassandra/data/exchangecf/udsuserhourlysnapshot-d1260590711511e587125dc4955cc492/exchangecf-udsuserhourlysnapshot-ka-21214
>  (23832772 bytes)
> INFO  16:32:15  Opening 
> /mnt/cassandra/data/exchangecf/udsuserhourlysnapshot-d1260590711511e587125dc4955cc492/exchangecf-udsuserhourlysnapshot-ka-18398
>  (149675 bytes)
> INFO  16:32:15  Opening 
> /mnt/cassandra/data/exchangecf/udsuserhourlysnapshot-d1260590711511e587125dc4955cc492/exchangecf-udsuserhourlysnapshot-ka-23707
>  (18270 bytes)
> INFO  16:32:15  Opening 
> /mnt/cassandra/data/exchangecf/udsuserhourlysnapshot-d1260590711511e587125dc4955cc492/exchangecf-udsuserhourlysnapshot-ka-13656
>  (814588 bytes)
> ERROR 16:32:15  Exiting forcefully due to file system exception on startup, 
> disk failure policy "stop"
> org.apache.cassandra.io.sstable.CorruptSSTableException: java.io.EOFException
> at 
> org.apache.cassandra.io.compress.CompressionMetadata.(CompressionMetadata.java:131)
>  ~[apache-cassandra-2.1.9-SNAPSHOT.jar:2.1.9-SNAPSHOT]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata.create(CompressionMetadata.java:85)
>  ~[apache-cassandra-2.1.9-SNAPSHOT.jar:2.1.9-SNAPSHOT]
> at 
> org.apache.cassandra.io.util.CompressedSegmentedFile$Builder.metadata(CompressedSegmentedFile.java:79)
>  ~[apache-cassandra-2.1.9-SNAPSHOT.jar:2.1.9-SNAPSHOT]
> at 
> org.apache.cassandra.io.util.CompressedPoolingSegmentedFile$Builder.complete(CompressedPoolingSegmentedFile.java:72)
>  ~[apache-cassandra-2.1.9-SNAPSHOT.jar:2.1.9-SNAPSHOT]
> at



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

[jira] [Updated] (CASSANDRA-10678) add SSTable flush observer

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10678:
--
Reviewer: Sam Tunnicliffe  (was: Jason Brown)

> add SSTable flush observer
> --
>
> Key: CASSANDRA-10678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10678
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
> Fix For: 3.x
>
>
> Add general interface which can intercept per SSTable flush events e.g. - 
> start of the key, columns etc. Make Index interface return such observer on 
> request, which couples index with corresponding SSTable file if needed.



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

[jira] [Created] (CASSANDRA-10728) Hash used in repair does not include partition key

[Nadav Har'El (JIRA)]

Nadav Har'El created CASSANDRA-10728:


 Summary: Hash used in repair does not include partition key
 Key: CASSANDRA-10728
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10728
 Project: Cassandra
  Issue Type: Bug
Reporter: Nadav Har'El
Priority: Minor


When the repair code builds the Merkle Tree, it appears to be using 
AbstractCompactedRow.update() to calculate a partition's hash. This method's 
documentation states that it calculates a "digest with the data bytes of the 
row (not including row key or row size).". The code itself seems to agree with 
this comment.

However, I believe that not including the row (actually, partition) key in the 
hash function is a mistake: This means that if two nodes have the same data but 
different key, repair would not notice this discrepancy. Moreover, if two 
different keys have their data switched - or have the same data - again this 
would not be noticed by repair. Actually running across this problem in a real 
repair is not very likely, but I can imagine seeing it easily in an 
hypothetical use case where all partitions have exactly the same data and just 
the partition key matters.

I am sorry if I'm mistaken and the partition key is actually taken into account 
in the Merkle tree, but I tried to find evidence that it does and failed. 
Glancing over the code, it almost seems that it does use the key: 
Validator.add() calculates rowHash() which includes the digest (without the 
partition key) *and* the key's token. But then, the code calls 
MerkleTree.TreeRange.addHash() on that tuple, and that function conspicuously 
ignores the token, and only uses the digest.



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

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

[aleksey]

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

Branch: refs/heads/cassandra-3.1
Commit: 077f9bf5f55fe7dca0b10b3357314c208c2f35ed
Parents: ae64cc0 5a665b8
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:52:36 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:52:36 2015 +

--
 .../org/apache/cassandra/io/sstable/CorruptSSTableException.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--

[1/5] cassandra git commit: Add file path to CorruptSSTableException message

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk aff6994c8 -> fa25b0a91


Add file path to CorruptSSTableException message

patch by Jeremiah D Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-10582


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

Branch: refs/heads/trunk
Commit: 5a665b805ea8755112a5f1d0d81e8cbc41915eb0
Parents: 8385bb6
Author: Jeremiah D Jordan 
Authored: Wed Nov 11 14:30:11 2015 -0600
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:45:45 2015 +

--
 .../org/apache/cassandra/io/sstable/CorruptSSTableException.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5a665b80/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java 
b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
index a71daaf..0fe316d 100644
--- a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
+++ b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
@@ -25,7 +25,7 @@ public class CorruptSSTableException extends RuntimeException
 
 public CorruptSSTableException(Exception cause, File path)
 {
-super(cause);
+super("Corrupted: " + path, cause);
 this.path = path;
 }
 

[jira] [Commented] (CASSANDRA-10678) add SSTable flush observer

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10678:
-

I guess the following is a prerequisite of 
https://github.com/xedin/sasi/issues/3, but I'll mention it here anyway:

{{SSTableFlushObserver::startRow}} is misnamed, being called when before a 
partition, not a row, is written to the SSTable. In fact, rows are not really 
tracked at all during the flush, only partitions and cells. The corresponding 
tests also highlight this. So at least one additional method is required on the 
interface to capture events at this level. Is it possible that RTs may be of 
interest to some observers too? If so, perhaps we also need another method for 
those. 

Nit: missing javadoc for {{Index::getFlushObserver}}

The {{SSTableFlushObserver.Source}} enum is unused at the moment. Is this in 
preparation for an upcoming patch, or a leftover from the pre-3.0 version?


> add SSTable flush observer
> --
>
> Key: CASSANDRA-10678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10678
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
> Fix For: 3.x
>
>
> Add general interface which can intercept per SSTable flush events e.g. - 
> start of the key, columns etc. Make Index interface return such observer on 
> request, which couples index with corresponding SSTable file if needed.



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

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

[aleksey]

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

Branch: refs/heads/trunk
Commit: 077f9bf5f55fe7dca0b10b3357314c208c2f35ed
Parents: ae64cc0 5a665b8
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:52:36 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:52:36 2015 +

--
 .../org/apache/cassandra/io/sstable/CorruptSSTableException.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--

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

[aleksey]

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

Branch: refs/heads/cassandra-3.0
Commit: 2753f95e61d01f25360e1610b63319acde304c3c
Parents: 5cc02dd 077f9bf
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:53:39 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:53:39 2015 +

--

--

[4/4] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.1

[aleksey]

Merge branch 'cassandra-3.0' into cassandra-3.1


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

Branch: refs/heads/cassandra-3.1
Commit: 7d3185059536ba23b6a4a3fa5a210697c6ac1850
Parents: 5be1f66 2753f95
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:54:43 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:54:43 2015 +

--

--

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

[aleksey]

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

Branch: refs/heads/cassandra-3.1
Commit: 2753f95e61d01f25360e1610b63319acde304c3c
Parents: 5cc02dd 077f9bf
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:53:39 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:53:39 2015 +

--

--

[1/4] cassandra git commit: Add file path to CorruptSSTableException message

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.1 5be1f663b -> 7d3185059


Add file path to CorruptSSTableException message

patch by Jeremiah D Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-10582


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

Branch: refs/heads/cassandra-3.1
Commit: 5a665b805ea8755112a5f1d0d81e8cbc41915eb0
Parents: 8385bb6
Author: Jeremiah D Jordan 
Authored: Wed Nov 11 14:30:11 2015 -0600
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:45:45 2015 +

--
 .../org/apache/cassandra/io/sstable/CorruptSSTableException.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5a665b80/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java 
b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
index a71daaf..0fe316d 100644
--- a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
+++ b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
@@ -25,7 +25,7 @@ public class CorruptSSTableException extends RuntimeException
 
 public CorruptSSTableException(Exception cause, File path)
 {
-super(cause);
+super("Corrupted: " + path, cause);
 this.path = path;
 }
 

[4/5] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.1

[aleksey]

Merge branch 'cassandra-3.0' into cassandra-3.1


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

Branch: refs/heads/trunk
Commit: 7d3185059536ba23b6a4a3fa5a210697c6ac1850
Parents: 5be1f66 2753f95
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:54:43 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:54:43 2015 +

--

--

[5/5] cassandra git commit: Merge branch 'cassandra-3.1' into trunk

[aleksey]

Merge branch 'cassandra-3.1' into trunk


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

Branch: refs/heads/trunk
Commit: fa25b0a91db9d3109b1c7a2ea96e28df1249e5e5
Parents: aff6994 7d31850
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:55:31 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:55:31 2015 +

--

--

[jira] [Updated] (CASSANDRA-10722) Error in system.log file about the compaction

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10722:
--
Fix Version/s: (was: 2.1.8)

> Error in system.log file about the compaction
> -
>
> Key: CASSANDRA-10722
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10722
> Project: Cassandra
>  Issue Type: Test
> Environment: 2nodes, 
> each 8GB RAM
> 500GB Disk
> dual core
>Reporter: Arunsandu
>Priority: Minor
>  Labels: test
> Attachments: Error_Compaction_systemlog.txt
>
>
> Was performing load testing on my tables using cassandra-stress and after the 
> test I did drop the keyspace(autogeneratedtest). I keep getting the message 
> in system.log every minute. 
> component_tracking_by_scid-ka-6-Data.db
> component_tracking_by_scid-ka-7-Data.db
> component_tracking_by_scid-ka-8-Data.db
> component_tracking_by_scid-ka-9-Data.db
> component_tracking_by_scid-ka-10-Data.db
> These SSTables no longer exists in my data directory. Just wanted to know if 
> deleting saved_caches of this keyspace would fix my issue. If so, is that 
> good practice to delete saved_caches?
> -
> INFO  [CompactionExecutor:5] 2015-11-17 09:27:58,894  CompactionTask.java:141 
> - Compacting 
> [SSTableReader(path='/apps/apg-data.cassandra/data/autogeneratedtest/component_tracking_by_scid-bb55a0818a6111e59c5e677600703f12/autogeneratedtest-component_tracking_by_scid-ka-8-Data.db'),
>  
> SSTableReader(path='/apps/apg-data.cassandra/data/autogeneratedtest/component_tracking_by_scid-bb55a0818a6111e59c5e677600703f12/autogeneratedtest-component_tracking_by_scid-ka-7-Data.db'),
>  
> SSTableReader(path='/apps/apg-data.cassandra/data/autogeneratedtest/component_tracking_by_scid-bb55a0818a6111e59c5e677600703f12/autogeneratedtest-component_tracking_by_scid-ka-6-Data.db'),
>  
> SSTableReader(path='/apps/apg-data.cassandra/data/autogeneratedtest/component_tracking_by_scid-bb55a0818a6111e59c5e677600703f12/autogeneratedtest-component_tracking_by_scid-ka-9-Data.db'),
>  
> SSTableReader(path='/apps/apg-data.cassandra/data/autogeneratedtest/component_tracking_by_scid-bb55a0818a6111e59c5e677600703f12/autogeneratedtest-component_tracking_by_scid-ka-10-Data.db')]
> ERROR [CompactionExecutor:5] 2015-11-17 09:27:58,895  
> CassandraDaemon.java:222 - Exception in thread 
> Thread[CompactionExecutor:5,1,main]
> java.lang.AssertionError: 
> /apps/apg-data.cassandra/data/autogeneratedtest/component_tracking_by_scid-bb55a0818a6111e59c5e677600703f12/autogeneratedtest-component_tracking_by_scid-ka-8-Data.db
> at 
> org.apache.cassandra.io.sstable.SSTableReader.getApproximateKeyCount(SSTableReader.java:279)
>  ~[cassandra-all-2.1.8.689.jar:2.1.8.689]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:151)
>  ~[cassandra-all-2.1.8.689.jar:2.1.8.689]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[cassandra-all-2.1.8.689.jar:2.1.8.689]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  ~[cassandra-all-2.1.8.689.jar:2.1.8.689]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[cassandra-all-2.1.8.689.jar:2.1.8.689]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:236)
>  ~[cassandra-all-2.1.8.689.jar:2.1.8.689]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_31]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_31]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_31]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_31]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_31]



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

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

[Ivan Burmistrov (JIRA)]

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

Ivan Burmistrov commented on CASSANDRA-10585:
-

I think, extending EstimatedHistogram to properly capture a 0 value is more 
preferably. Because not only row cache may cause reading 0 SSTables, but  
[CASSANDRA-2498|https://issues.apache.org/jira/browse/CASSANDRA-2498] and 
[CASSANDRA-5514|https://issues.apache.org/jira/browse/CASSANDRA-5514] 
optimizations too: read request can process only Memtable without touching any 
SSTable if these optimizations work well.

I will prepare new versions of patches and will attach it for your review soon.

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



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

[jira] [Updated] (CASSANDRA-10582) CorruptSSTableException should print the SS Table Name

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10582:
--
Reviewer: Aleksey Yeschenko

> CorruptSSTableException should print the SS Table Name
> --
>
> Key: CASSANDRA-10582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10582
> Project: Cassandra
>  Issue Type: Bug
> Environment: Azure
>Reporter: Anubhav Kale
>Assignee: Jeremiah Jordan
>Priority: Minor
> Fix For: 2.1.x, 2.2.x
>
> Attachments: 
> 0001-Add-file-path-to-CorruptSSTableException-message.patch
>
>
> We should print the SS Table name that's being reported as corrupt to help 
> with quick recovery.
> INFO  16:32:15  Opening 
> /mnt/cassandra/data/exchangecf/udsuserhourlysnapshot-d1260590711511e587125dc4955cc492/exchangecf-udsuserhourlysnapshot-ka-21214
>  (23832772 bytes)
> INFO  16:32:15  Opening 
> /mnt/cassandra/data/exchangecf/udsuserhourlysnapshot-d1260590711511e587125dc4955cc492/exchangecf-udsuserhourlysnapshot-ka-18398
>  (149675 bytes)
> INFO  16:32:15  Opening 
> /mnt/cassandra/data/exchangecf/udsuserhourlysnapshot-d1260590711511e587125dc4955cc492/exchangecf-udsuserhourlysnapshot-ka-23707
>  (18270 bytes)
> INFO  16:32:15  Opening 
> /mnt/cassandra/data/exchangecf/udsuserhourlysnapshot-d1260590711511e587125dc4955cc492/exchangecf-udsuserhourlysnapshot-ka-13656
>  (814588 bytes)
> ERROR 16:32:15  Exiting forcefully due to file system exception on startup, 
> disk failure policy "stop"
> org.apache.cassandra.io.sstable.CorruptSSTableException: java.io.EOFException
> at 
> org.apache.cassandra.io.compress.CompressionMetadata.(CompressionMetadata.java:131)
>  ~[apache-cassandra-2.1.9-SNAPSHOT.jar:2.1.9-SNAPSHOT]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata.create(CompressionMetadata.java:85)
>  ~[apache-cassandra-2.1.9-SNAPSHOT.jar:2.1.9-SNAPSHOT]
> at 
> org.apache.cassandra.io.util.CompressedSegmentedFile$Builder.metadata(CompressedSegmentedFile.java:79)
>  ~[apache-cassandra-2.1.9-SNAPSHOT.jar:2.1.9-SNAPSHOT]
> at 
> org.apache.cassandra.io.util.CompressedPoolingSegmentedFile$Builder.complete(CompressedPoolingSegmentedFile.java:72)
>  ~[apache-cassandra-2.1.9-SNAPSHOT.jar:2.1.9-SNAPSHOT]
> at



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

[1/3] cassandra git commit: Add file path to CorruptSSTableException message

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 5cc02dd9a -> 2753f95e6


Add file path to CorruptSSTableException message

patch by Jeremiah D Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-10582


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

Branch: refs/heads/cassandra-3.0
Commit: 5a665b805ea8755112a5f1d0d81e8cbc41915eb0
Parents: 8385bb6
Author: Jeremiah D Jordan 
Authored: Wed Nov 11 14:30:11 2015 -0600
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:45:45 2015 +

--
 .../org/apache/cassandra/io/sstable/CorruptSSTableException.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5a665b80/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java 
b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
index a71daaf..0fe316d 100644
--- a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
+++ b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
@@ -25,7 +25,7 @@ public class CorruptSSTableException extends RuntimeException
 
 public CorruptSSTableException(Exception cause, File path)
 {
-super(cause);
+super("Corrupted: " + path, cause);
 this.path = path;
 }
 

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

[aleksey]

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

Branch: refs/heads/cassandra-3.0
Commit: 077f9bf5f55fe7dca0b10b3357314c208c2f35ed
Parents: ae64cc0 5a665b8
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:52:36 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:52:36 2015 +

--
 .../org/apache/cassandra/io/sstable/CorruptSSTableException.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--

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

[aleksey]

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

Branch: refs/heads/cassandra-2.2
Commit: 077f9bf5f55fe7dca0b10b3357314c208c2f35ed
Parents: ae64cc0 5a665b8
Author: Aleksey Yeschenko 
Authored: Wed Nov 18 12:52:36 2015 +
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:52:36 2015 +

--
 .../org/apache/cassandra/io/sstable/CorruptSSTableException.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--

[1/2] cassandra git commit: Add file path to CorruptSSTableException message

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 ae64cc0da -> 077f9bf5f


Add file path to CorruptSSTableException message

patch by Jeremiah D Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-10582


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

Branch: refs/heads/cassandra-2.2
Commit: 5a665b805ea8755112a5f1d0d81e8cbc41915eb0
Parents: 8385bb6
Author: Jeremiah D Jordan 
Authored: Wed Nov 11 14:30:11 2015 -0600
Committer: Aleksey Yeschenko 
Committed: Wed Nov 18 12:45:45 2015 +

--
 .../org/apache/cassandra/io/sstable/CorruptSSTableException.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5a665b80/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
--
diff --git 
a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java 
b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
index a71daaf..0fe316d 100644
--- a/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
+++ b/src/java/org/apache/cassandra/io/sstable/CorruptSSTableException.java
@@ -25,7 +25,7 @@ public class CorruptSSTableException extends RuntimeException
 
 public CorruptSSTableException(Exception cause, File path)
 {
-super(cause);
+super("Corrupted: " + path, cause);
 this.path = path;
 }
 

[jira] [Commented] (CASSANDRA-10690) Secondary index does not process deletes unless columns are specified

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10690:
--

bq. the Index interface is a somewhat public API

Meant to, but forgot to mention that. I'm not too fussed about breaking that 
API right now cause it's brand new, 3.0 is so very new and adapting your custom 
index code to the change is trivial. But yes, it's a breaking change strictly 
speaking and I'm totally fine only doing that in 3.2 if we prefer. 

> Secondary index does not process deletes unless columns are specified
> -
>
> Key: CASSANDRA-10690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10690
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Tyler Hobbs
> Fix For: 3.0.1, 3.1
>
>
> The new secondary index API does not notify indexes of single-row or slice 
> deletions unless specific columns are deleted.  I believe the problem is that 
> in {{SecondaryIndexManager.newUpdateTransaction()}}, we skip indexes unless 
> {{index.indexes(update.columns())}}.  When no columns are specified in the 
> the deletion, {{update.columns()}} is empty, which causes all indexes to be 
> skipped.
> I think the correct fix is to do something like this in the 
> {{ModificationStatement}} constructor:
> {code}
> if (type == StatementType.DELETE && modifiedColumns.isEmpty())
> modifiedColumns = cfm.partitionColumns();
> {code}
> However, I'm not sure if that may have unintended side-effects.  What do you 
> think, [~slebresne]?



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

[jira] [Updated] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-10719:
---
Labels: docs docs-impacting  (was: )

> Inconsistencies within CQL 'describe', and CQL docs/'help describe'
> ---
>
> Key: CASSANDRA-10719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10719
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL, Documentation and Website
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Minor
>  Labels: docs, docs-impacting
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10719-Describe.patch
>
>
> While investigating the issue CASSANDRA-9678 I noticed a number of 
> inconsistencies in the way 'describe' operates, so I'm opening a new issue to 
> address these. This issue will also address CASSANDRA-9678.
> I'd be happy to work on this.
> There are a number of inconsistencies in the way 'describe' operates within 
> cqlsh, and also in the 'help describe' description within cqlsh compared to 
> the CQL documentation (at 
> http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html)
> For example, 'desc functions' will list all functions for all keyspaces 
> regardless of whether there is a current keyspace or not, whereas 'desc 
> tables' or 'desc types' will list only the tables or types for the current 
> keyspace.
> Some commands exist in cqlsh that are not in the CQL documentation, nor in 
> the 'help describe' description. For example, 'desc functions' is a valid 
> CQLSH command but does not appear in either the CQL docs or 'help describe'.
> I suggest we align the way the 'describe' command works so that it works 
> consistently regardless of whether it is describing a table, type, function 
> or any other database object, and also update the CQL and 'help describe' 
> docs to match. Since 'describe tables' and it's variants has been around the 
> longest we should probably align other 'describe' commands to 'describe 
> tables'.
> My preliminary analysis has shown at least the following inconsistencies:
> - 'desc functions' (with current keyspace), differs from 'desc tables' and 
> 'desc types'.
> - a number of commands are missing from the CQL docs or 'help describe, such 
> as: desc table ., desc functions (no current keyspace), 
> desc function , desc type ., etc.



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

[jira] [Updated] (CASSANDRA-9043) Improve COPY command to work with Counter columns

[ZhaoYang (JIRA)]

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

ZhaoYang updated CASSANDRA-9043:

Attachment: (was: CASSANDRA-9043(2.1.8).patch)

> Improve COPY command to work with Counter columns
> -
>
> Key: CASSANDRA-9043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9043
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sebastian Estevez
>Assignee: ZhaoYang
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: CASSANDRA-9043-trunk.patch
>
>
> Noticed today that the copy command doesn't work with counter column tables.
> This makes sense given that we need to use UPDATE instead of INSERT with 
> counters.
> Given that we're making improvements in the COPY command in 3.0 with 
> CASSANDRA-7405, can we also tweak it to work with counters?



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

[jira] [Updated] (CASSANDRA-9043) Improve COPY command to work with Counter columns

[ZhaoYang (JIRA)]

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

ZhaoYang updated CASSANDRA-9043:

Attachment: (was: CASSANDRA-9043-trunk.patch)

> Improve COPY command to work with Counter columns
> -
>
> Key: CASSANDRA-9043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9043
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sebastian Estevez
>Assignee: ZhaoYang
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: CASSANDRA-9043-2.1.8.patch, CASSANDRA-9043-trunk.patch
>
>
> Noticed today that the copy command doesn't work with counter column tables.
> This makes sense given that we need to use UPDATE instead of INSERT with 
> counters.
> Given that we're making improvements in the COPY command in 3.0 with 
> CASSANDRA-7405, can we also tweak it to work with counters?



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

[jira] [Commented] (CASSANDRA-10681) make index building pluggable via IndexBuildTask

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10681:
-

The issue with this is that it serializes the building of all indexes, 
regardless of whether they're SASI indexes or not. So whereas previously all 
indexes for a table were built in a single pass over the data, a separate 
iteration is required for each. This could be a problem wherever multiple 
indexes are defined for a table & indexes need to be rebuilt, so when new 
SSTables are added via streaming or sideloading, or during a user-requested 
rebuild from nodetool.

> make index building pluggable via IndexBuildTask
> 
>
> Key: CASSANDRA-10681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10681
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Local Write-Read Paths
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
>Priority: Minor
>  Labels: sasi
> Fix For: 3.x
>
>
> Currently index building assumes one and only way to build all of the indexes 
> - through SecondaryIndexBuilder - which merges all of the sstables together, 
> collates columns etc. Such works fine for built-in indexes but not for SASI 
> since it's attaches to every SSTable individually. We need a "IndexBuildTask" 
> interface (based on CompactionInfo.Holder) to be returned from Index on 
> demand to give power to SI interface implementers to decide how build should 
> work. This might be less effective for CassandraIndex, since this effectively 
> means that collation will have to be done multiple times on the same data, 
> but  nevertheless is a good compromise for clean interface to outside world.



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