[jira] [Commented] (CASSANDRA-14108) Improve commit log chain marker updating

2019-04-01 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14108:
--

[~jasobrown] Sorry for the assignment change; I hit the key combo by mistake 
while viewing this issue.

> Improve commit log chain marker updating
> 
>
> Key: CASSANDRA-14108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14108
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Normal
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> CASSANDRA-13987 addressed the commit log behavior change that was introduced 
> with CASSANDRA-3578. After that patch was committed, [~aweisberg] did his own 
> review and found a bug as well as having some concerns about the 
> configuration. He and I discussed offline, and agreed on some improvements. 
> Instead of requiring users to configure a deep, dark implementation detail 
> like the commit log chained markers (via {{commitlog_marker_period_in_ms}} in 
> the yaml), we decided it is best to eliminate thew configuration and always 
> update the chained markers (when in periodic mode). 
> The bug [~aweisberg] found was when the chained marker update is not a value 
> that evenly divides into the periodic sync mode value, we would not sync in 
> an expected manner. For example if the marker interval is 9 seconds, and the 
> sync interval is 10 seconds, we would update the markers at time9, but we 
> would then sleep for another 9 seconds, and when we wake up at time18, it is 
> then that we flush - 8 seconds later than we should have. 



--
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-14108) Improve commit log chain marker updating

2019-04-01 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas reassigned CASSANDRA-14108:


Assignee: Jason Brown  (was: C. Scott Andreas)

> Improve commit log chain marker updating
> 
>
> Key: CASSANDRA-14108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14108
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Normal
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> CASSANDRA-13987 addressed the commit log behavior change that was introduced 
> with CASSANDRA-3578. After that patch was committed, [~aweisberg] did his own 
> review and found a bug as well as having some concerns about the 
> configuration. He and I discussed offline, and agreed on some improvements. 
> Instead of requiring users to configure a deep, dark implementation detail 
> like the commit log chained markers (via {{commitlog_marker_period_in_ms}} in 
> the yaml), we decided it is best to eliminate thew configuration and always 
> update the chained markers (when in periodic mode). 
> The bug [~aweisberg] found was when the chained marker update is not a value 
> that evenly divides into the periodic sync mode value, we would not sync in 
> an expected manner. For example if the marker interval is 9 seconds, and the 
> sync interval is 10 seconds, we would update the markers at time9, but we 
> would then sleep for another 9 seconds, and when we wake up at time18, it is 
> then that we flush - 8 seconds later than we should have. 



--
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-14108) Improve commit log chain marker updating

2019-04-01 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas reassigned CASSANDRA-14108:


Assignee: C. Scott Andreas  (was: Jason Brown)

> Improve commit log chain marker updating
> 
>
> Key: CASSANDRA-14108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14108
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: C. Scott Andreas
>Priority: Normal
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> CASSANDRA-13987 addressed the commit log behavior change that was introduced 
> with CASSANDRA-3578. After that patch was committed, [~aweisberg] did his own 
> review and found a bug as well as having some concerns about the 
> configuration. He and I discussed offline, and agreed on some improvements. 
> Instead of requiring users to configure a deep, dark implementation detail 
> like the commit log chained markers (via {{commitlog_marker_period_in_ms}} in 
> the yaml), we decided it is best to eliminate thew configuration and always 
> update the chained markers (when in periodic mode). 
> The bug [~aweisberg] found was when the chained marker update is not a value 
> that evenly divides into the periodic sync mode value, we would not sync in 
> an expected manner. For example if the marker interval is 9 seconds, and the 
> sync interval is 10 seconds, we would update the markers at time9, but we 
> would then sleep for another 9 seconds, and when we wake up at time18, it is 
> then that we flush - 8 seconds later than we should have. 



--
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-15072) Incomplete range results during 2.X -> 3.11.4 upgrade

2019-04-01 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15072:
-
Discovered By: User Report
 Bug Category: Parent values: Correctness(12982)Level 1 values: Response 
Corruption / Loss(12987)
 Priority: High  (was: Normal)

> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Muir Manders
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting 
> back incomplete results for range queries. When all nodes were upgraded 
> (before upgrading sstables), we stopped getting incomplete results. I was 
> able to reproduce it and listed steps below. It seems to require the random 
> partitioner and compact storage to reproduce reliably. It also reproduces 
> coming from 2.1.21 and 2.2.14.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy', 
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
>   id text,
>   foo text,
>   bar text,
>   PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> # need to use new cqlsh so we can configure page size
> cqlsh 127.0.0.2 < PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
>  id | bar   | foo
> +---+-
>   2 | there |  hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
>  id | bar   | foo
> +---+-
>   2 | there |  hi
>   1 | there |  hi
> (2 rows)
> {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-15059) Gossiper#markAlive can race with Gossiper#markDead

2019-04-01 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15059:
-
Reviewers: Ariel Weisberg, Jordan West  (was: Ariel Weisberg)

> Gossiper#markAlive can race with Gossiper#markDead
> --
>
> Key: CASSANDRA-15059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15059
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
>
> The Gossiper class is not threadsafe and assumes all state changes happen in 
> a single thread (the gossip stage). Gossiper#convict, however, can be called 
> from the GossipTasks thread. This creates a race where calls to 
> Gossiper#markAlive and Gossiper#markDead can interleave, corrupting gossip 
> state. Gossiper#assassinateEndpoint has a similar problem, being called from 
> the mbean server thread.



--
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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: apachecon-cfp.png

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: apachecon-cfp.diff

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: apachecon-cfp.diff

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: (was: apachecon-cfp.png)

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: (was: apachecon-cfp.diff)

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: (was: apachecon-cfp.png)

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: (was: apachecon-cfp.diff)

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: apachecon-cfp.png

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png, apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: (was: apachecon-cfp.png)

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: apachecon-cfp.png

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: apachecon-cfp.diff

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: (was: apachecon-cfp.diff)

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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] [Assigned] (CASSANDRA-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas reassigned CASSANDRA-15051:


Assignee: Nate McCall

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: Nate McCall
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website (as part of this commit), though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: apachecon-2019.jpeg

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website (as part of this commit), though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Reviewers: Nate McCall

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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] [Assigned] (CASSANDRA-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas reassigned CASSANDRA-15051:


Assignee: C. Scott Andreas  (was: Nate McCall)

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Description: 
This patch for the Apache Cassandra SVN repo adds a page to 
cassandra.apache.org for Cassandra's presence at ApacheCon 2019.

It also contains a one-line fix for building the site via the non-Dockerized 
flow (excluding vendor/ from Jekyll's search path for compilation).

When published, the URI for this page will be: 
/events/2019-apache-cassandra-summit. This address won't be linked publicly 
from the website as part of this commit, though we can follow with a short blog 
post announcing + linking to it.

A visual rendering of the page is also attached.

  was:
This patch for the Apache Cassandra SVN repo adds a page to 
cassandra.apache.org for Cassandra's presence at ApacheCon 2019.

It also contains a one-line fix for building the site via the non-Dockerized 
flow (excluding vendor/ from Jekyll's search path for compilation).

When published, the URI for this page will be: 
/events/2019-apache-cassandra-summit. This address won't be linked publicly 
from the website (as part of this commit), though we can follow with a short 
blog post announcing + linking to it.

A visual rendering of the page is also attached.


> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Assignee: Nate McCall
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website as part of this commit, though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: apachecon-cfp.png

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website (as part of this commit), though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15051:
-
Attachment: apachecon-cfp.diff

> Website: Add Page Announcing ApacheCon 2019 Event + CFP
> ---
>
> Key: CASSANDRA-15051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: C. Scott Andreas
>Priority: Normal
> Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, 
> apachecon-cfp.png
>
>
> This patch for the Apache Cassandra SVN repo adds a page to 
> cassandra.apache.org for Cassandra's presence at ApacheCon 2019.
> It also contains a one-line fix for building the site via the non-Dockerized 
> flow (excluding vendor/ from Jekyll's search path for compilation).
> When published, the URI for this page will be: 
> /events/2019-apache-cassandra-summit. This address won't be linked publicly 
> from the website (as part of this commit), though we can follow with a short 
> blog post announcing + linking to it.
> A visual rendering of the page is also 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] [Created] (CASSANDRA-15051) Website: Add Page Announcing ApacheCon 2019 Event + CFP

2019-03-12 Thread C. Scott Andreas (JIRA)
C. Scott Andreas created CASSANDRA-15051:


 Summary: Website: Add Page Announcing ApacheCon 2019 Event + CFP
 Key: CASSANDRA-15051
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15051
 Project: Cassandra
  Issue Type: Task
  Components: Documentation/Website
Reporter: C. Scott Andreas
 Attachments: apachecon-2019.jpeg, apachecon-cfp.diff, apachecon-cfp.png

This patch for the Apache Cassandra SVN repo adds a page to 
cassandra.apache.org for Cassandra's presence at ApacheCon 2019.

It also contains a one-line fix for building the site via the non-Dockerized 
flow (excluding vendor/ from Jekyll's search path for compilation).

When published, the URI for this page will be: 
/events/2019-apache-cassandra-summit. This address won't be linked publicly 
from the website (as part of this commit), though we can follow with a short 
blog post announcing + linking to it.

A visual rendering of the page is also 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] [Commented] (CASSANDRA-15020) Invalid CQL in documentation

2019-03-05 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-15020:
--

Thanks, [~vinaykumarcse]!

> Invalid CQL in documentation
> 
>
> Key: CASSANDRA-15020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15020
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Liudmila Kornilova
>Assignee: C. Scott Andreas
>Priority: Trivial
> Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0
>
> Attachments: CASSANDRA-15020-3.0.patch, 
> CASSANDRA-15020-trunk-3.11.patch
>
>
>  [http://cassandra.apache.org/doc/4.0/cql/security.html]
> 1.
> Wrong:
> CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER;
>  CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true 
> AND SUPERUSER = true;
> Correct:
> CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
> CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = 
> true AND SUPERUSER = true; 
>  
> 2. 
>  Wrong:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> Correct:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
>  



--
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-15033) Refactor to singleQuote reuse java.util.regex.Pattern instead of String.replaceAll for TableCQLHelper.java

2019-02-23 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15033:
-
Component/s: CQL/Interpreter

> Refactor to singleQuote reuse java.util.regex.Pattern instead of 
> String.replaceAll for TableCQLHelper.java
> --
>
> Key: CASSANDRA-15033
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15033
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Interpreter
>Reporter: DaeMyung Kang
>Assignee: DaeMyung Kang
>Priority: Trivial
> Attachments: patch-15033.patch
>
>
> singleQuote uses `String.replaceAll ()` a lot in loop.
> and 'String.replaceAll()' compiles the regular expression each time it is 
> called.
>  
> {code:java}
> public String replaceAll(String regex, String replacement) {
>     return Pattern.compile(regex).matcher(this).replaceAll(replacement);
>  }{code}
>  
> It is suggested in javadoc 
> (https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#matches(java.lang.String,%20java.lang.CharSequence))
>  that it is efficient to reuse the pattern.



--
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-15033) Refactor to singleQuote reuse java.util.regex.Pattern instead of String.replaceAll for TableCQLHelper.java

2019-02-23 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas reassigned CASSANDRA-15033:


Assignee: DaeMyung Kang

> Refactor to singleQuote reuse java.util.regex.Pattern instead of 
> String.replaceAll for TableCQLHelper.java
> --
>
> Key: CASSANDRA-15033
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15033
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: DaeMyung Kang
>Assignee: DaeMyung Kang
>Priority: Trivial
> Attachments: patch-15033.patch
>
>
> singleQuote uses `String.replaceAll ()` a lot in loop.
> and 'String.replaceAll()' compiles the regular expression each time it is 
> called.
>  
> {code:java}
> public String replaceAll(String regex, String replacement) {
>     return Pattern.compile(regex).matcher(this).replaceAll(replacement);
>  }{code}
>  
> It is suggested in javadoc 
> (https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#matches(java.lang.String,%20java.lang.CharSequence))
>  that it is efficient to reuse the pattern.



--
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-15020) Invalid CQL in documentation

2019-02-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15020:
-
Reviewer: Nate McCall

> Invalid CQL in documentation
> 
>
> Key: CASSANDRA-15020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15020
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Liudmila Kornilova
>Assignee: C. Scott Andreas
>Priority: Trivial
> Attachments: CASSANDRA-15020-3.0.patch, 
> CASSANDRA-15020-trunk-3.11.patch
>
>
>  [http://cassandra.apache.org/doc/4.0/cql/security.html]
> 1.
> Wrong:
> CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER;
>  CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true 
> AND SUPERUSER = true;
> Correct:
> CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
> CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = 
> true AND SUPERUSER = true; 
>  
> 2. 
>  Wrong:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> Correct:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
>  



--
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-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes

2019-02-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14848:
-
Status: In Progress  (was: Ready to Commit)

> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non 
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
>  Labels: security
> Fix For: 4.0
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0 
> node only connects to 3.11.3 seed node, there are no connection established 
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3 
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this 
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> {noformat}
>  
> I have built 4.0 with wire tracing activated and in my config the 
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the 
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but 
> quickly switch to the ssl_storage_port, but when connecting to the non-seed 
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT: 
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT: 
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT: 
> /10.216.193.243:12700{noformat}
>  
> When I had the dbug log activated and started the 4.0 node I can see that it 
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep 
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG 
> o.a.c.n.a.OutboundMessagingConnection:314 maybeUpdateConnectionId changing 
> connectionId to 10.216.193.246:12701 (GOSSIP), with a different port for 
> secure communication, because peer version is 11
> 2018-10-25T13:12:58.100+0200 

[jira] [Comment Edited] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes

2019-02-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas edited comment on CASSANDRA-14848 at 2/20/19 4:14 PM:
---

It looks like an anonymous user modified the state of this ticket to "Ready to 
Commit" yesterday. Moving back to "In Progress" because I don't see a reviewer 
assigned.


was (Author: cscotta):
It looks like an anonymous user modified the state of this ticket to "Ready to 
Commit" yesterday. Moving back to "Patch Available" because I don't see a 
reviewer assigned.

> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non 
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
>  Labels: security
> Fix For: 4.0
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0 
> node only connects to 3.11.3 seed node, there are no connection established 
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3 
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this 
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> {noformat}
>  
> I have built 4.0 with wire tracing activated and in my config the 
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the 
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but 
> quickly switch to the ssl_storage_port, but when connecting to the non-seed 
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT: 
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT: 
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT: 
> /10.216.193.243:12700{noformat}
>  
> When I had the dbug log activated and started the 4.0 node I can see that it 
> switch port for *.246 but not for *.243 and *.244.

[jira] [Commented] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes

2019-02-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14848:
--

It looks like an anonymous user modified the state of this ticket to "Ready to 
Commit" yesterday. Moving back to "Patch Available" because I don't see a 
reviewer assigned.

> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non 
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
>  Labels: security
> Fix For: 4.0
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0 
> node only connects to 3.11.3 seed node, there are no connection established 
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3 
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this 
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> {noformat}
>  
> I have built 4.0 with wire tracing activated and in my config the 
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the 
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but 
> quickly switch to the ssl_storage_port, but when connecting to the non-seed 
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT: 
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT: 
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT: 
> /10.216.193.243:12700{noformat}
>  
> When I had the dbug log activated and started the 4.0 node I can see that it 
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep 
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG 
> o.a.c.n.a.OutboundMessagingConnection:314 maybeUpdateConnectionId 

[jira] [Updated] (CASSANDRA-15025) Avoid NPE in RepairRunnable.recordFailure

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15025:
-
Component/s: Consistency/Repair

> Avoid NPE in RepairRunnable.recordFailure
> -
>
> Key: CASSANDRA-15025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15025
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> failureMessage parameter in {{RepairRunnable.recordFailure}} can be null, 
> avoid this happening and make sure we log the actual exception



--
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] [Comment Edited] (CASSANDRA-13763) Trivial but potential security issue?

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas edited comment on CASSANDRA-13763 at 2/16/19 9:15 PM:
---

Thanks for reaching out, and sorry for the delay in reply to your question.

This code is part of the cassandra-stress tool, a benchmarking harness that is 
typically used for load testing purposes only, and in this case would print 
`null` indicating that no password was supplied by the user at the start of the 
run. I don't think a substantial issue exists here.

Thanks again for the report.


was (Author: cscotta):
Thanks for reaching out, and sorry for the delay in reply to your question.

This code is part of the cassandra-stress tool, a benchmarking harness that is 
typically used for load testing purposes only, and in this case would print the 
password supplied by the user at the beginning of that test to document the 
run. I don't think a substantial issue exists here.

Thanks again for the report.

> Trivial but potential security issue? 
> --
>
> Key: CASSANDRA-13763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13763
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: JC
>Priority: Trivial
>
> Hi
> In a recent github mirror, I've found the following line.
> Path: tools/stress/src/org/apache/cassandra/stress/settings/SettingsMode.java
> {code:java}
> 177 out.printf("  Password: %s%n", 
> (password==null?password:"*suppressed*"));
> {code}
> As the original password is intended to be masked as "*suppressed   *", I was 
> wondering if showing "null" when the password is null is safe. This might not 
> be an issue but I wanted to report just in case. 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-13766) Invalid page state caused by IllegalArgumentException from ByteBuffer.limit()

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-13766:
-
Component/s: (was: Legacy/Core)
 Local/SSTable

> Invalid page state caused by IllegalArgumentException from ByteBuffer.limit()
> -
>
> Key: CASSANDRA-13766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13766
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/SSTable
>Reporter: Jay Zhuang
>Priority: Minor
>
> Here is the exception:
> {noformat}
> ERROR [SharedPool-Worker-5] 2017-08-15 22:53:37,255 ErrorMessage.java:349 - 
> Unexpected exception during request
> java.lang.IllegalArgumentException: null
> at java.nio.Buffer.limit(Buffer.java:275) ~[na:1.8.0_121]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:613) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readBytesWithShortLength(ByteBufferUtil.java:622)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:201)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.db.LegacyLayout.decodeClustering(LegacyLayout.java:326) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:242)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadCommand(SinglePartitionPager.java:73)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:68)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:34)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:315)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:351)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:227)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:494)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:471)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:131)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.1.0.CR6.jar:4.1.0.CR6]
> at 
> io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
>  [netty-all-4.1.0.CR6.jar:4.1.0.CR6]
> at 
> io.netty.channel.DefaultChannelHandlerInvoker$7.run(DefaultChannelHandlerInvoker.java:159)
>  [netty-all-4.1.0.CR6.jar:4.1.0.CR6]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {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-13558) WHERE or LIMIT clause with COPY TO and COPY FROM command

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-13558:
-
Component/s: (was: Legacy/CQL)
 Tool/cqlsh

