[jira] [Created] (CASSANDRA-18822) Blog entry for 2023 User Survey

2023-09-05 Thread Patrick McFadin (Jira) 
Patrick McFadin created CASSANDRA-18822:
---

 Summary: Blog entry for 2023 User Survey
 Key: CASSANDRA-18822
 URL: https://issues.apache.org/jira/browse/CASSANDRA-18822
 Project: Cassandra
  Issue Type: Task
  Components: Legacy/Documentation and Website
Reporter: Patrick McFadin
Assignee: Patrick McFadin


The user survey results were published as a google doc but would like to 
formalize this into a blog post with results for people to see from the web 
site. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18621) Update Cassandra logos on ASF project logos site

2023-08-08 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18621:

Component/s: Legacy/Documentation and Website

> Update Cassandra logos on ASF project logos site
> 
>
> Key: CASSANDRA-18621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18621
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Documentation and Website
>Reporter: Melissa Logan
>Assignee: Melissa Logan
>Priority: Normal
> Attachments: Cassandra_R.zip
>
>
> It appears that the Cassandra logos on the ASF project logos website are 
> outdated, as they include lowercase letters and no trademark: 
> https://www.apache.org/logos/#cassandra
> The logo currently being used on the website is this one: 
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/images/logo-white.svg
> To ensure proper usage by contributors and third parties, I propose the 
> creation of the following logo set based on the current website logo:
> Version 1 - update and create black and white versions
> Version 2- remove
> Version 3 - update and create black and white versions
> Version 4 - no change
> If these already exist somewhere, then please upload them to the ASF project 
> logos page (requires a committer): https://www.apache.org/logos/about.html
> Otherwise I will be asking our designer to create hi-res versions to be 
> uploaded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18629) BLOG - Clarify wording on 3.x EOL post

2023-06-27 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18629:

Source Control Link: 
https://github.com/apache/cassandra-website/commit/898aa3ff0d702a961f6a139eaf0562ea5ab2cce2
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> BLOG - Clarify wording on 3.x EOL post
> --
>
> Key: CASSANDRA-18629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18629
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: c18629-01-blog-index.png, c18629-02-blog-post.png
>
>
> CASSANDRA-18531 generated some confusion so attempting to clean up the 
> wording. 
> https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (CASSANDRA-18629) BLOG - Clarify wording on 3.x EOL post

2023-06-27 Thread Patrick McFadin (Jira) 


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

Patrick McFadin commented on CASSANDRA-18629:
-

Pushed to asf-site and successfully deployed 
https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html

> BLOG - Clarify wording on 3.x EOL post
> --
>
> Key: CASSANDRA-18629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18629
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: c18629-01-blog-index.png, c18629-02-blog-post.png
>
>
> CASSANDRA-18531 generated some confusion so attempting to clean up the 
> wording. 
> https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (CASSANDRA-18629) BLOG - Clarify wording on 3.x EOL post

2023-06-27 Thread Patrick McFadin (Jira) 


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

Patrick McFadin commented on CASSANDRA-18629:
-

Successfully staged 
[https://cassandra.staged.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html]

 

 

> BLOG - Clarify wording on 3.x EOL post
> --
>
> Key: CASSANDRA-18629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18629
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: c18629-01-blog-index.png, c18629-02-blog-post.png
>
>
> CASSANDRA-18531 generated some confusion so attempting to clean up the 
> wording. 
> https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18629) BLOG - Clarify wording on 3.x EOL post

2023-06-26 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18629:

Attachment: c18629-01-blog-index.png

> BLOG - Clarify wording on 3.x EOL post
> --
>
> Key: CASSANDRA-18629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18629
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: c18629-01-blog-index.png, c18629-02-blog-post.png
>
>
> CASSANDRA-18531 generated some confusion so attempting to clean up the 
> wording. 
> https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (CASSANDRA-18629) BLOG - Clarify wording on 3.x EOL post

2023-06-26 Thread Patrick McFadin (Jira) 


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

Patrick McFadin commented on CASSANDRA-18629:
-

Changes added

!c18629-01-blog-index.png!!c18629-02-blog-post.png!

> BLOG - Clarify wording on 3.x EOL post
> --
>
> Key: CASSANDRA-18629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18629
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: c18629-01-blog-index.png, c18629-02-blog-post.png
>
>
> CASSANDRA-18531 generated some confusion so attempting to clean up the 
> wording. 
> https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18629) BLOG - Clarify wording on 3.x EOL post

2023-06-26 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18629:

Attachment: c18629-02-blog-post.png

> BLOG - Clarify wording on 3.x EOL post
> --
>
> Key: CASSANDRA-18629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18629
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: c18629-01-blog-index.png, c18629-02-blog-post.png
>
>
> CASSANDRA-18531 generated some confusion so attempting to clean up the 
> wording. 
> https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Created] (CASSANDRA-18629) Clarify wording on EOL blog post

2023-06-26 Thread Patrick McFadin (Jira) 
Patrick McFadin created CASSANDRA-18629:
---

 Summary: Clarify wording on EOL blog post
 Key: CASSANDRA-18629
 URL: https://issues.apache.org/jira/browse/CASSANDRA-18629
 Project: Cassandra
  Issue Type: Task
Reporter: Patrick McFadin


CASSANDRA-18531 generated some confusion so attempting to clean up the wording. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-16 Thread Patrick McFadin (Jira) 


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

Patrick McFadin commented on CASSANDRA-18531:
-

