[jira] [Commented] (CASSANDRA-15159) Purgable tombstones are ignored by read query

[Laxmikant Upadhyay (JIRA)]

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

Laxmikant Upadhyay commented on CASSANDRA-15159:


This issue is not related to CASSANDRA-12765 as the sstable with tombstone does 
not have maxLocalDeletionTime == Integer.MAX_VALUE.

> Purgable tombstones are ignored by read query
> -
>
> Key: CASSANDRA-15159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15159
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Local Write-Read Paths
>Reporter: Laxmikant Upadhyay
>Priority: Normal
> Attachments: steps2reproduce.txt, trace.txt
>
>
> In 3 node Cassandra cluster, one node has old mutation and two nodes have 
> evict-able (crossed gc grace period) tombstone produced by TTL. A read query 
> with local quorum return the old mutation as result when one request goes to 
> the node having old mutation. However expected result should be empty. 
> Attached the steps to reproduce and trace of read query.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-15159) Purgable tombstones are ignored by read query

[Laxmikant Upadhyay (JIRA)]

Laxmikant Upadhyay created CASSANDRA-15159:
--

 Summary: Purgable tombstones are ignored by read query
 Key: CASSANDRA-15159
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15159
 Project: Cassandra
  Issue Type: Bug
  Components: Legacy/Local Write-Read Paths
Reporter: Laxmikant Upadhyay
 Attachments: steps2reproduce.txt, trace.txt

In 3 node Cassandra cluster, one node has old mutation and two nodes have 
evict-able (crossed gc grace period) tombstone produced by TTL. A read query 
with local quorum return the old mutation as result when one request goes to 
the node having old mutation. However expected result should be empty. 

Attached the steps to reproduce and trace of read query.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15158) Wait for schema agreement rather then in flight schema requests when bootstrapping

[Vincent White (JIRA)]

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

Vincent White updated CASSANDRA-15158:
--
 Severity: Normal
Discovered By: User Report
 Bug Category: Parent values: Correctness(12982)Level 1 values: Consistency 
Failure(12989)
Since Version: 3.1

> Wait for schema agreement rather then in flight schema requests when 
> bootstrapping
> --
>
> Key: CASSANDRA-15158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15158
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip
>Reporter: Vincent White
>Priority: Normal
>
> Currently when a node is bootstrapping we use a set of latches 
> (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of 
> in-flight schema pull requests, and we don't proceed with 
> bootstrapping/stream until all the latches are released (or we timeout 
> waiting for each one). One issue with this is that if we have a large schema, 
> or the retrieval of the schema from the other nodes was unexpectedly slow 
> then we have no explicit check in place to ensure we have actually received a 
> schema before we proceed.
> While it's possible to increase "migration_task_wait_in_seconds" to force the 
> node to wait on each latches longer, there are cases where this doesn't help 
> because the callbacks for the schema pull requests have expired off the 
> messaging service's callback map 
> (org.apache.cassandra.net.MessagingService#callbacks) after 
> getMinRpcTimeout() (2 seconds by default) before the other nodes were able to 
> respond to the new node.
> This patch checks for schema agreement between the bootstrapping node and the 
> rest of the live nodes before proceeding with bootstrapping. It also adds a 
> check to prevent the new node from flooding existing nodes with simultaneous 
> schema pull requests as can happen in large clusters.
> |||3.11||
> |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]|



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-13990) Remove OldNetworkTopologyStrategy

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna reassigned CASSANDRA-13990:


Assignee: Pedro Gordo

> Remove OldNetworkTopologyStrategy
> -
>
> Key: CASSANDRA-13990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13990
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Jeremy Hanna
>Assignee: Pedro Gordo
>Priority: Low
>  Labels: lhf
>
> RackAwareStrategy was renamed OldNetworkTopologyStrategy back in 0.7 
> (CASSANDRA-1392) and it's still around.  Is there any reason to keep this 
> relatively dead code in the codebase at this point?  I'm not aware of its use 
> and it sometimes confuses users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13990) Remove OldNetworkTopologyStrategy

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna commented on CASSANDRA-13990:
--

Go for it.  I'm just double checking around to see if there are any final 
objections to do this in principle.

> Remove OldNetworkTopologyStrategy
> -
>
> Key: CASSANDRA-13990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13990
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Jeremy Hanna
>Priority: Low
>  Labels: lhf
>
> RackAwareStrategy was renamed OldNetworkTopologyStrategy back in 0.7 
> (CASSANDRA-1392) and it's still around.  Is there any reason to keep this 
> relatively dead code in the codebase at this point?  I'm not aware of its use 
> and it sometimes confuses users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13990) Remove OldNetworkTopologyStrategy

[Pedro Gordo (JIRA)]

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

Pedro Gordo commented on CASSANDRA-13990:
-

[~jeromatron] this looks like a good ticket to start my Cassandra 
contributions. Can I pick this up?

> Remove OldNetworkTopologyStrategy
> -
>
> Key: CASSANDRA-13990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13990
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Jeremy Hanna
>Priority: Low
>  Labels: lhf
>
> RackAwareStrategy was renamed OldNetworkTopologyStrategy back in 0.7 
> (CASSANDRA-1392) and it's still around.  Is there any reason to keep this 
> relatively dead code in the codebase at this point?  I'm not aware of its use 
> and it sometimes confuses users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[Cassandra Wiki] Update of "Committers" by StefanPodkowinski

[Apache Wiki]

Dear Wiki user,

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

The "Committers" page has been changed by StefanPodkowinski:
https://wiki.apache.org/cassandra/Committers?action=diff=83=84

+ The following listing may contain outdated information. Please refer to 
[[http://people.apache.org/phonebook.html|Apache Phone Book]] for a generated 
list of committers.
+ 
  ||Committer ||Since ||Employer ||Comments ||
  ||Avinash Lakshman ||Jan 2009 ||Facebook ||Co-author of Facebook Cassandra ||
  ||Prashant Malik ||Jan 2009 ||Facebook ||Co-author of Facebook Cassandra ||
@@ -24, +26 @@

  ||Marcus Eriksson ||Apr 2013 ||Apple ||PMC member ||
  ||Mikhail Stepura ||Jan 2014 ||Apple || ||
  ||Tyler Hobbs ||Mar 2014 ||Datastax ||PMC member ||
- ||Benedict Elliott Smith ||May 2014 ||Apple || ||
+ ||Benedict Elliott Smith ||May 2014 ||Apple ||PMC member ||
  ||Josh Mckenzie ||Jul 2014 ||Datastax ||PMC member ||
  ||Robert Stupp ||Jan 2015 ||Datastax || ||
  ||Sam Tunnicliffe ||May 2015 ||Apple ||PMC member ||
  ||Benjamin Lerer ||Jul 2015 ||Datastax ||PMC member ||
  ||Carl Yeksigian ||Jan 2016 ||Datastax ||Also a 
[[http://thrift.apache.org|Thrift]] committer ||
- ||Stefania Alborghetti ||Apr 2016 ||Datastax || ||
+ ||Stefania Alborghetti ||Apr 2016 ||Datastax ||PMC member ||
  ||Jeff Jirsa ||June 2016 ||Apple|| PMC member ||
  ||Nate !McCall ||June 2016 ||Apple|| Project chair ||
  ||Jake Farrell ||June 2016 || || PMC member ||
@@ -40, +42 @@

  ||Branimir Lambov ||November 2016 ||Datastax || ||
  ||Paulo Motta || November 2016 ||Datastax || ||
  ||Sankalp Kohli || November 2016 ||Apple || PMC member ||
- ||Stefan Podkowinski ||February 2017 ||1&1 ||PMC member ||
+ ||Stefan Podkowinski ||February 2017 ||Apple ||PMC member ||
- ||Ariel Weisberg ||February 2017 ||Apple || ||
+ ||Ariel Weisberg ||February 2017 ||Apple ||PMC member ||
  ||Blake Eggleston ||February 2017 ||Apple ||PMC member ||
- ||Alex Petrov ||February 2017 ||Apple || ||
+ ||Alex Petrov ||February 2017 ||Apple ||PMC member ||
  ||Joel Knighton ||February 2017 || Datastax || ||
  ||Philip Thompson ||June 2017 || Datastax || ||
  ||Jay Zhuang ||February 2018 || Uber || ||
  ||Chris Lohfink ||August 2018 || Apple || ||
+ ||Vinay Chella ||February 2019 || || ||
+ ||Joseph Lynch ||February 2019 || || ||
+ ||Dinesh Joshi ||March 2019 || || ||
+ 
  
  {{https://c.statcounter.com/9397521/0/fe557aad/1/|stats}}
  

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9289) Recover from unknown table when deserializing internode messages

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9289:
-
Resolution: Fixed
Status: Resolved  (was: Awaiting Feedback)

> Recover from unknown table when deserializing internode messages
> 
>
> Key: CASSANDRA-9289
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9289
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tyler Hobbs
>Assignee: ZhaoYang
>Priority: Low
>  Labels: lhf
> Fix For: 3.11.x
>
>
> As discussed in CASSANDRA-9136, it would be nice to gracefully recover from 
> seeing an unknown table in a message from another node.  Currently, we close 
> the connection and reconnect, which can cause other concurrent queries to 
> fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9289) Recover from unknown table when deserializing internode messages

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-9289:
-
Fix Version/s: (was: 3.11.x)
   4.0

> Recover from unknown table when deserializing internode messages
> 
>
> Key: CASSANDRA-9289
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9289
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tyler Hobbs
>Assignee: ZhaoYang
>Priority: Low
>  Labels: lhf
> Fix For: 4.0
>
>
> As discussed in CASSANDRA-9136, it would be nice to gracefully recover from 
> seeing an unknown table in a message from another node.  Currently, we close 
> the connection and reconnect, which can cause other concurrent queries to 
> fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-15149:
---
  Fix Version/s: 4.0
Source Control Link: 
https://github.com/apache/cassandra/commit/7c0cb6db32ecbde5534087ce53364bd6cf1ddcec
 Status: Resolved  (was: Ready to Commit)
 Resolution: Fixed

> Change the text and link for low hanging fruit tickets to include the LHF 
> ticket complexity
> ---
>
> Key: CASSANDRA-15149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15149
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Normal
> Fix For: 4.0
>
> Attachments: CASSANDRA-15149.txt
>
>
> Right now in the docs for how to contribute, it points to the lhf (low 
> hanging fruit) label which is how things were marked before the Jira flow 
> evolution.  We should note the complexity field in there and include both the 
> label and the complexity field in the associated link.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-15149:
---
Status: Ready to Commit  (was: Review In Progress)

> Change the text and link for low hanging fruit tickets to include the LHF 
> ticket complexity
> ---
>
> Key: CASSANDRA-15149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15149
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Normal
> Attachments: CASSANDRA-15149.txt
>
>
> Right now in the docs for how to contribute, it points to the lhf (low 
> hanging fruit) label which is how things were marked before the Jira flow 
> evolution.  We should note the complexity field in there and include both the 
> label and the complexity field in the associated link.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch trunk updated: Change low hanging fruit JIRA link/text in docs

[mshuler]

This is an automated email from the ASF dual-hosted git repository.

mshuler pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new 7c0cb6d  Change low hanging fruit JIRA link/text in docs
7c0cb6d is described below

commit 7c0cb6db32ecbde5534087ce53364bd6cf1ddcec
Author: Jeremy Hanna 
AuthorDate: Thu Jun 13 13:54:24 2019 -0500

Change low hanging fruit JIRA link/text in docs

Patch by Jeremy Hanna, Reviewed by Michael Shuler for CASSANDRA-15149
---
 doc/source/development/patches.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/source/development/patches.rst 
b/doc/source/development/patches.rst
index cc61c6c..43bdb8c 100644
--- a/doc/source/development/patches.rst
+++ b/doc/source/development/patches.rst
@@ -33,7 +33,7 @@ As a general rule of thumb:
 
 .. hint::
 
-   Not sure what to work? Just pick an issue tagged with the `low hanging 
fruit label 
`_
 in JIRA, which we use to flag issues that could turn out to be good starter 
tasks for beginners.
+   Not sure what to work? Just pick an issue marked as `Low Hanging Fruit 
`_
 Complexity in JIRA, which we use to flag issues that could turn out to be good 
starter tasks for beginners.
 
 Before You Start Coding
 ===


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-15149:
---
Reviewers: Michael Shuler
   Status: Review In Progress  (was: Patch Available)

> Change the text and link for low hanging fruit tickets to include the LHF 
> ticket complexity
> ---
>
> Key: CASSANDRA-15149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15149
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Normal
> Attachments: CASSANDRA-15149.txt
>
>
> Right now in the docs for how to contribute, it points to the lhf (low 
> hanging fruit) label which is how things were marked before the Jira flow 
> evolution.  We should note the complexity field in there and include both the 
> label and the complexity field in the associated link.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-3017) add a Message size limit

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-3017:
-
Resolution: Fixed
Status: Resolved  (was: Open)

> add a Message size limit
> 
>
> Key: CASSANDRA-3017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3017
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Streaming and Messaging
>Reporter: Jonathan Ellis
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 
> 0001-use-the-thrift-max-message-size-for-inter-node-messa.patch, 
> trunk-3017.txt
>
>
> We protect the server from allocating huge buffers for malformed message with 
> the Thrift frame size (CASSANDRA-475).  But we don't have similar protection 
> for the inter-node Message objects.
> Adding this would be good to deal with malicious adversaries as well as a 
> malfunctioning cluster participant.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-3017) add a Message size limit

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-3017:
-
Fix Version/s: (was: 4.x)
   4.0

> add a Message size limit
> 
>
> Key: CASSANDRA-3017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3017
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Streaming and Messaging
>Reporter: Jonathan Ellis
>Priority: Low
>  Labels: lhf
> Fix For: 4.0
>
> Attachments: 
> 0001-use-the-thrift-max-message-size-for-inter-node-messa.patch, 
> trunk-3017.txt
>
>
> We protect the server from allocating huge buffers for malformed message with 
> the Thrift frame size (CASSANDRA-475).  But we don't have similar protection 
> for the inter-node Message objects.
> Adding this would be good to deal with malicious adversaries as well as a 
> malfunctioning cluster participant.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-15149:
-
Attachment: CASSANDRA-15149.txt

> Change the text and link for low hanging fruit tickets to include the LHF 
> ticket complexity
> ---
>
> Key: CASSANDRA-15149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15149
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Normal
> Attachments: CASSANDRA-15149.txt
>
>
> Right now in the docs for how to contribute, it points to the lhf (low 
> hanging fruit) label which is how things were marked before the Jira flow 
> evolution.  We should note the complexity field in there and include both the 
> label and the complexity field in the associated link.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-15149:
-
Attachment: (was: CASSANDRA-15149.txt)

> Change the text and link for low hanging fruit tickets to include the LHF 
> ticket complexity
> ---
>
> Key: CASSANDRA-15149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15149
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Normal
> Attachments: CASSANDRA-15149.txt
>
>
> Right now in the docs for how to contribute, it points to the lhf (low 
> hanging fruit) label which is how things were marked before the Jira flow 
> evolution.  We should note the complexity field in there and include both the 
> label and the complexity field in the associated link.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11418:
-
Complexity: Low Hanging Fruit

> Nodetool status should reflect hibernate/replacing states
> -
>
> Key: CASSANDRA-11418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11418
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability, Tool/nodetool
>Reporter: Joel Knighton
>Assignee: Shaurya Gupta
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: cassandra-11418-trunk
>
>
> Currently, the four options for state in nodetool status are 
> joining/leaving/moving/normal.
> Joining nodes are determined based on bootstrap tokens, leaving nodes are 
> based on leaving endpoints in TokenMetadata, moving nodes are based on moving 
> endpoints in TokenMetadata.
> This means that a node will appear in normal state when going through a 
> bootstrap with flag replace_address, which can be confusing to operators.
> We should add another state for hibernation/replacing to make this visible. 
> This will require a way to get a list of all hibernating endpoints.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-10968) When taking snapshot, manifest.json contains incorrect or no files when column family has secondary indexes

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-10968:
-
Complexity: Low Hanging Fruit

> When taking snapshot, manifest.json contains incorrect or no files when 
> column family has secondary indexes
> ---
>
> Key: CASSANDRA-10968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10968
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/2i Index
>Reporter: Fred A
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
>  Labels: lhf
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> xNoticed indeterminate behaviour when taking snapshot on column families that 
> has secondary indexes setup. The created manifest.json created when doing 
> snapshot, sometimes contains no file names at all and sometimes some file 
> names. 
> I don't know if this post is related but that was the only thing I could find:
> http://www.mail-archive.com/user%40cassandra.apache.org/msg42019.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12849) The parameter -XX:HeapDumpPath is not ovewritten by cassandra-env.sh

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12849:
-
Complexity: Low Hanging Fruit

> The parameter  -XX:HeapDumpPath is not ovewritten by cassandra-env.sh
> -
>
> Key: CASSANDRA-12849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: jean carlo rivera ura
>Priority: Normal
>  Labels: lhf
> Attachments: 12849-trunk.txt
>
>
> The parameter  -XX:HeapDumpPath appears twice in the java process 
> {panel}
> user@node:~$ sudo ps aux | grep --color  HeapDumpPath
> java -ea -javaagent:/usr/share/cassandra/lib/jamm-0.3.0.jar 
> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities 
> -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn200M 
> -XX:+HeapDumpOnOutOfMemoryError 
> -XX:*HeapDumpPath*=/var/lib/cassandra-1477577769-pid1516.hprof -Xss256k 
> ...
> -XX:*HeapDumpPath*=/home/cassandra/java_1477577769.hprof 
> -XX:ErrorFile=/var/lib/cassandra/hs_err_1477577769.log 
> org.apache.cassandra.service.CassandraDaemon
> {panel}
> The problem is when we have an OOM error, the JVM dump goes to 
> */home/cassandra/java_1477577769.hprof * when the correct behavior is to go 
> to the path defined by cassandra-env.sh  
> */var/lib/cassandra-1477577769-pid1516.hprof*
> This is quite annoying because cassandra takes into account only the path 
> defined by the script init (usually that disk is not that big to keep 8Gb of 
> a heap dump) and not the path defined in cassandra-env.sh
> {noformat}
> user@node:~$ jmx4perl http://localhost:8523/jolokia read 
> com.sun.management:type=HotSpotDiagnostic DiagnosticOptions
>  {
> name => 'HeapDumpPath',
> origin => 'VM_CREATION',
> value => '/home/cassandra/java_1477043835.hprof',
> writeable => '[true]'
>   },
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9430) Add startup options to cqlshrc

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-9430:

Complexity: Low Hanging Fruit

> Add startup options to cqlshrc
> --
>
> Key: CASSANDRA-9430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9430
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Jeremy Hanna
>Priority: Low
>  Labels: cqlsh, lhf
>
> There are certain settings that would be nice to set defaults for in the 
> cqlshrc file.  For example, a user may want to set the paging to off by 
> default for their environment.  You can't simply do
> {code}
> echo "paging off;" | cqlsh
> {code}
> because this would disable paging and immediately exit cqlsh.
> So it would be nice to have a section of the cqlshrc to include default 
> settings on startup.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12757) NPE if allocate_tokens_for_keyspace is typo/doesn't exist.

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12757:
-
Complexity: Low Hanging Fruit

> NPE if allocate_tokens_for_keyspace is typo/doesn't exist.
> --
>
> Key: CASSANDRA-12757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12757
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Jeremiah Jordan
>Assignee: Damien Stevenson
>Priority: Normal
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x
>
>
> If the keyspace specified in allocate_tokens_for_keyspace does not exist you 
> get an NPE.  Should probably have a better error here letting people know 
> what the issue was.
> {code}
> INFO  21:07:22,582  StorageService.java:1152 - JOINING: getting bootstrap 
> token
> Exception (java.lang.NullPointerException) encountered during startup: null
> ERROR 21:07:22,590  CassandraDaemon.java:709 - Exception encountered during 
> startup
> java.lang.NullPointerException: null
>at 
> org.apache.cassandra.db.Keyspace.createReplicationStrategy(Keyspace.java:325) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.(Keyspace.java:298) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at 
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:201) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at 
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
>  ~[cassandra-all-3.0.8:3.0.8]
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9452) Remove configuration of storage-conf from tools

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-9452:

Complexity: Low Hanging Fruit

> Remove configuration of storage-conf from tools
> ---
>
> Key: CASSANDRA-9452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9452
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Testing, Legacy/Tools, Local/Config
>Reporter: Mike Adamson
>Assignee: Vinay Chella
>Priority: Low
>  Labels: 4.0-feature-freeze-review-requested, lhf
> Fix For: 4.x
>
> Attachments: CASSANDRA-14092-trunk_v1.txt, CASSANDRA-9452-trunk.txt
>
>
> The following files still making reference to storage-config and/or 
> storage-conf.xml
> * ./build.xml
> * ./bin/nodetool
> * ./bin/sstablekeys
> * ./test/resources/functions/configure_cassandra.sh
> * ./test/resources/functions/install_cassandra.sh
> * ./tools/bin/json2sstable
> * ./tools/bin/sstable2json
> * ./tools/bin/sstablelevelreset



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9289) Recover from unknown table when deserializing internode messages

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-9289:

Complexity: Low Hanging Fruit

> Recover from unknown table when deserializing internode messages
> 
>
> Key: CASSANDRA-9289
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9289
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tyler Hobbs
>Assignee: ZhaoYang
>Priority: Low
>  Labels: lhf
> Fix For: 3.11.x
>
>
> As discussed in CASSANDRA-9136, it would be nice to gracefully recover from 
> seeing an unknown table in a message from another node.  Currently, we close 
> the connection and reconnect, which can cause other concurrent queries to 
> fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12972) Print stress-tool output header about each 30 secs.

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12972:
-
Complexity: Low Hanging Fruit

> Print stress-tool output header about each 30 secs.
> ---
>
> Key: CASSANDRA-12972
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12972
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools, Tool/stress
>Reporter: Vovodroid
>Assignee: Vovodroid
>Priority: Low
>  Labels: lhf
> Attachments: 3.11.patch
>
>
> Currently header with columns meaning is printed only on test beginning. If 
> test is long it's not handy to interpret rows with numbers only.
> I propose to repeatably print headers each half-minute or so.
> Patch is available, is this improvement needed?
> Thanks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12701) Repair history tables should have TTL and TWCS

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12701:
-
Complexity: Low Hanging Fruit

> Repair history tables should have TTL and TWCS
> --
>
> Key: CASSANDRA-12701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12701
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Chris Lohfink
>Priority: Normal
>  Labels: lhf
> Attachments: CASSANDRA-12701.txt
>
>
> Some tools schedule a lot of small subrange repairs which can lead to a lot 
> of repairs constantly being run. These partitions can grow pretty big in 
> theory. I dont think much reads from them which might help but its still 
> kinda wasted disk space. I think a month TTL (longer than gc grace) and maybe 
> a 1 day twcs window makes sense to me.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12922:
-
Complexity: Low Hanging Fruit

> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Local Write-Read Paths
>Reporter: Branimir Lambov
>Assignee: Sundar Srinivasan
>Priority: Normal
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 12922-trunk.txt
>
>
> Bloom filter hits and misses are evaluated incorrectly in 
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In 
> particular, if we don't find a match for a key in the index, which is where 
> almost all non-matches will be rejected, [we don't record a bloom filter 
> false 
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14128) Prune dead links from cassandra.apache.org

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14128:
-
Complexity: Low Hanging Fruit

> Prune dead links from cassandra.apache.org
> --
>
> Key: CASSANDRA-14128
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14128
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Documentation and Website
>Reporter: Jeff Jirsa
>Assignee: Kurt Greaves
>Priority: Low
>  Labels: lhf
> Attachments: 14128-site.patch
>
>
> Lots of dead links on the site, including the homepage. Should do some 
> pruning cleanup.
> Site repo is [here|https://svn.apache.org/repos/asf/cassandra/site/] (in svn) 
> for anyone who wishes to give this a shot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13917) COMPACT STORAGE queries on dense static tables accept hidden column1 and value columns

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13917:
-
Complexity: Low Hanging Fruit