> WHERE or LIMIT clause with COPY TO and COPY FROM command
> 
>
> Key: CASSANDRA-13558
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13558
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
>Reporter: Deepak Patel
>Priority: Minor
>
> COPY TO and COPY FROM commands are very useful and developer friendly. It 
> would be really nice to see where condition/limit clause supported with COPY 
> command.



--
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] [Resolved] (CASSANDRA-13763) Trivial but potential security issue?

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas resolved CASSANDRA-13763.
--
Resolution: Not A Problem

> Trivial but potential security issue? 
> --
>
> Key: CASSANDRA-13763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13763
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: JC
>Priority: Trivial
>
> Hi
> In a recent github mirror, I've found the following line.
> Path: tools/stress/src/org/apache/cassandra/stress/settings/SettingsMode.java
> {code:java}
> 177 out.printf("  Password: %s%n", 
> (password==null?password:"*suppressed*"));
> {code}
> As the original password is intended to be masked as "*suppressed   *", I was 
> wondering if showing "null" when the password is null is safe. This might not 
> be an issue but I wanted to report just in case. 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] [Commented] (CASSANDRA-13763) Trivial but potential security issue?

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-13763:
--

Thanks for reaching out, and sorry for the delay in reply to your question.

This code is part of the cassandra-stress tool, a benchmarking harness that is 
typically used for load testing purposes only, and in this case would print the 
password supplied by the user at the beginning of that test to document the 
run. I don't think a substantial issue exists here.

Thanks again for the report.

> Trivial but potential security issue? 
> --
>
> Key: CASSANDRA-13763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13763
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: JC
>Priority: Trivial
>
> Hi
> In a recent github mirror, I've found the following line.
> Path: tools/stress/src/org/apache/cassandra/stress/settings/SettingsMode.java
> {code:java}
> 177 out.printf("  Password: %s%n", 
> (password==null?password:"*suppressed*"));
> {code}
> As the original password is intended to be masked as "*suppressed   *", I was 
> wondering if showing "null" when the password is null is safe. This might not 
> be an issue but I wanted to report just in case. 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-13895) IOException unwrapping in CommitLogReader. readCommitLogSegment misses exceptions in resource creation block

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-13895:
-
Reproduced In: 3.11.0

> IOException unwrapping in CommitLogReader. readCommitLogSegment misses 
> exceptions in resource creation block
> 
>
> Key: CASSANDRA-13895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13895
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Commit Log
>Reporter: Catalin Grigoroscuta
>Priority: Minor
>
> CommitLogReader. readCommitLogSegment is unwrapping IOExceptions wrapped as 
> RuntimeExceptions using a try-with-resource block.
> However, the resource specification block, {{RandomAccessReader reader = 
> RandomAccessReader.open(file)}}, could also throw such an exception, which is 
> missed by the catch block and throws as a RuntimeException instead of an 
> IOException. 
> One such example that I've seen is: 
> - RandomAccessReader.open (called in try-with-resource resource specification 
> block initialization)
> - ChannelProxy(File) constructor 
> - ChannelProxy.openChannel (wraps IOException as RuntimeException) 
> I don't know what the impact in Cassandra could be, I ran into this while 
> processing CDC/commit logs for synchronization with another system.
> Was using Cassandra 3.11.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-14235) ReadFailure Error -- Large Unbound Query

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14235:
-
Reproduced In: 3.11.1

> ReadFailure Error -- Large Unbound Query 
> -
>
> Key: CASSANDRA-14235
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14235
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
> Environment: My instance of Cassandra is a single local node. It was 
> installed via a tar file, versus installing it as a service. All settings are 
> default. 
> I'm operating on a Centos 7 machine (release 7.4.1708)
>Reporter: Fraizier
>Priority: Major
>  Labels: newbie
>
> Receiving ReadFailure Error when executing 'select' query with cassandra 
> python-driver.  
> I have a keyspace called "Documents" and a table with two columns, name and 
> object. Name is the text datatype and object is the blob datatype. The blob 
> objects are pickled python class instances. The description of the 
> keyspace/table is as follows:
>  
> {code:java}
> CREATE TABLE "Documents".table ( 
>  name text PRIMARY KEY, 
>  object blob 
> ) WITH bloom_filter_fp_chance = 0.01 
>  AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment 
> = '' 
>  AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'} 
>  AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'} 
>  AND crc_check_chance = 1.0 
>  AND dclocal_read_repair_chance = 0.1 
>  AND default_time_to_live = 0 AND gc_grace_seconds = 864000 
>  AND max_index_interval = 2048 
>  AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 
>  AND read_repair_chance = 0.0 
>  AND speculative_retry = '99PERCENTILE';{code}
>  
> There are 3509 rows contained within this table and each object is approx. 
> 25kb of data. (so I'm estimating ~90Mb of data in the object column.) I'm 
> attempting to run a simple line of python cassandra code :
> {code:java}
> rows = session.execute("SELECT name, object FROM table")
> {code}
> and in the log file of cassandra this is what is produced:
> {code:java}
> WARN  [ReadStage-4] 2018-02-13 14:53:12,319 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-4,10,main]: {}
> java.lang.RuntimeException: java.lang.RuntimeException
> at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2598)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_151]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> Caused by: java.lang.RuntimeException: null
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 

[jira] [Updated] (CASSANDRA-14587) TrueDiskSpaceUsed overcounts snapshots

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14587:
-
Component/s: (was: Legacy/Tools)
 Tool/nodetool

> TrueDiskSpaceUsed overcounts snapshots
> --
>
> Key: CASSANDRA-14587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
> Environment: Debian 8
> Cassandra 3.11.2
>Reporter: Elliott Sims
>Priority: Trivial
>
> Running 'nodetool listsnapshots' seems to overcount "TrueDiskSpaceUsed" under 
> some circumstances.  Specifically when there's a large number of snapshots.  
> I suspect that it's not deduplicating space used when multiple snapshots 
> share sstables that are not part of the current table.
> Results of "nodetool listsnapshots":
> Total TrueDiskSpaceUsed: 396.11 MiB
> Results of "du -hcs" on the table's directory:
> 18M    total
> This is 50+ snapshots (every minute) run with "-t  -sf 
> --column-family  "
> The results of a "du -hcs -L  "TrueDiskSpaceUsed"
> I have only tested against 3.11.2, but have no reason to believe it's unique 
> to that version or even 3.x.



--
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-13895) IOException unwrapping in CommitLogReader. readCommitLogSegment misses exceptions in resource creation block

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-13895:
-
Component/s: (was: Legacy/Core)
 Local/Commit Log

> IOException unwrapping in CommitLogReader. readCommitLogSegment misses 
> exceptions in resource creation block
> 
>
> Key: CASSANDRA-13895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13895
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Commit Log
>Reporter: Catalin Grigoroscuta
>Priority: Minor
>
> CommitLogReader. readCommitLogSegment is unwrapping IOExceptions wrapped as 
> RuntimeExceptions using a try-with-resource block.
> However, the resource specification block, {{RandomAccessReader reader = 
> RandomAccessReader.open(file)}}, could also throw such an exception, which is 
> missed by the catch block and throws as a RuntimeException instead of an 
> IOException. 
> One such example that I've seen is: 
> - RandomAccessReader.open (called in try-with-resource resource specification 
> block initialization)
> - ChannelProxy(File) constructor 
> - ChannelProxy.openChannel (wraps IOException as RuntimeException) 
> I don't know what the impact in Cassandra could be, I ran into this while 
> processing CDC/commit logs for synchronization with another system.
> Was using Cassandra 3.11.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] [Commented] (CASSANDRA-13921) Unable to start Cassandra

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-13921:
--

Hi [~rameshsraj], sorry for the delay in my reply.

This bug tracker is used by the developers of Apache Cassandra to track 
development itself. If you are still experiencing this issue, could you reach 
out to the User's list or IRC channel as described here? Thanks! 
http://cassandra.apache.org/community/