{{➜  prod-cassandra-website git:(asf-site) git push -f origin asf-site}}
{{Total 0 (delta 0), reused 0 (delta 0), pack-reused 0}}
{{remote:}}
{{remote: GitHub found 23 vulnerabilities on apache/cassandra-website's default 
branch (5 critical, 13 high, 5 moderate). To find out more, visit:}}
{{remote:      https://github.com/apache/cassandra-website/security/dependabot}}
{{remote:}}
{{To https://github.com/apache/cassandra-website}}
{{ + 55f0cf21...55aa6e26 asf-site -> asf-site (forced update)}}

 

{{Now live on website: 
https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html}}

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch, 
> Screenshot 2023-05-15 at 8.35.24 PM.png, Screenshot 2023-05-15 at 8.35.56 
> PM.png, Screenshot 2023-05-16 at 5.28.10 PM.png
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-16 Thread Patrick McFadin (Jira) 


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

Patrick McFadin commented on CASSANDRA-18531:
-

Now in staging and reviewed: 
https://cassandra.staged.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch, 
> Screenshot 2023-05-15 at 8.35.24 PM.png, Screenshot 2023-05-15 at 8.35.56 
> PM.png, Screenshot 2023-05-16 at 5.28.10 PM.png
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-16 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18531:

Attachment: Screenshot 2023-05-16 at 5.28.10 PM.png

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch, 
> Screenshot 2023-05-15 at 8.35.24 PM.png, Screenshot 2023-05-15 at 8.35.56 
> PM.png, Screenshot 2023-05-16 at 5.28.10 PM.png
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-16 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18531:

Source Control Link: 
https://github.com/apache/cassandra-website/commit/16320f1d2977271a88334fd47f3b9d3c26816147
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch, 
> Screenshot 2023-05-15 at 8.35.24 PM.png, Screenshot 2023-05-15 at 8.35.56 
> PM.png
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-16 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18531:

Status: Ready to Commit  (was: Changes Suggested)

Changes approved

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch, 
> Screenshot 2023-05-15 at 8.35.24 PM.png, Screenshot 2023-05-15 at 8.35.56 
> PM.png
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Comment Edited] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-15 Thread Patrick McFadin (Jira) 


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

Patrick McFadin edited comment on CASSANDRA-18531 at 5/16/23 3:55 AM:
--

PR: [https://github.com/apache/cassandra-website/pull/222]

!Screenshot 2023-05-15 at 8.35.24 PM.png|width=300!

!Screenshot 2023-05-15 at 8.35.56 PM.png|width=300!
 


was (Author: patrick):
PR: https://github.com/apache/cassandra-website/pull/222

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch, 
> Screenshot 2023-05-15 at 8.35.24 PM.png, Screenshot 2023-05-15 at 8.35.56 
> PM.png
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-15 Thread Patrick McFadin (Jira) 


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

Patrick McFadin commented on CASSANDRA-18531:
-

PR: https://github.com/apache/cassandra-website/pull/222

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch, 
> Screenshot 2023-05-15 at 8.35.24 PM.png, Screenshot 2023-05-15 at 8.35.56 
> PM.png
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-15 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18531:

Attachment: Screenshot 2023-05-15 at 8.35.56 PM.png

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch, 
> Screenshot 2023-05-15 at 8.35.24 PM.png, Screenshot 2023-05-15 at 8.35.56 
> PM.png
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-15 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18531:

Attachment: Screenshot 2023-05-15 at 8.35.24 PM.png

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Fix For: NA
>
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch, 
> Screenshot 2023-05-15 at 8.35.24 PM.png, Screenshot 2023-05-15 at 8.35.56 
> PM.png
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-15 Thread Patrick McFadin (Jira) 


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

Patrick McFadin updated CASSANDRA-18531:

Attachment: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch

> BLOG - EOL Announcement for 3.x and 3.0.x
> -
>
> Key: CASSANDRA-18531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
> Project: Cassandra
>  Issue Type: Task
>Reporter: Patrick McFadin
>Assignee: Patrick McFadin
>Priority: Normal
> Attachments: 0001-Added-blog-EOL-for-versions-3.0-and-3.11.patch
>
>
> This ticket is to capture the work associated with publishing the May 2023 
> blog "Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Created] (CASSANDRA-18531) BLOG - EOL Announcement for 3.x and 3.0.x

2023-05-15 Thread Patrick McFadin (Jira) 
Patrick McFadin created CASSANDRA-18531:
---

 Summary: BLOG - EOL Announcement for 3.x and 3.0.x
 Key: CASSANDRA-18531
 URL: https://issues.apache.org/jira/browse/CASSANDRA-18531
 Project: Cassandra
  Issue Type: Task
Reporter: Patrick McFadin
Assignee: Patrick McFadin


This ticket is to capture the work associated with publishing the May 2023 blog 
"Apache Cassandra 3.0.x and 3.11.x - End of Life Announcement"



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (CASSANDRA-7622) Implement virtual tables

2018-03-13 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin commented on CASSANDRA-7622:


+1 to static tables for now. Getting just CQL support for a virtual table is 
good progress. 

> Implement virtual tables
> 
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tupshin Harper
>Assignee: Chris Lohfink
>Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any 
> table that would be backed by an API, rather than data explicitly managed and 
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a 
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml 
> configuration information. So it would be an alternate approach to 
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not 
> presupposing.



--
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] [Issue Comment Deleted] (CASSANDRA-13809) Make BatchlogManagerMBean.forceBatchlogReplay() blocking

2017-08-25 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-13809:

Comment: was deleted

(was: Placeholder reply to [~iamaleksey])

> Make BatchlogManagerMBean.forceBatchlogReplay() blocking
> 
>
> Key: CASSANDRA-13809
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13809
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 2.2.x
>
>
> In 3.0, {{BatchlogManagerMBean.forceBatchlogReplay()}} blocks until 
> completion. In 2.2 it just submits a runnable and instaexits, which makes it 
> impossible to create non-flaky dtests that rely on batchlog replay.
> [here|https://github.com/iamaleksey/cassandra/commits/13809-2.2] is a small 
> 2.2-only commit that make the behaviour consistent between 2.2 and 3.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13809) Make BatchlogManagerMBean.forceBatchlogReplay() blocking

2017-08-25 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin commented on CASSANDRA-13809:
-

Placeholder reply to [~iamaleksey]

> Make BatchlogManagerMBean.forceBatchlogReplay() blocking
> 
>
> Key: CASSANDRA-13809
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13809
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 2.2.x
>
>
> In 3.0, {{BatchlogManagerMBean.forceBatchlogReplay()}} blocks until 
> completion. In 2.2 it just submits a runnable and instaexits, which makes it 
> impossible to create non-flaky dtests that rely on batchlog replay.
> [here|https://github.com/iamaleksey/cassandra/commits/13809-2.2] is a small 
> 2.2-only commit that make the behaviour consistent between 2.2 and 3.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-11873) Add duration type

2016-06-15 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin commented on CASSANDRA-11873:
-

I am +1 on this. Making up completely new syntax is just harsh to the end user. 
No need to re-invent the wheel. 


> Add duration type
> -
>
> Key: CASSANDRA-11873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11873
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>  Labels: client-impacting, doc-impacting
> Fix For: 3.x
>
>
> For CASSANDRA-11871 or to allow queries with {{WHERE}} clause like:
> {{... WHERE reading_time < now() - 2h}}, we need to support some duration 
> type.
> In my opinion, it should be represented internally as a number of 
> microseconds.



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

[jira] [Created] (CASSANDRA-11994) Expose metrics via CQL interface

2016-06-11 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-11994:
---

 Summary: Expose metrics via CQL interface
 Key: CASSANDRA-11994
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11994
 Project: Cassandra
  Issue Type: Bug
Reporter: Patrick McFadin


This is an attempt to revive the concept introduced in CASSANDRA-3527. Instead 
of specifically targeting JMX metrics, simplify by just exposing metrics into 
CQL tables as a dynamic view. 

Exposing these metrics will give operators vital insight without resorting to 
anything more than what is installed with Apache Cassandra. 

The scope of these tickets is only for reading metrics with a SELECT command. 
The actual data model can be discussed in the comments below. 

Some basic requirements I would propose:
 - SELECT syntax should allow for single node or cluster wide statistics
 - Aggregations should be supported (min, max, avg)
 - Inside metric tables, future column additions should be automatically 
created when new metrics are added to a family
 - Large schema changes such as deletes should be postponed to a major release 





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

[jira] [Commented] (CASSANDRA-11873) Add duration type

2016-06-03 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin commented on CASSANDRA-11873:
-

+1 on _us_ instead of _µs_

I can't even figure out where to type that on my keyboard. 

> Add duration type
> -
>
> Key: CASSANDRA-11873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11873
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>  Labels: client-impacting, doc-impacting
> Fix For: 3.x
>
>
> For CASSANDRA-11871 or to allow queries with {{WHERE}} clause like:
> {{... WHERE reading_time < now() - 2h}}, we need to support some duration 
> type.
> In my opinion, it should be represented internally as a number of 
> microseconds.



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

[jira] [Commented] (CASSANDRA-9666) Provide an alternative to DTCS

2016-04-28 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin commented on CASSANDRA-9666:


Thank you [~lucasdss] for the very detailed report on your experience. I'm 
currently doing some of my own testing and I wonder if you would be willing to 
share more details. We can do this out of band in email. 

> Provide an alternative to DTCS
> --
>
> Key: CASSANDRA-9666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9666
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 2.1.x, 2.2.x
>
> Attachments: dashboard-DTCS_to_TWCS.png, dtcs-twcs-io.png, 
> dtcs-twcs-load.png
>
>
> DTCS is great for time series data, but it comes with caveats that make it 
> difficult to use in production (typical operator behaviors such as bootstrap, 
> removenode, and repair have MAJOR caveats as they relate to 
> max_sstable_age_days, and hints/read repair break the selection algorithm).
> I'm proposing an alternative, TimeWindowCompactionStrategy, that sacrifices 
> the tiered nature of DTCS in order to address some of DTCS' operational 
> shortcomings. I believe it is necessary to propose an alternative rather than 
> simply adjusting DTCS, because it fundamentally removes the tiered nature in 
> order to remove the parameter max_sstable_age_days - the result is very very 
> different, even if it is heavily inspired by DTCS. 
> Specifically, rather than creating a number of windows of ever increasing 
> sizes, this strategy allows an operator to choose the window size, compact 
> with STCS within the first window of that size, and aggressive compact down 
> to a single sstable once that window is no longer current. The window size is 
> a combination of unit (minutes, hours, days) and size (1, etc), such that an 
> operator can expect all data using a block of that size to be compacted 
> together (that is, if your unit is hours, and size is 6, you will create 
> roughly 4 sstables per day, each one containing roughly 6 hours of data). 
> The result addresses a number of the problems with 
> DateTieredCompactionStrategy:
> - At the present time, DTCS’s first window is compacted using an unusual 
> selection criteria, which prefers files with earlier timestamps, but ignores 
> sizes. In TimeWindowCompactionStrategy, the first window data will be 
> compacted with the well tested, fast, reliable STCS. All STCS options can be 
> passed to TimeWindowCompactionStrategy to configure the first window’s 
> compaction behavior.
> - HintedHandoff may put old data in new sstables, but it will have little 
> impact other than slightly reduced efficiency (sstables will cover a wider 
> range, but the old timestamps will not impact sstable selection criteria 
> during compaction)
> - ReadRepair may put old data in new sstables, but it will have little impact 
> other than slightly reduced efficiency (sstables will cover a wider range, 
> but the old timestamps will not impact sstable selection criteria during 
> compaction)
> - Small, old sstables resulting from streams of any kind will be swiftly and 
> aggressively compacted with the other sstables matching their similar 
> maxTimestamp, without causing sstables in neighboring windows to grow in size.
> - The configuration options are explicit and straightforward - the tuning 
> parameters leave little room for error. The window is set in common, easily 
> understandable terms such as “12 hours”, “1 Day”, “30 days”. The 
> minute/hour/day options are granular enough for users keeping data for hours, 
> and users keeping data for years. 
> - There is no explicitly configurable max sstable age, though sstables will 
> naturally stop compacting once new data is written in that window. 
> - Streaming operations can create sstables with old timestamps, and they'll 
> naturally be joined together with sstables in the same time bucket. This is 
> true for bootstrap/repair/sstableloader/removenode. 
> - It remains true that if old data and new data is written into the memtable 
> at the same time, the resulting sstables will be treated as if they were new 
> sstables, however, that no longer negatively impacts the compaction 
> strategy’s selection criteria for older windows. 
> Patch provided for : 
> - 2.1: https://github.com/jeffjirsa/cassandra/commits/twcs-2.1 
> - 2.2: https://github.com/jeffjirsa/cassandra/commits/twcs-2.2
> - trunk (post-8099):  https://github.com/jeffjirsa/cassandra/commits/twcs 
> Rebased, force-pushed July 18, with bug fixes for estimated pending 
> compactions and potential starvation if more than min_threshold tables 
> existed in current window but STCS did not consider them viable candidates
> Rebased, force-pushed Aug 20 to bring

[jira] [Commented] (CASSANDRA-11145) Materialized View throws error if Map type is in base table

2016-02-09 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin commented on CASSANDRA-11145:
-

I just tested it in trunk and it's still there. 

You are right, it is pretty much a dupe of CASSANDRA-11069. My Jira foo failed 
me but yours is strong!

> Materialized View throws error if Map type is in base table
> ---
>
> Key: CASSANDRA-11145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11145
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Patrick McFadin
>Priority: Critical
>
> Using the following test setup:
> {code}CREATE TABLE test (
>   a int PRIMARY KEY,
>   b text,
>   c map
> );
> CREATE MATERIALIZED VIEW test_mv AS
> SELECT a, b
> FROM test
> WHERE a IS NOT NULL AND b IS NOT NULL
> PRIMARY KEY(b, a);
> {code}
> When inserting data to the base table:
> {code}
> INSERT INTO test (a,b,c)
> VALUES(1, 'b', {'c':'c'});
> {code}
> The insert will fail and a stack trace is generated in the logs:
> {code}
> ERROR [SharedPool-Worker-2] 2016-02-10 05:25:05,957 StorageProxy.java:1339 - 
> Failed to apply mutation locally : {}
> java.lang.IllegalStateException: [ColumnDefinition{name=c, 
> type=org.apache.cassandra.db.marshal.MapType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type),
>  kind=REGULAR, position=-1}] is not a subset of []
>   at 
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:532) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.Columns$Serializer.serializedSubsetSize(Columns.java:484)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:277)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:249)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:236)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:229)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serializedSize(UnfilteredRowIteratorSerializer.java:171)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serializedSize(PartitionUpdate.java:716)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serializedSize(Mutation.java:372)
>  ~[main/:na]
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262) 
> ~[main/:na]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:498) ~[main/:na]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:399) ~[main/:na]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:202) 
> ~[main/:na]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:214) ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:748) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:149)
>  ~[main/:na]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:516) ~[main/:na]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:399) ~[main/:na]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:202) 
> ~[main/:na]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:214) ~[main/:na]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:228) ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$$Lambda$197/1675816556.run(Unknown 
> Source) ~[na:na]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1333)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2510)
>  [main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [main/:na]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> ERROR [SharedPool-Worker-2] 2016-02-10 05:26:08,687 StorageProxy.java:752 - 
> Error applying local view update to keyspace killrvideo: 
> Mutation(keyspace='killrvideo', key='62', modifications=[
>   [killrvideo.test_mv] key=b columns=[[] | [c]]
> Row: a=1 |

[jira] [Resolved] (CASSANDRA-11145) Materialized View throws error if Map type is in base table

2016-02-09 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin resolved CASSANDRA-11145.
-
   Resolution: Duplicate
Reproduced In: 3.3, 3.2  (was: 3.2, 3.3)

> Materialized View throws error if Map type is in base table
> ---
>
> Key: CASSANDRA-11145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11145
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Patrick McFadin
>Priority: Critical
>
> Using the following test setup:
> {code}CREATE TABLE test (
>   a int PRIMARY KEY,
>   b text,
>   c map
> );
> CREATE MATERIALIZED VIEW test_mv AS
> SELECT a, b
> FROM test
> WHERE a IS NOT NULL AND b IS NOT NULL
> PRIMARY KEY(b, a);
> {code}
> When inserting data to the base table:
> {code}
> INSERT INTO test (a,b,c)
> VALUES(1, 'b', {'c':'c'});
> {code}
> The insert will fail and a stack trace is generated in the logs:
> {code}
> ERROR [SharedPool-Worker-2] 2016-02-10 05:25:05,957 StorageProxy.java:1339 - 
> Failed to apply mutation locally : {}
> java.lang.IllegalStateException: [ColumnDefinition{name=c, 
> type=org.apache.cassandra.db.marshal.MapType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type),
>  kind=REGULAR, position=-1}] is not a subset of []
>   at 
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:532) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.Columns$Serializer.serializedSubsetSize(Columns.java:484)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:277)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:249)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:236)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:229)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serializedSize(UnfilteredRowIteratorSerializer.java:171)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serializedSize(PartitionUpdate.java:716)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serializedSize(Mutation.java:372)
>  ~[main/:na]
>   at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262) 
> ~[main/:na]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:498) ~[main/:na]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:399) ~[main/:na]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:202) 
> ~[main/:na]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:214) ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:748) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:149)
>  ~[main/:na]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:516) ~[main/:na]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:399) ~[main/:na]
>   at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:202) 
> ~[main/:na]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:214) ~[main/:na]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:228) ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$$Lambda$197/1675816556.run(Unknown 
> Source) ~[na:na]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1333)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2510)
>  [main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [main/:na]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> ERROR [SharedPool-Worker-2] 2016-02-10 05:26:08,687 StorageProxy.java:752 - 
> Error applying local view update to keyspace killrvideo: 
> Mutation(keyspace='killrvideo', key='62', modifications=[
>   [killrvideo.test_mv] key=b columns=[[] | [c]]
> Row: a=1 | c={}
> ])
> ERROR [SharedPool-Worker-2] 2016-02-10 05:26:08,688 Keyspace.java:521 - 
> Unknown exception caught while

[jira] [Created] (CASSANDRA-11145) Materialized View throws error if Map type is in base table

2016-02-09 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-11145:
---

 Summary: Materialized View throws error if Map type is in base 
table
 Key: CASSANDRA-11145
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11145
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Patrick McFadin
Priority: Critical


Using the following test setup:

{code}CREATE TABLE test (
  a int PRIMARY KEY,
  b text,
  c map
);

CREATE MATERIALIZED VIEW test_mv AS
SELECT a, b
FROM test
WHERE a IS NOT NULL AND b IS NOT NULL
PRIMARY KEY(b, a);
{code}

When inserting data to the base table:
{code}
INSERT INTO test (a,b,c)
VALUES(1, 'b', {'c':'c'});
{code}

The insert will fail and a stack trace is generated in the logs:

{code}
ERROR [SharedPool-Worker-2] 2016-02-10 05:25:05,957 StorageProxy.java:1339 - 
Failed to apply mutation locally : {}
java.lang.IllegalStateException: [ColumnDefinition{name=c, 
type=org.apache.cassandra.db.marshal.MapType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type),
 kind=REGULAR, position=-1}] is not a subset of []