> COMPACT STORAGE queries on dense static tables accept hidden column1 and 
> value columns
> --
>
> Key: CASSANDRA-13917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13917
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: Alex Petrov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x
>
> Attachments: 13917-3.0-testall-2.png, 13917-3.0.png, 
> 13917-3.11-testall-2.png, 13917-3.11.png
>
>
> Test for the issue:
> {code}
> @Test
> public void testCompactStorage() throws Throwable
> {
> createTable("CREATE TABLE %s (a int PRIMARY KEY, b int, c int) WITH 
> COMPACT STORAGE");
> assertInvalid("INSERT INTO %s (a, b, c, column1) VALUES (?, ?, ?, 
> ?)", 1, 1, 1, ByteBufferUtil.bytes('a'));
> // This one fails with Some clustering keys are missing: column1, 
> which is still wrong
> assertInvalid("INSERT INTO %s (a, b, c, value) VALUES (?, ?, ?, ?)", 
> 1, 1, 1, ByteBufferUtil.bytes('a'));   
> assertInvalid("INSERT INTO %s (a, b, c, column1, value) VALUES (?, ?, 
> ?, ?, ?)", 1, 1, 1, ByteBufferUtil.bytes('a'), ByteBufferUtil.bytes('b'));
> assertEmpty(execute("SELECT * FROM %s"));
> }
> {code}
> Gladly, these writes are no-op, even though they succeed.
> {{value}} and {{column1}} should be completely hidden. Fixing this one should 
> be as easy as just adding validations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12273) Casandra stress graph: option to create directory for graph if it doesn't exist

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12273:
-
Complexity: Low Hanging Fruit

> Casandra stress graph: option to create directory for graph if it doesn't 
> exist
> ---
>
> Key: CASSANDRA-12273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12273
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Christopher Batey
>Assignee: Murukesh Mohanan
>Priority: Low
>  Labels: lhf
> Attachments: 12273.patch
>
>
> I am running it in CI with ephemeral workspace  / build dirs. It would be 
> nice if CS would create the directory so my build tool doesn't have to



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13692) CompactionAwareWriter_getWriteDirectory throws incompatible exceptions

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13692:
-
Complexity: Low Hanging Fruit

> CompactionAwareWriter_getWriteDirectory throws incompatible exceptions
> --
>
> Key: CASSANDRA-13692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13692
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Hao Zhong
>Assignee: Dimitar Dimitrov
>Priority: Normal
>  Labels: lhf
> Attachments: c13692-2.2-dtest-results.PNG, 
> c13692-2.2-testall-results.PNG, c13692-3.0-dtest-results-updated.PNG, 
> c13692-3.0-dtest-results.PNG, c13692-3.0-testall-results.PNG, 
> c13692-3.11-dtest-results-updated.PNG, c13692-3.11-dtest-results.PNG, 
> c13692-3.11-testall-results.PNG, c13692-dtest-results-updated.PNG, 
> c13692-dtest-results.PNG, c13692-testall-results-updated.PNG, 
> c13692-testall-results.PNG
>
>
> The CompactionAwareWriter_getWriteDirectory throws RuntimeException:
> {code}
> public Directories.DataDirectory getWriteDirectory(Iterable 
> sstables, long estimatedWriteSize)
> {
> File directory = null;
> for (SSTableReader sstable : sstables)
> {
> if (directory == null)
> directory = sstable.descriptor.directory;
> if (!directory.equals(sstable.descriptor.directory))
> {
> logger.trace("All sstables not from the same disk - putting 
> results in {}", directory);
> break;
> }
> }
> Directories.DataDirectory d = 
> getDirectories().getDataDirectoryForFile(directory);
> if (d != null)
> {
> long availableSpace = d.getAvailableSpace();
> if (availableSpace < estimatedWriteSize)
> throw new RuntimeException(String.format("Not enough space to 
> write %s to %s (%s available)",
>  
> FBUtilities.prettyPrintMemory(estimatedWriteSize),
>  d.location,
>  
> FBUtilities.prettyPrintMemory(availableSpace)));
> logger.trace("putting compaction results in {}", directory);
> return d;
> }
> d = getDirectories().getWriteableLocation(estimatedWriteSize);
> if (d == null)
> throw new RuntimeException(String.format("Not enough disk space 
> to store %s",
>  
> FBUtilities.prettyPrintMemory(estimatedWriteSize)));
> return d;
> }
> {code}
> However, the thrown exception does not  trigger the failure policy. 
> CASSANDRA-11448 fixed a similar problem. The buggy code is:
> {code}
> protected Directories.DataDirectory getWriteDirectory(long writeSize)
> {
> Directories.DataDirectory directory = 
> getDirectories().getWriteableLocation(writeSize);
> if (directory == null)
> throw new RuntimeException("Insufficient disk space to write " + 
> writeSize + " bytes");
> return directory;
> }
> {code}
> The fixed code is:
> {code}
> protected Directories.DataDirectory getWriteDirectory(long writeSize)
> {
> Directories.DataDirectory directory = 
> getDirectories().getWriteableLocation(writeSize);
> if (directory == null)
> throw new FSWriteError(new IOException("Insufficient disk space 
> to write " + writeSize + " bytes"), "");
> return directory;
> }
> {code}
> The fixed code throws FSWE and triggers the failure policy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14410) tablehistograms with non-existent table gives an exception

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14410:
-
Complexity: Low Hanging Fruit

> tablehistograms with non-existent table gives an exception
> --
>
> Key: CASSANDRA-14410
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14410
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Normal
>  Labels: lhf
> Fix For: 3.11.x, 4.x
>
>
> nodetool tablehistograms with non-existent table gives a crazy exception. It 
> should give a nice error message like "Table acdc.abba doesn't exist" or 
> something like that.
>  
> Example:
> {code:java}
> $ nodetool tablehistograms acdc.abba
> error: 
> org.apache.cassandra.metrics:type=Table,keyspace=acdc,scope=abba,name=EstimatedPartitionSizeHistogram
> -- StackTrace --
> javax.management.InstanceNotFoundException: 
> org.apache.cassandra.metrics:type=Table,keyspace=acdc,scope=abba,name=EstimatedPartitionSizeHistogram
>     at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
>     at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
>     at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1445)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:639)
>     at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:498)
>     at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
>     at sun.rmi.transport.Transport$1.run(Transport.java:200)
>     at sun.rmi.transport.Transport$1.run(Transport.java:197)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>     at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
>     at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
>     at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>     at java.lang.Thread.run(Thread.java:745)
>     at 
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
>     at 
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
>     at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
>     at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl_Stub.getAttribute(Unknown 
> Source)
>     at 
> javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.getAttribute(RMIConnector.java:903)
>     at 
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
>     at com.sun.proxy.$Proxy20.getValue(Unknown Source)
>     at 
> org.apache.cassandra.tools.NodeProbe.getColumnFamilyMetric(NodeProbe.java:1334)
>     at 
> org.apache.cassandra.tools.nodetool.TableHistograms.execute(TableHistograms.java:62)
>     at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:254)
>     at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:168){code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14098) Potential Integer Overflow

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14098:
-
Complexity: Low Hanging Fruit

> Potential Integer Overflow
> --
>
> Key: CASSANDRA-14098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14098
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: songwanging
>Priority: Low
>  Labels: lhf
> Attachments: 14098-3.0.txt
>
>
> Our tool DeepTect has detected a potential integer overflow: 
> Path: cassandra/src/java/org/apache/cassandra/service/StorageService.java
> {code:java}
> ...
> long totalRowCountEstimate = cfs.estimatedKeysForRange(range);
> ...
>  int splitCount = Math.max(1, Math.min(maxSplitCount, 
> (int)(totalRowCountEstimate / keysPerSplit)));
> {code}
> In the above code snippet, "totalRowCountEstimate" is a long variable, 
> "keysPerSplit" is an integer variable. If "totalRowCountEstimate" is super 
> large, directly casting "(totalRowCountEstimate / keysPerSplit" into integer 
> will definitely lead to a potential integer overflow.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11537:
-
Complexity: Low Hanging Fruit

> Give clear error when certain nodetool commands are issued before server is 
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Priority: Low
>  Labels: lhf
>
> As an ops person upgrading and servicing Cassandra servers, I require a more 
> clear message when I issue a nodetool command that the server is not ready 
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool 
> scrub/compact/updatess etc you get unfriendly assertion. An exception would 
> be easier to understand. Also if a user has turned assertions off it is 
> unclear what might happen. 
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process. 
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at 
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at 
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at 
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1: 
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

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

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-10023:
-
Complexity: Low Hanging Fruit

> Emit a metric for number of local read and write calls
> --
>
> Key: CASSANDRA-10023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10023
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Metrics
>Reporter: sankalp kohli
>Assignee: Damien Stevenson
>Priority: Low
>  Labels: 4.0-feature-freeze-review-requested, lhf
> Fix For: 4.x
>
> Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, 
> CASSANDRA-10023.patch
>
>
> Many C* drivers have feature to be replica aware and chose the co-ordinator 
> which is a replica. We should add a metric which tells us whether all calls 
> to the co-ordinator are replica aware.
> We have seen issues where client thinks they are replica aware when they 
> forget to add routing key at various places in the code. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9191) Log and count failure to obtain requested consistency

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-9191:

Complexity: Low Hanging Fruit

> Log and count failure to obtain requested consistency
> -
>
> Key: CASSANDRA-9191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9191
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Coordination, Legacy/Observability
>Reporter: Matt Stump
>Priority: Low
>  Labels: lhf
> Attachments: patch_CASSANDRA-9191_trunk, patch_CASSANDRA-9191_v3.11.3
>
>
> Cassandra should have a way to log failed requests due to failure to obtain 
> requested consistency. This should be logged as error or warning by default. 
> Also exposed should be a counter for the benefit of opscenter. 
> Currently the only way to log this is at the client. Often the application 
> and DB teams are separate and it's very difficult to obtain client logs. Also 
> because it's only visible to the client no visibility is given to opscenter 
> making it difficult for the field to track down or isolate systematic or node 
> level errors.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11695) Move JMX connection config to cassandra.yaml

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11695:
-
Complexity: Low Hanging Fruit

> Move JMX connection config to cassandra.yaml
> 
>
> Key: CASSANDRA-11695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11695
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Sam Tunnicliffe
>Assignee: Zhongxiang Zheng
>Priority: Low
>  Labels: lhf
> Fix For: 3.11.x
>
>
> Since CASSANDRA-10091, we always construct the JMX connector server 
> programatically, so we could move its configuration from cassandra-env to 
> yaml.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-8969) Add indication in cassandra.yaml that rpc timeouts going too high will cause memory build up

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-8969:

Complexity: Low Hanging Fruit

> Add indication in cassandra.yaml that rpc timeouts going too high will cause 
> memory build up
> 
>
> Key: CASSANDRA-8969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8969
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
>  Labels: lhf
> Fix For: 3.11.x
>
> Attachments: 8969.txt
>
>
> It would be helpful to communicate that setting the rpc timeouts too high may 
> cause memory problems on the server as it can become overloaded and has to 
> retain the in flight requests in memory.  I'll get this done but just adding 
> the ticket as a placeholder for memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13855) URL Seed provider

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13855:
-
Complexity: Low Hanging Fruit

> URL Seed provider
> -
>
> Key: CASSANDRA-13855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13855
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Coordination, Legacy/Core
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>  Labels: lhf
> Attachments: 0001-Add-URL-Seed-Provider-trunk.txt
>
>
> Seems like including a dead simple seed provider that can fetch from a URL, 1 
> line per seed, would be useful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14566) Cache CSM.onlyPurgeRepairedTombstones()

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14566:
-
Complexity: Low Hanging Fruit

> Cache CSM.onlyPurgeRepairedTombstones()
> ---
>
> Key: CASSANDRA-14566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14566
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Stefan Podkowinski
>Assignee: Thomas Pouget-Abadie
>Priority: Low
>  Labels: lhf, performance
> Attachments: 14566-3.11.txt
>
>
> We currently call {{CompactionStrategyManager.onlyPurgeRepairedTombstones()}} 
> *a lot* during compaction, I think at least for every key. So we should 
> probably cache the value, instead of constantly reading from a volatile and 
> calling parseBoolean.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14218) Deprecate Throwables.propagate usage

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14218:
-
Complexity: Low Hanging Fruit