> Unable to start Cassandra
> -
>
> Key: CASSANDRA-13921
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13921
> Project: Cassandra
>  Issue Type: Test
>  Components: Legacy/Testing
> Environment: CentOS Linux release 7.2.1511 (Core)
> I am unable to start the cassandra and getting the below error:
>Reporter: Ramesh S Raj
>Priority: Major
>
> [root@btpvm0603 sbin]# ./cassandra -R
> [root@btpvm0603 sbin]#
> [root@btpvm0603 sbin]# CompilerOracle: dontinline 
> org/apache/cassandra/db/Columns$Serializer.deserializeLargeSubset 
> (Lorg/apache/cassandra/io/util/DataInputPlus;Lorg/apache/cassandra/db/Columns;I)Lorg/apache/cassandra/db/Columns;
> CompilerOracle: dontinline 
> org/apache/cassandra/db/Columns$Serializer.serializeLargeSubset 
> (Ljava/util/Collection;ILorg/apache/cassandra/db/Columns;ILorg/apache/cassandra/io/util/DataOutputPlus;)V
> CompilerOracle: dontinline 
> org/apache/cassandra/db/Columns$Serializer.serializeLargeSubsetSize 
> (Ljava/util/Collection;ILorg/apache/cassandra/db/Columns;I)I
> CompilerOracle: dontinline 
> org/apache/cassandra/db/commitlog/AbstractCommitLogSegmentManager.advanceAllocatingFrom
>  (Lorg/apache/cassandra/db/commitlog/CommitLogSegment;)V
> CompilerOracle: dontinline 
> org/apache/cassandra/db/transform/BaseIterator.tryGetMoreContents ()Z
> CompilerOracle: dontinline 
> org/apache/cassandra/db/transform/StoppingTransformation.stop ()V
> CompilerOracle: dontinline 
> org/apache/cassandra/db/transform/StoppingTransformation.stopInPartition ()V
> CompilerOracle: dontinline 
> org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.doFlush (I)V
> CompilerOracle: dontinline 
> org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.writeExcessSlow ()V
> CompilerOracle: dontinline 
> org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.writeSlow (JI)V
> CompilerOracle: dontinline 
> org/apache/cassandra/io/util/RebufferingInputStream.readPrimitiveSlowly (I)J
> CompilerOracle: inline 
> org/apache/cassandra/db/rows/UnfilteredSerializer.serializeRowBody 
> (Lorg/apache/cassandra/db/rows/Row;ILorg/apache/cassandra/db/SerializationHeader;Lorg/apache/cassandra/io/util/DataOutputPlus;)V
> CompilerOracle: inline org/apache/cassandra/io/util/Memory.checkBounds (JJ)V
> CompilerOracle: inline org/apache/cassandra/io/util/SafeMemory.checkBounds 
> (JJ)V
> CompilerOracle: inline 
> org/apache/cassandra/utils/AsymmetricOrdering.selectBoundary 
> (Lorg/apache/cassandra/utils/AsymmetricOrdering/Op;II)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/AsymmetricOrdering.strictnessOfLessThan 
> (Lorg/apache/cassandra/utils/AsymmetricOrdering/Op;)I
> CompilerOracle: inline org/apache/cassandra/utils/BloomFilter.indexes 
> (Lorg/apache/cassandra/utils/IFilter/FilterKey;)[J
> CompilerOracle: inline org/apache/cassandra/utils/BloomFilter.setIndexes 
> (JJIJ[J)V
> CompilerOracle: inline org/apache/cassandra/utils/ByteBufferUtil.compare 
> (Ljava/nio/ByteBuffer;[B)I
> CompilerOracle: inline org/apache/cassandra/utils/ByteBufferUtil.compare 
> ([BLjava/nio/ByteBuffer;)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/ByteBufferUtil.compareUnsigned 
> (Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo 
> (Ljava/lang/Object;JILjava/lang/Object;JI)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo 
> (Ljava/lang/Object;JILjava/nio/ByteBuffer;)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo 
> (Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)I
> CompilerOracle: inline org/apache/cassandra/utils/vint/VIntCoding.encodeVInt 
> (JI)[B
> [root@btpvm0603 sbin]# Error: A JNI error has occurred, please check your 
> installation and try again
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/yaml/snakeyaml/introspector/PropertyUtils
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
> at java.lang.Class.getMethod0(Class.java:3018)
> at java.lang.Class.getMethod(Class.java:1784)
> at 
> 

[jira] [Resolved] (CASSANDRA-13921) Unable to start Cassandra

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas resolved CASSANDRA-13921.
--
Resolution: Information Provided

> Unable to start Cassandra
> -
>
> Key: CASSANDRA-13921
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13921
> Project: Cassandra
>  Issue Type: Test
>  Components: Legacy/Testing
> Environment: CentOS Linux release 7.2.1511 (Core)
> I am unable to start the cassandra and getting the below error:
>Reporter: Ramesh S Raj
>Priority: Major
>
> [root@btpvm0603 sbin]# ./cassandra -R
> [root@btpvm0603 sbin]#
> [root@btpvm0603 sbin]# CompilerOracle: dontinline 
> org/apache/cassandra/db/Columns$Serializer.deserializeLargeSubset 
> (Lorg/apache/cassandra/io/util/DataInputPlus;Lorg/apache/cassandra/db/Columns;I)Lorg/apache/cassandra/db/Columns;
> CompilerOracle: dontinline 
> org/apache/cassandra/db/Columns$Serializer.serializeLargeSubset 
> (Ljava/util/Collection;ILorg/apache/cassandra/db/Columns;ILorg/apache/cassandra/io/util/DataOutputPlus;)V
> CompilerOracle: dontinline 
> org/apache/cassandra/db/Columns$Serializer.serializeLargeSubsetSize 
> (Ljava/util/Collection;ILorg/apache/cassandra/db/Columns;I)I
> CompilerOracle: dontinline 
> org/apache/cassandra/db/commitlog/AbstractCommitLogSegmentManager.advanceAllocatingFrom
>  (Lorg/apache/cassandra/db/commitlog/CommitLogSegment;)V
> CompilerOracle: dontinline 
> org/apache/cassandra/db/transform/BaseIterator.tryGetMoreContents ()Z
> CompilerOracle: dontinline 
> org/apache/cassandra/db/transform/StoppingTransformation.stop ()V
> CompilerOracle: dontinline 
> org/apache/cassandra/db/transform/StoppingTransformation.stopInPartition ()V
> CompilerOracle: dontinline 
> org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.doFlush (I)V
> CompilerOracle: dontinline 
> org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.writeExcessSlow ()V
> CompilerOracle: dontinline 
> org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.writeSlow (JI)V
> CompilerOracle: dontinline 
> org/apache/cassandra/io/util/RebufferingInputStream.readPrimitiveSlowly (I)J
> CompilerOracle: inline 
> org/apache/cassandra/db/rows/UnfilteredSerializer.serializeRowBody 
> (Lorg/apache/cassandra/db/rows/Row;ILorg/apache/cassandra/db/SerializationHeader;Lorg/apache/cassandra/io/util/DataOutputPlus;)V
> CompilerOracle: inline org/apache/cassandra/io/util/Memory.checkBounds (JJ)V
> CompilerOracle: inline org/apache/cassandra/io/util/SafeMemory.checkBounds 
> (JJ)V
> CompilerOracle: inline 
> org/apache/cassandra/utils/AsymmetricOrdering.selectBoundary 
> (Lorg/apache/cassandra/utils/AsymmetricOrdering/Op;II)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/AsymmetricOrdering.strictnessOfLessThan 
> (Lorg/apache/cassandra/utils/AsymmetricOrdering/Op;)I
> CompilerOracle: inline org/apache/cassandra/utils/BloomFilter.indexes 
> (Lorg/apache/cassandra/utils/IFilter/FilterKey;)[J
> CompilerOracle: inline org/apache/cassandra/utils/BloomFilter.setIndexes 
> (JJIJ[J)V
> CompilerOracle: inline org/apache/cassandra/utils/ByteBufferUtil.compare 
> (Ljava/nio/ByteBuffer;[B)I
> CompilerOracle: inline org/apache/cassandra/utils/ByteBufferUtil.compare 
> ([BLjava/nio/ByteBuffer;)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/ByteBufferUtil.compareUnsigned 
> (Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo 
> (Ljava/lang/Object;JILjava/lang/Object;JI)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo 
> (Ljava/lang/Object;JILjava/nio/ByteBuffer;)I
> CompilerOracle: inline 
> org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo 
> (Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)I
> CompilerOracle: inline org/apache/cassandra/utils/vint/VIntCoding.encodeVInt 
> (JI)[B
> [root@btpvm0603 sbin]# Error: A JNI error has occurred, please check your 
> installation and try again
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/yaml/snakeyaml/introspector/PropertyUtils
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
> at java.lang.Class.getMethod0(Class.java:3018)
> at java.lang.Class.getMethod(Class.java:1784)
> at 
> sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
> at 
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
> Caused by: java.lang.ClassNotFoundException: 
> org.yaml.snakeyaml.introspector.PropertyUtils
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at 

[jira] [Updated] (CASSANDRA-14351) Support systemd SD_NOTIFY interface during startup

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14351:
-
Component/s: (was: Legacy/Core)
 Packaging

> Support systemd SD_NOTIFY interface during startup
> --
>
> Key: CASSANDRA-14351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14351
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Thomas Bechtold
>Priority: Major
>
> When cassandra is started via systemd, it would be nice to support the 
> [SD_NOTIFY|https://www.freedesktop.org/software/systemd/man/sd_notify.html] 
> protocol so systemd know, when cassandra is ready (that can be use for 
> dependencies or when you need to wait until cassandra startup is done).
> A very simple implementation could be done using the 
> {code:java}
> systemd-notify --ready
> {code}
> command line tool (and ignore it if the tool is not there)



--
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-14235) ReadFailure Error -- Large Unbound Query

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14235:
-
Fix Version/s: (was: 3.11.1)

> ReadFailure Error -- Large Unbound Query 
> -
>
> Key: CASSANDRA-14235
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14235
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
> Environment: My instance of Cassandra is a single local node. It was 
> installed via a tar file, versus installing it as a service. All settings are 
> default. 
> I'm operating on a Centos 7 machine (release 7.4.1708)
>Reporter: Fraizier
>Priority: Major
>  Labels: newbie
>
> Receiving ReadFailure Error when executing 'select' query with cassandra 
> python-driver.  
> I have a keyspace called "Documents" and a table with two columns, name and 
> object. Name is the text datatype and object is the blob datatype. The blob 
> objects are pickled python class instances. The description of the 
> keyspace/table is as follows:
>  
> {code:java}
> CREATE TABLE "Documents".table ( 
>  name text PRIMARY KEY, 
>  object blob 
> ) WITH bloom_filter_fp_chance = 0.01 
>  AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment 
> = '' 
>  AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'} 
>  AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'} 
>  AND crc_check_chance = 1.0 
>  AND dclocal_read_repair_chance = 0.1 
>  AND default_time_to_live = 0 AND gc_grace_seconds = 864000 
>  AND max_index_interval = 2048 
>  AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 
>  AND read_repair_chance = 0.0 
>  AND speculative_retry = '99PERCENTILE';{code}
>  
> There are 3509 rows contained within this table and each object is approx. 
> 25kb of data. (so I'm estimating ~90Mb of data in the object column.) I'm 
> attempting to run a simple line of python cassandra code :
> {code:java}
> rows = session.execute("SELECT name, object FROM table")
> {code}
> and in the log file of cassandra this is what is produced:
> {code:java}
> WARN  [ReadStage-4] 2018-02-13 14:53:12,319 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-4,10,main]: {}
> java.lang.RuntimeException: java.lang.RuntimeException
> at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2598)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_151]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> Caused by: java.lang.RuntimeException: null
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 

[jira] [Updated] (CASSANDRA-14235) ReadFailure Error -- Large Unbound Query

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14235:
-
Component/s: (was: Legacy/CQL)
 Messaging/Client

> ReadFailure Error -- Large Unbound Query 
> -
>
> Key: CASSANDRA-14235
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14235
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
> Environment: My instance of Cassandra is a single local node. It was 
> installed via a tar file, versus installing it as a service. All settings are 
> default. 
> I'm operating on a Centos 7 machine (release 7.4.1708)
>Reporter: Fraizier
>Priority: Major
>  Labels: newbie
> Fix For: 3.11.1
>
>
> Receiving ReadFailure Error when executing 'select' query with cassandra 
> python-driver.  
> I have a keyspace called "Documents" and a table with two columns, name and 
> object. Name is the text datatype and object is the blob datatype. The blob 
> objects are pickled python class instances. The description of the 
> keyspace/table is as follows:
>  
> {code:java}
> CREATE TABLE "Documents".table ( 
>  name text PRIMARY KEY, 
>  object blob 
> ) WITH bloom_filter_fp_chance = 0.01 
>  AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment 
> = '' 
>  AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'} 
>  AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'} 
>  AND crc_check_chance = 1.0 
>  AND dclocal_read_repair_chance = 0.1 
>  AND default_time_to_live = 0 AND gc_grace_seconds = 864000 
>  AND max_index_interval = 2048 
>  AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 
>  AND read_repair_chance = 0.0 
>  AND speculative_retry = '99PERCENTILE';{code}
>  
> There are 3509 rows contained within this table and each object is approx. 
> 25kb of data. (so I'm estimating ~90Mb of data in the object column.) I'm 
> attempting to run a simple line of python cassandra code :
> {code:java}
> rows = session.execute("SELECT name, object FROM table")
> {code}
> and in the log file of cassandra this is what is produced:
> {code:java}
> WARN  [ReadStage-4] 2018-02-13 14:53:12,319 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-4,10,main]: {}
> java.lang.RuntimeException: java.lang.RuntimeException
> at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2598)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_151]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> Caused by: java.lang.RuntimeException: null
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
>  

[jira] [Updated] (CASSANDRA-14658) Cassandra hangs at startup

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14658:
-
Component/s: Local/Commit Log

> Cassandra hangs at startup
> --
>
> Key: CASSANDRA-14658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14658
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Commit Log
>Reporter: Jing Weng
>Priority: Major
> Fix For: 3.11.1
>
>
> Some time ago, when our cassandra cluster started, we found that it could not 
> be started, checked various logs, and found no error message. Later, we 
> obtained the thread stack information at startup by some means, and then 
> refer to the source code, and found that if the commitlog initialization 
> error occurs at startup, cassandra will appear deadlock and hang.
> The thread stack of COMMIT-LOG-ALLOCATOR:
>  
> {noformat}
> {
>   "waitedCount": 0,
>   "lockOwnerId": -1,
>   "lockedMonitors": [],
>   "waitedTime": -1,
>   "blockedCount": 0,
>   "threadState": "RUNNABLE",
>   "inNative": false,
>   "suspended": false,
>   "threadName": "COMMIT-LOG-ALLOCATOR",
>   "lockInfo": null,
>   "threadId": 36,
>   "stackTrace": [
> {
>   "fileName": "AbstractCommitLogSegmentManager.java",
>   "nativeMethod": false,
>   "methodName": "runMayThrow",
>   "className": 
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1",
>   "lineNumber": 133
> },
> {
>   "fileName": "WrappedRunnable.java",
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": "org.apache.cassandra.utils.WrappedRunnable",
>   "lineNumber": 28
> },
> {
>   "fileName": "NamedThreadFactory.java",
>   "nativeMethod": false,
>   "methodName": "lambda$threadLocalDeallocator$0",
>   "className": "org.apache.cassandra.concurrent.NamedThreadFactory",
>   "lineNumber": 81
> },
> {
>   "fileName": null,
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": 
> "org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$4\/1392794732",
>   "lineNumber": -1
> },
> {
>   "fileName": "Thread.java",
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": "java.lang.Thread",
>   "lineNumber": 748
> }
>   ],
>   "blockedTime": -1,
>   "lockName": null,
>   "lockOwnerName": null,
>   "lockedSynchronizers": []
> }{noformat}
>  
> The thread stack of main thread:
>  
> {noformat}
> {
>   "waitedCount": 2,
>   "lockOwnerId": -1,
>   "lockedMonitors": [
> {
>   "identityHashCode": 600118828,
>   "lockedStackDepth": 10,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 620
>   }
> },
> {
>   "identityHashCode": 600118828,
>   "lockedStackDepth": 11,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 594
>   }
> },
> {
>   "identityHashCode": 1087037934,
>   "lockedStackDepth": 15,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "Keyspace.java",
> "nativeMethod": false,
> "methodName": "open",
> "className": "org.apache.cassandra.db.Keyspace",
> "lineNumber": 127
>   }
> }
>   ],
>   "waitedTime": -1,
>   "blockedCount": 0,
>   "threadState": "WAITING",
>   "inNative": false,
>   "suspended": false,
>   "threadName": "main",
>   "lockInfo": null,
>   "threadId": 1,
>   "stackTrace": [
> {
>   "fileName": "Unsafe.java",
>   "nativeMethod": true,
>   "methodName": "park",
>   "className": "sun.misc.Unsafe",
>   "lineNumber": -2
> },
> {
>   "fileName": "LockSupport.java",
>   "nativeMethod": false,
>   "methodName": "park",
>   "className": "java.util.concurrent.locks.LockSupport",
>   "lineNumber": 304
> },
> {
>   "fileName": "WaitQueue.java",
>   "nativeMethod": false,
>   "methodName": "awaitUninterruptibly",
>   "className": 
> "org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal",
>   "lineNumber": 280
> },
> {
>   "fileName": "AbstractCommitLogSegmentManager.java",
>   "nativeMethod": false,
>   "methodName": "awaitAvailableSegment",
>   "className": 
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager",
>   

[jira] [Commented] (CASSANDRA-14676) Use joins and aggregate functions in cassandra

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14676:
--

Hi [~rk0589], sorry for the delay in my reply.

Cassandra has limited support for user-defined aggregations. See here for 
documentation contributed by members of the community: 
[https://www.instaclustr.com/user-defined-functions-and-aggregates/]. As a 
non-relational database, joins are not supported though many join-related use 
cases can be met via denormalized data models.

I should mention that this bug tracker is used by developers of Apache 
Cassandra. The best avenue for help is via the user's list or IRC channel. 
Details on these are available here: http://cassandra.apache.org/community/

> Use joins and aggregate functions in cassandra
> --
>
> Key: CASSANDRA-14676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14676
> Project: Cassandra
>  Issue Type: Wish
>  Components: Legacy/Testing
>Reporter: Rama Krishna
>Priority: Major
> Fix For: 3.11.2
>
>
> Team, 
>  
> I am using Apache Cassandra 3.11.2 version , apart from Spark , do we have 
> any other alternative to use Joins and Aggregate functions in cassandra .
>  
>  
> Thanks,
> RK.



--
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-14669) Transient Replication: Confirm vnode support w/Transient Replication

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14669:
-
Component/s: (was: Legacy/Core)
 Feature/Transient Replication

> Transient Replication: Confirm vnode support w/Transient Replication
> 
>
> Key: CASSANDRA-14669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14669
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Feature/Transient Replication
>Reporter: Ariel Weisberg
>Priority: Major
> Fix For: 4.0.x
>
>
> Transient replication's implementation supports vnodes, but the test coverage 
> is insufficient to be confident there are no hidden issues. Once test 
> coverage is sufficient we should allow the creation of TR keyspaces with 
> vnodes.



--
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-14676) Use joins and aggregate functions in cassandra

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14676:
-
Component/s: (was: Legacy/Testing)
 Feature/UDA

> Use joins and aggregate functions in cassandra
> --
>
> Key: CASSANDRA-14676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14676
> Project: Cassandra
>  Issue Type: Wish
>  Components: Feature/UDA
>Reporter: Rama Krishna
>Priority: Major
> Fix For: 3.11.2
>
>
> Team, 
>  
> I am using Apache Cassandra 3.11.2 version , apart from Spark , do we have 
> any other alternative to use Joins and Aggregate functions in cassandra .
>  
>  
> Thanks,
> RK.



--
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-14364) Update Seed provider documentation

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14364:
-
Component/s: (was: Legacy/Documentation and Website)
 Documentation/Website

> Update Seed provider documentation
> --
>
> Key: CASSANDRA-14364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14364
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Ben Bromhead
>Priority: Trivial
>
> Update documentation to describe how Cassandra uses the seed list. Include 
> details about nuances of using DNS hostnames vs IP addresses. 
>  
> [http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html#seed-provider]
>  



--
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-14508) Jenkins Slave doesn't have permission to write to /tmp/ directory

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14508:
-
Component/s: (was: Legacy/Testing)
 Build

> Jenkins Slave doesn't have permission to write to /tmp/ directory
> -
>
> Key: CASSANDRA-14508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14508
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build
>Reporter: Jay Zhuang
>Priority: Major
>
> Which is causing uTest failed, e.g.:
> https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-test/lastCompletedBuild/testReport/org.apache.cassandra.streaming.compression/CompressedInputStreamTest/testCompressedReadUncompressedChunks/
> h3. Error Message
> {noformat}
> java.nio.file.AccessDeniedException: /tmp/na-1-big-Data.db
> {noformat}
> h3. Stacktrace
> {noformat}
> java.lang.RuntimeException: java.nio.file.AccessDeniedException: 
> /tmp/na-1-big-Data.db at 
> org.apache.cassandra.io.util.SequentialWriter.openChannel(SequentialWriter.java:119)
>  at 
> org.apache.cassandra.io.util.SequentialWriter.(SequentialWriter.java:141)
>  at 
> org.apache.cassandra.io.compress.CompressedSequentialWriter.(CompressedSequentialWriter.java:82)
>  at 
> org.apache.cassandra.streaming.compression.CompressedInputStreamTest.testCompressedReadWith(CompressedInputStreamTest.java:118)
>  at 
> org.apache.cassandra.streaming.compression.CompressedInputStreamTest.testCompressedReadUncompressedChunks(CompressedInputStreamTest.java:83)
>  Caused by: java.nio.file.AccessDeniedException: /tmp/na-1-big-Data.db at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) at 
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at 
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at 
> sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
>  at java.nio.channels.FileChannel.open(FileChannel.java:287) at 
> java.nio.channels.FileChannel.open(FileChannel.java:335) at 
> org.apache.cassandra.io.util.SequentialWriter.openChannel(SequentialWriter.java:100)
> {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-14533) Frozen Collections should allow TTL and WRITETIME access

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14533:
-
Component/s: (was: Legacy/CQL)
 CQL/Interpreter

> Frozen Collections should allow TTL and WRITETIME access
> 
>
> Key: CASSANDRA-14533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14533
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Scott Carey
>Priority: Major
>
> It is clear why we can not simply access ttl and writetime of normal 
> collections, as the collection itself is made up of multiple cells  (see 
> CASSANDRA-8877)
>  
> But frozen collections should allow it, since they are just one cell with the 
> whole collection stored in a simple blob.
>  
> Right now, I get an error message whether it is frozen or not:
>  
> {noformat}
> cqlsh:testing> create table stuff (id int primary key, blah text, stuff 
> frozen>);
> cqlsh:testing> insert into stuff (id, blah, stuff) VALUES (1, 'blargh', { 
> 'setstuff' });
> cqlsh:testing> select id, blah, writetime(blah) from stuff;
> id | blah | writetime(blah)
> ++--
> 1 | blargh | 1529512132503886
> (1 rows)
> cqlsh:testing> select id, stuff, writetime(stuff) from stuff;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot 
> use selection function writeTime on collections"
> cqlsh:testing> select id, stuff from stuff;
> id | stuff
> +--
> 1 | {'setstuff'}{noformat}
>  
> It is likewise not possible to get the timestamp on a frozen collection from 
> the java client.



--
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-14582) Add a system property to set the cassandra hostId if not yet initialized

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14582:
-
Fix Version/s: (was: 3.11.x)
   (was: 4.x)

> Add a system property to set the cassandra hostId if not yet initialized
> 
>
> Key: CASSANDRA-14582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14582
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: vincent royer
>Priority: Minor
>
> Add a system property *cassandra.host_id* to set the cassandra hostId if not 
> yet initialized.
> This allow to push the cassandra host ID when provisioning new cassandra 
> nodes rather than to retreive it after the first start.



--
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-14658) Cassandra hangs at startup

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14658:
-
Reproduced In: 3.11.1

> Cassandra hangs at startup
> --
>
> Key: CASSANDRA-14658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14658
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Commit Log
>Reporter: Jing Weng
>Priority: Major
>
> Some time ago, when our cassandra cluster started, we found that it could not 
> be started, checked various logs, and found no error message. Later, we 
> obtained the thread stack information at startup by some means, and then 
> refer to the source code, and found that if the commitlog initialization 
> error occurs at startup, cassandra will appear deadlock and hang.
> The thread stack of COMMIT-LOG-ALLOCATOR:
>  
> {noformat}
> {
>   "waitedCount": 0,
>   "lockOwnerId": -1,
>   "lockedMonitors": [],
>   "waitedTime": -1,
>   "blockedCount": 0,
>   "threadState": "RUNNABLE",
>   "inNative": false,
>   "suspended": false,
>   "threadName": "COMMIT-LOG-ALLOCATOR",
>   "lockInfo": null,
>   "threadId": 36,
>   "stackTrace": [
> {
>   "fileName": "AbstractCommitLogSegmentManager.java",
>   "nativeMethod": false,
>   "methodName": "runMayThrow",
>   "className": 
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1",
>   "lineNumber": 133
> },
> {
>   "fileName": "WrappedRunnable.java",
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": "org.apache.cassandra.utils.WrappedRunnable",
>   "lineNumber": 28
> },
> {
>   "fileName": "NamedThreadFactory.java",
>   "nativeMethod": false,
>   "methodName": "lambda$threadLocalDeallocator$0",
>   "className": "org.apache.cassandra.concurrent.NamedThreadFactory",
>   "lineNumber": 81
> },
> {
>   "fileName": null,
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": 
> "org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$4\/1392794732",
>   "lineNumber": -1
> },
> {
>   "fileName": "Thread.java",
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": "java.lang.Thread",
>   "lineNumber": 748
> }
>   ],
>   "blockedTime": -1,
>   "lockName": null,
>   "lockOwnerName": null,
>   "lockedSynchronizers": []
> }{noformat}
>  
> The thread stack of main thread:
>  
> {noformat}
> {
>   "waitedCount": 2,
>   "lockOwnerId": -1,
>   "lockedMonitors": [
> {
>   "identityHashCode": 600118828,
>   "lockedStackDepth": 10,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 620
>   }
> },
> {
>   "identityHashCode": 600118828,
>   "lockedStackDepth": 11,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 594
>   }
> },
> {
>   "identityHashCode": 1087037934,
>   "lockedStackDepth": 15,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "Keyspace.java",
> "nativeMethod": false,
> "methodName": "open",
> "className": "org.apache.cassandra.db.Keyspace",
> "lineNumber": 127
>   }
> }
>   ],
>   "waitedTime": -1,
>   "blockedCount": 0,
>   "threadState": "WAITING",
>   "inNative": false,
>   "suspended": false,
>   "threadName": "main",
>   "lockInfo": null,
>   "threadId": 1,
>   "stackTrace": [
> {
>   "fileName": "Unsafe.java",
>   "nativeMethod": true,
>   "methodName": "park",
>   "className": "sun.misc.Unsafe",
>   "lineNumber": -2
> },
> {
>   "fileName": "LockSupport.java",
>   "nativeMethod": false,
>   "methodName": "park",
>   "className": "java.util.concurrent.locks.LockSupport",
>   "lineNumber": 304
> },
> {
>   "fileName": "WaitQueue.java",
>   "nativeMethod": false,
>   "methodName": "awaitUninterruptibly",
>   "className": 
> "org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal",
>   "lineNumber": 280
> },
> {
>   "fileName": "AbstractCommitLogSegmentManager.java",
>   "nativeMethod": false,
>   "methodName": "awaitAvailableSegment",
>   "className": 
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager",
>   "lineNumber": 262
> },
> {
>

[jira] [Updated] (CASSANDRA-14582) Add a system property to set the cassandra hostId if not yet initialized

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14582:
-
Component/s: (was: Local/Startup and Shutdown)
 Local/Config

> Add a system property to set the cassandra hostId if not yet initialized
> 
>
> Key: CASSANDRA-14582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14582
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: vincent royer
>Priority: Minor
> Fix For: 3.11.x, 4.x
>
>
> Add a system property *cassandra.host_id* to set the cassandra hostId if not 
> yet initialized.
> This allow to push the cassandra host ID when provisioning new cassandra 
> nodes rather than to retreive it after the first start.



--
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-14658) Cassandra hangs at startup

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14658:
-
Fix Version/s: (was: 3.11.1)

> Cassandra hangs at startup
> --
>
> Key: CASSANDRA-14658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14658
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Commit Log
>Reporter: Jing Weng
>Priority: Major
>
> Some time ago, when our cassandra cluster started, we found that it could not 
> be started, checked various logs, and found no error message. Later, we 
> obtained the thread stack information at startup by some means, and then 
> refer to the source code, and found that if the commitlog initialization 
> error occurs at startup, cassandra will appear deadlock and hang.
> The thread stack of COMMIT-LOG-ALLOCATOR:
>  
> {noformat}
> {
>   "waitedCount": 0,
>   "lockOwnerId": -1,
>   "lockedMonitors": [],
>   "waitedTime": -1,
>   "blockedCount": 0,
>   "threadState": "RUNNABLE",
>   "inNative": false,
>   "suspended": false,
>   "threadName": "COMMIT-LOG-ALLOCATOR",
>   "lockInfo": null,
>   "threadId": 36,
>   "stackTrace": [
> {
>   "fileName": "AbstractCommitLogSegmentManager.java",
>   "nativeMethod": false,
>   "methodName": "runMayThrow",
>   "className": 
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1",
>   "lineNumber": 133
> },
> {
>   "fileName": "WrappedRunnable.java",
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": "org.apache.cassandra.utils.WrappedRunnable",
>   "lineNumber": 28
> },
> {
>   "fileName": "NamedThreadFactory.java",
>   "nativeMethod": false,
>   "methodName": "lambda$threadLocalDeallocator$0",
>   "className": "org.apache.cassandra.concurrent.NamedThreadFactory",
>   "lineNumber": 81
> },
> {
>   "fileName": null,
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": 
> "org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$4\/1392794732",
>   "lineNumber": -1
> },
> {
>   "fileName": "Thread.java",
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": "java.lang.Thread",
>   "lineNumber": 748
> }
>   ],
>   "blockedTime": -1,
>   "lockName": null,
>   "lockOwnerName": null,
>   "lockedSynchronizers": []
> }{noformat}
>  
> The thread stack of main thread:
>  
> {noformat}
> {
>   "waitedCount": 2,
>   "lockOwnerId": -1,
>   "lockedMonitors": [
> {
>   "identityHashCode": 600118828,
>   "lockedStackDepth": 10,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 620
>   }
> },
> {
>   "identityHashCode": 600118828,
>   "lockedStackDepth": 11,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 594
>   }
> },
> {
>   "identityHashCode": 1087037934,
>   "lockedStackDepth": 15,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "Keyspace.java",
> "nativeMethod": false,
> "methodName": "open",
> "className": "org.apache.cassandra.db.Keyspace",
> "lineNumber": 127
>   }
> }
>   ],
>   "waitedTime": -1,
>   "blockedCount": 0,
>   "threadState": "WAITING",
>   "inNative": false,
>   "suspended": false,
>   "threadName": "main",
>   "lockInfo": null,
>   "threadId": 1,
>   "stackTrace": [
> {
>   "fileName": "Unsafe.java",
>   "nativeMethod": true,
>   "methodName": "park",
>   "className": "sun.misc.Unsafe",
>   "lineNumber": -2
> },
> {
>   "fileName": "LockSupport.java",
>   "nativeMethod": false,
>   "methodName": "park",
>   "className": "java.util.concurrent.locks.LockSupport",
>   "lineNumber": 304
> },
> {
>   "fileName": "WaitQueue.java",
>   "nativeMethod": false,
>   "methodName": "awaitUninterruptibly",
>   "className": 
> "org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal",
>   "lineNumber": 280
> },
> {
>   "fileName": "AbstractCommitLogSegmentManager.java",
>   "nativeMethod": false,
>   "methodName": "awaitAvailableSegment",
>   "className": 
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager",
>   "lineNumber": 262
> },
> 

[jira] [Updated] (CASSANDRA-14658) Cassandra hangs at startup

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14658:
-
Component/s: (was: Legacy/Core)

> Cassandra hangs at startup
> --
>
> Key: CASSANDRA-14658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14658
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jing Weng
>Priority: Major
> Fix For: 3.11.1
>
>
> Some time ago, when our cassandra cluster started, we found that it could not 
> be started, checked various logs, and found no error message. Later, we 
> obtained the thread stack information at startup by some means, and then 
> refer to the source code, and found that if the commitlog initialization 
> error occurs at startup, cassandra will appear deadlock and hang.
> The thread stack of COMMIT-LOG-ALLOCATOR:
>  
> {noformat}
> {
>   "waitedCount": 0,
>   "lockOwnerId": -1,
>   "lockedMonitors": [],
>   "waitedTime": -1,
>   "blockedCount": 0,
>   "threadState": "RUNNABLE",
>   "inNative": false,
>   "suspended": false,
>   "threadName": "COMMIT-LOG-ALLOCATOR",
>   "lockInfo": null,
>   "threadId": 36,
>   "stackTrace": [
> {
>   "fileName": "AbstractCommitLogSegmentManager.java",
>   "nativeMethod": false,
>   "methodName": "runMayThrow",
>   "className": 
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1",
>   "lineNumber": 133
> },
> {
>   "fileName": "WrappedRunnable.java",
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": "org.apache.cassandra.utils.WrappedRunnable",
>   "lineNumber": 28
> },
> {
>   "fileName": "NamedThreadFactory.java",
>   "nativeMethod": false,
>   "methodName": "lambda$threadLocalDeallocator$0",
>   "className": "org.apache.cassandra.concurrent.NamedThreadFactory",
>   "lineNumber": 81
> },
> {
>   "fileName": null,
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": 
> "org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$4\/1392794732",
>   "lineNumber": -1
> },
> {
>   "fileName": "Thread.java",
>   "nativeMethod": false,
>   "methodName": "run",
>   "className": "java.lang.Thread",
>   "lineNumber": 748
> }
>   ],
>   "blockedTime": -1,
>   "lockName": null,
>   "lockOwnerName": null,
>   "lockedSynchronizers": []
> }{noformat}
>  
> The thread stack of main thread:
>  
> {noformat}
> {
>   "waitedCount": 2,
>   "lockOwnerId": -1,
>   "lockedMonitors": [
> {
>   "identityHashCode": 600118828,
>   "lockedStackDepth": 10,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 620
>   }
> },
> {
>   "identityHashCode": 600118828,
>   "lockedStackDepth": 11,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 594
>   }
> },
> {
>   "identityHashCode": 1087037934,
>   "lockedStackDepth": 15,
>   "className": "java.lang.Class",
>   "lockedStackFrame": {
> "fileName": "Keyspace.java",
> "nativeMethod": false,
> "methodName": "open",
> "className": "org.apache.cassandra.db.Keyspace",
> "lineNumber": 127
>   }
> }
>   ],
>   "waitedTime": -1,
>   "blockedCount": 0,
>   "threadState": "WAITING",
>   "inNative": false,
>   "suspended": false,
>   "threadName": "main",
>   "lockInfo": null,
>   "threadId": 1,
>   "stackTrace": [
> {
>   "fileName": "Unsafe.java",
>   "nativeMethod": true,
>   "methodName": "park",
>   "className": "sun.misc.Unsafe",
>   "lineNumber": -2
> },
> {
>   "fileName": "LockSupport.java",
>   "nativeMethod": false,
>   "methodName": "park",
>   "className": "java.util.concurrent.locks.LockSupport",
>   "lineNumber": 304
> },
> {
>   "fileName": "WaitQueue.java",
>   "nativeMethod": false,
>   "methodName": "awaitUninterruptibly",
>   "className": 
> "org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal",
>   "lineNumber": 280
> },
> {
>   "fileName": "AbstractCommitLogSegmentManager.java",
>   "nativeMethod": false,
>   "methodName": "awaitAvailableSegment",
>   "className": 
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager",
>   "lineNumber": 262
> },
> 

[jira] [Resolved] (CASSANDRA-14676) Use joins and aggregate functions in cassandra

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas resolved CASSANDRA-14676.
--
Resolution: Information Provided

> Use joins and aggregate functions in cassandra
> --
>
> Key: CASSANDRA-14676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14676
> Project: Cassandra
>  Issue Type: Wish
>  Components: Legacy/Testing
>Reporter: Rama Krishna
>Priority: Major
> Fix For: 3.11.2
>
>
> Team, 
>  
> I am using Apache Cassandra 3.11.2 version , apart from Spark , do we have 
> any other alternative to use Joins and Aggregate functions in cassandra .
>  
>  
> Thanks,
> RK.



--
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-14771) Transient Replication: Writes at CL.ALL should block on all full replicas, but not transients

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14771:
-
Component/s: (was: Legacy/Coordination)
 Feature/Transient Replication