at 
org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:532) 
~[main/:na]
at 
org.apache.cassandra.db.Columns$Serializer.serializedSubsetSize(Columns.java:484)
 ~[main/:na]
at 
org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:277)
 ~[main/:na]
at 
org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:249)
 ~[main/:na]
at 
org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:236)
 ~[main/:na]
at 
org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:229)
 ~[main/:na]
at 
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serializedSize(UnfilteredRowIteratorSerializer.java:171)
 ~[main/:na]
at 
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serializedSize(PartitionUpdate.java:716)
 ~[main/:na]
at 
org.apache.cassandra.db.Mutation$MutationSerializer.serializedSize(Mutation.java:372)
 ~[main/:na]
at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262) 
~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:498) ~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:399) ~[main/:na]
at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:202) 
~[main/:na]
at org.apache.cassandra.db.Mutation.apply(Mutation.java:214) ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:748) 
~[main/:na]
at 
org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:149)
 ~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:516) ~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:399) ~[main/:na]
at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:202) 
~[main/:na]
at org.apache.cassandra.db.Mutation.apply(Mutation.java:214) ~[main/:na]
at org.apache.cassandra.db.Mutation.apply(Mutation.java:228) ~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$$Lambda$197/1675816556.run(Unknown 
Source) ~[na:na]
at 
org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1333) 
~[main/:na]
at 
org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2510)
 [main/:na]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_45]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
 [main/:na]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
 [main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
ERROR [SharedPool-Worker-2] 2016-02-10 05:26:08,687 StorageProxy.java:752 - 
Error applying local view update to keyspace killrvideo: 
Mutation(keyspace='killrvideo', key='62', modifications=[
  [killrvideo.test_mv] key=b columns=[[] | [c]]
Row: a=1 | c={}
])
ERROR [SharedPool-Worker-2] 2016-02-10 05:26:08,688 Keyspace.java:521 - Unknown 
exception caught while attempting to update MaterializedView! killrvideo.test
java.lang.IllegalStateException: [ColumnDefinition{name=c, 
type=org.apache.cassandra.db.marshal.MapType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type),
 kind=REGULAR, position=-1}] is not a subset of []
at 
org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:532)

[jira] [Commented] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches

2015-12-23 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin commented on CASSANDRA-10876:
-

You are correct. A single partition key on one keyspace.table.  No matter how 
many statements are in the batch. 

I don't see the patch file attached. You may want to try again. 

> Alter behavior of batch WARN and fail on single partition batches
> -
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Patrick McFadin
>Priority: Minor
>
> In an attempt to give operator insight into potentially harmful batch usage, 
> Jiras were created to log WARN or fail on certain batch sizes. This ignores 
> the single partition batch, which doesn't create the same issues as a 
> multi-partition batch. 
> The proposal is to ignore size on single partition batch statements. 
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
> [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011]



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

[jira] [Commented] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches

2015-12-21 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin commented on CASSANDRA-10876:
-

[~firstprayer] if you would like to take this Jira, please feel free. 

The conclusion is that multiple mutations on a single partitions aren't the 
same type of impact as a multi-partition batch. The basic logic would be: If a 
single partition, don't warn or fail.

There is the possibility that the mutations are so large that you'll get an 
entirely new set of problems, but that's edging into a new realm of discussion. 

> Alter behavior of batch WARN and fail on single partition batches
> -
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Patrick McFadin
>Priority: Minor
>
> In an attempt to give operator insight into potentially harmful batch usage, 
> Jiras were created to log WARN or fail on certain batch sizes. This ignores 
> the single partition batch, which doesn't create the same issues as a 
> multi-partition batch. 
> The proposal is to ignore size on single partition batch statements. 
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
> [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011]



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

[jira] [Updated] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches

2015-12-16 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-10876:

Summary: Alter behavior of batch WARN and fail on single partition batches  
(was: Alter behavior of batch WARN and ERROR on single partition batches)

> Alter behavior of batch WARN and fail on single partition batches
> -
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Patrick McFadin
>Priority: Minor
>
> In an attempt to give operator insight into potentially harmful batch usage, 
> Jiras were created to log WARN or fail on certain batch sizes. This ignores 
> the single partition batch, which doesn't create the same issues as a 
> multi-partition batch. 
> The proposal is to ignore size on single partition batch statements. 
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
> [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011]



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

[jira] [Updated] (CASSANDRA-10876) Alter behavior of batch WARN and ERROR on single partition batches

2015-12-15 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-10876:

Description: 
In an attempt to give operator insight into potentially harmful batch usage, 
Jiras were created to log WARN or fail on certain batch sizes. This ignores the 
single partition batch, which doesn't create the same issues as a 
multi-partition batch. 

The proposal is to ignore size on single partition batch statements. 