> Deprecate Throwables.propagate usage
> 
>
> Key: CASSANDRA-14218
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14218
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Dependencies
>Reporter: Romain Hardouin
>Assignee: Kirk True
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 14218-trunk.txt, 14218-trunk.txt
>
>
> Google decided to deprecate guava {{Throwables.propagate}} method:
>  * [Why we deprecated 
> Throwables.propagate|https://github.com/google/guava/wiki/Why-we-deprecated-Throwables.propagate]
>  * [Documentation 
> update|https://github.com/google/guava/wiki/ThrowablesExplained/_compare/92190ee7e37d334fa5fcdb6db8d0f43a2fdf02e1...226a3060445716d479981e606f589c99eee517ca]
> We have 35 occurences in the trunk:
> {code:java}
> $ rg -c 'Throwables.propagate' *
> src/java/org/apache/cassandra/streaming/StreamReader.java:1
> src/java/org/apache/cassandra/streaming/StreamTransferTask.java:1
> src/java/org/apache/cassandra/db/SnapshotDetailsTabularData.java:1
> src/java/org/apache/cassandra/db/Memtable.java:1
> src/java/org/apache/cassandra/db/ColumnFamilyStore.java:4
> src/java/org/apache/cassandra/cache/ChunkCache.java:2
> src/java/org/apache/cassandra/utils/WrappedRunnable.java:1
> src/java/org/apache/cassandra/hints/Hint.java:1
> src/java/org/apache/cassandra/tools/LoaderOptions.java:1
> src/java/org/apache/cassandra/tools/SSTableOfflineRelevel.java:1
> src/java/org/apache/cassandra/streaming/management/ProgressInfoCompositeData.java:3
> src/java/org/apache/cassandra/streaming/management/StreamStateCompositeData.java:2
> src/java/org/apache/cassandra/streaming/management/StreamSummaryCompositeData.java:2
> src/java/org/apache/cassandra/streaming/compress/CompressedStreamReader.java:1
> src/java/org/apache/cassandra/db/compaction/Scrubber.java:1
> src/java/org/apache/cassandra/db/compaction/Verifier.java:1
> src/java/org/apache/cassandra/db/compaction/CompactionHistoryTabularData.java:1
> src/java/org/apache/cassandra/db/compaction/Upgrader.java:1
> src/java/org/apache/cassandra/io/compress/CompressionMetadata.java:1
> src/java/org/apache/cassandra/streaming/management/SessionCompleteEventCompositeData.java:2
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleWriter.java:1
> src/java/org/apache/cassandra/io/sstable/ISSTableScanner.java:1
> src/java/org/apache/cassandra/streaming/management/SessionInfoCompositeData.java:3
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java:1
> {code}
> I don't know if we want to remove all usages but we should at least check 
> author's intention for each usage and refactor if needed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13685) PartitionColumns.java:161: java.lang.AssertionError: null

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13685:
-
Complexity: Low Hanging Fruit

> PartitionColumns.java:161: java.lang.AssertionError: null
> -
>
> Key: CASSANDRA-13685
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13685
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Legacy/Local Write-Read Paths
>Reporter: Jay Zhuang
>Assignee: Michael Burman
>Priority: Low
>  Labels: lhf
> Attachments: CASSANDRA-13685.patch
>
>
> Similar to CASSANDRA-8192, I guess the SSTable is corrupted:
> {noformat}
> ERROR [SSTableBatchOpen:1] 2017-07-10 21:28:09,325 CassandraDaemon.java:207 - 
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:339)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:486)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:375)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$4.run(SSTableReader.java:534)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_121]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {noformat}
> Would be better to report {{CorruptSSTableException}} with SSTable path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13874) nodetool setcachecapacity behaves oddly when cache size = 0

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13874:
-
Complexity: Low Hanging Fruit

> nodetool setcachecapacity behaves oddly when cache size = 0
> ---
>
> Key: CASSANDRA-13874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13874
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Local/Config
>Reporter: Jon Haddad
>Assignee: Michal Szczepanski
>Priority: Low
>  Labels: lhf, user-experience
> Attachments: 13874-trunk.txt
>
>
> If a node has row cache disabled, trying to turn it on via setcachecapacity 
> doesn't issue an error, and doesn't turn it on, it just silently doesn't work.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14787) nodetool status "Load" columns has wrong width

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14787:
-
Complexity: Low Hanging Fruit

> nodetool status "Load" columns has wrong width
> --
>
> Key: CASSANDRA-14787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14787
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: Lapo Luchini
>Assignee: Kirk True
>Priority: Low
>  Labels: lhf, nodetool, pull-request-available
> Fix For: 4.x
>
> Attachments: CASSANDRA-14787.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Using Cassandra 3.11.2 on FreeBSD, I get:
> {code:java}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  AddressLoad   Tokens   Owns (effective)  Host ID ...
> UN  server1.andxor.it  11.11 MiB  256  39.6% ...
> UN  server2.andxor.it  32.04 MiB  256  41.8% ...
> UN  server3.andxor.it  519.33 KiB  256  40.0% ...
> UN  server4.andxor.it  10.95 MiB  256  40.3% ...
> UN  server5.andxor.it  11.03 MiB  256  38.4% ...
> {code}
> AFAICT this is caused by {{"%-9s"}} in 
> [Status.java:292|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/tools/nodetool/Status.java#L292]
>  which should be probably a 10 instead of 9.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-10273) Reduce number of data directory scans during startup

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-10273:
-
Complexity: Low Hanging Fruit

> Reduce number of data directory scans during startup
> 
>
> Key: CASSANDRA-10273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10273
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Robert Stupp
>Assignee: Shaurya Gupta
>Priority: Low
>  Labels: lhf
> Attachments: patch_CASSANDRA-10273_trunk
>
>
> ATM we scan each data directory four times. We could easily reduce that to at 
> least two, maybe to one.
> # pre-flight (startup tests) scrub
> # pre-flight (startup tests) sstable min version
> # {{ColumnFamilyStore.createColumnFamilyStore}}
> # {{ColumnFamilyStore.}} (if {{loadSSTables==true}})
> First two pre-flight tests could be combined to one and 3+4 could also be 
> combined, as both appear at pretty related code paths.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14563) Add animalsniffer to build to ensure runtime jdk compatbility

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14563:
-
Complexity: Low Hanging Fruit

> Add animalsniffer to build to ensure runtime jdk compatbility
> -
>
> Key: CASSANDRA-14563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14563
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: mck
>Assignee: Sumanth Pasupuleti
>Priority: Low
>  Labels: lhf
>
> Cassandra-2.2 still supports running on JDK1.7
> No tests check this though, as all build and test with JDK1.8
> Adding the ant animalsniffer task can check that jdk1.8 classes or methods 
> are not used accidentally.
> ref: http://www.mojohaus.org/animal-sniffer/animal-sniffer/index.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14228) Add expiration date overflow notice and recovery instructions to doc

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14228:
-
Complexity: Low Hanging Fruit

> Add expiration date overflow notice and recovery instructions to doc
> 
>
> Key: CASSANDRA-14228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14228
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Documentation and Website
>Reporter: Paulo Motta
>Assignee: Andrew Baker
>Priority: Low
>  Labels: lhf
>
> On CASSANDRA-14092 we added a new 
> [CASSANDRA-14092.txt|https://github.com/apache/cassandra/blob/trunk/CASSANDRA-14092.txt]
>  file with the maximum ttl expiration notice and recovery instructions for 
> affected users.
> We should probably also add the contents of this file to the documentation 
> with some basic formatting.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12464) Investigate the potential improvement of parallelism on higher level compactions in LCS

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12464:
-
Complexity: Low Hanging Fruit

> Investigate the potential improvement of parallelism on higher level 
> compactions in LCS
> ---
>
> Key: CASSANDRA-12464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12464
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Wei Deng
>Assignee: Pramod K Sivaraju
>Priority: Normal
>  Labels: lcs, lhf, performance
>
> According to LevelDB's design doc 
> [here|https://github.com/google/leveldb/blob/master/doc/impl.md#compactions], 
> "A compaction merges the contents of the picked files to produce a sequence 
> of level-(L+1) files", it will "switch to producing a new level-(L+1) file 
> after the current output file has reached the target file size" (in our case 
> 160MB), it will also "switch to a new output file when the key range of the 
> current output file has grown enough to overlap more than ten level-(L+2) 
> files". This is to ensure "that a later compaction of a level-(L+1) file will 
> not pick up too much data from level-(L+2)."
> Our current code in LeveledCompactionStrategy doesn't implement this last 
> rule, but we might be able to quickly implement it and see how much a 
> compaction throughput improvement it can deliver. Potentially we can create a 
> scenario where a number of large L0 SSTables are present (e.g. 200GB after 
> switching from STCS) and let it to create thousands of L1 SSTables overflow, 
> and see how fast LCS can digest this much data from L1 and properly 
> upper-level them to completion.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13010:
-
Complexity: Low Hanging Fruit

> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Compaction, Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Alex Lourie
>Priority: Normal
>  Labels: 4.0-feature-freeze-review-requested, lhf
> Attachments: cleanup.png, multiple operations.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13016) log messages should include human readable sizes

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13016:
-
Complexity: Low Hanging Fruit

> log messages should include human readable sizes
> 
>
> Key: CASSANDRA-13016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13016
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability
>Reporter: Jon Haddad
>Assignee: Sumant Sahney
>Priority: Normal
>  Labels: lhf
>
> displaying bytes by itself is difficult to read when going through log 
> messages.  we should add a human readable version in parens (10MB) after 
> displaying bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12937) Default setting (yaml) for SSTable compression

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12937:
-
Complexity: Low Hanging Fruit

> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: mck
>Assignee: Vinay Chella
>Priority: Low
>  Labels: lhf
>
> In many situations the choice of compression for sstables is more relevant to 
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable 
> compression that new tables will inherit (instead of the defaults found in 
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly 
> compression (btrfs, zfs) or specific disk configurations or even specific C* 
> versions (see CASSANDRA-10995 ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11370) Display sstable count per level according to repair status on nodetool tablestats

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11370:
-
Complexity: Low Hanging Fruit

> Display sstable count per level according to repair status on nodetool 
> tablestats
> -
>
> Key: CASSANDRA-11370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11370
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Paulo Motta
>Priority: Low
>  Labels: lhf
>
> After CASSANDRA-8004 we still display sstables in each level on nodetool 
> tablestats as if we had a single compaction strategy, while we have one 
> strategy for repaired and another for unrepaired data. 
> We should split display into repaired and unrepaired set, so this:
> SSTables in each level: [2, 20/10, 15, 0, 0, 0, 0, 0, 0]
> Would become:
> SSTables in each level (repaired): [1, 10, 0, 0, 0, 0, 0, 0, 0]
> SSTables in each level (unrepaired): [1, 10, 15, 0, 0, 0, 0, 0, 0]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12881) Move SASI docs into sphinx docs

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12881:
-
Complexity: Low Hanging Fruit

> Move SASI docs into sphinx docs
> ---
>
> Key: CASSANDRA-12881
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12881
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Documentation and Website
>Reporter: Evan Prothro
>Priority: Low
>  Labels: lhf, sasi
>
> Previous TODO in code regarding SASI docs:
> TODO: we should probably move the first half of that documentation to the 
> general documentation, and the implementation explanation parts into the wiki.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14476) ShortType and ByteType are incorrectly considered variable-length types

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14476:
-
Complexity: Low Hanging Fruit

> ShortType and ByteType are incorrectly considered variable-length types
> ---
>
> Key: CASSANDRA-14476
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14476
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: Vladimir Krivopalov
>Assignee: Jearvon Dharrie
>Priority: Low
>  Labels: lhf
>
> The AbstractType class has a method valueLengthIfFixed() that returns -1 for 
> data types with a variable length and a positive value for types with a fixed 
> length. This is primarily used for efficient serialization and 
> deserialization. 
>  
> It turns out that there is an inconsistency in types ShortType and ByteType 
> as those are in fact fixed-length types (2 bytes and 1 byte, respectively) 
> but they don't have the valueLengthIfFixed() method overloaded and it returns 
> -1 as if they were of variable length.
>  
> It would be good to fix that at some appropriate point, for example, when 
> introducing a new version of SSTables format, to keep the meaning of the 
> function consistent across data types. Saving some bytes in serialized format 
> is a minor but pleasant bonus.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12001) nodetool stopdaemon doesn't stop cassandra gracefully

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12001:
-
Complexity: Low Hanging Fruit