> Transient Replication: Writes at CL.ALL should block on all full replicas, 
> but not transients 
> --
>
> Key: CASSANDRA-14771
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14771
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Transient Replication
>Reporter: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> Reading at ONE will still be safe because ONE only selects full replicas. 
> There is no reason to write to transients if we are going to block on all 
> full replicas.



--
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-14816) Add Operating System Specific Setup Documentation for Cassandra

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14816:
-
Component/s: (was: Legacy/Documentation and Website)
 Documentation/Website

> Add Operating System Specific Setup Documentation for Cassandra
> ---
>
> Key: CASSANDRA-14816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14816
> Project: Cassandra
>  Issue Type: Wish
>  Components: Documentation/Website
>Reporter: Joseph Lynch
>Priority: Minor
>
> There are a number of operating system tunings that can vastly improve 
> Cassandra's performance on Linux in particular things like:
> # Setting {{/sys/block/${DEVICE}/queue/read_ahead_kb}} to something more 
> reasonable like 32
> # Setting the qdisc on modern linux to something better like {{tc-fq}} with 
> {{bbr}}
> # Setting {{nofile}} ulimits properly and {{fs.file-max}}
> # Potentially raising {{vm.max_map_count}} even higher than the default 
> debian package does
> # Using raid instead of jbod
> # Mounting /tmp on a tmpfs and turning back on {{PerfDisableSharedMem}}
> And many more ... I think many of the recommendations from [Amy 
> Tobey's|https://tobert.github.io/pages/als-cassandra-21-tuning-guide.html] 
> 2.1 guide may still be pretty relevant.
> Perhaps we can document some of these in the website's Operations section?



--
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-14774) Upgrade of snappy java and JNA

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14774:
-
Component/s: (was: Build)
 Dependencies