Reference:
[CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
[https://issues.apache.org/jira/browse/CASSANDRA-8011]

  was:
In an attempt to give operator insight into potentially harmful batch usage, 
Jiras were created to log WARN or fail on certain batch sizes. This ignores the 
single partition batch, which doesn't create the same issues as a 
multi-partition batch. 

The proposal is to ignore size on single partition batch statements. 

Reference:
[CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]


> Alter behavior of batch WARN and ERROR on single partition batches
> --
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Patrick McFadin
>Priority: Minor
>
> In an attempt to give operator insight into potentially harmful batch usage, 
> Jiras were created to log WARN or fail on certain batch sizes. This ignores 
> the single partition batch, which doesn't create the same issues as a 
> multi-partition batch. 
> The proposal is to ignore size on single partition batch statements. 
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
> [https://issues.apache.org/jira/browse/CASSANDRA-8011]



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

[jira] [Updated] (CASSANDRA-10876) Alter behavior of batch WARN and ERROR on single partition batches

2015-12-15 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-10876:

Description: 
In an attempt to give operator insight into potentially harmful batch usage, 
Jiras were created to log WARN or fail on certain batch sizes. This ignores the 
single partition batch, which doesn't create the same issues as a 
multi-partition batch. 

The proposal is to ignore size on single partition batch statements. 

Reference:
[CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
[CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011]

  was:
In an attempt to give operator insight into potentially harmful batch usage, 
Jiras were created to log WARN or fail on certain batch sizes. This ignores the 
single partition batch, which doesn't create the same issues as a 
multi-partition batch. 

The proposal is to ignore size on single partition batch statements. 

Reference:
[CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
[https://issues.apache.org/jira/browse/CASSANDRA-8011]


> Alter behavior of batch WARN and ERROR on single partition batches
> --
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Patrick McFadin
>Priority: Minor
>
> In an attempt to give operator insight into potentially harmful batch usage, 
> Jiras were created to log WARN or fail on certain batch sizes. This ignores 
> the single partition batch, which doesn't create the same issues as a 
> multi-partition batch. 
> The proposal is to ignore size on single partition batch statements. 
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
> [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011]



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

[jira] [Commented] (CASSANDRA-6487) Log WARN on large batch sizes

2015-12-15 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin commented on CASSANDRA-6487:


[~martin.grotzke] and [~pragone] Sorry! I just caught these comments. 

Valid points on a single partition and I think it warrants a change in the way 
we log WARN and ERROR for batches. The original intent was to prevent horrible 
anti-patterns on multi-partition batches. In the case of a single partition 
update, the impact is only in network payload size. Since there is no need for 
the coordinator to track all of the mutations across the batch partitions, the 
load is much less. 

I'll make an updated ticket to reflect that difference. 

Thanks for the comments and raising this issue. 

> Log WARN on large batch sizes
> -
>
> Key: CASSANDRA-6487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6487
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Patrick McFadin
>Assignee: Lyuben Todorov
>Priority: Minor
> Fix For: 2.0.8, 2.1 beta2
>
> Attachments: 6487-cassandra-2.0.patch, 6487-cassandra-2.0_v2.patch
>
>
> Large batches on a coordinator can cause a lot of node stress. I propose 
> adding a WARN log entry if batch sizes go beyond a configurable size. This 
> will give more visibility to operators on something that can happen on the 
> developer side. 
> New yaml setting with 5k default.
> {{# Log WARN on any batch size exceeding this value. 5k by default.}}
> {{# Caution should be taken on increasing the size of this threshold as it 
> can lead to node instability.}}
> {{batch_size_warn_threshold: 5k}}



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

[jira] [Created] (CASSANDRA-10876) Alter behavior of batch WARN and ERROR on single partition batches

2015-12-15 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-10876:
---

 Summary: Alter behavior of batch WARN and ERROR on single 
partition batches
 Key: CASSANDRA-10876
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Priority: Minor


In an attempt to give operator insight into potentially harmful batch usage, 
Jiras were created to log WARN or fail on certain batch sizes. This ignores the 
single partition batch, which doesn't create the same issues as a 
multi-partition batch. 

The proposal is to ignore size on single partition batch statements. 



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

[jira] [Updated] (CASSANDRA-10876) Alter behavior of batch WARN and ERROR on single partition batches

2015-12-15 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-10876:

Description: 
In an attempt to give operator insight into potentially harmful batch usage, 
Jiras were created to log WARN or fail on certain batch sizes. This ignores the 
single partition batch, which doesn't create the same issues as a 
multi-partition batch. 

The proposal is to ignore size on single partition batch statements. 

Reference:
[CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]

  was:
In an attempt to give operator insight into potentially harmful batch usage, 
Jiras were created to log WARN or fail on certain batch sizes. This ignores the 
single partition batch, which doesn't create the same issues as a 
multi-partition batch. 

The proposal is to ignore size on single partition batch statements. 


> Alter behavior of batch WARN and ERROR on single partition batches
> --
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Patrick McFadin
>Priority: Minor
>
> In an attempt to give operator insight into potentially harmful batch usage, 
> Jiras were created to log WARN or fail on certain batch sizes. This ignores 
> the single partition batch, which doesn't create the same issues as a 
> multi-partition batch. 
> The proposal is to ignore size on single partition batch statements. 
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]



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

[jira] [Commented] (CASSANDRA-9200) Sequences

2015-07-01 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610630#comment-14610630
 ] 

Patrick McFadin commented on CASSANDRA-9200:


bq. where sequence ids are reserved per session as I am proposing here per 
coordinator. 

The more I think of use cases and potential failure modes, I'm less -1 if we 
enforce that sequences are never used in partition keys. That will eliminate a 
ton of potential mis-use and disasters. I've been through sequence hell in 
RDBMS land. Reset counters or buffer under-run can make for a long weekend. 

If the proposal is to use a sequence with a partition key, then I'm at a loss 
as to why that is useful. 

 Sequences
 -

 Key: CASSANDRA-9200
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9200
 Project: Cassandra
  Issue Type: New Feature
Reporter: Jonathan Ellis
Assignee: Robert Stupp
 Fix For: 3.x


 UUIDs are usually the right choice for surrogate keys, but sometimes 
 application constraints dictate an increasing numeric value.
 We could do this by using LWT to reserve blocks of the sequence for each 
 member of the cluster, which would eliminate paxos contention at the cost of 
 not being strictly increasing.
 PostgreSQL syntax: 
 http://www.postgresql.org/docs/9.4/static/sql-createsequence.html



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

[jira] [Commented] (CASSANDRA-9200) Sequences

2015-07-01 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610660#comment-14610660
 ] 

Patrick McFadin commented on CASSANDRA-9200:


Bugs, user error, sun spots, anything that may cause values to become 
overlapping. You get the safety of unique checks in RDBMS to stop you from 
overwriting. If I were to advise someone to use a sequence on a partition key, 
always use IF NOT EXISTS on insert. If it were a 32 bit value, what do you get 
after inserting 4 billion keys? 

If these were scoped per partition, the chance of data loss is much less. In 
addition, I can see the general usefullness of having an increasing number for 
ordering in partition without the need for something like a timeUUID or 
timestamp. 

[~tupshin] not sure if this matches with your IMAP use case. Seems like it 
would. 

 Sequences
 -

 Key: CASSANDRA-9200
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9200
 Project: Cassandra
  Issue Type: New Feature
Reporter: Jonathan Ellis
Assignee: Robert Stupp
 Fix For: 3.x


 UUIDs are usually the right choice for surrogate keys, but sometimes 
 application constraints dictate an increasing numeric value.
 We could do this by using LWT to reserve blocks of the sequence for each 
 member of the cluster, which would eliminate paxos contention at the cost of 
 not being strictly increasing.
 PostgreSQL syntax: 
 http://www.postgresql.org/docs/9.4/static/sql-createsequence.html



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

[jira] [Commented] (CASSANDRA-9200) Sequences

2015-05-18 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14548314#comment-14548314
 ] 

Patrick McFadin commented on CASSANDRA-9200:


Can somebody expound a bit on the use case dictating this change? In an RDBMS 
they are critical for unique PKs and scanning sequential records. A UUID vs a 
numeric is going to be just as random once it is hashed. Are we talking about 
the ability for a application to scan based on a sequence?

Twitter Snowflake tried to accomplish something similar with Zookeeper. I know 
there were failure modes difficult to manage and is now no longer available on 
GitHub. I can't think of any project that has done this without introducing 
very restrictive failure modes. 

 Sequences
 -

 Key: CASSANDRA-9200
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9200
 Project: Cassandra
  Issue Type: New Feature
Reporter: Jonathan Ellis
Assignee: Robert Stupp
 Fix For: 3.x


 UUIDs are usually the right choice for surrogate keys, but sometimes 
 application constraints dictate an increasing numeric value.
 We could do this by using LWT to reserve blocks of the sequence for each 
 member of the cluster, which would eliminate paxos contention at the cost of 
 not being strictly increasing.
 PostgreSQL syntax: 
 http://www.postgresql.org/docs/9.4/static/sql-createsequence.html



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

[jira] [Commented] (CASSANDRA-9193) Facility to write dynamic code to selectively trigger trace or log for queries

2015-04-28 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14518079#comment-14518079
 ] 

Patrick McFadin commented on CASSANDRA-9193:


+1 from me

 Facility to write dynamic code to selectively trigger trace or log for queries
 --

 Key: CASSANDRA-9193
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9193
 Project: Cassandra
  Issue Type: New Feature
Reporter: Matt Stump

 I want the equivalent of dtrace for Cassandra. I want the ability to 
 intercept a query with a dynamic script (assume JS) and based on logic in 
 that script trigger the statement for trace or logging. 
 Examples 
 - Trace only INSERT statements to a particular CF. 
 - Trace statements for a particular partition or consistency level.
 - Log statements that fail to reach the desired consistency for read or write.
 - Log If the request size for read or write exceeds some threshold
 At some point in the future it would be helpful to also do things such as log 
 partitions greater than X bytes or Z cells when performing compaction. 
 Essentially be able to inject custom code dynamically without a reboot to the 
 different stages of C*. 
 The code should be executed synchronously as part of the monitored task, but 
 we should provide the ability to log or execute CQL asynchronously from the 
 provided API.
 Further down the line we could use this functionality to modify/rewrite 
 requests or tasks dynamically.



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

[jira] [Commented] (CASSANDRA-9193) Facility to write dynamic code to selectively trigger trace or log for queries

2015-04-28 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14517534#comment-14517534
 ] 

Patrick McFadin commented on CASSANDRA-9193:


I'm sensing this debate shifting to more about a potential developer centric 
feature when it's almost 100% not. This is all about the operators/DBAs that 
need insight. System log and JMX mostly work in a postmortem but less so in a 
real-time diagnostic scenario. The two most important features are that it's 
expressive and complete. I don't think that negative side effect is a deal 
killer. I would even say if there wasn't any potential negative side-effects 
then it's not complete enough. If you look at the original kernel of an idea 
for this Jira, dtrace for Cassandra it holds up. Dtrace can add a lot of 
overhead. You can do horrible things to your OS. Despite of all the downsides, 
put in the hands of the right operator, dtrace can save hours of 
troubleshooting and potentially save the day.

As scary as it might be, this seems to me like a step in the right direction 
for product maturity.

 Facility to write dynamic code to selectively trigger trace or log for queries
 --

 Key: CASSANDRA-9193
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9193
 Project: Cassandra
  Issue Type: New Feature
Reporter: Matt Stump

 I want the equivalent of dtrace for Cassandra. I want the ability to 
 intercept a query with a dynamic script (assume JS) and based on logic in 
 that script trigger the statement for trace or logging. 
 Examples 
 - Trace only INSERT statements to a particular CF. 
 - Trace statements for a particular partition or consistency level.
 - Log statements that fail to reach the desired consistency for read or write.
 - Log If the request size for read or write exceeds some threshold
 At some point in the future it would be helpful to also do things such as log 
 partitions greater than X bytes or Z cells when performing compaction. 
 Essentially be able to inject custom code dynamically without a reboot to the 
 different stages of C*. 
 The code should be executed synchronously as part of the monitored task, but 
 we should provide the ability to log or execute CQL asynchronously from the 
 provided API.
 Further down the line we could use this functionality to modify/rewrite 
 requests or tasks dynamically.



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

[jira] [Commented] (CASSANDRA-9193) Facility to write dynamic code to selectively trigger trace or log for queries

2015-04-14 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14495451#comment-14495451
 ] 

Patrick McFadin commented on CASSANDRA-9193:


I don't think this is too far away from CASSANDRA-7526 with addition of 
metadata. 

I have used something similar on F5 network appliances in a feature called 
iRules. It was a feature to run a trigger based on a network event. My favorite 
part was how the user specified actions. You assigned a rule to a network port 
and wrote a collection of actions on events. If I were to translate that to a 
Cassandra use case, you would assign a rule set to a Table. Inside the rule set 
would be actions on events. Something like this pseudo code:

{
   onRequest {
  if(consistencyLevel == ALL) {
 log.WARN (Dude. Seriously?)
  }
   }

   onResponse {
  if (consistencyError) {
 ...do something...
  }

  if (data.size  50) {
 log.WARN (Dude. Seriously?)
  }
   }
}

Not proposing syntax but you get the idea. Could be a very powerful tool for 
troubleshooting and insight. 



 Facility to write dynamic code to selectively trigger trace or log for queries
 --

 Key: CASSANDRA-9193
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9193
 Project: Cassandra
  Issue Type: New Feature
Reporter: Matt Stump

 I want the equivalent of dtrace for Cassandra. I want the ability to 
 intercept a query with a dynamic script (assume JS) and based on logic in 
 that script trigger the statement for trace or logging. 
 Examples 
 - Trace only INSERT statements to a particular CF. 
 - Trace statements for a particular partition or consistency level.
 - Log statements that fail to reach the desired consistency for read or write.
 - Log If the request size for read or write exceeds some threshold
 At some point in the future it would be helpful to also do things such as log 
 partitions greater than X bytes or Z cells when performing compaction. 
 Essentially be able to inject custom code dynamically without a reboot to the 
 different stages of C*. 
 The code should be executed synchronously as part of the monitored task, but 
 we should provide the ability to log or execute CQL asynchronously from the 
 provided API.
 Further down the line we could use this functionality to modify/rewrite 
 requests or tasks dynamically.



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

[jira] [Commented] (CASSANDRA-8371) DateTieredCompactionStrategy is always compacting

2014-11-24 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14223840#comment-14223840
 ] 

Patrick McFadin commented on CASSANDRA-8371:


Mck, can you post your compaction settings for this keyspace?

For the use of any others reading this Jira. The line legends are:
Orange - STCS
Green - LCS
Purple - DTCS

 DateTieredCompactionStrategy is always compacting 
 --

 Key: CASSANDRA-8371
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8371
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: mck
  Labels: compaction, performance
 Attachments: java_gc_counts_rate-month.png, read-latency.png, 
 sstables.png, vg2_iad-month.png


 Running 2.0.11 and having switched a table to 
 [DTCS|https://issues.apache.org/jira/browse/CASSANDRA-6602] we've seen that 
 disk IO and gc count increase, along with the number of reads happening in 
 the compaction hump of cfhistograms.
 Data, and generally performance, looks good, but compactions are always 
 happening, and pending compactions are building up.
 The schema for this is 
 {code}CREATE TABLE search (
   loginid text,
   searchid timeuuid,
   description text,
   searchkey text,
   searchurl text,
   PRIMARY KEY ((loginid), searchid)
 );{code}
 We're sitting on about 82G (per replica) across 6 nodes in 4 DCs.
 CQL executed against this keyspace, and traffic patterns, can be seen in 
 slides 7+8 of https://prezi.com/b9-aj6p2esft
 Attached are sstables-per-read and read-latency graphs from cfhistograms, and 
 screenshots of our munin graphs as we have gone from STCS, to LCS (week ~44), 
 to DTCS (week ~46).
 These screenshots are also found in the prezi on slides 9-11.
 [~pmcfadin], [~Bj0rn], 
 Can this be a consequence of occasional deleted rows, as is described under 
 (3) in the description of CASSANDRA-6602 ?



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

[jira] [Created] (CASSANDRA-8011) Fail on large batch sizes

2014-09-26 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-8011:
--

 Summary: Fail on large batch sizes 
 Key: CASSANDRA-8011
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Priority: Minor


Related to https://issues.apache.org/jira/browse/CASSANDRA-6487

Just education alone is not going to stop some of the largeest batch sizes from 
being used. Just like we have a tombstone fail threshold, I propose that we 
have a batch size fail threshold.

Maybe 10x warn?

{{batch_fail_threshold: 50k}}



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

[jira] [Updated] (CASSANDRA-8011) Fail on large batch sizes

2014-09-26 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-8011:
---
Description: 
Related to https://issues.apache.org/jira/browse/CASSANDRA-6487

Just education alone is not going to stop some of the largest batch sizes from 
being used. Just like we have a tombstone fail threshold, I propose that we 
have a batch size fail threshold.

Maybe 10x warn?

{{batch_fail_threshold: 50k}}

  was:
Related to https://issues.apache.org/jira/browse/CASSANDRA-6487

Just education alone is not going to stop some of the largeest batch sizes from 
being used. Just like we have a tombstone fail threshold, I propose that we 
have a batch size fail threshold.

Maybe 10x warn?

{{batch_fail_threshold: 50k}}


 Fail on large batch sizes 
 --

 Key: CASSANDRA-8011
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Assignee: Carl Yeksigian
Priority: Minor
 Fix For: 3.0


 Related to https://issues.apache.org/jira/browse/CASSANDRA-6487
 Just education alone is not going to stop some of the largest batch sizes 
 from being used. Just like we have a tombstone fail threshold, I propose that 
 we have a batch size fail threshold.
 Maybe 10x warn?
 {{batch_fail_threshold: 50k}}



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

[jira] [Comment Edited] (CASSANDRA-7891) Select an element inside a UDT throws an index error

2014-09-06 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14123579#comment-14123579
 ] 