> nodetool stopdaemon  doesn't  stop cassandra gracefully 
> 
>
> Key: CASSANDRA-12001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12001
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
> Environment: Ubuntu: Linux  3.11.0-15-generic #25~precise1-Ubuntu SMP 
> Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Cassandra Version : 
> cassandra -v
> 2.1.2
>Reporter: Anshu Vajpayee
>Priority: Low
>  Labels: lhf
>
> As per general opinion, nodetool stopdaemon should perform graceful shutdown 
> rater than crash killing of cassandra daemon .
> It  doesn't flush the memtables and also it doesn't stop the thrift and CQL 
> connection interfaces before crashing/stopping  the node.  It directly calls 
> SIGTERM on process as simple as kill -15/ctrl + c. 
>  
> 1. created a table  like as below:
> cqlsh:test_ks> create table t2(id1 int, id2 text, primary key(id1));
> cqlsh:test_ks> 
> cqlsh:test_ks> insert into t2(id1,id2) values (1,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (2,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (3,'a');
> cqlsh:test_ks> select * from t2;
>  id1 | id2
> -+-
>1 |   a
>2 |   a
>3 |   a
> 2.Flush  the memtable manually using nodetool flush
> student@cascor:~/node1/apache-cassandra-2.1.2/bin$ nodetool flush
> student@cascor:~/node1/apache-cassandra-2.1.2/bin$ cd 
> ../data/data/test_ks/t2-a671f6b0319a11e6a91ae3263299699d/
> student@cascor:~/node1/apache-cassandra-2.1.2/data/data/test_ks/t2-a671f6b0319a11e6a91ae3263299699d$
>  ls -ltr 
> total 36
> -rw-rw-r-- 1 student student   16 Jun 13 12:14 test_ks-t2-ka-1-Filter.db
> -rw-rw-r-- 1 student student   54 Jun 13 12:14 test_ks-t2-ka-1-Index.db
> -rw-rw-r-- 1 student student   93 Jun 13 12:14 test_ks-t2-ka-1-Data.db
> -rw-rw-r-- 1 student student   91 Jun 13 12:14 test_ks-t2-ka-1-TOC.txt
> -rw-rw-r-- 1 student student   80 Jun 13 12:14 test_ks-t2-ka-1-Summary.db
> -rw-rw-r-- 1 student student 4442 Jun 13 12:14 test_ks-t2-ka-1-Statistics.db
> -rw-rw-r-- 1 student student   10 Jun 13 12:14 test_ks-t2-ka-1-Digest.sha1
> -rw-rw-r-- 1 student student   43 Jun 13 12:14 
> test_ks-t2-ka-1-CompressionInfo.db
> 3. Make few more changes on table t2
> cqlsh:test_ks> insert into t2(id1,id2) values (5,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (6,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (7,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (8,'a');
> cqlsh:test_ks> select * from t2;
>  id1 | id2
> -+-
>5 |   a
>1 |   a
>8 |   a
>2 |   a
>7 |   a
>6 |   a
>3 |   a
> 4. Stopping the node using nodetool stopdaemon 
> student@cascor:~$ nodetool stopdaemon
> Cassandra has shutdown.
> error: Connection refused
> -- StackTrace --
> java.net.ConnectException: Connection refused
> 5. No new version of SStables . Reason stopdaemon doesn't run nodetool 
> flush/drain before actually stopping daemon.
> student@cascor:~/node1/apache-cassandra-2.1.2/data/data/test_ks/t2-a671f6b0319a11e6a91ae3263299699d$
>  ls -ltr
> total 36
> -rw-rw-r-- 1 student student   16 Jun 13 12:14 test_ks-t2-ka-1-Filter.db
> -rw-rw-r-- 1 student student   54 Jun 13 12:14 test_ks-t2-ka-1-Index.db
> -rw-rw-r-- 1 student student   93 Jun 13 12:14 test_ks-t2-ka-1-Data.db
> -rw-rw-r-- 1 student student   91 Jun 13 12:14 test_ks-t2-ka-1-TOC.txt
> -rw-rw-r-- 1 student student   80 Jun 13 12:14 test_ks-t2-ka-1-Summary.db
> -rw-rw-r-- 1 student student 4442 Jun 13 12:14 test_ks-t2-ka-1-Statistics.db
> -rw-rw-r-- 1 student student   10 Jun 13 12:14 test_ks-t2-ka-1-Digest.sha1
> -rw-rw-r-- 1 student student   43 Jun 13 12:14 
> test_ks-t2-ka-1-CompressionInfo.db
> student@cascor:~/node1/apache-cassandra-2.1.2/data/data/test_ks/t2-a671f6b0319a11e6a91ae3263299699d$
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11141) Alert if firewall is running and/or blocking C* ports

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11141:
-
Complexity: Low Hanging Fruit

> Alert if firewall is running and/or blocking C* ports
> -
>
> Key: CASSANDRA-11141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11141
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Paulo Motta
>Priority: Low
>  Labels: lhf
>
> We've struggled quite a few times with firewalls blocking C* port on Windows. 
> [~JoshuaMcKenzie] suggested on CASSANDRA-11073:
> bq. It'd be nice if there's a way for us to check whether or not firewalls 
> are running on Windows and fire an alert if found (or if C* ports are blocked 
> in built-in firewall, for instance).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11097) Idle session timeout for secure environments

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11097:
-
Complexity: Low Hanging Fruit

> Idle session timeout for secure environments
> 
>
> Key: CASSANDRA-11097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11097
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/CQL
>Reporter: Jeff Jirsa
>Priority: Low
>  Labels: lhf, ponies
>
> A thread on the user list pointed out that some use cases may prefer to have 
> a database disconnect sessions after some idle timeout. An example would be 
> an administrator who connected via ssh+cqlsh and then walked away. 
> Disconnecting that user and forcing it to re-authenticate could protect 
> against unauthorized access.
> It seems like it may be possible to do this using a netty 
> {{IdleStateHandler}} in a way that's low risk and perhaps off by default.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13356) BootstrapMonitor.progress does not store all error messages

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13356:
-
Complexity: Low Hanging Fruit

> BootstrapMonitor.progress does not store all error messages
> ---
>
> Key: CASSANDRA-13356
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13356
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: Hao Zhong
>Assignee: Hao Zhong
>Priority: Normal
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: cassandra.patch
>
>
> The BootstrapMonitor.progress ignores error messages when an error is 
> ProgressEventType.ERROR. Indeed, RepairRunner.progress once had a similar 
> bug, but is fixed. The fixed code is:
> {code}
>  public void progress(String tag, ProgressEvent event)
> {
> ProgressEventType type = event.getType();
> String message = String.format("[%s] %s", 
> format.format(System.currentTimeMillis()), event.getMessage());
> if (type == ProgressEventType.PROGRESS)
> {
> message = message + " (progress: " + 
> (int)event.getProgressPercentage() + "%)";
> }
> out.println(message);
> if (type == ProgressEventType.ERROR)
> {
> error = new RuntimeException("Repair job has failed with the 
> error message: " + message);
> }
> if (type == ProgressEventType.COMPLETE)
> {
> condition.signalAll();
> }
> }
> {code}
> Please refer to CASSANDRA-12508 for details.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11714) shutdown script should wait more than 30 seconds before force kill

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11714:
-
Complexity: Low Hanging Fruit

> shutdown script should wait more than 30 seconds before force kill
> --
>
> Key: CASSANDRA-11714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11714
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Wei Deng
>Assignee: Wei Deng
>Priority: Low
>  Labels: lhf
>
> I'm running with 3.0.6 and it appears that if I let it run for multiple days 
> (ingesting a never-ending streaming data from Kafka), then the next time I'm 
> restarting the JVM by "service cassandra restart", it will take 9 minutes to 
> replay the commit log segments (the commitlog_total_space_in_mb is using the 
> default 8GB and I observed close to 8GB commitlog segment files before the 
> restart). Here is a fragment of the system.log showing how long it takes:
> {noformat}
> INFO  [main] 2016-05-04 19:06:54,356  CommitLog.java:168 - Replaying 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248187.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248191.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248195.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248198.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248201.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248205.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248209.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248213.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248217.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248221.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248225.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248230.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248234.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248238.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248242.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248246.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248250.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248254.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248258.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248262.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248266.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248270.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248274.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248278.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248282.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248286.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248290.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248294.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248299.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248303.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248307.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248311.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248315.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248319.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248323.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248327.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248331.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248335.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248340.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248344.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248348.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248352.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248356.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248360.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248364.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248368.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248372.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248376.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248380.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248384.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248388.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248392.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248396.log, 
> 

[jira] [Updated] (CASSANDRA-3017) add a Message size limit

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-3017:

Complexity: Low Hanging Fruit

> add a Message size limit
> 
>
> Key: CASSANDRA-3017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3017
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Streaming and Messaging
>Reporter: Jonathan Ellis
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 
> 0001-use-the-thrift-max-message-size-for-inter-node-messa.patch, 
> trunk-3017.txt
>
>
> We protect the server from allocating huge buffers for malformed message with 
> the Thrift frame size (CASSANDRA-475).  But we don't have similar protection 
> for the inter-node Message objects.
> Adding this would be good to deal with malicious adversaries as well as a 
> malfunctioning cluster participant.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13990) Remove OldNetworkTopologyStrategy

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13990:
-
Complexity: Low Hanging Fruit

> Remove OldNetworkTopologyStrategy
> -
>
> Key: CASSANDRA-13990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13990
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Jeremy Hanna
>Priority: Low
>  Labels: lhf
>
> RackAwareStrategy was renamed OldNetworkTopologyStrategy back in 0.7 
> (CASSANDRA-1392) and it's still around.  Is there any reason to keep this 
> relatively dead code in the codebase at this point?  I'm not aware of its use 
> and it sometimes confuses users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14810) Upgrade dtests to pytest-3.8

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14810:
-
Complexity: Low Hanging Fruit

> Upgrade dtests to pytest-3.8
> 
>
> Key: CASSANDRA-14810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14810
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Stefan Podkowinski
>Assignee: Thomas Pouget-Abadie
>Priority: Low
>  Labels: lhf
> Attachments: 14810-master.txt
>
>
> The [dtest project|https://github.com/apache/cassandra-dtest] uses pytest as 
> test runner of choice for executing tests on builds.apache.org or CircleCI. 
> The pytest dependency has recently been upgrade to 3.6, but couldn't be 
> upgrade to the most recent 3.8 version, due to issues described below.
> Before test execution, the {{run_dtests.py}} script will gather a list of all 
> tests:
>  {{./run_dtests.py --dtest-print-tests-only}}
> Afterwards pytest can be started with any of the output lines as argument. 
> With pytest-3.8 however, the output format changed and preventing pytest to 
> find the test:
>  {{pytest 
> upgrade_tests/upgrade_supercolumns_test.py::TestSCUpgrade::test_upgrade_super_columns_through_limited_versions}}
>  vs
>  {{pytest 
> upgrade_supercolumns_test.py::TestSCUpgrade::test_upgrade_super_columns_through_limited_versions}}
> The underlying issue appears to be the changes in the {{pytest 
> --collect-only}} output, consumed in {{run_dtests.py}}, which now includes a 
>  element that needs to be parsed as well to derive at the path as we 
> did before. We'd have to parse the new output and assemble the correct paths 
> again, so we can use run_dtests.py as we did before with pytest 3.6.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-5780) nodetool status and ring report incorrect/stale information after decommission

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-5780:

Complexity: Low Hanging Fruit

> nodetool status and ring report incorrect/stale information after decommission
> --
>
> Key: CASSANDRA-5780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5780
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: Peter Haggerty
>Assignee: John Sumsion
>Priority: Low
>  Labels: lhf, ponies, qa-resolved
> Fix For: 2.1.x
>
>
> Cassandra 1.2.6 ring of 12 instances, each with 256 tokens.
> Decommission 3 of the 12 nodes, one after another resulting a 9 instance ring.
> The 9 instances of cassandra that are in the ring all correctly report 
> nodetool status information for the ring and have the same data.
> After the first node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> After the second node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> "nodetool status" on "decommissioned-2nd" reports 10 nodes
> After the second node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> "nodetool status" on "decommissioned-2nd" reports 10 nodes
> "nodetool status" on "decommissioned-3rd" reports 9 nodes
> The storage load information is similarly stale on the various decommissioned 
> nodes. The nodetool status and ring commands continue to return information 
> as if they were part of a cluster and they appear to return the last 
> information that they saw.
> In contrast the nodetool info command fails with an exception, which isn't 
> ideal but at least indicates that there was a failure rather than returning 
> stale information.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-8817) Error handling in Cassandra logs in low memory scenarios could use improvement

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-8817:

Complexity: Low Hanging Fruit