> Upgrade of snappy java and JNA
> --
>
> Key: CASSANDRA-14774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14774
> Project: Cassandra
>  Issue Type: Wish
>  Components: Dependencies
> Environment: Ubuntu, RHEL
>Reporter: Nayana Thorat
>Priority: Critical
> Fix For: 3.11.x
>
>
> We are building Apache Cassandra for s390x. We have observed that current 
> latest version 3.11.3 has snappy java 1.1.1.7 and JNA 4.2.2.
> However these versions doesn't have s390x support. s390x support is available 
> in JNA 4.5.0 and snappy-java 1.1.2.6
> Is it possible to upgrade JNA from 4.2.2. to 4.5.0?
> Also the snappy from 1.1.1.7 to 1.1.2.6?
> Please let us know if you need more info.
>  
>  
>  



--
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-14982) PicklingError: Can't pickle : attribute lookup cqlshlib.copyutil.ImmutableDict failed

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14982:
--

Hi [~vaclavt], it looks like the size of the batch generated via your cqlsh 
import is exceeding the max batch size configured in Cassandra. This is 
controlled in cqlsh via MAXBATCHSIZE=x, and in cassandra.yaml via 
batch_size_fail_threshold_in_kb.

To address this you can either specify a MAXBATCHSIZE in cqlsh by adding a low 
limit such as "and MAXBATCHSIZE=10" to your COPY command, or via increasing the 
max batch size server-side with batch_size_fail_threshold_in_kb to a value that 
exceeds what would be imported by cqlsh on a per-batch basis.

Point taken re: the PicklingError and exit-0 status that's returned; thanks for 
filing this.

> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> --
>
> Key: CASSANDRA-14982
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14982
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
> Environment: cqlsh --version
> cqlsh 5.0.1
>  
>Reporter: Vaclav
>Priority: Major
> Fix For: 3.11.3
>
>
> Hello
> I am trying to load records from file containing some very long lines (up to 
> 180_000 characters). In some cases order of lines in file causes error
> 'Error from server: code=2200 [Invalid query] message="Batch too large"' 
> catched and printed in copyutils.py, class SendingChanel in method feed(), 
> but error is just printed, records are not loaded, no error file with 
> unimported rows is created and import continues. cqlsh at the end returns 
> code 0 even not all rows are imported. Even that number of imported rows is 
> wrong, it shows number of records in file but in fact it loaded less records. 
> So I cannot be sure, based on returned code, that copy command did load all 
> rows. My problem is that in this case only way to find something went wrong 
> and data are not loaded correctly is to watch for error message on screen, 
> which is problem when this happens in very long import script (script loading 
> many tables).
> I think when not all rows are loaded correctly return code should not be 0, 
> or when records aren't loaded it should exit with error immediatelly.
> $ cqlsh 127.0.0.1 --request-timeout="3600" -e "copy woc.item_container from 
> '/tmp/cexport/woc/item_container.csv' with escape='\"' and null=null and 
> header=True"
> Reading options from the command line: \{'header': 'True', 'null': 'null', 
> 'escape': '"'}
> Using 7 child processes
> Starting copy of woc.item_container with columns [container_id, capacity, 
> classes, instances, owner_id, type].
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle : 
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> Processed: 38420 rows; Rate: 7455 rows/s; Avg. rate: 6881 rows/s
> 38420 rows imported from 1 files in 5.584 seconds (0 skipped).
> $ echo $?
> 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-14941) Expired secondary index sstables are not promptly discarded under TWCS

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14941:
-
Reproduced In: 3.0.17

> Expired secondary index sstables are not promptly discarded under TWCS
> --
>
> Key: CASSANDRA-14941
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14941
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/2i Index
>Reporter: Samuel Klock
>Priority: Major
>
> We have a table in a cluster running 3.0.17 storing roughly time-series data 
> using TWCS with a secondary index. We've noticed that while expired sstables 
> for the table are discarded mostly when we expect them to be, the expired 
> sstables for the secondary index would linger for weeks longer than expected 
> – essentially indefinitely. Eventually the sstables would fill disks, which 
> would require manual steps (deleting ancient index sstables) to address. We 
> verified with {{sstableexpiredblockers}} that there wasn't anything on disk 
> blocking the expired sstables from being dropped, so this looks like a bug.
> Through some debugging, we traced the problem to the index's memtables, which 
> were consistently (except _just_ after node restarts) reporting a minimum 
> timestamp from September 2015 – much older than any of our live data – which 
> causes {{CompactionController.getFullyExpiredSSTables()}} to consistently 
> return an empty set. The reason that the index sstables report this minimum 
> timestamp is because of how index updates are created, using 
> {{PartitionUpdate.singleRowUpdate()}}:
> {code:java}
> public static PartitionUpdate singleRowUpdate(CFMetaData metadata, 
> DecoratedKey key, Row row, Row staticRow)
> {
> MutableDeletionInfo deletionInfo = MutableDeletionInfo.live();
> Holder holder = new Holder(
> new PartitionColumns(
> staticRow == null ? Columns.NONE : 
> Columns.from(staticRow.columns()),
> row == null ? Columns.NONE : Columns.from(row.columns())
> ),
> row == null ? BTree.empty() : BTree.singleton(row),
> deletionInfo,
> staticRow == null ? Rows.EMPTY_STATIC_ROW : staticRow,
> EncodingStats.NO_STATS
> );
> return new PartitionUpdate(metadata, key, holder, deletionInfo, 
> false);
> }
> {code}
> The use of {{EncodingStats.NO_STATS}} makes it appear as though the earliest 
> timestamp in the resulting {{PartitionUpdate}} is from September 2015. That 
> timestamp becomes the minimum for the memtable.
> Modifying this version of {{PartitionUpdate.singleRowUpdate()}} to:
> {code:java}
> public static PartitionUpdate singleRowUpdate(CFMetaData metadata, 
> DecoratedKey key, Row row, Row staticRow)
> {
> MutableDeletionInfo deletionInfo = MutableDeletionInfo.live();
> staticRow = (staticRow == null ? Rows.EMPTY_STATIC_ROW : staticRow);
> EncodingStats stats = EncodingStats.Collector.collect(staticRow,
>   (row == null ?
>
> Collections.emptyIterator() :
>
> Iterators.singletonIterator(row)),
>   deletionInfo);
> Holder holder = new Holder(
> new PartitionColumns(
> staticRow == Rows.EMPTY_STATIC_ROW ? Columns.NONE : 
> Columns.from(staticRow.columns()),
> row == null ? Columns.NONE : Columns.from(row.columns())
> ),
> row == null ? BTree.empty() : BTree.singleton(row),
> deletionInfo,
> staticRow,
> stats
> );
> return new PartitionUpdate(metadata, key, holder, deletionInfo, 
> false);
> }
> {code}
> (i.e., computing an {{EncodingStats}} from the contents of the update) seems 
> to fix the problem. However, we're not certain whether A) there's a 
> functional reason the method was using {{EncodingStats.NO_STATS}} previously 
> or B) whether the {{EncodingStats}} the revised version creates is correct 
> (in particular, the use of {{deletionInfo}} feels a little suspect). We're 
> also not sure whether there's a more appropriate fix (e.g., changing how the 
> memtables compute the minimum timestamp, particularly in the {{NO_STATS}} 
> case).



--
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-14774) Upgrade of snappy java and JNA

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14774:
-
Priority: Minor  (was: Critical)

> Upgrade of snappy java and JNA
> --
>
> Key: CASSANDRA-14774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14774
> Project: Cassandra
>  Issue Type: Wish
>  Components: Dependencies
> Environment: Ubuntu, RHEL
>Reporter: Nayana Thorat
>Priority: Minor
> Fix For: 3.11.x
>
>
> We are building Apache Cassandra for s390x. We have observed that current 
> latest version 3.11.3 has snappy java 1.1.1.7 and JNA 4.2.2.
> However these versions doesn't have s390x support. s390x support is available 
> in JNA 4.5.0 and snappy-java 1.1.2.6
> Is it possible to upgrade JNA from 4.2.2. to 4.5.0?
> Also the snappy from 1.1.1.7 to 1.1.2.6?
> Please let us know if you need more info.
>  
>  
>  



--
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-14853) Change default timestamp format to output only milliseconds, not microseconds

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14853:
-
Component/s: (was: Dependencies)
 Tool/cqlsh

> Change default timestamp format to output only milliseconds, not microseconds
> -
>
> Key: CASSANDRA-14853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14853
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
> Environment: Reproduced in trunk
>Reporter: Alex Ott
>Priority: Major
>  Labels: cqlsh
>
> By default cqlsh outputs the timestamp column with microseconds precision, 
> like this:
> {noformat}
> cqlsh:test> create table t1(tm timestamp primary key, t text);
> cqlsh:test> insert into t1(tm, t) values(toTimestamp(now()), 't');
> cqlsh:test> insert into t1(tm, t) values(toTimestamp(now()), 't2');
> cqlsh:test> SELECT * from t1;
>  tm  | t
> -+
>  2018-10-27 18:01:54.738000+ | t2
>  2018-10-27 18:01:52.599000+ |  t
> (2 rows)
> {noformat}
> But if I want to use the value that is output on the screen in my query, I 
> get an error:
> {noformat}
> cqlsh:test> select * from t1 where tm = '2018-10-27 18:01:54.738000+';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Unable 
> to coerce '2018-10-27 18:01:54.738000+' to a formatted date (long)"
> {noformat}
> But if I manually round it to milliseconds, then everything works:
> {noformat}
> cqlsh:test> select * from t1 where tm = '2018-10-27 18:01:54.738+';
>  tm  | t
> -+
>  2018-10-27 18:01:54.738000+ | t2
> (1 rows)
> {noformat}
> It would be much easier user's experience if we use the same format for 
> output & input data, because right now this leads to errors, that often not 
> really understandable by novice users.
> P.S. I know about cqlshrc, but not every user has it configured.



--
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-14994) Incorrect repair history when running repair

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14994:
-
Component/s: Consistency/Repair

> Incorrect repair history when running repair
> 
>
> Key: CASSANDRA-14994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14994
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Marcus Olsson
>Priority: Minor
>
> Since CASSANDRA-5220 there is an issue with 
> *system_distributed.repair_history* when using virtual nodes. Performing a 
> standard "nodetool repair" will create a lot less entries than it should.
> Example:
> {code}
> $ ccm create test_repair -n 3 --vnodes -v 3.0.17
> ...
> cqlsh> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 3};
> cqlsh> CREATE TABLE test.test(key PRIMARY KEY);
> ...
> ccm node1 nodetool repair test
> ...
> cqlsh> SELECT keyspace_name, columnfamily_name, id, range_begin, range_end 
> FROM system_distributed.repair_history ;
>  keyspace_name | columnfamily_name | id   | 
> range_begin | range_end
> ---+---+--+-+-
>   test |  test | 12f27830-1e53-11e9-93a0-2122ff85bd0a | 
> 6842951316968308632 | 6844625844103123572
> {code}
> In the above example the cluster is created with 256 tokens but the repair 
> history only shows one entry.
> The problem is that in CASSANDRA-5220 a single repair session can repair 
> multiple token ranges but the insertion into the repair_history table is done 
> with the same id for all of them.



--
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-14942) cqlsh cannot describe keyspace when having table schema extensions

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14942:
-
Component/s: (was: Legacy/CQL)
 Tool/cqlsh

> cqlsh cannot describe keyspace when having table schema extensions
> --
>
> Key: CASSANDRA-14942
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14942
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/cqlsh
> Environment: Cassandra 3.11.3
> The issue comes from the cqlsh utility, in cassandra/metadata.py, function 
> _all_as_cql, viewkeys is not known. 
>  
>  
>Reporter: vincent royer
>Priority: Minor
>  Labels: cqlsh
>
> When adding a schema table extension to a table, cqlsh failed to describe 
> keyspace or table with the following error message: 'module' object has no 
> attribute 'viewkeys'
> Step to reproduce the issue:
> {{docker run --name some-cassandra -d docker.io/cassandra:3.11.3}}{{docker 
> exec -it  cqlsh < {{CREATE KEYSPACE ks WITH replication = \{'class': 'SimpleStrategy', 
> 'replication_factor': 1};}}
> {{CREATE TABLE ks.cf (id text PRIMARY KEY , a int);}}
> {{INSERT INTO system_schema.tables (keyspace_name, table_name, extensions ) 
> VALUES ( 'ks','cf',\{'key1':textAsBlob('foo')});}}
> {{EOF}}
>  
> {{docker exec -it  cqlsh -e "DESC KEYSPACE ks"}}
> {{'module' object has no attribute 'viewkeys'}}
>  
> docker exec -it c75a002959e2 cqlsh --debug -e "DESC KEYSPACE ks"
> Using CQL driver:  '/usr/share/cassandra/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/__init__.py'>
> Using connect timeout: 5 seconds
> Using 'utf-8' encoding
> Using ssl: False
> Traceback (most recent call last):
>  File "/usr/bin/cqlsh.py", line 925, in onecmd
>  self.handle_statement(st, statementtext)
>  File "/usr/bin/cqlsh.py", line 962, in handle_statement
>  return custom_handler(parsed)
>  File "/usr/bin/cqlsh.py", line 1545, in do_describe
>  self.describe_keyspace(ksname)
>  File "/usr/bin/cqlsh.py", line 1281, in describe_keyspace
>  self.print_recreate_keyspace(self.get_keyspace_meta(ksname), sys.stdout)
>  File "/usr/bin/cqlsh.py", line 1231, in print_recreate_keyspace
>  out.write(ksdef.export_as_string())
>  File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/metadata.py",
>  line 661, in export_as_string
>  + [t.export_as_string() for t in self.tables.values()])
>  File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/metadata.py",
>  line 1116, in export_as_string
>  ret = self._all_as_cql()
>  File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/metadata.py",
>  line 1135, in _all_as_cql
>  for k in six.viewkeys(registry) & self.extensions: # no viewkeys on 
> OrderedMapSerializeKey
> AttributeError: 'module' object has no attribute 'viewkeys'
>  



--
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-14984) [dtest] 2 TestBootstrap tests failed for branch 2.2

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14984:
-
Reproduced In: 2.2.14

> [dtest] 2 TestBootstrap tests failed for branch 2.2
> ---
>
> Key: CASSANDRA-14984
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14984
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest
>Reporter: Jay Zhuang
>Priority: Major
>
> Failed tests:
> {noformat}
> test_decommissioned_wiped_node_can_join
> test_decommissioned_wiped_node_can_gossip_to_single_seed
> {noformat}
> Error:
> {noformat}
> ...
> # Decommision the new node and kill it
> logger.debug("Decommissioning & stopping node2")
> >   node2.decommission()
> ...
> def handle_external_tool_process(process, cmd_args):
> out, err = process.communicate()
> if (out is not None) and isinstance(out, bytes):
> out = out.decode()
> if (err is not None) and isinstance(err, bytes):
> err = err.decode()
> rc = process.returncode
> if rc != 0:
> >   raise ToolError(cmd_args, rc, out, err)
> E   ccmlib.node.ToolError: Subprocess ['nodetool', '-h', 'localhost', 
> '-p', '7200', 'decommission'] exited with non-zero status; exit status: 2;
> E   stderr: error: Thread signal failed
> E   -- StackTrace --
> E   java.io.IOException: Thread signal failed
> {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-14998) Support "validate only" option for `nodetool import`

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14998:
-
Component/s: Tool/nodetool