Patrick McFadin edited comment on CASSANDRA-7891 at 9/7/14 4:44 AM:


It was trunk. Sorry, the version in cqlsh was 2.1.1. 


was (Author: pmcfadin):
It was truck. Sorry, the version in cqlsh was 2.1.1. 

 Select an element inside a UDT throws an index error
 

 Key: CASSANDRA-7891
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7891
 Project: Cassandra
  Issue Type: Bug
Reporter: Patrick McFadin
 Fix For: 3.0


 Create the following data model:
 {noformat}
 CREATE TYPE address (
 street text,
 city text,
 zip_code int,
 phones settext
  );
  
 CREATE TYPE fullname (
 firstname text,
 lastname text
 );
 CREATE TABLE users (
 id uuid PRIMARY KEY,
 name FROZEN fullname,
 addresses maptext, FROZEN address
 );
 INSERT INTO users (id, name) 
 VALUES (62c36092-82a1-3a00-93d1-46196ee77204, {firstname: 'Marie-Claude', 
 lastname: 'Josset'});
 {noformat}
 When trying to select a sub-field in the name type:
 {noformat}
 SELECT name.lastname FROM users WHERE id=62c36092-82a1-3a00-93d1-46196ee77204;
 {noformat}
 You get the following error:
 {noformat}
 list index out of range
 {noformat}



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

[jira] [Created] (CASSANDRA-7891) Select an element inside a UDT throws an index error

2014-09-05 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-7891:
--

 Summary: Select an element inside a UDT throws an index error
 Key: CASSANDRA-7891
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7891
 Project: Cassandra
  Issue Type: Bug
Reporter: Patrick McFadin
 Fix For: 2.1.1


Create the following data model:
{{
CREATE TYPE address (
street text,
city text,
zip_code int,
phones settext
 );
 
CREATE TYPE fullname (
firstname text,
lastname text
);

CREATE TABLE users (
id uuid PRIMARY KEY,
name FROZEN fullname,
addresses maptext, FROZEN address
);

INSERT INTO users (id, name) 
VALUES (62c36092-82a1-3a00-93d1-46196ee77204, {firstname: 'Marie-Claude', 
lastname: 'Josset'});
}}

When trying to select a sub-field in the name type:
{{
SELECT name.lastname FROM users WHERE id=62c36092-82a1-3a00-93d1-46196ee77204;
}}

You get the following error:
{{
list index out of range
}}



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

[jira] [Updated] (CASSANDRA-7891) Select an element inside a UDT throws an index error

2014-09-05 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-7891:
---
Description: 
Create the following data model:
{noformat}
CREATE TYPE address (
street text,
city text,
zip_code int,
phones settext
 );
 
CREATE TYPE fullname (
firstname text,
lastname text
);

CREATE TABLE users (
id uuid PRIMARY KEY,
name FROZEN fullname,
addresses maptext, FROZEN address
);

INSERT INTO users (id, name) 
VALUES (62c36092-82a1-3a00-93d1-46196ee77204, {firstname: 'Marie-Claude', 
lastname: 'Josset'});
{noformat}

When trying to select a sub-field in the name type:
{{
SELECT name.lastname FROM users WHERE id=62c36092-82a1-3a00-93d1-46196ee77204;
}}

You get the following error:
{{
list index out of range
}}

  was:
Create the following data model:
{{
CREATE TYPE address (
street text,
city text,
zip_code int,
phones settext
 );
 
CREATE TYPE fullname (
firstname text,
lastname text
);

CREATE TABLE users (
id uuid PRIMARY KEY,
name FROZEN fullname,
addresses maptext, FROZEN address
);

INSERT INTO users (id, name) 
VALUES (62c36092-82a1-3a00-93d1-46196ee77204, {firstname: 'Marie-Claude', 
lastname: 'Josset'});
}}

When trying to select a sub-field in the name type:
{{
SELECT name.lastname FROM users WHERE id=62c36092-82a1-3a00-93d1-46196ee77204;
}}

You get the following error:
{{
list index out of range
}}


 Select an element inside a UDT throws an index error
 

 Key: CASSANDRA-7891
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7891
 Project: Cassandra
  Issue Type: Bug
Reporter: Patrick McFadin
 Fix For: 2.1.1


 Create the following data model:
 {noformat}
 CREATE TYPE address (
 street text,
 city text,
 zip_code int,
 phones settext
  );
  
 CREATE TYPE fullname (
 firstname text,
 lastname text
 );
 CREATE TABLE users (
 id uuid PRIMARY KEY,
 name FROZEN fullname,
 addresses maptext, FROZEN address
 );
 INSERT INTO users (id, name) 
 VALUES (62c36092-82a1-3a00-93d1-46196ee77204, {firstname: 'Marie-Claude', 
 lastname: 'Josset'});
 {noformat}
 When trying to select a sub-field in the name type:
 {{
 SELECT name.lastname FROM users WHERE id=62c36092-82a1-3a00-93d1-46196ee77204;
 }}
 You get the following error:
 {{
 list index out of range
 }}



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

[jira] [Updated] (CASSANDRA-7891) Select an element inside a UDT throws an index error

2014-09-05 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-7891:
---
Description: 
Create the following data model:
{noformat}
CREATE TYPE address (
street text,
city text,
zip_code int,
phones settext
 );
 
CREATE TYPE fullname (
firstname text,
lastname text
);

CREATE TABLE users (
id uuid PRIMARY KEY,
name FROZEN fullname,
addresses maptext, FROZEN address
);

INSERT INTO users (id, name) 
VALUES (62c36092-82a1-3a00-93d1-46196ee77204, {firstname: 'Marie-Claude', 
lastname: 'Josset'});
{noformat}

When trying to select a sub-field in the name type:
{noformat}
SELECT name.lastname FROM users WHERE id=62c36092-82a1-3a00-93d1-46196ee77204;
{noformat}

You get the following error:
{noformat}
list index out of range
{noformat}

  was:
Create the following data model:
{noformat}
CREATE TYPE address (
street text,
city text,
zip_code int,
phones settext
 );
 
CREATE TYPE fullname (
firstname text,
lastname text
);

CREATE TABLE users (
id uuid PRIMARY KEY,
name FROZEN fullname,
addresses maptext, FROZEN address
);

INSERT INTO users (id, name) 
VALUES (62c36092-82a1-3a00-93d1-46196ee77204, {firstname: 'Marie-Claude', 
lastname: 'Josset'});
{noformat}

When trying to select a sub-field in the name type:
{{
SELECT name.lastname FROM users WHERE id=62c36092-82a1-3a00-93d1-46196ee77204;
}}

You get the following error:
{{
list index out of range
}}


 Select an element inside a UDT throws an index error
 

 Key: CASSANDRA-7891
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7891
 Project: Cassandra
  Issue Type: Bug
Reporter: Patrick McFadin
 Fix For: 2.1.1


 Create the following data model:
 {noformat}
 CREATE TYPE address (
 street text,
 city text,
 zip_code int,
 phones settext
  );
  
 CREATE TYPE fullname (
 firstname text,
 lastname text
 );
 CREATE TABLE users (
 id uuid PRIMARY KEY,
 name FROZEN fullname,
 addresses maptext, FROZEN address
 );
 INSERT INTO users (id, name) 
 VALUES (62c36092-82a1-3a00-93d1-46196ee77204, {firstname: 'Marie-Claude', 
 lastname: 'Josset'});
 {noformat}
 When trying to select a sub-field in the name type:
 {noformat}
 SELECT name.lastname FROM users WHERE id=62c36092-82a1-3a00-93d1-46196ee77204;
 {noformat}
 You get the following error:
 {noformat}
 list index out of range
 {noformat}



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

[jira] [Commented] (CASSANDRA-7891) Select an element inside a UDT throws an index error

2014-09-05 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14123579#comment-14123579
 ] 

Patrick McFadin commented on CASSANDRA-7891:


It was truck. Sorry, the version in cqlsh was 2.1.1. 

 Select an element inside a UDT throws an index error
 

 Key: CASSANDRA-7891
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7891
 Project: Cassandra
  Issue Type: Bug
Reporter: Patrick McFadin
 Fix For: 2.1.1


 Create the following data model:
 {noformat}
 CREATE TYPE address (
 street text,
 city text,
 zip_code int,
 phones settext
  );
  
 CREATE TYPE fullname (
 firstname text,
 lastname text
 );
 CREATE TABLE users (
 id uuid PRIMARY KEY,
 name FROZEN fullname,
 addresses maptext, FROZEN address
 );
 INSERT INTO users (id, name) 
 VALUES (62c36092-82a1-3a00-93d1-46196ee77204, {firstname: 'Marie-Claude', 
 lastname: 'Josset'});
 {noformat}
 When trying to select a sub-field in the name type:
 {noformat}
 SELECT name.lastname FROM users WHERE id=62c36092-82a1-3a00-93d1-46196ee77204;
 {noformat}
 You get the following error:
 {noformat}
 list index out of range
 {noformat}



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

[jira] [Commented] (CASSANDRA-7857) Ability to froze UDT

2014-09-01 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14117854#comment-14117854
 ] 

Patrick McFadin commented on CASSANDRA-7857:


I heard someone mention atom which also sounds like a good contender. 

This would be a good place for a Jira voting mechanism...

 Ability to froze UDT
 

 Key: CASSANDRA-7857
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7857
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
 Fix For: 2.1.0

 Attachments: 7857-v2.txt, 7857.txt


 Currently, UDT are serialized into a single value. For 3.0, we want to change 
 that somewhat and allow updating individual subfields: CASSANDRA-7423 (and 
 ultimately, we'll probably allow querying subpart of UDT to some extend). 
 Also for 3.0, we want to allow some nesting of collections (CASSANDRA-7826).
 However, migrating the currently serialized UDT would be challenging. Besides 
 that, even with nested collections, we probably won't be able to support 
 nesting within map keys and sets without serializing (at the very least, not 
 initially). Also, it can be useful in some specific case to have UDT or 
 collections for PK columns, even if those are serialized.
 So we need a better way to distinguish when a composite types (collections  
 UDT) are serialized (which imply you can't update subpart of the value, you 
 have to rewrite it fully) and when they are not. The suggestion is then to 
 introduce a new keyword, {{frozen}}, to indicate that a type is serialized:
 {noformat}
 CREATE TYPE foo (a int, b int);
 CREATE TABLE bar (
 k frozenfoo PRIMARY KEY,
 m mapfrozensetint, text
 )
 {noformat}
 A big advantage is that it makes the downside (you can't update the value 
 without rewriting it all) clear and upfront.
 Now, as of 2.1, we only support frozen UDT, and so we should make this clear 
 by 1) adding the frozen keyword and 2) don't allow use of UDT unless they are 
 frozen (since that's all we really support). This is what this ticket 
 proposes to do. And this should be done in 2.1.0 or this will be a breaking 
 change.
 We will have a follow-up ticket that will extend {{frozen}} to collection, 
 but this is less urgent since this will be strictly an improvement.
 I'll note that in term of syntax, {{serialized}} was suggested as an 
 alternative to {{frozen}}. I personally have a minor preference for 
 {{serialized}} but it was argued that it had a sequential connotation which 
 {{frozen}} don't have. Changing that is still up for discussion, but we need 
 to reach a decision quickly.



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

[jira] [Commented] (CASSANDRA-7056) Add RAMP transactions

2014-06-28 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046904#comment-14046904
 ] 