> Error handling in Cassandra logs in low memory scenarios could use improvement
> --
>
> Key: CASSANDRA-8817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8817
> Project: Cassandra
>  Issue Type: Improvement
> Environment: Ubuntu 14.04, VM originally created with 1 GB RAM, DSE 
> 4.6.0 installed
>Reporter: Michael DeHaan
>Priority: Low
>  Labels: lhf
> Fix For: 2.1.x
>
>
> When running Cassandra with a low amount of RAM, in this case, using DataStax 
> Enterprise 4.6.0 in a reasonably default configuration, I find that I get an 
> error after starting and trying to use nodetool, namely that it cannot 
> connect to 127.0.0.1.   Originally this sends me up a creek, looking for why 
> Cassandra is not listening on 7199.  The truth ends up being a bit more 
> cryptic - that Cassandra isn't running.
> Upon looking at the Cassandra system logs, I see the last thing that it did 
> was print out the (very long) class path.   This confused me as basically I'm 
> seeing no errors in the log at all.
> I am proposing that Cassandra should check the amount of available RAM and 
> issue a warning in the log, or possibly an error, because in this scenario 
> Cassandra is going to oomkill and probably could have predicted this in 
> advance.
> Something like:
> "Found X MB of RAM, expecting at least Y MB of RAM, Z MB recommended, may 
> crash, adjust " or something similar would be a possible solution.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-8937) add liveSSTableCount metrics at keyspace level

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-8937:

Complexity: Low Hanging Fruit

> add liveSSTableCount metrics at keyspace level
> --
>
> Key: CASSANDRA-8937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8937
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: yangwei
>Assignee: yangwei
>Priority: Low
>  Labels: lhf
> Fix For: 2.1.x
>
> Attachments: 
> 0001-add-liveSSTableCount-metrics-at-keyspace-level-2.1.patch, 
> 0001-add-liveSSTableCount-metrics-at-keyspace-level.patch
>
>
> We currently don't have liveSSTableCount metrics aggregated at keyspace 
> level.  If many sstables exists and we can't realize it earlier,  cassandra 
> will oom while doing scanning operations. It would be nice and easy to 
> aggregate it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11888) cassandra-env.sh may not work properly with jvm args containing a space

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11888:
-
Complexity: Low Hanging Fruit

> cassandra-env.sh may not work properly with jvm args containing a space
> ---
>
> Key: CASSANDRA-11888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
> Environment: linux
>Reporter: Russ Hatch
>Priority: Low
>  Labels: lhf
>
> When using the JVM_EXTRA_OPTS environment variable, it looks like there's 
> some cases that may not work if an env var contains a space.
> For example, setting:
> {noformat}
> export JVM_EXTRA_OPTS='-XX:OnOutOfMemoryError="echo oh_no"'
> {noformat}
> Results in the jvm not starting because the resultant startup command looks 
> to java like it should load a class called oh_no.
> {noformat}
> Error: Could not find or load main class oh_no
> {noformat}
> I think this results from the last line of cassandra-env.sh, where it does 
> this:
> {noformat}
> JVM_OPTS="$JVM_OPTS $JVM_EXTRA_OPTS"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12485) Always require replace_address to replace existing token

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12485:
-
Complexity: Low Hanging Fruit

> Always require replace_address to replace existing token
> 
>
> Key: CASSANDRA-12485
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12485
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Distributed Metadata
>Reporter: Paulo Motta
>Priority: Low
>  Labels: lhf
>
> CASSANDRA-10134 prevented replace an existing node unless 
> {{\-Dcassandra.replace_address}} or 
> {{\-Dcassandra.allow_unsafe_replace=true}} is specified.
> We should extend this behavior to tokens, preventing a node from joining the 
> ring if another node with the same token already existing in the ring, unless 
> {{\-Dcassandra.replace_address}} or 
> {{\-Dcassandra.allow_unsafe_replace=true}} is specified in order to avoid 
> catastrophic scenarios.
> One scenario where this can easily happen is if you replace a node with 
> another node with a different IP, and after some time you restart the 
> original node by mistake. The original node will then take over the tokens of 
> the replaced node (since it has a newer gossip generation).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13979) update contributing guidelines

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13979:
-
Complexity: Low Hanging Fruit

> update contributing guidelines
> --
>
> Key: CASSANDRA-13979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13979
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Normal
>  Labels: lhf
>
> Current contributing guidelines point to the more or less dead wiki, we 
> should point to the website docs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13960) update cassandra.yaml links to point to new docs instead of the wiki

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13960:
-
Complexity: Low Hanging Fruit

> update cassandra.yaml links to point to new docs instead of the wiki
> 
>
> Key: CASSANDRA-13960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13960
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Gabriel Nobrega
>Priority: Low
>  Labels: lhf
>
> The wiki is dead, let's clean up the links and be sure we have the right into 
> on cassandra.apache.org.
> {code}
> # NOTE:
> #   See http://wiki.apache.org/cassandra/StorageConfiguration for
> #   full explanations of configuration directives
> # /NOTE
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-4967) config options have different bounds when set via different methods

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-4967:

Complexity: Low Hanging Fruit

> config options have different bounds when set via different methods
> ---
>
> Key: CASSANDRA-4967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4967
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Affects Versions: 1.2.0 beta 2
>Reporter: Robert Coli
>Priority: Low
>  Labels: lhf
>
> (similar to some of the work done in 
> https://issues.apache.org/jira/browse/CASSANDRA-4479
> )
> If one sets a value in cassandra.yaml, that value might be subject to bounds 
> checking there. However if one sets that same value via JMX, it doesn't get 
> set via a bounds-checking code path.
> "./src/java/org/apache/cassandra/config/DatabaseDescriptor.java" (JMX set)
> {noformat}
> public static void setPhiConvictThreshold(double phiConvictThreshold)
> {
> conf.phi_convict_threshold = phiConvictThreshold;
> }
> {noformat}
> Versus..
> ./src/java/org/apache/cassandra/config/DatabaseDescriptor.java 
> (cassandra.yaml)
> {noformat}
> static void loadYaml()
> ...
>   /* phi convict threshold for FailureDetector */
> if (conf.phi_convict_threshold < 5 || conf.phi_convict_threshold 
> > 16)
> {
> throw new ConfigurationException("phi_convict_threshold must 
> be between 5 and 16");
> }
> {noformat}
> This seems to create a confusing situation where the range of potential 
> values for a given configuration option is different when set by different 
> methods. 
> It's difficult to imagine a circumstance where you want bounds checking to 
> keep your node from starting if you set that value in cassandra.yaml, but 
> also want to allow circumvention of that bounds checking if you set via JMX.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11409) set read repair chance to 0 but find read repair process in trace

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11409:
-
Complexity: Low Hanging Fruit

> set read repair chance to 0 but find read repair process in trace
> -
>
> Key: CASSANDRA-11409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11409
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/CQL, Legacy/Distributed Metadata
> Environment: Cassandra 2.1.13 with centos 7
>Reporter: Ryan Cho
>Priority: Low
>  Labels: lhf
> Attachments: 螢幕快照 2016-03-23 下午2.06.10.png
>
>
> I have set  dclocal_read_repair_chance and read_repair_chance to 0.0 for one 
> month, but I still find "Read-repair DC_LOCAL" and "Initiating read-repair" 
> activities in system_trace.events, and  query was executed in these two days 
> and long time after set read repair chance to 0.0 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-8880) Add metrics to monitor the amount of tombstones created

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-8880:

Complexity: Low Hanging Fruit

> Add metrics to monitor the amount of tombstones created
> ---
>
> Key: CASSANDRA-8880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8880
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Michaël Figuière
>Priority: Low
>  Labels: lhf, metrics
> Fix For: 2.1.x
>
> Attachments: cassandra-2.1-8880.patch
>
>
> AFAIK there's currently no way to monitor the amount of tombstones created on 
> a Cassandra node. CASSANDRA-6057 has made it possible for users to figure out 
> how many tombstones are scanned at read time, but in write mostly workloads, 
> it may not be possible to realize if some inappropriate queries are 
> generating too many tombstones.
> Therefore the following additional metrics should be added:
> * {{writtenCells}}: amount of cells that have been written
> * {{writtenTombstoneCells}}: amount of tombstone cells that have been written
> Alternatively these could be exposed as a single gauge such as 
> {{writtenTombstoneCellsRatio}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13733) nodetool toptables

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13733:
-
Complexity: Low Hanging Fruit

> nodetool toptables
> --
>
> Key: CASSANDRA-13733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13733
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability, Observability/Metrics
>Reporter: Jon Haddad
>Assignee: Neil Patel
>Priority: Normal
>  Labels: lhf, low-hanging-fruit
>
> In the same way toppartitions samples the activity on a table, toptables 
> should be able to report which tables are used the most.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12489) consecutive repairs of same range always finds 'out of sync' in sane cluster

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12489:
-
Complexity: Low Hanging Fruit

> consecutive repairs of same range always finds 'out of sync' in sane cluster
> 
>
> Key: CASSANDRA-12489
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12489
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Benjamin Roth
>Assignee: Benjamin Roth
>Priority: Normal
>  Labels: lhf
> Attachments: trace_3_10.1.log.gz, trace_3_10.2.log.gz, 
> trace_3_10.3.log.gz, trace_3_10.4.log.gz, trace_3_9.1.log.gz, 
> trace_3_9.2.log.gz
>
>
> No matter how often or when I run the same subrange repair, it ALWAYS tells 
> me that some ranges are our of sync. Tested in 3.9 + 3.10 (git trunk of 
> 2016-08-17). The cluster is sane. All nodes are up, cluster is not overloaded.
> I guess this is not a desired behaviour. I'd expect that a repair does what 
> it says and a consecutive repair shouldn't report "out of syncs" any more if 
> the cluster is sane.
> Especially for tables with MVs that puts a lot of pressure during repair as 
> ranges are repaired over and over again.
> See traces of different runs attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13947) Add some clarifying examples of nodetool usage

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13947:
-
Complexity: Low Hanging Fruit

> Add some clarifying examples of nodetool usage
> --
>
> Key: CASSANDRA-13947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13947
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Jeremy Hanna
>Priority: Normal
>  Labels: lhf
>
> Certain nodetool commands would benefit from some examples of usage.  For 
> example, user defined compactions require a comma separated list of path 
> names from the data directory room to the table name.
> {code}
> nodetool compact --user-defined 
> system_schema/types-5a8b1ca866023f77a0459273d308917a/mc-5-big-Data.db,system_schema/types-5a8b1ca866023f77a0459273d308917a/mc-6-big-Data.db
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13601:
-
Complexity: Low Hanging Fruit

> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Low
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: ppc64le_unaligned_memory_access.patch
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12760) SELECT JSON "firstName" FROM ... results in {"\"firstName\"": "Bill"}

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12760:
-
Complexity: Low Hanging Fruit

> SELECT JSON "firstName" FROM ... results in {"\"firstName\"": "Bill"}
> -
>
> Key: CASSANDRA-12760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12760
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
> Environment: Cassandra 3.7
>Reporter: Niek Bartholomeus
>Assignee: Shivang Nagaria
>Priority: Normal
>  Labels: lhf
>
> I'm using Cassandra to store data coming from Spark and intended for being 
> consumed by a javascript front end.
> To avoid unnecessary field name mappings I have decided to use mixed case 
> fields in Cassandra. I also happily leave it to Cassandra to jsonify the data 
> (using SELECT JSON ...) so my scala/play web server can send the results from 
> Cassandra straight through to the front end.
> I noticed however that all mixed case fields (that were created with quotes 
> as Cassandra demands) end up having a double set of quotes
> {code}
> create table user(id text PRIMARY KEY, "firstName" text);
> insert into user(id, "firstName") values ('b', 'Bill');
> select json * from user;
>  [json]
> --
>  {"id": "b", "\"firstName\"": "Bill"}
> {code}
> Ideally that would be:
> {code}
>  [json]
> --
>  {"id": "b", "firstName": "Bill"}
> {code}
> I worked around it for now by removing all "\""'s before sending the json to 
> the front end.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13816) Document and test CAS and non-CAS batch behavior for deleting and inserting the same key

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13816:
-
Complexity: Low Hanging Fruit

> Document and test CAS and non-CAS batch behavior for deleting and inserting 
> the same key
> 
>
> Key: CASSANDRA-13816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13816
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Documentation and Website, Legacy/Testing
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Low
>  Labels: LWT, lhf
> Fix For: 3.11.x, 4.x
>
>
> Add/verify unit tests for inserting and deleting the same key for cell 
> deletion, partition deletion, and range tombstone deletion for both CAS and 
> non-CAS batches.
> Don't change the existing behavior.
> The behavior differs between batch and CAS so in the both the CAS and batch 
> documentation mention that the behavior is not consistent. Make sure it is 
> visible in both high level and reference docs for that functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11402:
-
Complexity: Low Hanging Fruit

> Alignment wrong in tpstats output for PerDiskMemtableFlushWriter
> 
>
> Key: CASSANDRA-11402
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11402
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Nishant Kelkar
>Priority: Low
>  Labels: lhf
> Fix For: 3.11.x
>
> Attachments: 11402-3_5_patch1.patch, 11402-trunk.txt
>
>
> With the accompanying designation of which memtableflushwriter it is, this 
> threadpool name is too long for the hardcoded padding in tpstats output.
> We should dynamically calculate padding so that we don't need to check this 
> every time we add a threadpool.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-10031) Name threads for improved ops/debugging

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-10031:
-
Complexity: Low Hanging Fruit