> Support "validate only" option for `nodetool import`
> 
>
> Key: CASSANDRA-14998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14998
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/bulk load, Tool/nodetool
>Reporter: Doug Rohrer
>Priority: Major
>
> In order to support safer import of data (especially in the face of nodetool 
> import now taking multiple directories as input completed in 
> CASSANDRA-14442), it would be good to be able to validate said data before 
> import as it is possible one or more SSTables may somehow have been corrupted 
> during transport. I'm not sure what the preferred way forward on this (add a 
> `nodetool verify-import` or perhaps `nodetool import --verify-only` as a 
> flag) but this would allow an end-user to prevent partial imports where some 
> of the data is good, and some is corrupt.



--
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-14998) Support "validate only" option for `nodetool import`

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14998:
-
Component/s: Tool/bulk load

> Support "validate only" option for `nodetool import`
> 
>
> Key: CASSANDRA-14998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14998
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/bulk load
>Reporter: Doug Rohrer
>Priority: Major
>
> In order to support safer import of data (especially in the face of nodetool 
> import now taking multiple directories as input completed in 
> CASSANDRA-14442), it would be good to be able to validate said data before 
> import as it is possible one or more SSTables may somehow have been corrupted 
> during transport. I'm not sure what the preferred way forward on this (add a 
> `nodetool verify-import` or perhaps `nodetool import --verify-only` as a 
> flag) but this would allow an end-user to prevent partial imports where some 
> of the data is good, and some is corrupt.



--
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] [Comment Edited] (CASSANDRA-15020) Invalid CQL in documentation

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas edited comment on CASSANDRA-15020 at 2/16/19 6:50 PM:
---

Thank you for reporting this, [~lucinda]!

I've attached two small patches to fix this. One applies to trunk and the 3.11 
branch (in which the .rst docs exist), and a second patch for the Textile 
documentation used for 3.0.


was (Author: cscotta):
Thank you for reporting this, [~lucinda]!

I've attached two small patches to fix this. One applies to trunk and the 3.11 
branch (in which the .rst docs exist), and a second patch for the Textile 
documentation used for 3.0.[^CASSANDRA-15020-trunk-3.11.patch]

> Invalid CQL in documentation
> 
>
> Key: CASSANDRA-15020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15020
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Liudmila Kornilova
>Assignee: C. Scott Andreas
>Priority: Trivial
> Attachments: CASSANDRA-15020-3.0.patch, 
> CASSANDRA-15020-trunk-3.11.patch
>
>
>  [http://cassandra.apache.org/doc/4.0/cql/security.html]
> 1.
> Wrong:
> CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER;
>  CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true 
> AND SUPERUSER = true;
> Correct:
> CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
> CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = 
> true AND SUPERUSER = true; 
>  
> 2. 
>  Wrong:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> Correct:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
>  



--
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-15020) Invalid CQL in documentation

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-15020:
--

Thank you for reporting this, [~lucinda]!

I've attached two small patches to fix this. One applies to trunk and the 3.11 
branch (in which the .rst docs exist), and a second patch for the Textile 
documentation used for 3.0.[^CASSANDRA-15020-trunk-3.11.patch]

> Invalid CQL in documentation
> 
>
> Key: CASSANDRA-15020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15020
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Liudmila Kornilova
>Priority: Trivial
> Attachments: CASSANDRA-15020-3.0.patch, 
> CASSANDRA-15020-trunk-3.11.patch
>
>
>  [http://cassandra.apache.org/doc/4.0/cql/security.html]
> 1.
> Wrong:
> CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER;
>  CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true 
> AND SUPERUSER = true;
> Correct:
> CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
> CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = 
> true AND SUPERUSER = true; 
>  
> 2. 
>  Wrong:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> Correct:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
>  



--
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-15020) Invalid CQL in documentation

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15020:
-
Attachment: CASSANDRA-15020-3.0.patch
CASSANDRA-15020-trunk-3.11.patch

> Invalid CQL in documentation
> 
>
> Key: CASSANDRA-15020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15020
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Liudmila Kornilova
>Priority: Trivial
> Attachments: CASSANDRA-15020-3.0.patch, 
> CASSANDRA-15020-trunk-3.11.patch
>
>
>  [http://cassandra.apache.org/doc/4.0/cql/security.html]
> 1.
> Wrong:
> CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER;
>  CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true 
> AND SUPERUSER = true;
> Correct:
> CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
> CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = 
> true AND SUPERUSER = true; 
>  
> 2. 
>  Wrong:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> Correct:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
>  



--
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-15020) Invalid CQL in documentation

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15020:
-
Assignee: C. Scott Andreas
  Status: Patch Available  (was: Open)

> Invalid CQL in documentation
> 
>
> Key: CASSANDRA-15020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15020
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Liudmila Kornilova
>Assignee: C. Scott Andreas
>Priority: Trivial
> Attachments: CASSANDRA-15020-3.0.patch, 
> CASSANDRA-15020-trunk-3.11.patch
>
>
>  [http://cassandra.apache.org/doc/4.0/cql/security.html]
> 1.
> Wrong:
> CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER;
>  CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true 
> AND SUPERUSER = true;
> Correct:
> CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
> CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = 
> true AND SUPERUSER = true; 
>  
> 2. 
>  Wrong:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> Correct:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
>  



--
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-15005) Configurable whilelist for UDFs

2019-02-16 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-15005:
--

Thanks for reaching out! +cc'ing [~jmeredithco] for visibility, who's begun 
exploring some related work, too.

> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Minor
>
> I would like to use the UDF system to distribute some simple calculations on 
> values. For some use cases, this would require access only to some Java API 
> classes that aren't on the (hardcoded) whitelist (e.g. 
> {{java.security.MessageDigest}}). In other cases, it would require access to 
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is 
> hardcoded in java in 
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to 
> be extended via some kind of deployment-time configuration. I realize that 
> serious security concerns immediately arise for this kind of functionality, 
> but I hope that by restricting it (only used during startup, no exposing the 
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I 
> have sufficient Java skill to do that, but no real familiarity with C*'s 
> codebase, yet. :) )



--
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-15024) Don't try to cancel 2i compactions when starting anticompaction

2019-02-15 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15024:
-
Component/s: Feature/2i Index
 Consistency/Repair

> Don't try to cancel 2i compactions when starting anticompaction
> ---
>
> Key: CASSANDRA-15024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15024
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair, Feature/2i Index
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> When we start an anticompaction we cancel ongoing compactions, 
> {{runWithCompactionsDisabled}} always cancels compactions for secondary index 
> cfs:es, this causes problem since CASSANDRA-14935 since we check for range 
> intersection which will fail since 2i sstables are LocalPartitioner.



--
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] [Resolved] (CASSANDRA-14953) Failed to reclaim the memory and too many MemtableReclaimMemory pending task

2019-02-14 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas resolved CASSANDRA-14953.
--
Resolution: Information Provided

Hi Huang, as Jeremy mentioned, please reach out with this question to the 
Cassandra user's mailing list, via IRC, or StackOverflow. Details on these are 
here: https://cassandra.apache.org/community/

> Failed to reclaim the memory and too many MemtableReclaimMemory pending task
> 
>
> Key: CASSANDRA-14953
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14953
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Memtable
> Environment: version : cassandra 2.1.15
> jdk: 8
> os:suse
>Reporter: HUANG DUICAN
>Priority: Major
> Attachments: 1.PNG, 2.PNG, cassandra.yaml, cassandra_20190105.zip
>
>
> We found that Cassandra has a lot of write accumulation in the production 
> environment, and our business has experienced a lot of write failures.
>  Through the system.log, it was found that MemtableReclaimMemory was pending 
> at the beginning, and then a large number of MutationStage stacks appeared at 
> a certain moment.
>  Finally, the heap memory is full, the GC time reaches tens of seconds, the 
> node status is DN through nodetool, but the Cassandra process is still 
> running.We killed the node and restarted the node, and the above situation 
> disappeared.
>  
> Also the number of Active MemtableReclaimMemory threads seems to stay at 1.
> (you can see the 1.PNG)
> a large number of MutationStage stacks appeared at a certain moment.
> (you can see the 2.PNG)
>  
> long GC time:
>  - MemtableReclaimMemory 1 156 24565 0 0
>  - G1 Old Generation GC in 87121ms. G1 Old Gen: 51175946656 -> 50082999760;
>  - MutationStage 128 11931622 1983820772 0 0
>  - CounterMutationStage 0 0 0 0 0
>  - MemtableReclaimMemory 1 156 24565 0 0
>  - G1 Young Generation GC in {color:#FF}969ms{color}. G1 Eden Space: 
> 1090519040 -> 0; G1 Old Gen: 50082999760 -> 51156741584;
>  - MutationStage 128 11953653 1983820772 0 0
>  - CounterMutationStage 0 0 0 0 0
>  - MemtableReclaimMemory 1 156 24565 0 0
>  - G1 Old Generation GC in {color:#FF}84785ms{color}. G1 Old Gen: 
> 51173518800 -> 50180911432;
>  - MutationStage 128 11967484 1983820772 0 0
>  - CounterMutationStage 0 0 0 0 0
>  - MemtableReclaimMemory 1 156 24565 0 0
>  - G1 Young Generation GC in 611ms. G1 Eden Space: 989855744 -> 0; G1 Old 
> Gen: 50180911432 -> 51153989960;
>  - MutationStage 128 11975849 1983820772 0 0
>  - CounterMutationStage 0 0 0 0 0
>  - MemtableReclaimMemory 1 156 24565 0 0
>  - G1 Old Generation GC in {color:#FF}85845ms{color}. G1 Old Gen: 
> 51170767176 -> 50238295416;
>  - MutationStage 128 11978192 1983820772 0 0
>  - CounterMutationStage 0 0 0 0 0
>  - MemtableReclaimMemory 1 156 24565 0 0
>  - G1 Young Generation GC in 602ms. G1 Eden Space: 939524096 -> 0; G1 Old 
> Gen: 50238295416 -> 51161042296;
>  - MutationStage 128 11994295 1983820772 0 0
>  - CounterMutationStage 0 0 0 0 0
>  - MemtableReclaimMemory 1 156 24565 0 0
>  - G1 Old Generation GC in {color:#FF}85307ms{color}. G1 Old Gen: 
> 51177819512 -> 50288829624; Metaspace: 36544536 -> 36525696
>  - MutationStage 128 12001932 1983820772 0 0
>  - CounterMutationStage 0 0 0 0 0
> 66 - MutationStage 128 12004395 1983820772 0 0
> 66 - CounterMutationStage 0 0 0 0 0
>  - MemtableReclaimMemory 1 156 24565 0 0
> 66 - MemtableReclaimMemory 1 156 24565 0 0
>  - G1 Young Generation GC in 610ms. G1 Eden Space: 889192448 -> 0; G1 Old 
> Gen: 50288829624 -> 51178022072;
>  - MutationStage 128 12023677 1983820772 0 0
> Why is this happening? 



--
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-8675) COPY TO/FROM broken for newline characters

2018-12-18 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-8675:

Component/s: Tools

> COPY TO/FROM broken for newline characters
> --
>
> Key: CASSANDRA-8675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8675
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: [cqlsh 5.0.1 | Cassandra 2.1.2 | CQL spec 3.2.0 | Native 
> protocol v3]
> Ubuntu 14.04 64-bit
>Reporter: Lex Lythius
>Priority: Major
>  Labels: cqlsh
> Fix For: 2.1.3
>
> Attachments: CASSANDRA-8675.patch, copytest.csv
>
>
> Exporting/importing does not preserve contents when texts containing newline 
> (and possibly other) characters are involved:
> {code:sql}
> cqlsh:test> create table if not exists copytest (id int primary key, t text);
> cqlsh:test> insert into copytest (id, t) values (1, 'This has a newline
> ... character');
> cqlsh:test> insert into copytest (id, t) values (2, 'This has a quote " 
> character');
> cqlsh:test> insert into copytest (id, t) values (3, 'This has a fake tab \t 
> character (typed backslash, t)');
> cqlsh:test> select * from copytest;
>  id | t
> +-
>   1 |   This has a newline\ncharacter
>   2 |This has a quote " character
>   3 | This has a fake tab \t character (entered slash-t text)
> (3 rows)
> cqlsh:test> copy copytest to '/tmp/copytest.csv';
> 3 rows exported in 0.034 seconds.
> cqlsh:test> copy copytest from '/tmp/copytest.csv';
> 3 rows imported in 0.005 seconds.
> cqlsh:test> select * from copytest;
>  id | t
> +---
>   1 |  This has a newlinencharacter
>   2 |  This has a quote " character
>   3 | This has a fake tab \t character (typed backslash, t)
> (3 rows)
> {code}
> I tried replacing \n in the CSV file with \\n, which just expands to \n in 
> the table; and with an actual newline character, which fails with error since 
> it prematurely terminates the record.
> It seems backslashes are only used to take the following character as a 
> literal
> Until this is fixed, what would be the best way to refactor an old table with 
> a new, incompatible structure maintaining its content and name, since we 
> can't rename tables?



--
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-14934) Cassandra Too many open files .

2018-12-13 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14934:
--

Hi [~Krishna29],

This bug tracker is primarily used by contributors of the Apache Cassandra 
project toward development of the database itself. For operational concerns / 
questions, can you reach out to the user's list or public IRC channel for 
support? A member of the community may be able to help.

Here's a page with information on the best channels for support: 
[http://cassandra.apache.org/community/]

> Cassandra Too many open files .
> ---
>
> Key: CASSANDRA-14934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14934
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: This is in the Production environment .
> We have observed 70k open files for the process in non-prd . 
>  
> Attached the entire logs of the open files . 
>Reporter: Umashankar
>Priority: Major
>  Labels: performance
> Fix For: 3.10
>
>
> We have 4 Node with 2 DC . 
> We are seeing 
> Caused by: java.nio.file.FileSystemException: 
> /apps/cassandra/data/commitlog/CommitLog-6-1544453835569.log: Too many open 
> files .
> We have increased the ulimit to 24 k. 
> lsof | grep  
> .3.3 million records . 
>  
> Found ~ .2.5 millions of records are of TCP connection with either Socket 
> connection status as ESTABLISHED/LISTEN . Found that connections are of 
> datasource on 9042 . 
>  
> 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-14934) Cassandra Too many open files .

2018-12-13 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14934:
-
Status: Awaiting Feedback  (was: Open)

> Cassandra Too many open files .
> ---
>
> Key: CASSANDRA-14934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14934
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: This is in the Production environment .
> We have observed 70k open files for the process in non-prd . 
>  
> Attached the entire logs of the open files . 
>Reporter: Umashankar
>Assignee: Umashankar
>Priority: Major
>  Labels: performance
> Fix For: 3.10
>
>
> We have 4 Node with 2 DC . 
> We are seeing 
> Caused by: java.nio.file.FileSystemException: 
> /apps/cassandra/data/commitlog/CommitLog-6-1544453835569.log: Too many open 
> files .
> We have increased the ulimit to 24 k. 
> lsof | grep  
> .3.3 million records . 
>  
> Found ~ .2.5 millions of records are of TCP connection with either Socket 
> connection status as ESTABLISHED/LISTEN . Found that connections are of 
> datasource on 9042 . 
>  
> 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] [Assigned] (CASSANDRA-14934) Cassandra Too many open files .

2018-12-13 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas reassigned CASSANDRA-14934:


Assignee: Umashankar

> Cassandra Too many open files .
> ---
>
> Key: CASSANDRA-14934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14934
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: This is in the Production environment .
> We have observed 70k open files for the process in non-prd . 
>  
> Attached the entire logs of the open files . 
>Reporter: Umashankar
>Assignee: Umashankar
>Priority: Major
>  Labels: performance
> Fix For: 3.10
>
>
> We have 4 Node with 2 DC . 
> We are seeing 
> Caused by: java.nio.file.FileSystemException: 
> /apps/cassandra/data/commitlog/CommitLog-6-1544453835569.log: Too many open 
> files .
> We have increased the ulimit to 24 k. 
> lsof | grep  
> .3.3 million records . 
>  
> Found ~ .2.5 millions of records are of TCP connection with either Socket 
> connection status as ESTABLISHED/LISTEN . Found that connections are of 
> datasource on 9042 . 
>  
> 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] [Commented] (CASSANDRA-14932) removenode coordinator, and its hints data will be lost

2018-12-13 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14932:
--

Hi [~sunhaihong],

This bug tracker is primarily used by contributors of the Apache Cassandra 
project toward development of the database itself. For operational concerns / 
questions, can you reach out to the user's list or public IRC channel for 
support? A member of the community may be able to help.

Here's a page with information on the best channels for support: 
[http://cassandra.apache.org/community/]

> removenode coordinator, and its hints data will be lost
> ---
>
> Key: CASSANDRA-14932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14932
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra version 3.11.3
>Reporter: sunhaihong
>Priority: Major
>
> There are four nodes in cluster. assume them are node A, B, C, D. enabled 
> hinted handoff.
> 1) create a keyspace with RF=2, and create a table.
> 2) make node B, C down(nodetool stopdaemon),
> 3) login in node A with cqlsh,set CONSISTENCY ANY, insert into a row(assume 
> the row will be stored in node B and C). The row was successfully inserted 
> even though the node B,C was down, because the consistency level is ANY. the 
> coordinator(node A) wrote hints.
> 4) make node A down(nodetool stopdaemon), then remove node A(nodetool 
> removenode ${nodeA_hostId})
> 5) make node B, C come back(nodetool start)
> 6) login in any node of B, C, D. and execute select statement with partition 
> key of inserted row. But there is no any data that inserted row on step 3. 
>  
> These steps lead to data(on step 3 was inserted row) lost.
> Is there any problem with the steps I performed above? 
> If yes, How to deal with this situation?
> look forward to your reply,  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] [Assigned] (CASSANDRA-14932) removenode coordinator, and its hints data will be lost