Patrick McFadin commented on CASSANDRA-7056:


I don't get how cross partition consistent reads are something seen as edge 
case. I feel this is the primary use case. I've passed this by several users 
and got some measurable excitement.

 Add RAMP transactions
 -

 Key: CASSANDRA-7056
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056
 Project: Cassandra
  Issue Type: Wish
  Components: Core
Reporter: Tupshin Harper
Priority: Minor

 We should take a look at 
 [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/]
  transactions, and figure out if they can be used to provide more efficient 
 LWT (or LWT-like) operations.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7405) Optimize cqlsh COPY TO and COPY FROM

2014-06-16 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033256#comment-14033256
 ] 

Patrick McFadin commented on CASSANDRA-7405:


For the load balancing policy, I think it would be best to set to Token Aware 
in this case. The current default is Round Robin

http://datastax.github.io/python-driver/api/cassandra/policies.html#load-balancing



 Optimize cqlsh COPY TO and COPY FROM
 

 Key: CASSANDRA-7405
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7405
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Mikhail Stepura
 Fix For: 2.1.0


 Now that we are using native proto via python-driver, we can, and should, at 
 the very least:
 1. Use proto paging in COPY TO
 2. Use async writes in COPY FROM



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7274) Better display table organization on desc table via primary key list

2014-05-25 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-7274:
---

Attachment: 7274-2.txt

You are right. Much simpler. Attaching updated patch.

 Better display table organization on desc table via primary key list
 

 Key: CASSANDRA-7274
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7274
 Project: Cassandra
  Issue Type: Improvement
Reporter: G Gordon Worley III
Assignee: Patrick McFadin
 Fix For: 2.0.8

 Attachments: 7274-2.txt, 7274.txt


 In cqlsh, the desc table command does not make it sufficiently clear which 
 columns are part of the row key and which are clustering keys.
 A simple change to the primary key list, though, would make it easier to tell.
 Consider the following table definition:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key (first_column, second_column, third_column)
 }
 {code}
 This table has a row key of first_column and clustering keys of 
 second_column, third_column. But if the user intended for the table to have 
 all three in the row key, the correct definition would be:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column, second_column, third_column))
 }
 {code}
 But this is a sufficiently subtle difference that the first may be mistaken 
 for the second or vice-versa.
 My suggested solution is to always wrap the row key in parentheses. This is 
 already supported by create table syntax, so it's just a matter of changing 
 desc table to display the create table statement with the primary key always 
 in parentheses, like so:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column), second_column, third_column)
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7274) Better display table organization on desc table via primary key list

2014-05-24 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-7274:
---

Fix Version/s: 2.0.8

 Better display table organization on desc table via primary key list
 

 Key: CASSANDRA-7274
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7274
 Project: Cassandra
  Issue Type: Improvement
Reporter: G Gordon Worley III
Assignee: Patrick McFadin
 Fix For: 2.0.8


 In cqlsh, the desc table command does not make it sufficiently clear which 
 columns are part of the row key and which are clustering keys.
 A simple change to the primary key list, though, would make it easier to tell.
 Consider the following table definition:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key (first_column, second_column, third_column)
 }
 {code}
 This table has a row key of first_column and clustering keys of 
 second_column, third_column. But if the user intended for the table to have 
 all three in the row key, the correct definition would be:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column, second_column, third_column))
 }
 {code}
 But this is a sufficiently subtle difference that the first may be mistaken 
 for the second or vice-versa.
 My suggested solution is to always wrap the row key in parentheses. This is 
 already supported by create table syntax, so it's just a matter of changing 
 desc table to display the create table statement with the primary key always 
 in parentheses, like so:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column), second_column, third_column)
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CASSANDRA-7274) Better display table organization on desc table via primary key list

2014-05-24 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin reassigned CASSANDRA-7274:
--

Assignee: Patrick McFadin

 Better display table organization on desc table via primary key list
 

 Key: CASSANDRA-7274
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7274
 Project: Cassandra
  Issue Type: Improvement
Reporter: G Gordon Worley III
Assignee: Patrick McFadin
 Fix For: 2.0.8


 In cqlsh, the desc table command does not make it sufficiently clear which 
 columns are part of the row key and which are clustering keys.
 A simple change to the primary key list, though, would make it easier to tell.
 Consider the following table definition:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key (first_column, second_column, third_column)
 }
 {code}
 This table has a row key of first_column and clustering keys of 
 second_column, third_column. But if the user intended for the table to have 
 all three in the row key, the correct definition would be:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column, second_column, third_column))
 }
 {code}
 But this is a sufficiently subtle difference that the first may be mistaken 
 for the second or vice-versa.
 My suggested solution is to always wrap the row key in parentheses. This is 
 already supported by create table syntax, so it's just a matter of changing 
 desc table to display the create table statement with the primary key always 
 in parentheses, like so:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column), second_column, third_column)
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7274) Better display table organization on desc table via primary key list

2014-05-24 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-7274:
---

Attachment: 7274.txt

Simple change in cqlsh to add parenthesis around a single partition key when 
doing a DESCRIBE TABLE

 Better display table organization on desc table via primary key list
 

 Key: CASSANDRA-7274
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7274
 Project: Cassandra
  Issue Type: Improvement
Reporter: G Gordon Worley III
Assignee: Patrick McFadin
 Fix For: 2.0.8

 Attachments: 7274.txt


 In cqlsh, the desc table command does not make it sufficiently clear which 
 columns are part of the row key and which are clustering keys.
 A simple change to the primary key list, though, would make it easier to tell.
 Consider the following table definition:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key (first_column, second_column, third_column)
 }
 {code}
 This table has a row key of first_column and clustering keys of 
 second_column, third_column. But if the user intended for the table to have 
 all three in the row key, the correct definition would be:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column, second_column, third_column))
 }
 {code}
 But this is a sufficiently subtle difference that the first may be mistaken 
 for the second or vice-versa.
 My suggested solution is to always wrap the row key in parentheses. This is 
 already supported by create table syntax, so it's just a matter of changing 
 desc table to display the create table statement with the primary key always 
 in parentheses, like so:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column), second_column, third_column)
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7274) Better display table organization on desc table via primary key list

2014-05-20 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004295#comment-14004295
 ] 

Patrick McFadin commented on CASSANDRA-7274:


I like it for clarity. The possible alternative than default behavior would be 
to flag some sort of verbose mode. 

 Better display table organization on desc table via primary key list
 

 Key: CASSANDRA-7274
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7274
 Project: Cassandra
  Issue Type: Improvement
Reporter: G Gordon Worley III

 In cqlsh, the desc table command does not make it sufficiently clear which 
 columns are part of the row key and which are clustering keys.
 A simple change to the primary key list, though, would make it easier to tell.
 Consider the following table definition:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key (first_column, second_column, third_column)
 }
 {code}
 This table has a row key of first_column and clustering keys of 
 second_column, third_column. But if the user intended for the table to have 
 all three in the row key, the correct definition would be:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column, second_column, third_column))
 }
 {code}
 But this is a sufficiently subtle difference that the first may be mistaken 
 for the second or vice-versa.
 My suggested solution is to always wrap the row key in parentheses. This is 
 already supported by create table syntax, so it's just a matter of changing 
 desc table to display the create table statement with the primary key always 
 in parentheses, like so:
 {code}
 create table my_table {
   first_column text,
   second_column text,
   third_column text,
   primary key ((first_column), second_column, third_column)
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7232) Enable live replay of commit logs

2014-05-16 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1332#comment-1332
 ] 

Patrick McFadin commented on CASSANDRA-7232:


sgtm 

 Enable live replay of commit logs
 -

 Key: CASSANDRA-7232
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7232
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Patrick McFadin
Assignee: Lyuben Todorov
Priority: Minor
 Fix For: 2.0.9


 Replaying commit logs takes a restart but restoring sstables can be an online 
 operation with refresh. In order to restore a point-in-time without a 
 restart, the node needs to live replay the commit logs from JMX and a 
 nodetool command.
 nodetool refreshcommitlogs keyspace table



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7232) Enable live replay of commit logs

2014-05-15 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-7232:
--

 Summary: Enable live replay of commit logs
 Key: CASSANDRA-7232
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7232
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Priority: Minor


Replaying commit logs takes a restart but restoring sstables can be an online 
operation with refresh. In order to restore a point-in-time without a restart, 
the node needs to live replay the commit logs from JMX and a nodetool command.

nodetool refreshcommitlogs keyspace table





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6357) Flush memtables to separate directory

2014-03-24 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945786#comment-13945786
 ] 

Patrick McFadin commented on CASSANDRA-6357:


I don't think we proved out the initial point for this patch. How can we 
minimize (or remove) flush writer blocks when disks are under stress?

Under load, the performance difference would be nice, but my intent was to 
prevent heap pressure and eventual node problems. That's what I would like to 
show if possible. 

 Flush memtables to separate directory
 -

 Key: CASSANDRA-6357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6357
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Patrick McFadin
Assignee: Jonathan Ellis
Priority: Minor
  Labels: performance
 Fix For: 2.1 beta1

 Attachments: 6357-v2.txt, 6357.txt, 
 c6357-2.1-stress-write-adj-ops-sec.png, 
 c6357-2.1-stress-write-latency-99th.png, 
 c6357-2.1-stress-write-latency-median.png, 
 c6357-stress-write-latency-99th-1.png


 Flush writers are a critical element for keeping a node healthy. When several 
 compactions run on systems with low performing data directories, IO becomes a 
 premium. Once the disk subsystem is saturated, write IO is blocked which will 
 cause flush writer threads to backup. Since memtables are large blocks of 
 memory in the JVM, too much blocking can cause excessive GC over time 
 degrading performance. In the worst case causing an OOM.
 Since compaction is running on the data directories. My proposal is to create 
 a separate directory for flushing memtables. Potentially we can use the same 
 methodology of keeping the commit log separate and minimize disk contention 
 against the critical function of the flushwriter. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6487) Log WARN on large batch sizes

2013-12-21 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855081#comment-13855081
 ] 

Patrick McFadin commented on CASSANDRA-6487:


Yes that was in bytes. Just in my own experience, I don't recommend more than 
~100 mutations per batch. Doing some quick math I came up with 5k as 100 x 50 
byte mutations. 

Totally up for debate.

 Log WARN on large batch sizes
 -

 Key: CASSANDRA-6487
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6487
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Assignee: Lyuben Todorov
Priority: Minor
 Attachments: 6487_trunk.patch, 6487_trunk_v2.patch


 Large batches on a coordinator can cause a lot of node stress. I propose 
 adding a WARN log entry if batch sizes go beyond a configurable size. This 
 will give more visibility to operators on something that can happen on the 
 developer side. 
 New yaml setting with 5k default.
 {{# Log WARN on any batch size exceeding this value. 5k by default.}}
 {{# Caution should be taken on increasing the size of this threshold as it 
 can lead to node instability.}}
 {{batch_size_warn_threshold: 5k}}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CASSANDRA-6487) Log WARN on large batch sizes

2013-12-13 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-6487:
--

 Summary: Log WARN on large batch sizes
 Key: CASSANDRA-6487
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6487
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Priority: Minor


Large batches on a coordinator can cause a lot of node stress. I propose adding 
a WARN log entry if batch sizes go beyond a configurable size. This will give 
more visibility to operators on something that can happen on the developer 
side. 

New yaml setting with 5k default.

# Log WARN on any batch size exceeding this value. 5k by default.
# Caution should be taken on increasing the size of this threshold as it can 
lead to node instability.

batch_size_warn_threshold: 5k





--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Updated] (CASSANDRA-6487) Log WARN on large batch sizes