> Name threads for improved ops/debugging
> ---
>
> Key: CASSANDRA-10031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10031
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability
>Reporter: T Jake Luciani
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> We currently provide basic names for threads in threads like {{STREAM-IN-1}}  
> which gives some basic information about what the job of the thread is.  
> When looking at a log statement or jstack it's helpful to have this context.
> For our work stealing thread pool we share threads across all thread pools so 
> we lose this insight.  
> I'd like to propose we start using the Thread.currentThread().setName("")
> In different aspects of the code to improve insight as to what cassandra is 
> doing at any given moment.
>* At a minimum in the start of each run() method.
>   Ideally for much finer grain things.
>* In compaction include the partition name currently being working on.  
>* In SP include the client ip
> Etc...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-7276) Include keyspace and table names in logs where possible

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-7276:

Complexity: Low Hanging Fruit

> Include keyspace and table names in logs where possible
> ---
>
> Key: CASSANDRA-7276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7276
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tyler Hobbs
>Priority: Low
>  Labels: bootcamp, lhf
> Fix For: 2.1.x
>
> Attachments: 0001-Better-Logging-for-KS-and-CF.patch, 
> 0001-Consistent-KS-and-Table-Logging.patch, 
> 0001-Logging-KS-and-CF-consistently.patch, 
> 0001-Logging-for-Keyspace-and-Tables.patch, 2.1-CASSANDRA-7276-v1.txt, 
> cassandra-2.1-7276-compaction.txt, cassandra-2.1-7276.txt, 
> cassandra-2.1.9-7276-v2.txt, cassandra-2.1.9-7276.txt
>
>
> Most error messages and stacktraces give you no clue as to what keyspace or 
> table was causing the problem.  For example:
> {noformat}
> ERROR [MutationStage:61648] 2014-05-20 12:05:45,145 CassandraDaemon.java 
> (line 198) Exception in thread Thread[MutationStage:61648,5,main]
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Unknown Source)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:63)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:98)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:35)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap$1.compareTo(SnapTreeMap.java:538)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1108)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap.updateUnderRoot(SnapTreeMap.java:1059)
> at edu.stanford.ppl.concurrent.SnapTreeMap.update(SnapTreeMap.java:1023)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap.putIfAbsent(SnapTreeMap.java:985)
> at 
> org.apache.cassandra.db.AtomicSortedColumns$Holder.addColumn(AtomicSortedColumns.java:328)
> at 
> org.apache.cassandra.db.AtomicSortedColumns.addAllWithSizeDelta(AtomicSortedColumns.java:200)
> at org.apache.cassandra.db.Memtable.resolve(Memtable.java:226)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:173)
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:893)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:333)
> at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:206)
> at 
> org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:56)
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> We should try to include info on the keyspace and column family in the error 
> messages or logs whenever possible.  This includes reads, writes, 
> compactions, flushes, repairs, and probably more.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11516) Make max number of streams configurable

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11516:
-
Complexity: Low Hanging Fruit

> Make max number of streams configurable
> ---
>
> Key: CASSANDRA-11516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11516
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Streaming and Messaging, Local/Config
>Reporter: Sebastian Estevez
>Assignee: Giampaolo
>Priority: Normal
>  Labels: lhf
>
> Today we default to num cores. In large boxes (many cores), this is 
> suboptimal as it can generate huge amounts of garbage that GC can't keep up 
> with.
> Usually we tackle issues like this with the streaming throughput levers but 
> in this case the problem is CPU consumption by StreamReceiverTasks 
> specifically in the IntervalTree build -- 
> https://github.com/apache/cassandra/blob/cassandra-2.1.12/src/java/org/apache/cassandra/utils/IntervalTree.java#L257
> We need a max number of parallel streams lever to hanlde this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-4938:

Complexity: Low Hanging Fruit

> CREATE INDEX can block for creation now that schema changes may be concurrent
> -
>
> Key: CASSANDRA-4938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4938
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> Response from CREATE INDEX command comes faster than the creation of 
> secondary index. So below code:
> {code:xml}
> CREATE INDEX ON tab(name);
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> doesn't return any rows(of course, in column family "tab", there are some 
> records with "name" value = 'Chris'..) and any errors ( i would expect 
> something like ??"Bad Request: No indexed columns present in by-columns 
> clause with Equal operator"??) 
> Inputing some timeout between those two commands resolves the problem, so:
> {code:xml}
> CREATE INDEX ON tab(name);
> Sleep(timeout); // for column family with 2000 rows the timeout had to be set 
> for ~1 second 
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> will return all rows with values as specified.
> I'm using single node cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11978) StreamReader fails to write sstable if CF directory is symlink

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11978:
-
Complexity: Low Hanging Fruit

> StreamReader fails to write sstable if CF directory is symlink
> --
>
> Key: CASSANDRA-11978
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11978
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Michael Frisch
>Assignee: Kirk True
>Priority: Normal
>  Labels: lhf
>
> I'm using Cassandra v2.2.6.  If the CF is stored as a symlink in the keyspace 
> directory on disk then StreamReader.createWriter fails because 
> Descriptor.fromFilename is passed the actual path on disk instead of path 
> with the symlink.
> Example:
> /path/to/data/dir/Keyspace/CFName -> /path/to/data/dir/AnotherDisk/CFName
> Descriptor.fromFilename is passed "/path/to/data/dir/AnotherDisk/CFName" 
> instead of "/path/to/data/dir/Keyspace/CFName", then it concludes that the 
> keyspace name is "AnotherDisk" which is erroneous. I've temporarily worked 
> around this by using cfs.keyspace.getName() to get the keyspace name and 
> cfs.name to get the CF name as those are correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13890) Expose current compaction throughput

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13890:
-
Complexity: Low Hanging Fruit

> Expose current compaction throughput
> 
>
> Key: CASSANDRA-13890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13890
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> Getting and setting the current compaction throughput limit is supported, but 
> there's no means of knowing if the setting is actually making a difference.
> Let's expose the current throughput being utilized by Cassandra that's in the 
> {{compactionRateLimiter}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-5108) expose overall progress of cleanup tasks in jmx

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-5108:

Complexity: Low Hanging Fruit

> expose overall progress of cleanup tasks in jmx
> ---
>
> Key: CASSANDRA-5108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5108
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Observability, Local/Compaction
>Affects Versions: 1.2.0
>Reporter: Michael Kjellman
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> it would be nice if, upon starting a cleanup operation, cassandra could 
> maintain a Set (i assume this already exists as we have to know which file to 
> act on next) and a new set of "completed" sstables. When each is compacted 
> remove it from the pending list. That way C* could give an overall completion 
> of the long running and pending cleanup tasks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-5992) Add a logger.trace call to Tracing

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-5992:

Complexity: Low Hanging Fruit

> Add a logger.trace call to Tracing
> --
>
> Key: CASSANDRA-5992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5992
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability
>Reporter: Jeremiah Jordan
>Assignee: Ryan Magnusson
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: CASSANDRA-5992.txt
>
>
> A bunch of stuff is now written to Tracing, and there are no logging trace 
> calls any more.  If a node is having issues on the read/write path and 
> tracing can't actually save data, there is no way to see through logging what 
> is going on.  Would be nice if we made all Tracing messages also go out at 
> logger.trace so that you could enable that to debug stuff.
> Being able to change the RF of the system_traces KS might also help here, but 
> there would still be classes of problems that it would be good to have the 
> logging there for. Added CASSANDRA-6016 for that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13745) Compaction History would be beneficial to include completion timestamp

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13745:
-
Complexity: Low Hanging Fruit

> Compaction History would be beneficial to include completion timestamp 
> ---
>
> Key: CASSANDRA-13745
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13745
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core, Local/Compaction
>Reporter: Richard Andersen
>Assignee: Ihar Kukharchuk
>Priority: Low
>  Labels: lhf
> Attachments: 13745-trunk.txt
>
>
> Compaction history does not currently contain the completion time stamp which 
> can be beneficial in determining performance and event tracing. I would like 
> to use this information also in our Health Check process to trace event 
> timelines. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-8094) Heavy writes in RangeSlice read requests

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-8094:

Complexity: Low Hanging Fruit

> Heavy writes in RangeSlice read  requests 
> --
>
> Key: CASSANDRA-8094
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8094
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Coordination
>Reporter: Minh Do
>Priority: Normal
>  Labels: lhf
> Fix For: 4.x
>
>
> RangeSlice requests always do a scheduled read repair when coordinators try 
> to resolve replicas' responses no matter read_repair_chance is set or not.
> Because of this, in low writes and high reads clusters, there are very high 
> write requests going on between nodes.  
> We should have an option to turn this off and this can be different than the 
> read_repair_chance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12166) Sequential repairs on LCS lead to many warnings

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12166:
-
Complexity: Low Hanging Fruit

> Sequential repairs on LCS lead to many warnings
> ---
>
> Key: CASSANDRA-12166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12166
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair, Local/Compaction
>Reporter: Stefano Ortolani
>Assignee: Paulo Motta
>Priority: Low
>  Labels: lcs, lhf
>
> I have been testing sequential repairs on 3.0.8 and now the logs are filled 
> with the following warnings. Note that they do make sense since snapshotting 
> is part of the repair process if sequential, but I was wondering if this 
> level of verbosity was intended.
> {noformat}
> WARN  [ValidationExecutor:3] 2016-07-11 13:35:52,930 
> LeveledCompactionStrategy.java:231 - Live sstable 
> /data/cassandra/data/schema/cf-e06f37a010bc11e6bb236776bf484396/snapshots/acc9a360-476a-11e6-87e0-dbcbe81a0cea/mb-840-big-Data.db
>  
> from level 0 is not on corresponding level in the leveled manifest. 
> This is not a problem per se, but may indicate an orphaned sstable due to a 
> failed compaction not cleaned up properly.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13823) The Getting Started page should have instructions on setting up a cluster

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13823:
-
Complexity: Low Hanging Fruit

> The Getting Started page should have instructions on setting up a cluster
> -
>
> Key: CASSANDRA-13823
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13823
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Sumanth Pasupuleti
>Priority: Low
>  Labels: lhf
>
> Currently the docs don't have an easy to follow guide on setting up a 
> cluster.  I think it would benefit from a nice easy to follow walkthrough.
> https://cassandra.apache.org/doc/latest/getting_started/index.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-11419) On local cassandra installations, rack-dc from ROOT/conf isn't honored.

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-11419:
-
Complexity: Low Hanging Fruit

> On local cassandra installations, rack-dc from ROOT/conf isn't honored.
> ---
>
> Key: CASSANDRA-11419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11419
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Anubhav Kale
>Priority: Low
>  Labels: lhf
>
> 1. Get the latest sources from trunk, build in eclipse. I am doing this on 
> Windows BTW.
> 2. Run from Eclipse
> 3. Bug: The change in conf/cassandra-rackdc.properties isn't honored. 
> Instead, the one in test/conf/cassandra-rackdc.properties is honored.
> Since yaml changes from conf/ are used, why don't we stay consistent for 
> other files as well ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13260) Add UDT support to Cassandra stress

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13260:
-
Complexity: Low Hanging Fruit

> Add UDT support to Cassandra stress
> ---
>
> Key: CASSANDRA-13260
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13260
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Jeremy Hanna
>Assignee: Kevin Wern
>Priority: Normal
>  Labels: lhf, stress
>
> Splitting out UDT support in cassandra stress from CASSANDRA-9556.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-8612) Read metrics should be updated on all types of reads

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-8612:

Complexity: Low Hanging Fruit

> Read metrics should be updated on all types of reads
> 
>
> Key: CASSANDRA-8612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8612
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Metrics
>Reporter: Chris Lohfink
>Priority: Low
>  Labels: lhf, metrics
>
> Metrics like "sstables per read" are not updated on a range slice.  Although 
> separating things out for each type of read could make sense like we do for 
> latencies, only exposing the metrics for one type can be a little confusing 
> when people do a query and see nothing increases.  I think its sufficient to 
> use the same metrics for all reads.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch trunk updated: ninja: Fix slack channel names in docs

[mshuler]

This is an automated email from the ASF dual-hosted git repository.

mshuler pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new c241029  ninja: Fix slack channel names in docs
c241029 is described below

commit c24102906d41eb2f06b737c3c3d89be9a151e9f7
Author: Michael Shuler 
AuthorDate: Thu Jun 13 11:47:22 2019 -0500

ninja: Fix slack channel names in docs
---
 doc/source/bugs.rst|  2 +-
 doc/source/contactus.rst   | 10 ++
 doc/source/development/release_process.rst |  2 +-
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/doc/source/bugs.rst b/doc/source/bugs.rst
index 196ea3a..32d676f 100644
--- a/doc/source/bugs.rst
+++ b/doc/source/bugs.rst
@@ -18,7 +18,7 @@ Reporting Bugs
 ==
 
 If you encounter a problem with Cassandra, the first places to ask for help 
are the :ref:`user mailing list
-` and the ``Cassandra`` :ref:`Slack room `.
+` and the ``cassandra`` :ref:`Slack room `.
 
 If, after having asked for help, you suspect that you have found a bug in 
Cassandra, you should report it by opening a
 ticket through the `Apache Cassandra JIRA 
`__. Please provide as much
diff --git a/doc/source/contactus.rst b/doc/source/contactus.rst
index 308d872..3ed9004 100644
--- a/doc/source/contactus.rst
+++ b/doc/source/contactus.rst
@@ -17,7 +17,7 @@
 Contact us
 ==
 
-You can get in touch with the Cassandra community either via the mailing lists 
or slack_ rooms.
+You can get in touch with the Cassandra community either via the mailing lists 
or :ref:`Slack rooms `.
 
 .. _mailing-lists:
 
@@ -40,9 +40,11 @@ email to confirm your subscription. Make sure to keep the 
welcome email as it co
 unsubscribe.
 
 .. _slack:
+
 Slack
-_
+-
 To chat with developers or users in real-time, join our rooms on `ASF Slack 
`__:
-- ``#cassandra`` - for user questions and general discussions.
-- ``#cassandra-dev`` - strictly for questions or discussions related to 
Cassandra development.
+
+- ``cassandra`` - for user questions and general discussions.
+- ``cassandra-dev`` - strictly for questions or discussions related to 
Cassandra development.
 
diff --git a/doc/source/development/release_process.rst 
b/doc/source/development/release_process.rst
index 464ecd6..b3c4032 100644
--- a/doc/source/development/release_process.rst
+++ b/doc/source/development/release_process.rst
@@ -244,7 +244,7 @@ Fill out the following email template and send to both user 
and dev mailing list
 Update Slack Cassandra topic
 ---
 
-Update Cassandra topic in Slack::
+Update topic in ``cassandra`` :ref:`Slack room `
 /topic cassandra.apache.org | Latest releases: 3.11.4, 3.0.18, 2.2.14, 
2.1.21 | ask, don't ask to ask
 
 Tweet from @Cassandra


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-15158) Wait for schema agreement rather then in flight schema requests when bootstrapping

[Vincent White (JIRA)]

Vincent White created CASSANDRA-15158:
-

 Summary: Wait for schema agreement rather then in flight schema 
requests when bootstrapping
 Key: CASSANDRA-15158
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15158
 Project: Cassandra
  Issue Type: Bug
  Components: Cluster/Gossip
Reporter: Vincent White


Currently when a node is bootstrapping we use a set of latches 
(org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of 
in-flight schema pull requests, and we don't proceed with bootstrapping/stream 
until all the latches are released (or we timeout waiting for each one). One 
issue with this is that if we have a large schema, or the retrieval of the 
schema from the other nodes was unexpectedly slow then we have no explicit 
check in place to ensure we have actually received a schema before we proceed.

While it's possible to increase "migration_task_wait_in_seconds" to force the 
node to wait on each latches longer, there are cases where this doesn't help 
because the callbacks for the schema pull requests have expired off the 
messaging service's callback map 
(org.apache.cassandra.net.MessagingService#callbacks) after getMinRpcTimeout() 
(2 seconds by default) before the other nodes were able to respond to the new 
node.

This patch checks for schema agreement between the bootstrapping node and the 
rest of the live nodes before proceeding with bootstrapping. It also adds a 
check to prevent the new node from flooding existing nodes with simultaneous 
schema pull requests as can happen in large clusters.

|||3.11||
|[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]|





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14978) Cassandra going down with "java.lang.OutOfMemoryError: Map failed" and "LEAK DETECTED"

[Roy Burstein (JIRA)]

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

Roy Burstein commented on CASSANDRA-14978:
--

[~jolynch]  -

Issue reproduced on C* version 3.11.4 and 3.11.3,We are using Zing as our JVM.
Issue was reproduced on Oracle JVM as well,we have large dataset per machine(5T 
data).

It seems that Cassandra process used very high virtual memory and did not 
release it back to the OS (despite we had full GC),once the process reached to 
120TB of virtual memory the OS failed to map files.

Solution was to cancel the mmap feature : disk_access_mode=standard .  
We did not run any repair .   

> Cassandra going down with "java.lang.OutOfMemoryError: Map failed" and "LEAK 
> DETECTED"
> --
>
> Key: CASSANDRA-14978
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14978
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Yakir Gibraltar
>Priority: Normal
>
> Cassandra version: 3.11.4
>  OS: CentOS Linux release 7.4.1708 (Core)
>  Kernel: 3.10.0-957.10.1.el7.x86_64
>  JDK: jdk1.8.0_131
> Heap: same errors with 16GB / 32GB / 64GB.
>  *We are seeing this errors in production:*
> *java.io.IOException: Map failed:*
> {code:java}
> ERROR [CompactionExecutor:5017] 2019-01-14 00:02:04,763 
> CassandraDaemon.java:228 - Exception in thread 
> Thread[CompactionExecutor:5017,1,main]
> org.apache.cassandra.io.FSReadError: java.io.IOException: Map failed
> at 
> org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:157) 
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:310)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:246)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:181)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:73) 
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:61) 
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:104) 
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:362) 
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:290)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:179)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:134)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:65)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:142)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:201)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:274)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_131]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_131]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_131]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.3.jar:3.11.3]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_131]
> Caused by: java.io.IOException: Map failed
> at 

[jira] [Updated] (CASSANDRA-14978) Cassandra going down with "java.lang.OutOfMemoryError: Map failed" and "LEAK DETECTED"

[Yakir Gibraltar (JIRA)]

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

Yakir Gibraltar updated CASSANDRA-14978:

Description: 
Cassandra version: 3.11.4
 OS: CentOS Linux release 7.4.1708 (Core)
 Kernel: 3.10.0-957.10.1.el7.x86_64
 JDK: jdk1.8.0_131
Heap: same errors with 16GB / 32GB / 64GB.


 *We are seeing this errors in production:*

*java.io.IOException: Map failed:*
{code:java}
ERROR [CompactionExecutor:5017] 2019-01-14 00:02:04,763 
CassandraDaemon.java:228 - Exception in thread 
Thread[CompactionExecutor:5017,1,main]
org.apache.cassandra.io.FSReadError: java.io.IOException: Map failed
at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:157) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:310) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:246)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:181)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:73) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:61) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:104) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:362) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:290)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:179)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:134)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:65)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:142)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:201)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:274)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_131]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_131]
at 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
 [apache-cassandra-3.11.3.jar:3.11.3]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_131]
Caused by: java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:940) 
~[na:1.8.0_131]
at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:153) 
~[apache-cassandra-3.11.3.jar:3.11.3]
... 23 common frames omitted
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method) ~[na:1.8.0_131]
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:937) 
~[na:1.8.0_131]
... 24 common frames omitted
{code}

*LEAK DETECTED error:*
{code:java}
ERROR [Reference-Reaper:1] 2019-01-14 00:03:46,469 Ref.java:224 - LEAK 
DETECTED: a reference 
(org.apache.cassandra.utils.concurrent.Ref$State@6a4ef142) to class 
org.apache.cassandra.io.util.SafeMemory$MemoryTidy@1651696741:Memory@[6b91a27c5290..6b91a27de290)
 was not released before the reference was garbage collected
ERROR [Reference-Reaper:1] 2019-01-14 00:03:46,520 Ref.java:224 - LEAK 
DETECTED: a reference 
(org.apache.cassandra.utils.concurrent.Ref$State@6c458f8a) to class 

[jira] [Updated] (CASSANDRA-14978) Cassandra going down with "java.lang.OutOfMemoryError: Map failed" and "LEAK DETECTED"

[Yakir Gibraltar (JIRA)]

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

Yakir Gibraltar updated CASSANDRA-14978:

Description: 
Cassandra version: 3.11.4
 OS: CentOS Linux release 7.4.1708 (Core)
 Kernel: 3.10.0-957.10.1.el7.x86_64
 JDK: jdk1.8.0_131
Heap: same errors with 16GB / 32GB / 64GB.


 *We are seeing this errors in production:*

*java.io.IOException: Map failed:*
{code:java}
ERROR [CompactionExecutor:5017] 2019-01-14 00:02:04,763 
CassandraDaemon.java:228 - Exception in thread 
Thread[CompactionExecutor:5017,1,main]
org.apache.cassandra.io.FSReadError: java.io.IOException: Map failed
at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:157) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:310) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:246)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:181)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:73) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:61) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:104) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:362) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:290)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:179)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:134)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:65)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:142)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:201)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:274)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_131]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_131]
at 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
 [apache-cassandra-3.11.3.jar:3.11.3]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_131]
Caused by: java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:940) 
~[na:1.8.0_131]
at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:153) 
~[apache-cassandra-3.11.3.jar:3.11.3]
... 23 common frames omitted
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method) ~[na:1.8.0_131]
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:937) 
~[na:1.8.0_131]
... 24 common frames omitted
{code}
*LEAK DETECTED:*
{code:java}
ERROR [Reference-Reaper:1] 2019-01-14 00:03:46,469 Ref.java:224 - LEAK 
DETECTED: a reference 
(org.apache.cassandra.utils.concurrent.Ref$State@6a4ef142) to class 
org.apache.cassandra.io.util.SafeMemory$MemoryTidy@1651696741:Memory@[6b91a27c5290..6b91a27de290)
 was not released before the reference was garbage collected
ERROR [Reference-Reaper:1] 2019-01-14 00:03:46,520 Ref.java:224 - LEAK 
DETECTED: a reference 
(org.apache.cassandra.utils.concurrent.Ref$State@6c458f8a) to class 

[jira] [Updated] (CASSANDRA-14978) Cassandra going down with "java.lang.OutOfMemoryError: Map failed" and "LEAK DETECTED"

[Yakir Gibraltar (JIRA)]

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

Yakir Gibraltar updated CASSANDRA-14978:

Description: 
Cassandra version: 3.11.4
 OS: CentOS Linux release 7.4.1708 (Core)
 Kernel: 3.10.0-957.10.1.el7.x86_64
 JDK: jdk1.8.0_131
Heap: same errors with 16GB / 32GB / 64GB.


 *We are seeing this errors in production:*

*java.io.IOException: Map failed:*
{code:java}
ERROR [CompactionExecutor:5017] 2019-01-14 00:02:04,763 
CassandraDaemon.java:228 - Exception in thread 
Thread[CompactionExecutor:5017,1,main]
org.apache.cassandra.io.FSReadError: java.io.IOException: Map failed
at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:157) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:310) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:246)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:181)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:73) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:61) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:104) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:362) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:290)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:179)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:134)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:65)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:142)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:201)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:274)
 ~[apache-cassandra-3.11.3.jar:3.11.3]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_131]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_131]
at 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
 [apache-cassandra-3.11.3.jar:3.11.3]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_131]
Caused by: java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:940) 
~[na:1.8.0_131]
at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:153) 
~[apache-cassandra-3.11.3.jar:3.11.3]
... 23 common frames omitted
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method) ~[na:1.8.0_131]
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:937) 
~[na:1.8.0_131]
... 24 common frames omitted
{code}
*LEAK DETECTED:*
{code:java}
ERROR [Reference-Reaper:1] 2019-01-14 00:03:46,469 Ref.java:224 - LEAK 
DETECTED: a reference 
(org.apache.cassandra.utils.concurrent.Ref$State@6a4ef142) to class 
org.apache.cassandra.io.util.SafeMemory$MemoryTidy@1651696741:Memory@[6b91a27c5290..6b91a27de290)
 was not released before the reference was garbage collected
ERROR [Reference-Reaper:1] 2019-01-14 00:03:46,520 Ref.java:224 - LEAK 
DETECTED: a reference 
(org.apache.cassandra.utils.concurrent.Ref$State@6c458f8a) to class