2018-12-13 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas reassigned CASSANDRA-14932:


Assignee: sunhaihong

> removenode coordinator, and its hints data will be lost
> ---
>
> Key: CASSANDRA-14932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14932
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra version 3.11.3
>Reporter: sunhaihong
>Assignee: sunhaihong
>Priority: Major
>
> There are four nodes in cluster. assume them are node A, B, C, D. enabled 
> hinted handoff.
> 1) create a keyspace with RF=2, and create a table.
> 2) make node B, C down(nodetool stopdaemon),
> 3) login in node A with cqlsh,set CONSISTENCY ANY, insert into a row(assume 
> the row will be stored in node B and C). The row was successfully inserted 
> even though the node B,C was down, because the consistency level is ANY. the 
> coordinator(node A) wrote hints.
> 4) make node A down(nodetool stopdaemon), then remove node A(nodetool 
> removenode ${nodeA_hostId})
> 5) make node B, C come back(nodetool start)
> 6) login in any node of B, C, D. and execute select statement with partition 
> key of inserted row. But there is no any data that inserted row on step 3. 
>  
> These steps lead to data(on step 3 was inserted row) lost.
> Is there any problem with the steps I performed above? 
> If yes, How to deal with this situation?
> look forward to your reply,  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] [Commented] (CASSANDRA-14927) During data migration from 7 node to 21 node cluster using sstableloader, new data is being populated on the new tables & data is being duplicated on user type tab

2018-12-11 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14927:
--

Hi [~K-Test], thank you for your report. This bug tracker is primarily used by 
contributors of the Apache Cassandra project toward development of the database 
itself. For operational concerns / questions, can you reach out to the user's 
list or public IRC channel for support? A member of the community may be able 
to help.

Here's a page with information on the best channels for support: 
[http://cassandra.apache.org/community/]

> During data migration from 7 node to 21 node cluster using sstableloader, new 
> data is being populated on the new tables & data is being duplicated on user 
> type tables 
> ---
>
> Key: CASSANDRA-14927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14927
> Project: Cassandra
>  Issue Type: Test
>Reporter: KALYAN CHAKRAVARTHY KANCHARLA
>Priority: Blocker
>  Labels: test
> Fix For: 2.1.13
>
>
> I'm trying to migrate data from 7 node (single DC) cluster to a 21 node (3 
> DC) cluster using sstableloader.
> We have same versions on both old and new clusters.
> *cqlsh 5.0.1* 
>  *Cassandra 2.1.13* 
>  *CQL spec 3.2.1* 
> Old and New clusters are in different networks. So we opened the following 
> ports between them.
> 7000- storage port
> 7001- ssl storage port
> 7199- JMX port
> 9042- client port
> 9160- Thrift client port
> We use vnodes in the clusters.
> We made sure cassandra.yaml file on the new cluster is set correct by 
> changing following options,
>  
> {{cluster_name: 'MyCassandraCluster' }}
> {{num_tokens: 256 }}
> {{seed_provider: - }}
> {{class_name: org.apache.cassandra.locator.SimpleSeedProvider }}
> {{parameters: - }}
> {{seeds: "10.168.66.41,10.176.170.59" }}
> {{listen_address: localhost}}
> {{endpoint_snitch: GossipingPropertyFileSnitch}}
> And also changes in cassaandra-rackdc-properties for each DC by specifying 
> respective DC and rack.
> while creating keyspaces, changed Replication to NetworkTopologyStratagy.
>  
> cluster looks healthy, all the node are UP and NORMAL. 
>  
> {color:#FF}*I was able to get the data from old cluster to new cluster. 
> But, along with the data from old cluster, I see some new rows being 
> populated in the tables on new cluster and data is being duplicated in the 
> tables with user type*. {color}
> {color:#33}We have used the following steps to migrate data:{color}
>  # Took snapshorts for all the keyspaces that we want to migrate. (9 
> keyspaces). Used the _nodetool snapshot_ command on source nodes to take 
> snapshot of required keyspace/table by specifying _hostname, jmx port_ and 
> _keyspace_
>  __ 
> _/a/cassandra/bin/nodetool -u $(sudo su - company -c "cat 
> /a/cassandra/jmxremote.password" | awk '\{print $1}') -pw $(sudo su - company 
> -c "cat /a/cassandra/jmxremote.password" | awk '\{print $2}')_  *_-h 
> localhost -p 7199 snapshot keyspace_name_*
>  # After taking snapshots, move these snapshot directory from source nodes to 
> target node.
>        
> → Create a tar file on source node for the snapshot directory that we want to 
> move on to target node.
>      tar -cvf file.tar snapshot_name
> → Move this file.tar from source node to local machine.
>      scp -S gwsh root@192.168.64.99:/a/cassandra/data/file.tar .
> → Now move this file.tar from local machine to a new directory(example: test) 
> in the target node.
>     scp -S gwsh file.tar root@192.168.58.41:/a/cassandra/data/test/.
>  # Now untar this file.tar in test directory in target node.
>  # The path of the sstables must be same in both source and target.
>  # To bulk load these files using _sstableloader,run sstableloader on source 
> node, indicate one or more nodes in the destination Cluster with -d flag, 
> which can accept comma-separated list of IP addresses or hostnames, and 
> specify the path to  sstables in the source node._ __ 
> _/a/Cassandra/bin/_ *_./sstableloader -d host_IP path_to_sstables_*
>           *_Example:_*
> [/a/cassandra/bin#|mailto:root@sqa-cassandra03.sqaextranet:/a/cassandra/bin] 
> sstableloader -d 192.168.58.41 -u popps -pw *** -tf 
> org.apache.cassandra.thrift.SSLTransportFactory -ts 
> /a/cassandra/ssl/truststore.jks -tspw test123 -ks 
> /a/cassandra/ssl/keystore.jks -kspw test123 -f 
> /a/cassandra/conf/cassandra.yaml 
> /a/cassandra/data/app_properties/_admins-58524140431511e8bbb6357f562e11ca_/ 
> Summary statistics:
>  Connections per host: : 1
>  Total files transferred: : 9
>  Total bytes transferred: : 1787893
>  Total duration (ms): : 2936
>  Average transfer rate 

[jira] [Resolved] (CASSANDRA-14923) Java8 forEach cannot be used in UDF

2018-12-10 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas resolved CASSANDRA-14923.
--
Resolution: Duplicate

> Java8 forEach cannot be used in UDF
> ---
>
> Key: CASSANDRA-14923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14923
> Project: Cassandra
>  Issue Type: Bug
> Environment: FreeBSD 11.2
> Cassandra 3.11.3
> OpenJDK 8.181.13
>Reporter: Lapo Luchini
>Priority: Major
>
> I get the following error:
> {noformat}
> cqlsh:test> CREATE OR REPLACE FUNCTION sumMap (state map, val 
> map)
>  ... RETURNS NULL ON NULL INPUT
>  ... RETURNS map
>  ... LANGUAGE java AS
>  ... $$
>  ... val.forEach((k, v) -> {
>  ... Integer cur = state.get(k);
>  ... state.put(k, (cur == null) ? v : cur + v);
>  ... });
>  ... return state;
>  ... $$;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Java 
> source compilation failed:
> Line 2: The type java.util.function.BiConsumer cannot be resolved. It is 
> indirectly referenced from required .class files
> Line 2: The method forEach(BiConsumer) from 
> the type Map refers to the missing type BiConsumer
> Line 2: The target type of this expression must be a functional interface
> "
> {noformat}
> on the other hand, this compiles correctly:
> {noformat}
> CREATE OR REPLACE FUNCTION sumMap (state map, val map)
> RETURNS NULL ON NULL INPUT
> RETURNS map
> LANGUAGE java AS
> $$
> for (Map.Entry e : val.entrySet()) {
> String k = e.getKey();
> Integer v = e.getValue();
> Integer cur = state.get(k);
> state.put(k, (cur == null) ? v : cur + v);
> };
> return state;
> $$;
> {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] [Commented] (CASSANDRA-14923) Java8 forEach cannot be used in UDF

2018-12-10 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14923:
--

Thanks for filing, [~l...@lapo.it]! This is tracked under 
[CASSANDRA-11052|https://issues.apache.org/jira/browse/CASSANDRA-11052].

> Java8 forEach cannot be used in UDF
> ---
>
> Key: CASSANDRA-14923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14923
> Project: Cassandra
>  Issue Type: Bug
> Environment: FreeBSD 11.2
> Cassandra 3.11.3
> OpenJDK 8.181.13
>Reporter: Lapo Luchini
>Priority: Major
>
> I get the following error:
> {noformat}
> cqlsh:test> CREATE OR REPLACE FUNCTION sumMap (state map, val 
> map)
>  ... RETURNS NULL ON NULL INPUT
>  ... RETURNS map
>  ... LANGUAGE java AS
>  ... $$
>  ... val.forEach((k, v) -> {
>  ... Integer cur = state.get(k);
>  ... state.put(k, (cur == null) ? v : cur + v);
>  ... });
>  ... return state;
>  ... $$;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Java 
> source compilation failed:
> Line 2: The type java.util.function.BiConsumer cannot be resolved. It is 
> indirectly referenced from required .class files
> Line 2: The method forEach(BiConsumer) from 
> the type Map refers to the missing type BiConsumer
> Line 2: The target type of this expression must be a functional interface
> "
> {noformat}
> on the other hand, this compiles correctly:
> {noformat}
> CREATE OR REPLACE FUNCTION sumMap (state map, val map)
> RETURNS NULL ON NULL INPUT
> RETURNS map
> LANGUAGE java AS
> $$
> for (Map.Entry e : val.entrySet()) {
> String k = e.getKey();
> Integer v = e.getValue();
> Integer cur = state.get(k);
> state.put(k, (cur == null) ? v : cur + v);
> };
> return state;
> $$;
> {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] [Commented] (CASSANDRA-14924) Cassandra nodes becomes unreachable to each other

2018-12-10 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14924:
--

Hi [~venksta], thanks for your report. This bug tracker is primarily used by 
contributors of the Apache Cassandra project toward development of the database 
itself. Can you reach out to the user's list or public IRC channel for support? 
A member of the community may be able to help.

Here's a page with information on the best channels for support: 
http://cassandra.apache.org/community/

> Cassandra nodes becomes unreachable to each other
> -
>
> Key: CASSANDRA-14924
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14924
> Project: Cassandra
>  Issue Type: Bug
>Reporter: ventsislav
>Priority: Critical
>
> I have 3 nodes of elassandra running in docker containers.
> Containers created like:
> {code:java}
> > Host 10.0.0.1 : docker run --name elassandra-node-1 --net=host -e 
> > CASSANDRA_SEEDS="10.0.0.1" -e CASSANDRA_CLUSTER_NAME="BD Storage" -e 
> > CASSANDRA_DC="DC1" -e CASSANDRA_RACK="r1" -d 
> > strapdata/elassandra:latest{code}
> {code:java}
> > Host 10.0.0.2 : docker run --name elassandra-node-2 --net=host -e 
> > CASSANDRA_SEEDS="10.0.0.1,10.0.0.2" -e CASSANDRA_CLUSTER_NAME="BD Storage" 
> > -e CASSANDRA_DC="DC1" -e CASSANDRA_RACK="r1" -d 
> > strapdata/elassandra:latest{code}
> {code:java}
> > Host 10.0.0.3 : docker run --name elassandra-node-3 --net=host -e 
> > CASSANDRA_SEEDS="10.0.0.1,10.0.0.2,10.0.0.3" -e CASSANDRA_CLUSTER_NAME="BD 
> > Storage" -e CASSANDRA_DC="DC1" -e CASSANDRA_RACK="r1" -d 
> > strapdata/elassandra:latest{code}
> Cluster was working fine for a couple of days since created, elastic, 
> cassandra all was perfect.
> Currently however all cassandra nodes became unreachable to each other:
>  Nodetool status on all nodes is like
> {code:java}
> > Datacenter: DC1
>  > ===
>  > Status=Up/Down
>  > |/ State=Normal/Leaving/Joining/Moving
>  > – Address Load Tokens Owns (effective) Host ID Rack
>  > DN 10.0.0.3 11.95 GiB 8 100.0% 7652f66e-194e-4886-ac10-0fc21ac8afeb r1
>  > DN 10.0.0.2 11.92 GiB 8 100.0% b91fa129-1dd0-4cf8-be96-9c06b23daac6 r1
>  > UN 10.0.0.1 11.9 GiB 8 100.0% 5c1afcff-b0aa-4985-a3cc-7f932056c08f r1{code}
> Where the UN is the current host 10.0.0.1
>  Same on all other nodes.
> Nodetool describecluster on 10.0.0.1 is like
> {code:java}
> > Cluster Information:
>  > Name: BD Storage
>  > Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
>  > DynamicEndPointSnitch: enabled
>  > Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>  > Schema versions:
>  > 24fa5e55-3935-3c0e-9808-99ce502fe98d: [10.0.0.1]
>  > 
>  > UNREACHABLE: [10.0.0.2,10.0.0.3]{code}
> When attached to the first node its only repeating these infos:
> {code:java}
> > 2018-12-09 07:47:32,927 WARN [OptionalTasks:1] 
> > org.apache.cassandra.auth.CassandraRoleManager.setupDefaultRole(CassandraRoleManager.java:361)
> >  CassandraRoleManager skipped default role setup: some nodes were not ready
>  > 2018-12-09 07:47:32,927 INFO [OptionalTasks:1] 
> org.apache.cassandra.auth.CassandraRoleManager$4.run(CassandraRoleManager.java:400)
>  Setup task failed with error, rescheduling
>  > 2018-12-09 07:47:32,980 INFO [HANDSHAKE-/10.0.0.2] 
> org.apache.cassandra.net.OutboundTcpConnection.lambda$handshakeVersion$1(OutboundTcpConnection.java:561)
>  Handshaking version with /10.0.0.2
>  > 2018-12-09 07:47:32,980 INFO [HANDSHAKE-/10.0.0.3] 
> org.apache.cassandra.net.OutboundTcpConnection.lambda$handshakeVersion$1(OutboundTcpConnection.java:561)
>  Handshaking version with /10.0.0.3{code}
> After a while when some node is restarted:
> {code:java}
> > 2018-12-09 07:52:21,972 WARN [MigrationStage:1] 
> > org.apache.cassandra.service.MigrationTask.runMayThrow(MigrationTask.java:67)
> >  Can't send schema pull request: node /10.0.0.2 is down.{code}
> Tried so far:
>  Restarting all containers at the same time
>  Restarting all containers one after another
>  Restarting cassandra in all containers like : service cassandra restart
>  Nodetool disablegossip then enable it
>  Nodetool repair : Repair command #1 failed with error Endpoint not alive: 
> /10.0.0.2
> Seems that all node schemas are different, but I still dont understand why 
> they are marked as down to each other.



--
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-14812) Multiget Thrift query returns null records after digest mismatch

2018-12-07 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14812:
--

Thanks! Reassuring to see that CQL is not impacted here.

> Multiget Thrift query returns null records after digest mismatch
> 
>
> Key: CASSANDRA-14812
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14812
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination, Core
>Reporter: Sivukhin Nikita
>Assignee: Benedict
>Priority: Critical
> Fix For: 3.0.18
>
> Attachments: repro_script.py, requirements.txt, small_repro_script.py
>
>
> It seems that in Cassandra 3.0.0 a nasty bug was introduced in {{multiget}} 
> Thrift query processing logic. When one tries to read data from several 
> partitions with a single {{multiget}} query and {{DigestMismatch}} exception 
> is raised during this query processing, request coordinator prematurely 
> terminates response stream right at the point where the first 
> \{{DigestMismatch}} error is occurring. This leads to situation where clients 
> "do not see" some data contained in the database.
> We managed to reproduce this bug in all versions of Cassandra starting with 
> v3.0.0. The pre-release version 3.0.0-rc2 works correctly. It looks like 
> [refactoring of iterator transformation 
> hierarchy|https://github.com/apache/cassandra/commit/609497471441273367013c09a1e0e1c990726ec7]
>  related to CASSANDRA-9975 triggers incorrect behaviour.
> When concatenated iterator is returned from the 
> [StorageProxy.fetchRows(...)|https://github.com/apache/cassandra/blob/a05785d82c621c9cd04d8a064c38fd2012ef981c/src/java/org/apache/cassandra/service/StorageProxy.java#L1770],
>  Cassandra starts to consume this combined iterator. Because of 
> {{DigestMismatch}} exception some elements of this combined iterator contain 
> additional {{ThriftCounter}}, that was added during 
> [DataResolver.resolve(...)|https://github.com/apache/cassandra/blob/ee9e06b5a75c0be954694b191ea4170456015b98/src/java/org/apache/cassandra/service/reads/DataResolver.java#L120]
>  execution. While consuming iterator for many partitions Cassandra calls 
> [BaseIterator.tryGetMoreContents(...)|https://github.com/apache/cassandra/blob/a05785d82c621c9cd04d8a064c38fd2012ef981c/src/java/org/apache/cassandra/db/transform/BaseIterator.java#L115]
>  method that must switch from one partition iterator to another in case of 
> exhaustion of the former. In this case all Transformations contained in the 
> next iterator are applied to the combined BaseIterator that enumerates 
> partitions sequence which is wrong. This behaviour causes BaseIterator to 
> stop enumeration after it fully consumes partition with {{DigestMismatch}} 
> error, because this partition iterator has additional {{ThriftCounter}} data 
> limit.
> The attachment contains the python2 script [^small_repro_script.py] that 
> reproduces this bug within 3-nodes ccmlib controlled cluster. Also, there is 
> an extended version of this script - [^repro_script.py] - that contains more 
> logging information and provides the ability to test behavior for many 
> Cassandra versions (to run all test cases from repro_script.py you can call 
> {{python -m unittest2 -v repro_script.ThriftMultigetTestCase}}). All the 
> necessary dependencies contained in the [^requirements.txt]
>  
> This bug is critical in our production environment because we can't permit 
> any data skip.
> Any ideas about a patch for this issue?



--
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-14918) multiget_slice returning inconsistent results when performed with CL higher than ONE

2018-12-03 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14918:
-
Component/s: Coordination

> multiget_slice returning inconsistent results when performed with CL higher 
> than ONE
> 
>
> Key: CASSANDRA-14918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14918
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
> Environment: 9 node ring, cassandra 3.11.2, RF of 3.
> Ring is not upgraded from any previous version.
>Reporter: Jason Harvey
>Priority: Major
>
> I'm on cassandra 3.11.2. On a number of CFs I'm observing that multiget_slice 
> sometimes returns inconsistent, partially-empty results for the exact same 
> request, despite the underlying data not changing. This behaviour is only 
> observed when I perform the multiget with a CL higher than `ONE` - all `ONE` 
> requests work as expected.
> I was able to create a test table in a lab environment and after fiddling 
> with the data enough was able to repro. I was unable to perform a very basic 
> repro with only a few rows present. To repro, I inserted a couple million 
> rows, deleted a subset of those rows, and the performed a multiget slice on a 
> list of partitions which included living and deleted partitions. The result 
> is that sometimes, when performing a multiget on this data, I get a thrift 
> struct back with partition info, but no column names or values - the thrift 
> LIST that is generated contains 0 elements. If I issue this exact same 
> request 5 times I might get the appropriate data back once or twice. I have 
> verified on the wire that the request being made is identical - only the 
> results are different.
> The repro case described above is rather meandering so I'm working to break 
> it down into a simple of a case as I can. It is unclear if deletions need to 
> occur to reproduce this or not.
> Edit: Just confirmed I'm observing this behaviour on multiple distinct 3.11.2 
> rings.



--
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-14918) multiget_slice returning inconsistent results when performed with CL higher than ONE

2018-12-03 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14918:
--

[~alienth] Thanks for reporting; this looks very similar to CASSANDRA-14812 
(currently in flight). Can you take a look at discussion on that issue and 
confirm?

> multiget_slice returning inconsistent results when performed with CL higher 
> than ONE
> 
>
> Key: CASSANDRA-14918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14918
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
> Environment: 9 node ring, cassandra 3.11.2.
> Ring is not upgraded from any previous version.
>Reporter: Jason Harvey
>Priority: Major
>
> I'm on cassandra 3.11.2. On a number of CFs I'm observing that multiget_slice 
> sometimes returns inconsistent, partially-empty results for the exact same 
> request, despite the underlying data not changing. This behaviour is only 
> observed when I perform the multiget with a CL higher than `ONE` - all `ONE` 
> requests work as expected.
> I was able to create a test table in a lab environment and after fiddling 
> with the data enough was able to repro. I was unable to perform a very basic 
> repro with only a few rows present. To repro, I inserted a couple million 
> rows, deleted a subset of those rows, and the performed a multiget slice on a 
> list of partitions which included living and deleted partitions. The result 
> is that sometimes, when performing a multiget on this data, I get a thrift 
> struct back with partition info, but no column names or values - the thrift 
> LIST that is generated contains 0 elements. If I issue this exact same 
> request 5 times I might get the appropriate data back once or twice. I have 
> verified on the wire that the request being made is identical - only the 
> results are different.
> The repro case described above is rather meandering so I'm working to break 
> it down into a simple of a case as I can. It is unclear if deletions need to 
> occur to reproduce this or not.
> Edit: Just confirmed I'm observing this behaviour on multiple distinct 3.11.2 
> rings.



--
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-14915) Handle ant-optional dependency

2018-11-30 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14915:
-
Component/s: Build

> Handle ant-optional dependency
> --
>
> Key: CASSANDRA-14915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14915
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> CASSANDRA-13117 added a JUnit task which dumps threads on unit test timeout, 
> and it depends on a class in {{org.apache.tools.ant.taskdefs.optional}} which 
> seems to not always be present depending on how {{ant}} was installed. It can 
> cause this error when building;
> {code:java}
> Throws: cassandra-trunk/build.xml:1134: taskdef A class needed by class 
> org.krummas.junit.JStackJUnitTask cannot be found:
> org/apache/tools/ant/taskdefs/optional/junit/JUnitTask  using the classloader
> AntClassLoader[/.../cassandra-trunk/lib/jstackjunit-0.0.1.jar]
> {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-14914) Deserialization Error

2018-11-28 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14914:
-
Component/s: Core

> Deserialization Error
> -
>
> Key: CASSANDRA-14914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14914
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: I use cassandra 3.9, but I tried to upgrade to 3.11 and 
> nothing has changed.
>Reporter: EDSON VICENTE CARLI JUNIOR
>Priority: Critical
> Fix For: 3.11.x
>
> Attachments: mutation4465429258841992355dat
>
>
>  
>  I have a single cassandra, now this error appears when I start the server:
> {code:java}
> ERROR 11:18:45 Exiting due to error while processing commit log during 
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
>  Unexpected error deserializing mutation; saved to 
> /tmp/mutation4787806670239768067dat.  This may be caused by replaying a 
> mutation against a table with the same name but incompatible schema.  
> Exception follows: org.apache.cassandra.serializers.MarshalException: A local 
> deletion time should not be negative
> {code}
> If I delete all the commitlog and saved_cached files the server goes up, but 
> the next day when I reboot the cassandra, the error occurs again.
> The file mutationDDdat change name for each restart. I attachament a 
> example mutation file .
> What's wrong? How to make cassandra stable again?
>  



--
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-14908) Deadlock occurs when executing a file selection in levelcompact

2018-11-23 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14908:
-
Component/s: Compaction

> Deadlock occurs when executing a file selection in levelcompact
> ---
>
> Key: CASSANDRA-14908
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14908
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: version : cassandra 2.1.15
> jdk: 8
> os:suse
>Reporter: wu taiyin
>Priority: Major
> Attachments: deadlock stack.txt
>
>
>  detailed exception stack as follows: 
> "CompactionExecutor:33616" #142049 daemon prio=1 os_prio=4 
> tid=0x7f73244cc000 nid=0x1919a waiting for monitor entry 
> [0x7fa94e13b000]
>  java.lang.Thread.State: {color:#FF}BLOCKED{color} (on object monitor)
>  at 
> org.apache.cassandra.db.compaction.WrappingCompactionStrategy.handleNotification(WrappingCompactionStrategy.java:265)
>  - waiting to lock <0x7faa776209b0> (a 
> org.apache.cassandra.db.compaction.WrappingCompactionStrategy)
>  at 
> org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:517)
>  at org.apache.cassandra.db.DataTracker.replaceReaders(DataTracker.java:408)
>  at 
> org.apache.cassandra.db.DataTracker.replaceWithNewInstances(DataTracker.java:305)
>  at 
> org.apache.cassandra.io.sstable.SSTableRewriter.moveStarts(SSTableRewriter.java:337)
>  at 
> org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:187)
>  at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
>  at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
>  at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>  at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:264)
>  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>  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)
> "CompactionExecutor:33615" #142048 daemon prio=1 os_prio=4 
> tid=0x7f7324451800 nid=0x19199 runnable [0x7fa7a096f000]
>  java.lang.Thread.State: RUNNABLE
>  at java.util.HashMap.hash(HashMap.java:338)
>  at java.util.HashMap.put(HashMap.java:611)
>  at java.util.HashSet.add(HashSet.java:219)
>  at java.util.AbstractCollection.addAll(AbstractCollection.java:344)
>  at java.util.HashSet.(HashSet.java:119)
>  at com.google.common.collect.Sets.newHashSet(Sets.java:218)
>  at 
> {color:#FF}org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:307){color}
> {color:#FF} - locked <0x7faa77620e70> (a 
> org.apache.cassandra.db.compaction.LeveledManifest){color}
> {color:#FF} at{color} 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getMaximalTask(LeveledCompactionStrategy.java:101)
>  at 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:90)
>  - locked <0x7faa77620e30> (a 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy)
>  at 
> org.apache.cassandra.db.compaction.WrappingCompactionStrategy.getNextBackgroundTask(WrappingCompactionStrategy.java:84)
>  - locked <0x7faa776209b0> (a 
> org.apache.cassandra.db.compaction.WrappingCompactionStrategy)
>  at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:258)
>  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>  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)
> "MemtableFlushWriter:22715" #142123 daemon prio=5 os_prio=0 
> tid=0x7f5a3d4ba000 nid=0x24063 waiting for monitor entry 
> [0x7fa8337bd000]
>  java.lang.Thread.State: BLOCKED (on object monitor)
>  at 
> org.apache.cassandra.db.compaction.WrappingCompactionStrategy.handleNotification(WrappingCompactionStrategy.java:265)
>  - waiting to lock <0x7faa776209b0> (a 
> org.apache.cassandra.db.compaction.WrappingCompactionStrategy)
>  at 