2013-12-13 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-6487:
---

Description: 
Large batches on a coordinator can cause a lot of node stress. I propose adding 
a WARN log entry if batch sizes go beyond a configurable size. This will give 
more visibility to operators on something that can happen on the developer 
side. 

New yaml setting with 5k default.

{{# Log WARN on any batch size exceeding this value. 5k by default.
# Caution should be taken on increasing the size of this threshold as it can 
lead to node instability.

batch_size_warn_threshold: 5k
}}


  was:
Large batches on a coordinator can cause a lot of node stress. I propose adding 
a WARN log entry if batch sizes go beyond a configurable size. This will give 
more visibility to operators on something that can happen on the developer 
side. 

New yaml setting with 5k default.

# Log WARN on any batch size exceeding this value. 5k by default.
# Caution should be taken on increasing the size of this threshold as it can 
lead to node instability.

batch_size_warn_threshold: 5k




 Log WARN on large batch sizes
 -

 Key: CASSANDRA-6487
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6487
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Priority: Minor

 Large batches on a coordinator can cause a lot of node stress. I propose 
 adding a WARN log entry if batch sizes go beyond a configurable size. This 
 will give more visibility to operators on something that can happen on the 
 developer side. 
 New yaml setting with 5k default.
 {{# Log WARN on any batch size exceeding this value. 5k by default.
 # Caution should be taken on increasing the size of this threshold as it can 
 lead to node instability.
 batch_size_warn_threshold: 5k
 }}



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (CASSANDRA-6487) Log WARN on large batch sizes

2013-12-13 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13848103#comment-13848103
 ] 

Patrick McFadin commented on CASSANDRA-6487:


Sure. Can't see any reason not to add more info if it's easy to add. 

 Log WARN on large batch sizes
 -

 Key: CASSANDRA-6487
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6487
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Priority: Minor

 Large batches on a coordinator can cause a lot of node stress. I propose 
 adding a WARN log entry if batch sizes go beyond a configurable size. This 
 will give more visibility to operators on something that can happen on the 
 developer side. 
 New yaml setting with 5k default.
 {{# Log WARN on any batch size exceeding this value. 5k by default.}}
 {{# Caution should be taken on increasing the size of this threshold as it 
 can lead to node instability.}}
 {{batch_size_warn_threshold: 5k}}



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Updated] (CASSANDRA-6487) Log WARN on large batch sizes

2013-12-13 Thread Patrick McFadin (JIRA) 

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

Patrick McFadin updated CASSANDRA-6487:
---

Description: 
Large batches on a coordinator can cause a lot of node stress. I propose adding 
a WARN log entry if batch sizes go beyond a configurable size. This will give 
more visibility to operators on something that can happen on the developer 
side. 

New yaml setting with 5k default.

{{# Log WARN on any batch size exceeding this value. 5k by default.}}
{{# Caution should be taken on increasing the size of this threshold as it can 
lead to node instability.}}

{{batch_size_warn_threshold: 5k}}



  was:
Large batches on a coordinator can cause a lot of node stress. I propose adding 
a WARN log entry if batch sizes go beyond a configurable size. This will give 
more visibility to operators on something that can happen on the developer 
side. 

New yaml setting with 5k default.

{{# Log WARN on any batch size exceeding this value. 5k by default.
# Caution should be taken on increasing the size of this threshold as it can 
lead to node instability.

batch_size_warn_threshold: 5k
}}



 Log WARN on large batch sizes
 -

 Key: CASSANDRA-6487
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6487
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Priority: Minor

 Large batches on a coordinator can cause a lot of node stress. I propose 
 adding a WARN log entry if batch sizes go beyond a configurable size. This 
 will give more visibility to operators on something that can happen on the 
 developer side. 
 New yaml setting with 5k default.
 {{# Log WARN on any batch size exceeding this value. 5k by default.}}
 {{# Caution should be taken on increasing the size of this threshold as it 
 can lead to node instability.}}
 {{batch_size_warn_threshold: 5k}}



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Created] (CASSANDRA-6357) Flush memtables to seperate directory

2013-11-15 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-6357:
--

 Summary: Flush memtables to seperate directory
 Key: CASSANDRA-6357
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6357
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Patrick McFadin


Flush writers are a critical element for keeping a node healthy. When several 
compactions run on systems with low performing data directories, IO becomes a 
premium. Once the disk subsystem is saturated, write IO is blocked which will 
cause flush writer threads to backup. Since memtables are large blocks of 
memory in the JVM, too much blocking can cause excessive GC over time degrading 
performance. In the worst case causing an OOM.

Since compaction is running on the data directories. My proposal is to create a 
separate directory for flushing memtables. Potentially we can use the same 
methodology of keeping the commit log separate and minimize disk contention 
against the critical function of the flushwriter. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up on some platforms with Java 7u40

2013-10-13 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793742#comment-13793742
 ] 

Patrick McFadin commented on CASSANDRA-6190:


Just tried c* 2.0.1 using Oracle JDK 7u40 on CentOS 6.4. Works without 
modification. 

 Cassandra 2.0 won't start up on some platforms with Java 7u40
 -

 Key: CASSANDRA-6190
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190
 Project: Cassandra
  Issue Type: Bug
  Components: Config
 Environment: Ubuntu 13.04 32- and 64-bit  JDK 7u40  (tried JRE 7u25)
Reporter: Steven Lowenthal

 Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM 
 option.  7u40 on Macintosh works correctly,  If I use the tarball 7u40 
 version of 7, we encounter the error below. I tried 7u25 (the previous 
 release) and it functioned correctly.
 ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark'
 Error: Could not create the Java Virtual Machine.
 Error: A fatal exception has occurred. Program will exit.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (CASSANDRA-5983) Include sample CQL schema with distribution

2013-09-06 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-5983:
--

 Summary: Include sample CQL schema with distribution
 Key: CASSANDRA-5983
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5983
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Priority: Minor


Having a sample schema will give new users a easy place to start with CQL. I 
have been using an example schema for over a year that tries to cover many data 
model topics. 

I have made the examples available on my Githib account: 
https://github.com/pmcfadin/cassandra-videodb-sample-schema

I need to add more sample queries but would like to start getting feedback on 
any specific CQL features to add. I would like to show as many features as 
possible and still make it useful. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5918) Remove CQL2 entirely from Cassandra 2.2

2013-08-22 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747615#comment-13747615
 ] 

Patrick McFadin commented on CASSANDRA-5918:


If we are going to remove it as a breaking change, this should be 3.0. There 
are still people in production using CQL2. If 2.x issues a warning, then we can 
give them until 3.x to migrate away. 

 Remove CQL2 entirely from Cassandra 2.2
 ---

 Key: CASSANDRA-5918
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5918
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Priority: Minor
  Labels: cql
 Fix For: 2.2


 CQL2 is officially no longer worked on since 1.2. cqlsh no longer supports 
 CQL2 as of Cassandra 2.0.
 It's probably the time to deprecate CQL2 in 2.0 and to remove it entirely in 
 2.2 - there is nothing in CQL2 now that can't be done via CQL3 and two 
 versions advance warning is plenty of time for those few still using CQL2 to 
 switch to CQL3.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5918) Remove CQL2 entirely from Cassandra 2.2

2013-08-22 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747648#comment-13747648
 ] 

Patrick McFadin commented on CASSANDRA-5918:


Your concern for my happiness is heart warming. heh

Whatever it is that isn't we just took away functionality inside 2.x will be 
just fine.

 Remove CQL2 entirely from Cassandra 2.2
 ---

 Key: CASSANDRA-5918
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5918
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Priority: Minor
  Labels: cql
 Fix For: 2.2


 CQL2 is officially no longer worked on since 1.2. cqlsh no longer supports 
 CQL2 as of Cassandra 2.0.
 It's probably the time to deprecate CQL2 in 2.0 and to remove it entirely in 
 2.2 - there is nothing in CQL2 now that can't be done via CQL3 and two 
 versions advance warning is plenty of time for those few still using CQL2 to 
 switch to CQL3.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5797) DC-local CAS

2013-07-24 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13718476#comment-13718476
 ] 

Patrick McFadin commented on CASSANDRA-5797:


I like LOCAL_SERIAL over ANY. It makes a closer match to LOCAL_QUORUM in that 
it's not meant to cross datacenter boundaries. There is enough confusion about 
ANY as it is and I think this would simplify things.

 DC-local CAS
 

 Key: CASSANDRA-5797
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5797
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 2.0
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 2.0.1


 For two-datacenter deployments where the second DC is strictly for disaster 
 failover, it would be useful to restrict CAS to a single DC to avoid cross-DC 
 round trips.
 (This would require manually truncating {{system.paxos}} when failing over.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5715) CAS on 'primary key only' table

2013-07-16 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13709563#comment-13709563
 ] 

Patrick McFadin commented on CASSANDRA-5715:


I'm with Jonathan on this one. I think it's best to start restricted and 
correct it later if needed. 

On the point of of blurring between INSERT and UPDATE, I personally like the 
separation. When talking about data models it keeps what we are doing in 
context. Another reason: we may not have a good reason to separate them now, 
but that may not be the case in the future. Just as a matter of style and 
future-proofing I would like to keep them separate. 

 CAS on 'primary key only' table
 ---

 Key: CASSANDRA-5715
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5715
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 2.0

 Attachments: 0001-Conditions-on-INSERT.txt, 
 0002-Support-updating-the-PK-only.txt, 5715-v2.txt


 Given a table with only a primary key, like
 {noformat}
 CREATE TABLE test (k int PRIMARY KEY)
 {noformat}
 there is currently no way to CAS a row in that table into existing because:
 # INSERT doesn't currently support IF
 # UPDATE has no way to update such table
 So we should probably allow IF conditions on INSERT statements.
 In addition (or alternatively), we could work on allowing UPDATE to update 
 such table. One motivation for that could be to make UPDATE always be more 
 general to INSERT. That is currently, there is a bunch of operation that 
 INSERT cannot do (counter increments, collection appends), but that primary 
 key table case is, afaik, the only case where you *need* to use INSERT. 
 However, because CQL forces segregation of PK value to the WHERE clause and 
 not to the SET one, the only syntax that I can see work would be:
 {noformat}
 UPDATE WHERE k=0;
 {noformat}
 which maybe is too ugly to allow?
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-1311) Triggers

2013-05-16 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660316#comment-13660316
 ] 

Patrick McFadin commented on CASSANDRA-1311:


I'm going to have to object one more time to storing a jar file in the file 
system. With large scale deployments, this is going to be a disaster waiting to 
happen. One last plea for https://issues.apache.org/jira/browse/CASSANDRA-4954 ?

 Triggers
 

 Key: CASSANDRA-1311
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
 Project: Cassandra
  Issue Type: New Feature
Reporter: Maxim Grinev
Assignee: Vijay
 Fix For: 2.0

 Attachments: 0001-1311-v3.patch, HOWTO-PatchAndRunTriggerExample.txt, 
 HOWTO-PatchAndRunTriggerExample-update1.txt, ImplementationDetails.pdf, 
 ImplementationDetails-update1.pdf, trunk-967053.txt, 
 trunk-984391-update1.txt, trunk-984391-update2.txt


 Asynchronous triggers is a basic mechanism to implement various use cases of 
 asynchronous execution of application code at database side. For example to 
 support indexes and materialized views, online analytics, push-based data 
 propagation.
 Please find the motivation, triggers description and list of applications:
 http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/
 An example of using triggers for indexing:
 http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/
 Implementation details are attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5457) Ordering is ignored when using 'CLUSTERING ORDER BY'