[jira] [Updated] (CASSANDRA-14905) if SizeEstimatesRecorder misses a 'onDropTable' notification, the size_estimates table will never be cleared for that table.

2018-11-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14905:
-
Component/s: Metrics

> if SizeEstimatesRecorder misses a 'onDropTable' notification, the 
> size_estimates table will never be cleared for that table.
> 
>
> Key: CASSANDRA-14905
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14905
> Project: Cassandra
>  Issue Type: Bug
>  Components: Metrics
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> if a node is down when a keyspace/table is dropped, it will receive the 
> schema notification before the size estimates listener is registered, so the 
> entries for the dropped keyspace/table will never be cleaned from the table. 



--
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-14906) FastByteOperations.UnsafeOperations fails to handle read only byte buffers correctly

2018-11-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14906:
-
Component/s: Core

> FastByteOperations.UnsafeOperations fails to handle read only byte buffers 
> correctly
> 
>
> Key: CASSANDRA-14906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14906
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Minor
> Fix For: 4.x
>
>
> If a buffer is read only it reports having no array, though it may well be 
> backed by an array. Code in UnsafeOperation works under the impression that a 
> buffer for which hasArray() == false is necessarily a direct buffer. Which is 
> not the case.



--
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-14904) SSTableloader doesn't understand listening for CQL connections on multiple ports

2018-11-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14904:
-
Component/s: Configuration

> SSTableloader doesn't understand listening for CQL connections on multiple 
> ports
> 
>
> Key: CASSANDRA-14904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14904
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Kurt Greaves
>Assignee: Ian Cleasby
>Priority: Minor
> Fix For: 4.0, 3.11.x
>
>
> sstableloader only searches the yaml for native_transport_port, so if 
> native_transport_port_ssl is set and encryption is enabled sstableloader will 
> fail to connect as it will use the non-SSL port for the connection.



--
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-14901) Add tests for authenticated user login audit activity

2018-11-19 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14901:
-
Component/s: Testing
 Auth

> Add tests for authenticated user login audit activity
> -
>
> Key: CASSANDRA-14901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14901
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Auth, Testing
>Reporter: Marcus Eriksson
>Assignee: Vinay Chella
>Priority: Major
> Fix For: 4.0
>
>
> missed when committing CASSANDRA-14498:
> https://github.com/vinaykumarchella/cassandra/commit/b9f9888422a4bd9f1f03ba4517e84408c036a22f



--
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] [Resolved] (CASSANDRA-13575) Snapshot fails on IndexInfo

2018-11-19 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas resolved CASSANDRA-13575.
--
Resolution: Information Provided

> Snapshot fails on IndexInfo
> ---
>
> Key: CASSANDRA-13575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13575
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Priority: Major
>
> Snapshot creation fails on IndexInfo table. This has happened in several 
> Cassandra environments.
> There is also Stratio lucene index installed 2.2.3.1. I don't know if that 
> matters.
> {code}
> [root@host1 IndexInfo-9f5c6374d48532299a0a5094af9ad1e3]# nodetool snapshot -t 
> testsnapshot
> Requested creating snapshot(s) for [all keyspaces] with snapshot name 
> [testsnapshot]
> error: Tried to hard link to file that does not exist 
> /cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/la-264-big-Filter.db
> -- StackTrace --
> java.lang.RuntimeException: Tried to hard link to file that does not exist 
> /cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/la-264-big-Filter.db
> at 
> org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:85)
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.createLinks(SSTableReader.java:1763)
> at 
> org.apache.cassandra.db.ColumnFamilyStore.snapshotWithoutFlush(ColumnFamilyStore.java:2328)
> at 
> org.apache.cassandra.db.ColumnFamilyStore.snapshot(ColumnFamilyStore.java:2453)
> at 
> org.apache.cassandra.db.ColumnFamilyStore.snapshot(ColumnFamilyStore.java:2443)
> at org.apache.cassandra.db.Keyspace.snapshot(Keyspace.java:198)
> at 
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:2604)
> at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> 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.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor31.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 
> 

  1   2   3   4   5   6   7   8   9   10   >