2013-04-11 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-5457:
--

 Summary: Ordering is ignored when using 'CLUSTERING ORDER BY' 
 Key: CASSANDRA-5457
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5457
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.4
Reporter: Patrick McFadin


Creating the following table:

create table reverse_sort_test (
id int,
field1 int,
field2 int
PRIMARY KEY (id, field1, field2)
) WITH CLUSTERING ORDER BY (field1 DESC);

I would expect field1 to be reverse ordered. 

Inserting this data:

insert into reverse_sort_test (id,field1,field2) values (1,1,1);
insert into reverse_sort_test (id,field1,field2) values (3,3,3);
insert into reverse_sort_test (id,field1,field2) values (2,2,2);
insert into reverse_sort_test (id,field1,field2) values (4,4,4);
insert into reverse_sort_test (id,field1,field2) values (6,6,6);
insert into reverse_sort_test (id,field1,field2) values (5,5,5);

And running a select:

select * from reverse_sort_test;

 id | field1 | field2
++
  5 |  5 |  5
  1 |  1 |  1
  2 |  2 |  2
  4 |  4 |  4
  6 |  6 |  6
  3 |  3 |  3

The order looks random.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5100) Create different log entry if dropped mutation is a hint

2013-01-02 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-5100:
--

 Summary: Create different log entry if dropped mutation is a hint
 Key: CASSANDRA-5100
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5100
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Patrick McFadin
Priority: Minor


When a mutation is dropped, you see an INFO log line like this:

MessagingService.java (line 607) 816 MUTATION messages dropped in last 5000ms

It would be helpful to know that the mutation was a local hint being dropped. 
Since this is much more severe case of a dropped mutation, I also think it 
should be a WARN and not an INFO. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4954) Store trigger jar file dependencies in system keyspace

2012-11-13 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-4954:
--

 Summary: Store trigger jar file dependencies in system keyspace
 Key: CASSANDRA-4954
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4954
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Patrick McFadin
 Fix For: 1.3


The implementation of triggers requires the use of jar files to be stored in 
the local filesystem, per node. See 
([https://issues.apache.org/jira/browse/CASSANDRA-1311]) 

I'm proposing that instead of using the filesystem, jars would be stored in the 
system keyspace. This would greatly reduce the operational complexity of 
implementing triggers on multiple node clusters. Some benefits would include:

* Triggers and dependencies would be part of a snapshot for backup and restore
* Every node would have a consistent version
* Everything needed for the trigger would be a part of bootstrap

Some details to start the conversation:
* Have a list of jars for each trigger be made available via JMX
* Expose the jar upload using CQL when trigger is created (USING FILE x) 
* Store the version number or date for each jar
* Implement a classloader trigger when jars are updated
* Provide some sort of guarantee that triggers aren't active until all nodes 
have the same version of jar(s)




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-1311) Triggers

2012-11-13 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496228#comment-13496228
 ] 

Patrick McFadin commented on CASSANDRA-1311:


Done: https://issues.apache.org/jira/browse/CASSANDRA-4954

Carry on. :)

 Triggers
 

 Key: CASSANDRA-1311
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
 Project: Cassandra
  Issue Type: New Feature
Reporter: Maxim Grinev
Assignee: Vijay
 Fix For: 1.3

 Attachments: HOWTO-PatchAndRunTriggerExample.txt, 
 HOWTO-PatchAndRunTriggerExample-update1.txt, ImplementationDetails.pdf, 
 ImplementationDetails-update1.pdf, trunk-967053.txt, 
 trunk-984391-update1.txt, trunk-984391-update2.txt


 Asynchronous triggers is a basic mechanism to implement various use cases of 
 asynchronous execution of application code at database side. For example to 
 support indexes and materialized views, online analytics, push-based data 
 propagation.
 Please find the motivation, triggers description and list of applications:
 http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/
 An example of using triggers for indexing:
 http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/
 Implementation details are attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-1311) Triggers

2012-11-12 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13495986#comment-13495986
 ] 

Patrick McFadin commented on CASSANDRA-1311:


I love the idea of having triggers but I'm less than enthusiastic about adding 
operation overhead in deploying jar files to every node. When you are talking 
about a cluster with 100s of nodes, that's going to be a lot of files to copy 
around.

Here's a radical idea. Why not store the jar file in a CF? 
* The jars will be distributed and available to all nodes in the cluster.
* When backing up and restoring a node, this won't add any extra steps.
* When new nodes come online, everything for the trigger will be a part of the 
bootstrap.

I'm saying this strictly from an operations standpoint. 

 Triggers
 

 Key: CASSANDRA-1311
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
 Project: Cassandra
  Issue Type: New Feature
Reporter: Maxim Grinev
Assignee: Vijay
 Fix For: 1.3

 Attachments: HOWTO-PatchAndRunTriggerExample.txt, 
 HOWTO-PatchAndRunTriggerExample-update1.txt, ImplementationDetails.pdf, 
 ImplementationDetails-update1.pdf, trunk-967053.txt, 
 trunk-984391-update1.txt, trunk-984391-update2.txt


 Asynchronous triggers is a basic mechanism to implement various use cases of 
 asynchronous execution of application code at database side. For example to 
 support indexes and materialized views, online analytics, push-based data 
 propagation.
 Please find the motivation, triggers description and list of applications:
 http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/
 An example of using triggers for indexing:
 http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/
 Implementation details are attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4881) Selecting records on a reversed column in CQL 3 returns wrong row

2012-10-30 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-4881:
--

 Summary: Selecting records on a reversed column in CQL 3 returns 
wrong row
 Key: CASSANDRA-4881
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4881
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Patrick McFadin


Using this table:
CREATE TABLE video_event (
  videoid_username varchar,
  event varchar,
  event_timestamp timestamp,
  video_timestamp timestamp,
  PRIMARY KEY (videoid_username, event, event_timestamp)
)WITH CLUSTERING ORDER BY (event_timestamp DESC);

Inserting these records:

INSERT INTO video_event (videoid_username, event, event_timestamp, 
video_timestamp) 
VALUES ('99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd','start','2012-09-02 
18:05:00','2012-09-02 18:05:00');
INSERT INTO video_event (videoid_username, event, event_timestamp, 
video_timestamp) 
VALUES ('99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd','stop','2012-09-02 
18:05:30','2012-09-02 18:05:30');
INSERT INTO video_event (videoid_username, event, event_timestamp, 
video_timestamp) 
VALUES ('99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd','start','2012-09-02 
18:35:00','2012-09-02 18:35:00');
INSERT INTO video_event (videoid_username, event, event_timestamp, 
video_timestamp) 
VALUES ('99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd','stop','2012-09-02 
18:37:30','2012-09-02 18:37:30');

Running this select:

select * from video_event where videoid_username = 
'99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd' limit 1;

I get this:

 videoid_username   | event | event_timestamp  
| video_timestamp
+---+--+--
 99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd | start | 2012-09-02 18:05:00+ 
| 2012-09-02 18:05:00+

I would expect to see this:

 videoid_username   | event | event_timestamp  
| video_timestamp
+---+--+--
 99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd |  stop | 2012-09-02 18:37:30+ 
| 2012-09-02 18:37:30+

where the first record pulled was the sorted record by event_timestamp in 
reverse order.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4882) CQL 3 select output inconsistent on timestamp

2012-10-30 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-4882:
--

 Summary: CQL 3 select output inconsistent on timestamp
 Key: CASSANDRA-4882
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4882
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Patrick McFadin


Using the same schema defined in 
https://issues.apache.org/jira/browse/CASSANDRA-4881

select * from video_event;
 videoid_username   | event | event_timestamp | 
video_timestamp
+---+-+--
 99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd | start |1346636100.0 | 
2012-09-02 18:35:00+
 99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd | start |1346634300.0 | 
2012-09-02 18:05:00+
 99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd |  stop |1346636250.0 | 
2012-09-02 18:37:30+
 99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd |  stop |1346634330.0 | 
2012-09-02 18:05:30+

And this:

select * from video_event where videoid_username = 
'99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd' limit 1;
 videoid_username   | event | event_timestamp | 
video_timestamp
+---+-+-
 99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd | start |1346636100.0 | 
   null

As you can see, we have some different output based on the select statement. 
The timestamp in both is formatted as a float or a double. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4867) Add verbose option to cqlsh when using file input

2012-10-27 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-4867:
--

 Summary: Add verbose option to cqlsh when using file input
 Key: CASSANDRA-4867
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4867
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Patrick McFadin
Priority: Minor


Add a verbose option (-v) for output when using the -f option for an external 
CQL file. Only error output is created now.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4602) Stack Size on Sun JVM 1.6.0_33 must be at least 160k

2012-09-26 Thread Patrick McFadin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464451#comment-13464451
 ] 

Patrick McFadin commented on CASSANDRA-4602:


+1 on greater than 160. Just fixed a re-occurring StackOverflowError problem by 
bumping the stack size. Added this line to cassandra-env.sh:

JVM_OPTS=$JVM_OPTS -Xss194k

Same JRE as above. build 1.6.0_35-b10

It was set to 160k but still threw exceptions.

 Stack Size on Sun JVM 1.6.0_33 must be at least 160k
 

 Key: CASSANDRA-4602
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4602
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Ubuntu 10.04 
 java version 1.6.0_35
 Java(TM) SE Runtime Environment (build 1.6.0_35-b10)
 Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01, mixed mode)
Reporter: amorton
Assignee: Jonathan Ellis
 Fix For: 1.0.12, 1.1.5

 Attachments: 4602.txt


 I started a fresh Cassandra 1.1.4 install with Sun JVM 1.6.35.
 On startup I got this in output.log
 {noformat}
 The stack size specified is too small, Specify at least 160k
 Cannot create Java VM
 Service exit with a return value of 1
 {noformat}
 Remembering CASSANDRA-4275 I monkeyed around and started the JVM with 
 -Xss160k the same as Java 7. I then got
 {code:java}
 ERROR [WRITE-/192.168.1.12] 2012-08-31 01:43:29,865 
 AbstractCassandraDaemon.java (line 134) Exception in thread 
 Thread[WRITE-/192.168.1.12,5,main]
 java.lang.StackOverflowError
   at java.net.SocketOutputStream.socketWrite0(Native Method)
   at java.net.SocketOutputStream.socketWrite(Unknown Source)
   at java.net.SocketOutputStream.write(Unknown Source)
   at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
   at java.io.BufferedOutputStream.flush(Unknown Source)
   at java.io.DataOutputStream.flush(Unknown Source)
   at 
 org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:156)
   at 
 org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:126)
 {code}
 Same as CASSANDRA-4442
 At which point I dropped back to Java 6.33. 
 CASSANDRA-4457 bumped the stack size to 180 for java 7, should we also do 
 this for Java 6.33+ ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4680) Show time drift between nodes when using nodetool ring

2012-09-18 Thread Patrick McFadin (JIRA) 
Patrick McFadin created CASSANDRA-4680:
--

 Summary: Show time drift between nodes when using nodetool ring
 Key: CASSANDRA-4680
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4680
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Priority: Minor


From the docs:
Server clock synchronization is more important in 1.2; replicas
will use a coordinator-provided timestamp to determine when a
request has timed out and is thus not worth proceeding with.
Using a service like NTP is strongly recommended.

Since this is now more important than ever, my proposed enhancement would be to 
the nodetool command. When displaying the ring information, add the time 
drift as relative to the current host.

This would be a valuable tool to aid in diagnostics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira