[cassandra-website] branch asf-staging updated (f4b7bf8d -> f711e8fb)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard f4b7bf8d generate docs for c4206294 new f711e8fb generate docs for c4206294 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (f4b7bf8d) \ N -- N -- N refs/heads/asf-staging (f711e8fb) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700969#comment-17700969 ] David Capwell commented on CASSANDRA-18302: --- Can you also run CI? I am +1 assuming the build is green > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- 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-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700966#comment-17700966 ] Caleb Rackliffe commented on CASSANDRA-18302: - +1 (also approved in PR) > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- 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
[cassandra-website] branch asf-staging updated (561c27c8 -> f4b7bf8d)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 561c27c8 generate docs for c4206294 new f4b7bf8d generate docs for c4206294 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (561c27c8) \ N -- N -- N refs/heads/asf-staging (f4b7bf8d) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700937#comment-17700937 ] Ekaterina Dimitrova edited comment on CASSANDRA-18247 at 3/16/23 3:16 AM: -- CASSANDRA-18106 is committed. *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * Current table of all test failures with respective ticket numbers will be opened on CASSANDRA-16895 after this one gets committed. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2] , started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run Ticket move to PATCH AVAILABLE pending on clean CI, tests were just started was (Author: e.dimitrova): CASSANDRA-18106 is committed. *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * Current table of all failures and respective tickets will be opened on CASSANDRA-16895 after this one gets committed. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2] , started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run Ticket move to PATCH AVAILABLE pending on clean CI, tests were just started > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700937#comment-17700937 ] Ekaterina Dimitrova edited comment on CASSANDRA-18247 at 3/16/23 3:15 AM: -- CASSANDRA-18106 is committed. *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * Current table of all failures and respective tickets will be opened on CASSANDRA-16895 after this one gets committed. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2] , started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run Ticket move to PATCH AVAILABLE pending on clean CI, tests were just started was (Author: e.dimitrova): CASSANDRA-18106 is committed. *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * I will add a table in CASSANDRA-16895 of all current JDK17 tests failures and match them to the different tickets we already have. Most of the time those tickets are not for particular tests fixes but to update dependency or any other issue as those solve more than one problem/test normally. I hope that table will help with clear visibility of where we are and what is needed, at least from CI perspective. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2] , started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run Ticket move to PATCH AVAILABLE pending on clean CI, tests were just started > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700937#comment-17700937 ] Ekaterina Dimitrova edited comment on CASSANDRA-18247 at 3/16/23 3:07 AM: -- CASSANDRA-18106 is committed. *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * I will add a table in CASSANDRA-16895 of all current JDK17 tests failures and match them to the different tickets we already have. Most of the time those tickets are not for particular tests fixes but to update dependency or any other issue as those solve more than one problem/test normally. I hope that table will help with clear visibility of where we are and what is needed, at least from CI perspective. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2] , rerun j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run Ticket move to PATCH AVAILABLE pending on clean CI, tests were just started was (Author: e.dimitrova): CASSANDRA-18106 is committed. *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * I will add a table in CASSANDRA-16895 of all current JDK17 tests failures and match them to the different tickets we already have. Most of the time those tickets are not for particular tests fixes but to update dependency or any other issue as those solve more than one problem/test normally. I hope that table will help with clear visibility of where we are and what is needed, at least from CI perspective. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2] Ticket move to PATCH AVAILABLE pending on clean CI, tests were just started > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700937#comment-17700937 ] Ekaterina Dimitrova edited comment on CASSANDRA-18247 at 3/16/23 3:07 AM: -- CASSANDRA-18106 is committed. *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * I will add a table in CASSANDRA-16895 of all current JDK17 tests failures and match them to the different tickets we already have. Most of the time those tickets are not for particular tests fixes but to update dependency or any other issue as those solve more than one problem/test normally. I hope that table will help with clear visibility of where we are and what is needed, at least from CI perspective. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2] , started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run Ticket move to PATCH AVAILABLE pending on clean CI, tests were just started was (Author: e.dimitrova): CASSANDRA-18106 is committed. *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * I will add a table in CASSANDRA-16895 of all current JDK17 tests failures and match them to the different tickets we already have. Most of the time those tickets are not for particular tests fixes but to update dependency or any other issue as those solve more than one problem/test normally. I hope that table will help with clear visibility of where we are and what is needed, at least from CI perspective. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2] , rerun j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run Ticket move to PATCH AVAILABLE pending on clean CI, tests were just started > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cass
[jira] [Commented] (CASSANDRA-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700937#comment-17700937 ] Ekaterina Dimitrova commented on CASSANDRA-18247: - CASSANDRA-18106 is committed. *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * I will add a table in CASSANDRA-16895 of all current JDK17 tests failures and match them to the different tickets we already have. Most of the time those tickets are not for particular tests fixes but to update dependency or any other issue as those solve more than one problem/test normally. I hope that table will help with clear visibility of where we are and what is needed, at least from CI perspective. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2] Ticket move to PATCH AVAILABLE pending on clean CI, tests were just started > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-16906) DOC - Formulae in Evaluating DM page does not display correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-16906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700921#comment-17700921 ] Lorina Poland edited comment on CASSANDRA-16906 at 3/16/23 1:55 AM: Erick, could you please review this ticket? There are two PRs: cassandra-website: [https://github.com/apache/cassandra-website/pull/215] cassandra: [https://github.com/apache/cassandra/pull/2221] I realize that the change will need to be made for 4.0 and possibly 3.x. was (Author: polandll): Erick, could you please review this ticket? There are two PRs: cassandra-website: [https://github.com/apache/cassandra-website/pull/215] cassandra: [https://github.com/apache/cassandra/pull/2221] > DOC - Formulae in Evaluating DM page does not display correctly > --- > > Key: CASSANDRA-16906 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16906 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Takuya inagaki >Assignee: Lorina Poland >Priority: Normal > Labels: doc > Fix For: 5.x > > Attachments: formula-fix-cass-build.png, スクリーンショット 2021-08-31 > 18.03.57.png > > > In latest document, all of formulas does not display correctly. > please refer to the following > [document|https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_refining.html] > and attached image. > > h3. Environment > browser: chrome 92.0.4515.159 > os: macOS Big Sur 11.5.2 > > h3. Slack > [https://the-asf.slack.com/archives/CJZLTM05A/p1630400708095100] > https://the-asf.slack.com/archives/CJZLTM05A/p1630400951095900 -- 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-16366) Fix architecture/storage_engine documentation format
[
https://issues.apache.org/jira/browse/CASSANDRA-16366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorina Poland updated CASSANDRA-16366:
--
Labels: low-hanging-fruit (was: )
> Fix architecture/storage_engine documentation format
>
>
> Key: CASSANDRA-16366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16366
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation
>Reporter: Mateus Dubiela Oliveira
>Priority: Normal
> Labels: low-hanging-fruit
>
> While reading the docs for cassandra I've took the time to fix and improve
> the formatting used in
> [https://cassandra.apache.org/doc/latest/architecture/storage_engine.html.]
> It had inconsistent indentation for the options and their default values.
> Formatting of the *NOTE* sections was also made consistent, removing extra
> {{*}} characters.
> And other small typos on architecure/dynamo and architecture/overview.
--
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-17755) Some information are missing from the SELECT ORDER BY section
[
https://issues.apache.org/jira/browse/CASSANDRA-17755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorina Poland updated CASSANDRA-17755:
--
Labels: low-hanging-fruit (was: )
> Some information are missing from the SELECT ORDER BY section
> -
>
> Key: CASSANDRA-17755
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17755
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: low-hanging-fruit
>
> The documentation does not specify that clustering columns restricted by an
> equality restriction can be omitted from the {{ORDER BY}} clause.
--
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-17911) Auditlog Documentation for 3.11 is wrong
[ https://issues.apache.org/jira/browse/CASSANDRA-17911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-17911: -- Labels: low-hanging-fruit (was: ) > Auditlog Documentation for 3.11 is wrong > > > Key: CASSANDRA-17911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17911 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Matthias Meyer >Priority: Normal > Labels: low-hanging-fruit > > Cassandra 3.11 does not support auditlog feature, but the documenation has a > chapter for Audit, see > [https://cassandra.apache.org/doc/3.11/cassandra/operating/audit_logging.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-18327) Fix link to .tar.gz download in documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorina Poland updated CASSANDRA-18327:
--
Labels: low-hanging-fruit (was: )
> Fix link to .tar.gz download in documentation
> -
>
> Key: CASSANDRA-18327
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18327
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation
>Reporter: Arnout Engelen
>Priority: Normal
> Labels: low-hanging-fruit
>
> On
> [https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html#installing-the-binary-tarball]
> the reader is instructed to:
>
> {{curl -OL
> [http://apache.mirror.digitalpacific.com.au/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz]}}
> However, that mirror no longer exists.
> It would be nicer to use a URL such as
> [https://www.apache.org/dyn/closer.lua/download/cassandra/4.1.0/apache-cassandra-4.1.0-bin.tar.gz],
> but that requires having the current Cassandra version available as a
> variable to asciidoc and inserting in into a code snippet, which I'm not sure
> is easy to do.
> Alternatively we could point people to
> [https://cassandra.apache.org/_/download.html] instead of showing a curl
> command.
--
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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18247: Description: Based on the direction of [this discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], I would like to propose CircleCI config files which can be used to test current trunk with JDK 17 (after I blindly remove the scripted UDFs in another ticket, to be opened soon) (was: Based on the direction of [this discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], I would like to propose a CircleCI config file which can be used to test current trunk with JDK 17 (after I blindly remove the scripted UDFs in another ticket, to be opened soon)) > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18247: Summary: Add CircleCI config files for J11+J17 (was: Add CircleCI config file for J11+J17) > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose a CircleCI config file which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-16906) DOC - Formulae in Evaluating DM page does not display correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-16906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-16906: -- Reviewers: Erick Ramirez Status: Review In Progress (was: Patch Available) Erick, could you please review this ticket? There are two PRs: cassandra-website: [https://github.com/apache/cassandra-website/pull/215] cassandra: [https://github.com/apache/cassandra/pull/2221] > DOC - Formulae in Evaluating DM page does not display correctly > --- > > Key: CASSANDRA-16906 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16906 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Takuya inagaki >Assignee: Lorina Poland >Priority: Normal > Labels: doc > Fix For: 5.x > > Attachments: formula-fix-cass-build.png, スクリーンショット 2021-08-31 > 18.03.57.png > > > In latest document, all of formulas does not display correctly. > please refer to the following > [document|https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_refining.html] > and attached image. > > h3. Environment > browser: chrome 92.0.4515.159 > os: macOS Big Sur 11.5.2 > > h3. Slack > [https://the-asf.slack.com/archives/CJZLTM05A/p1630400708095100] > https://the-asf.slack.com/archives/CJZLTM05A/p1630400951095900 -- 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-16906) DOC - Formulae in Evaluating DM page does not display correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-16906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-16906: -- Test and Documentation Plan: I tested this modification along with a modification in cassandra-website. Status: Patch Available (was: In Progress) > DOC - Formulae in Evaluating DM page does not display correctly > --- > > Key: CASSANDRA-16906 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16906 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Takuya inagaki >Assignee: Lorina Poland >Priority: Normal > Labels: doc > Fix For: 5.x > > Attachments: formula-fix-cass-build.png, スクリーンショット 2021-08-31 > 18.03.57.png > > > In latest document, all of formulas does not display correctly. > please refer to the following > [document|https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_refining.html] > and attached image. > > h3. Environment > browser: chrome 92.0.4515.159 > os: macOS Big Sur 11.5.2 > > h3. Slack > [https://the-asf.slack.com/archives/CJZLTM05A/p1630400708095100] > https://the-asf.slack.com/archives/CJZLTM05A/p1630400951095900 -- 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-16906) DOC - Formulae in Evaluating DM page does not display correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-16906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-16906: -- Attachment: formula-fix-cass-build.png > DOC - Formulae in Evaluating DM page does not display correctly > --- > > Key: CASSANDRA-16906 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16906 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Takuya inagaki >Assignee: Lorina Poland >Priority: Normal > Labels: doc > Fix For: 5.x > > Attachments: formula-fix-cass-build.png, スクリーンショット 2021-08-31 > 18.03.57.png > > > In latest document, all of formulas does not display correctly. > please refer to the following > [document|https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_refining.html] > and attached image. > > h3. Environment > browser: chrome 92.0.4515.159 > os: macOS Big Sur 11.5.2 > > h3. Slack > [https://the-asf.slack.com/archives/CJZLTM05A/p1630400708095100] > https://the-asf.slack.com/archives/CJZLTM05A/p1630400951095900 -- 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-16906) DOC - Formulae in Evaluating DM page does not display correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-16906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700918#comment-17700918
]
Lorina Poland commented on CASSANDRA-16906:
---
Okay, coming back to this ticket, I realized that I had not rebundled the
site-ui, and that is why the build was failing. By first building the bundle
for the CASS-16906 branch of cassandra-website, then building the
cassandra-website using the CASS-16906 branch of cassandra, does in fact, build
just fine.
{code:java}
./run.sh website-ui bundle
./run.sh website build -g -u
cassandra:/Users/lorinapoland/CLONES/polandll-cassandra -b cassandra:CASS-16906
cassandra-website:CASS-16906 {code}
!formula-fix-cass-build.png!
> DOC - Formulae in Evaluating DM page does not display correctly
> ---
>
> Key: CASSANDRA-16906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16906
> Project: Cassandra
> Issue Type: Task
> Components: Documentation
>Reporter: Takuya inagaki
>Assignee: Lorina Poland
>Priority: Normal
> Labels: doc
> Fix For: 5.x
>
> Attachments: formula-fix-cass-build.png, スクリーンショット 2021-08-31
> 18.03.57.png
>
>
> In latest document, all of formulas does not display correctly.
> please refer to the following
> [document|https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_refining.html]
> and attached image.
>
> h3. Environment
> browser: chrome 92.0.4515.159
> os: macOS Big Sur 11.5.2
>
> h3. Slack
> [https://the-asf.slack.com/archives/CJZLTM05A/p1630400708095100]
> https://the-asf.slack.com/archives/CJZLTM05A/p1630400951095900
--
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-18337) Operations.migrateReadRequiredOperations fails due to concurrent access when TransactionStatement is prepared
[
https://issues.apache.org/jira/browse/CASSANDRA-18337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18337:
--
Description:
{code}
java.util.NoSuchElementException
at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
at
org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
at
org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
at
org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
at
org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
at
org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
at
org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
at
org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
{code}
this was caused by having shared mutable state! when we start creating the txn
objects we would also mutate the mutations that had operations that need to be
run in the txn, this has an issue when the txn is run from prepared statements
as the object is shared by multiple threads, causing the array to be mutated
while iterating.
was:
{code}
java.util.NoSuchElementException
at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
at
org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
at
org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
at
org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
at
org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
at
org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
at
org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
at
org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
{code}
> Operations.migrateReadRequiredOperations fails due to concurrent access when
> TransactionStatement is prepared
> -
>
> Key: CASSANDRA-18337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18337
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>
> {code}
> java.util.NoSuchElementException
> at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
> {code}
> this was caused by having shared mutable state! when we start creating the
> txn objects we would also mutate the mutations that had operations that need
> to be run in the txn, this has an issue when the txn is run from prepared
> statements as the object is shared by multiple threads, causing the array to
> be mutated while iterating.
--
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-18337) Operations.migrateReadRequiredOperations fails due to concurrent access when TransactionStatement is prepared
[
https://issues.apache.org/jira/browse/CASSANDRA-18337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18337:
--
Test and Documentation Plan: cluster testing
Status: Patch Available (was: Open)
> Operations.migrateReadRequiredOperations fails due to concurrent access when
> TransactionStatement is prepared
> -
>
> Key: CASSANDRA-18337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18337
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>
> {code}
> java.util.NoSuchElementException
> at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
> {code}
--
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-18337) Operations.migrateReadRequiredOperations fails due to concurrent access when TransactionStatement is prepared
[
https://issues.apache.org/jira/browse/CASSANDRA-18337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18337:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable
Corruption / Loss(12986)
Complexity: Low Hanging Fruit
Discovered By: Fuzz Test
Fix Version/s: 5.x
Severity: Critical
Assignee: David Capwell
Status: Open (was: Triage Needed)
> Operations.migrateReadRequiredOperations fails due to concurrent access when
> TransactionStatement is prepared
> -
>
> Key: CASSANDRA-18337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18337
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>
> {code}
> java.util.NoSuchElementException
> at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
> {code}
--
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-18337) Operations.migrateReadRequiredOperations fails due to concurrent access when TransactionStatement is prepared
David Capwell created CASSANDRA-18337:
-
Summary: Operations.migrateReadRequiredOperations fails due to
concurrent access when TransactionStatement is prepared
Key: CASSANDRA-18337
URL: https://issues.apache.org/jira/browse/CASSANDRA-18337
Project: Cassandra
Issue Type: Bug
Components: Accord
Reporter: David Capwell
{code}
java.util.NoSuchElementException
at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
at
org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
at
org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
at
org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
at
org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
at
org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
at
org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
at
org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
{code}
--
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-18336) Sstables were cleared when restarting
NAIZHEN QUE created CASSANDRA-18336:
---
Summary: Sstables were cleared when restarting
Key: CASSANDRA-18336
URL: https://issues.apache.org/jira/browse/CASSANDRA-18336
Project: Cassandra
Issue Type: Bug
Components: Local/Compaction
Reporter: NAIZHEN QUE
Attachments: system.log.2023-02-21.0
1.When this exception occurs in the system
{code:java}
//
ERROR [CompactionExecutor:351627] 2023-02-21 17:59:20,721
CassandraDaemon.java:581 - Exception in thread
Thread[CompactionExecutor:351627,1,main]
org.apache.cassandra.io.FSReadError: java.io.IOException: Map failed
at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:167)
at
org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:310)
at
org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:246)
at
org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:170)
at
org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:73)
at
org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:61)
at org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:104)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:365)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:337)
at
org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:172)
at
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:124)
at
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:64)
at
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:137)
at
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:193)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
at
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:298)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.io.IOException: Map failed
at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1016)
at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:163)
... 23 common frames omitted
Caused by: java.lang.OutOfMemoryError: Map failed
at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method)
at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1013)
{code}
2.restart the node, Verifying logfile transaction ,All sstables are deleted
{code:java}
// code placeholder
INFO [main] 2023-02-21 18:00:23,350 LogTransaction.java:240 - Unfinished
transaction log, deleting
/historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Index.db
INFO [main] 2023-02-21 18:00:23,615 LogTransaction.java:240 - Unfinished
transaction log, deleting
/historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Data.db
INFO [main] 2023-02-21 18:00:46,504 LogTransaction.java:240 - Unfinished
transaction log, deleting
/historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb_txn_compaction_c923b230-b077-11ed-a081-5d5a5c990823.log
INFO [main] 2023-02-21 18:00:46,510 LogTransaction.java:536 - Verifying
logfile transaction [nb_txn_compaction_461935b0-b1ce-11ed-a081-5d5a5c990823.log
in
/historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b]
INFO [main] 2023-02-21 18:00:46,517 LogTransaction.java:240 - Unfinished
transaction log, deleting
/historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8830658-big-Filter.db
INFO [main] 2023-02-21 18:00:46,517 LogTransaction.java:240 - Unfinished
transaction log, deleting
/historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8830658-big-Index.db
INFO [main] 2023-02-21 18:00:46,518 LogTransaction.java:240 - Unfinished
transaction log, deleting
/historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8830658-big-Data.db
INFO [main] 2023-02-21 18:
[jira] [Updated] (CASSANDRA-18320) Incompatible file system thrown while running Simulator
[
https://issues.apache.org/jira/browse/CASSANDRA-18320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18320:
--
Fix Version/s: 4.1.1
5.0
(was: 5.x)
(was: 4.1.x)
Since Version: 4.1.0
Source Control Link:
https://github.com/apache/cassandra/commit/d5b1483703b53c02fb0e616e58107afb814f9f81
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Incompatible file system thrown while running Simulator
> ---
>
> Key: CASSANDRA-18320
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18320
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.1, 5.0
>
>
> {code}
> java.io.UncheckedIOException
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:831)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:816)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:257)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:381)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:395)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at org.apache.cassandra.io.util.PathUtils.forEach(PathUtils.java:155)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:378)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:395)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at org.apache.cassandra.io.util.PathUtils.forEach(PathUtils.java:155)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:378)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1047)
> at
> org.apache.cassandra.simulator.ClusterSimulation.close(ClusterSimulation.java:816)
> at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:370)
> at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:345)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner.main(PaxosSimulationRunner.java:148)
> at
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest(ShortPaxosSimulationTest.java:33)
> Caused by: java.nio.file.DirectoryNotEmptyException:
> /cassandra/node1/commitlog
> at
> com.google.common.jimfs.FileSystemView.checkEmpty(FileSystemView.java:535)
> at
> com.google.common.jimfs.FileSystemView.checkDeletable(FileSystemView.java:517)
> at
> com.google.common.jimfs.FileSystemView.delete(FileSystemView.java:479)
> at
> com.google.common.jimfs.FileSystemView.deleteFile(FileSystemView.java:465)
> at
> com.google.common.jimfs.JimfsFileSystemProvider.delete(JimfsFileSystemProvider.java:261)
> at java.nio.file.Files.delete(Files.java:1126)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:252)
> {code}
--
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
[cassandra] branch cassandra-4.1 updated: Incompatible file system thrown while running Simulator
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-4.1 by this push:
new d5b1483703 Incompatible file system thrown while running Simulator
d5b1483703 is described below
commit d5b1483703b53c02fb0e616e58107afb814f9f81
Author: David Capwell
AuthorDate: Tue Mar 14 10:36:38 2023 -0700
Incompatible file system thrown while running Simulator
patch by David Capwell; reviewed by Brandon Williams, Caleb Rackliffe for
CASSANDRA-18320
---
checkstyle.xml | 2 +-
.../apache/cassandra/audit/AuditLogOptions.java| 4 +--
.../org/apache/cassandra/audit/BinAuditLogger.java | 4 +--
.../cassandra/hadoop/cql3/CqlConfigHelper.java | 6 ++--
src/java/org/apache/cassandra/io/util/File.java| 9 --
.../org/apache/cassandra/io/util/FileUtils.java| 3 +-
.../security/FileBasedSslContextFactory.java | 5 ++-
.../apache/cassandra/security/JKSKeyProvider.java | 4 +--
.../security/PEMBasedSslContextFactory.java| 3 +-
.../apache/cassandra/service/CassandraDaemon.java | 5 ++-
.../service/FileSystemOwnershipCheck.java | 3 +-
.../apache/cassandra/service/StartupChecks.java| 7 ++--
.../apache/cassandra/service/StorageService.java | 3 +-
.../cassandra/service/snapshot/SnapshotLoader.java | 3 +-
.../cassandra/service/snapshot/TableSnapshot.java | 3 +-
.../org/apache/cassandra/tools/HashPassword.java | 5 +--
.../cassandra/tools/SSTableRepairedAtSetter.java | 3 +-
.../apache/cassandra/tools/StandaloneScrubber.java | 3 +-
.../cassandra/simulator/SimulationException.java | 37 ++
.../cassandra/simulator/SimulationRunner.java | 7 +++-
20 files changed, 78 insertions(+), 41 deletions(-)
diff --git a/checkstyle.xml b/checkstyle.xml
index 06e0cddd90..053cc735ab 100644
--- a/checkstyle.xml
+++ b/checkstyle.xml
@@ -93,7 +93,7 @@
-
diff --git a/src/java/org/apache/cassandra/audit/AuditLogOptions.java
b/src/java/org/apache/cassandra/audit/AuditLogOptions.java
index 8ec066f5b5..e9e31c9040 100644
--- a/src/java/org/apache/cassandra/audit/AuditLogOptions.java
+++ b/src/java/org/apache/cassandra/audit/AuditLogOptions.java
@@ -18,7 +18,6 @@
package org.apache.cassandra.audit;
import java.nio.file.Path;
-import java.nio.file.Paths;
import java.util.Arrays;
import java.util.Collections;
import java.util.Map;
@@ -32,6 +31,7 @@ import org.apache.commons.lang3.StringUtils;
import org.apache.cassandra.config.CassandraRelevantProperties;
import org.apache.cassandra.config.ParameterizedClass;
import org.apache.cassandra.exceptions.ConfigurationException;
+import org.apache.cassandra.io.util.File;
import org.apache.cassandra.utils.binlog.BinLogOptions;
public class AuditLogOptions extends BinLogOptions
@@ -52,7 +52,7 @@ public class AuditLogOptions extends BinLogOptions
{
String auditLogDir =
CassandraRelevantProperties.LOG_DIR_AUDIT.getString();
String logDir = CassandraRelevantProperties.LOG_DIR.getString() +
"/audit";
-Path path = auditLogDir == null ? Paths.get(logDir) :
Paths.get(auditLogDir);
+Path path = auditLogDir == null ? File.getPath(logDir) :
File.getPath(auditLogDir);
audit_logs_dir = path.normalize().toString();
}
diff --git a/src/java/org/apache/cassandra/audit/BinAuditLogger.java
b/src/java/org/apache/cassandra/audit/BinAuditLogger.java
index 7768868742..607d9fee0b 100644
--- a/src/java/org/apache/cassandra/audit/BinAuditLogger.java
+++ b/src/java/org/apache/cassandra/audit/BinAuditLogger.java
@@ -17,7 +17,6 @@
*/
package org.apache.cassandra.audit;
-import java.nio.file.Paths;
import java.util.Map;
import com.google.common.annotations.VisibleForTesting;
@@ -27,6 +26,7 @@ import org.slf4j.LoggerFactory;
import net.openhft.chronicle.wire.WireOut;
import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.io.util.File;
import org.apache.cassandra.utils.ObjectSizes;
import org.apache.cassandra.utils.binlog.BinLog;
import org.apache.cassandra.utils.concurrent.WeightedQueue;
@@ -42,7 +42,7 @@ public class BinAuditLogger implements IAuditLogger
public BinAuditLogger(AuditLogOptions auditLoggingOptions)
{
-this.binLog = new
BinLog.Builder().path(Paths.get(auditLoggingOptions.audit_logs_dir))
+this.binLog = new
BinLog.Builder().path(File.getPath(auditLoggingOptions.audit_logs_dir))
.rollCycle(auditLoggingOptions.roll_cycle)
.blocking(auditLoggingOptions.block)
.maxQueueWeight(auditLoggingOptions.max_queue_weight)
diff --git a/src/java/org/apache/cassandra/hadoop/cql3/CqlConfigHelper.java
b/src/
[cassandra] branch trunk updated (a76286795f -> 92c90cd4ef)
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
from a76286795f Add system_views.max_sstable_size and
system_views.max_sstable_duration tables
new d5b1483703 Incompatible file system thrown while running Simulator
new 92c90cd4ef Merge branch 'cassandra-4.1' into trunk
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
checkstyle.xml | 2 +-
.../apache/cassandra/audit/AuditLogOptions.java| 4 ++--
.../org/apache/cassandra/audit/BinAuditLogger.java | 4 ++--
.../cassandra/config/DatabaseDescriptor.java | 11 +--
.../cassandra/hadoop/cql3/CqlConfigHelper.java | 6 +++---
.../io/sstable/format/SortedTableScrubber.java | 3 +--
src/java/org/apache/cassandra/io/util/File.java| 12 +++
.../security/FileBasedSslContextFactory.java | 5 ++---
.../apache/cassandra/security/JKSKeyProvider.java | 4 ++--
.../security/PEMBasedSslContextFactory.java| 3 +--
.../apache/cassandra/service/CassandraDaemon.java | 5 ++---
.../service/FileSystemOwnershipCheck.java | 3 +--
.../apache/cassandra/service/StartupChecks.java| 7 +++
.../apache/cassandra/service/StorageService.java | 3 +--
.../cassandra/service/snapshot/SnapshotLoader.java | 3 +--
.../cassandra/service/snapshot/TableSnapshot.java | 3 +--
.../org/apache/cassandra/tools/HashPassword.java | 5 +++--
.../cassandra/tools/SSTableRepairedAtSetter.java | 3 +--
src/java/org/apache/cassandra/utils/HeapUtils.java | 3 +--
.../{OrderedOn.java => SimulationException.java} | 23 +-
.../cassandra/simulator/SimulationRunner.java | 7 ++-
21 files changed, 61 insertions(+), 58 deletions(-)
copy test/simulator/main/org/apache/cassandra/simulator/{OrderedOn.java =>
SimulationException.java} (63%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 92c90cd4ef385cab0bd7acfbd9a10261110f85ee
Merge: a76286795f d5b1483703
Author: David Capwell
AuthorDate: Wed Mar 15 16:19:05 2023 -0700
Merge branch 'cassandra-4.1' into trunk
checkstyle.xml | 2 +-
.../apache/cassandra/audit/AuditLogOptions.java| 4 +--
.../org/apache/cassandra/audit/BinAuditLogger.java | 4 +--
.../cassandra/config/DatabaseDescriptor.java | 11 +++
.../cassandra/hadoop/cql3/CqlConfigHelper.java | 6 ++--
.../io/sstable/format/SortedTableScrubber.java | 3 +-
src/java/org/apache/cassandra/io/util/File.java| 12 ---
.../security/FileBasedSslContextFactory.java | 5 ++-
.../apache/cassandra/security/JKSKeyProvider.java | 4 +--
.../security/PEMBasedSslContextFactory.java| 3 +-
.../apache/cassandra/service/CassandraDaemon.java | 5 ++-
.../service/FileSystemOwnershipCheck.java | 3 +-
.../apache/cassandra/service/StartupChecks.java| 7 ++--
.../apache/cassandra/service/StorageService.java | 3 +-
.../cassandra/service/snapshot/SnapshotLoader.java | 3 +-
.../cassandra/service/snapshot/TableSnapshot.java | 3 +-
.../org/apache/cassandra/tools/HashPassword.java | 5 +--
.../cassandra/tools/SSTableRepairedAtSetter.java | 3 +-
src/java/org/apache/cassandra/utils/HeapUtils.java | 3 +-
.../cassandra/simulator/SimulationException.java | 37 ++
.../cassandra/simulator/SimulationRunner.java | 7 +++-
21 files changed, 84 insertions(+), 49 deletions(-)
diff --cc src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index e314f0a677,d2c529c3d4..46b16db90c
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@@ -27,8 -25,6 +27,7 @@@ import java.net.NetworkInterface
import java.net.SocketException;
import java.net.UnknownHostException;
import java.nio.file.FileStore;
+import java.nio.file.Path;
- import java.nio.file.Paths;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Comparator;
@@@ -4585,96 -4398,4 +4584,96 @@@ public class DatabaseDescripto
{
conf.min_tracked_partition_tombstone_count = value;
}
+
+public static boolean getDumpHeapOnUncaughtException()
+{
+return conf.dump_heap_on_uncaught_exception;
+}
+
+/**
+ * @return Whether the path exists (be it created now or already prior)
+ */
+private static boolean maybeCreateHeapDumpPath()
+{
+if (!conf.dump_heap_on_uncaught_exception)
+return false;
+
+Path heap_dump_path = getHeapDumpPath();
+if (heap_dump_path == null)
+{
+logger.warn("Neither -XX:HeapDumpPath nor
cassandra.yaml:heap_dump_path are set; unable to create a directory to hold the
output.");
+return false;
+}
- if (PathUtils.exists(Paths.get(conf.heap_dump_path)))
++if (PathUtils.exists(File.getPath(conf.heap_dump_path)))
+return true;
- return
PathUtils.createDirectoryIfNotExists(Paths.get(conf.heap_dump_path));
++return
PathUtils.createDirectoryIfNotExists(File.getPath(conf.heap_dump_path));
+}
+
+/**
+ * As this is at its heart a debug operation (getting a one-shot heapdump
from an uncaught exception), we support
+ * both the more evolved cassandra.yaml approach but also the -XX param
to override it on a one-off basis so you don't
+ * have to change the full config of a node or a cluster in order to get
a heap dump from a single node that's
+ * misbehaving.
+ * @return the absolute path of the -XX param if provided, else the
heap_dump_path in cassandra.yaml
+ */
+public static Path getHeapDumpPath()
+{
+RuntimeMXBean runtimeMxBean = ManagementFactory.getRuntimeMXBean();
+Optional pathArg =
runtimeMxBean.getInputArguments().stream().filter(s ->
s.startsWith("-XX:HeapDumpPath=")).findFirst();
+
+if (pathArg.isPresent())
+{
+Pattern HEAP_DUMP_PATH_SPLITTER =
Pattern.compile("HeapDumpPath=");
+String fullHeapPathString =
HEAP_DUMP_PATH_SPLITTER.split(pathArg.get())[1];
- Path absolutePath =
Paths.get(fullHeapPathString).toAbsolutePath();
++Path absolutePath =
File.getPath(fullHeapPathString).toAbsolutePath();
+Path basePath = fullHeapPathString.endsWith(".hprof") ?
absolutePath.subpath(0, absolutePath.getNameCount() - 1) : absolutePath;
- return Paths.get("/").resolve(basePath);
++return File.getPath("/").resolve(basePath);
+}
+if (conf.heap_dump_path == null)
+throw new ConfigurationException("Attempted to get he
[jira] [Commented] (CASSANDRA-18320) Incompatible file system thrown while running Simulator
[
https://issues.apache.org/jira/browse/CASSANDRA-18320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700895#comment-17700895
]
David Capwell commented on CASSANDRA-18320:
---
CI is clean, going to start merging
> Incompatible file system thrown while running Simulator
> ---
>
> Key: CASSANDRA-18320
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18320
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> {code}
> java.io.UncheckedIOException
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:831)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:816)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:257)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:381)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:395)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at org.apache.cassandra.io.util.PathUtils.forEach(PathUtils.java:155)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:378)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:395)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at org.apache.cassandra.io.util.PathUtils.forEach(PathUtils.java:155)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:378)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1047)
> at
> org.apache.cassandra.simulator.ClusterSimulation.close(ClusterSimulation.java:816)
> at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:370)
> at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:345)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner.main(PaxosSimulationRunner.java:148)
> at
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest(ShortPaxosSimulationTest.java:33)
> Caused by: java.nio.file.DirectoryNotEmptyException:
> /cassandra/node1/commitlog
> at
> com.google.common.jimfs.FileSystemView.checkEmpty(FileSystemView.java:535)
> at
> com.google.common.jimfs.FileSystemView.checkDeletable(FileSystemView.java:517)
> at
> com.google.common.jimfs.FileSystemView.delete(FileSystemView.java:479)
> at
> com.google.common.jimfs.FileSystemView.deleteFile(FileSystemView.java:465)
> at
> com.google.common.jimfs.JimfsFileSystemProvider.delete(JimfsFileSystemProvider.java:261)
> at java.nio.file.Files.delete(Files.java:1126)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:252)
> {code}
--
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-18319) Cassandra in Kubernetes: IP switch decommission issue
[
https://issues.apache.org/jira/browse/CASSANDRA-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700889#comment-17700889
]
Raymond Huffman commented on CASSANDRA-18319:
-
As one attempt at remediation, I added a call to
`Gossiper.instance.replacementQuarantine(ep)` in `SS.handleStateNormal`, if a
hostId collision is detected, but since this only doubles the value of
QUARANTINE_DELAY, I can still get the issue to appear if I restart the nodes
more slowly during the rolling restart. Presumably there is some value for
QUARANTINE_DELAY that is large enough, but it would probably need to scale with
the number of nodes in the cluster.
> Cassandra in Kubernetes: IP switch decommission issue
> -
>
> Key: CASSANDRA-18319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18319
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ines Potier
>Priority: Normal
> Attachments: 3.11_gossipinfo.zip, node1_gossipinfo.txt,
> test_decommission_after_ip_change_logs.zip,
> v4.0_1678853171792_test_decommission_after_ip_change.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have recently encountered a recurring old IP reappearance issue while
> testing decommissions on some of our Kubernetes Cassandra staging clusters.
> *Issue Description*
> In Kubernetes, a Cassandra node can change IP at each pod bounce. We have
> noticed that this behavior, associated with a decommission operation, can get
> the cluster into an erroneous state.
> Consider the following situation: a Cassandra node {{node1}} , with
> {{{}hostId1{}}}, owning 20.5% of the token ring, bounces and switches IP
> ({{{}old_IP{}}} → {{{}new_IP{}}}). After a couple gossip iterations, all
> other nodes’ nodetool status output includes a {{new_IP}} UN entry owning
> 20.5% of the token ring and no {{old_IP}} entry.
> Shortly after the bounce, {{node1}} gets decommissioned. Our cluster does not
> have a lot of data, and the decommission operation completes pretty quickly.
> Logs on other nodes start showing acknowledgment that {{node1}} has left and
> soon, nodetool status’ {{new_IP}} UL entry disappears. {{node1}} ‘s pod is
> deleted.
> After a minute delay, the cluster enters the erroneous state. An {{old_IP}}
> DN entry reappears in nodetool status, owning 20.5% of the token ring. No
> node owns this IP anymore and according to logs, {{old_IP}} is still
> associated with {{{}hostId1{}}}.
> *Issue Root Cause*
> By digging through Cassandra logs, and re-testing this scenario over and over
> again, we have reached the following conclusion:
> * Other nodes will continue exchanging gossip about {{old_IP}} , even after
> it becomes a fatClient.
> * The fatClient timeout and subsequent quarantine does not stop {{old_IP}}
> from reappearing in a node’s Gossip state, once its quarantine is over. We
> believe that this is due to a misalignment on all nodes’ {{old_IP}}
> expiration time.
> * Once {{new_IP}} has left the cluster, and {{old_IP}} next gossip state
> message is received by a node, StorageService will no longer face collisions
> (or will, but with an even older IP) for {{hostId1}} and its corresponding
> tokens. As a result, {{old_IP}} will regain ownership of 20.5% of the token
> ring.
> *Proposed fix*
> Following the above investigation, we were thinking about implementing the
> following fix:
> When a node receives a gossip status change with {{STATE_LEFT}} for a leaving
> endpoint {{{}new_IP{}}}, before evicting {{{}new_IP from the token ring,
> purge from Gossip (ie evictFromMembership{}}}) all endpoints that meet the
> following criteria:
> * {{endpointStateMap}} contains this endpoint
> * The endpoint is not currently a token owner
> ({{{}!tokenMetadata.isMember(endpoint){}}})
> * The endpoint’s {{hostId}} matches the {{hostId}} of {{new_IP}}
> * The endpoint is older than {{leaving_IP}}
> ({{{}Gossiper.instance.compareEndpointStartup{}}})
> * The endpoint’s token range (from {{{}endpointStateMap{}}}) intersects with
> {{{}new_IP{}}}’s
> This modification’s intention is to force nodes to realign on {{old_IP}}
> expiration, and expunge it from Gossip so it does not reappear after
> {{new_IP}} leaves the ring.
> Another approach we have also been considering is expunging {{old_IP}} at the
> moment of the StorageService collision resolution.
--
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
[cassandra-website] branch asf-staging updated (69dbf78d -> 561c27c8)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 69dbf78d generate docs for c4206294 new 561c27c8 generate docs for c4206294 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (69dbf78d) \ N -- N -- N refs/heads/asf-staging (561c27c8) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18319) Cassandra in Kubernetes: IP switch decommission issue
[
https://issues.apache.org/jira/browse/CASSANDRA-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700384#comment-17700384
]
Raymond Huffman edited comment on CASSANDRA-18319 at 3/15/23 9:39 PM:
--
I've implemented a DTest here that reproduces the issue.
[https://github.com/apache/cassandra-dtest/pull/215] I've confirmed that this
test fails on v3.0.28, v3.11.14, v4.0.8, and v4.1.0. Logs from these tests are
attached. [^test_decommission_after_ip_change_logs.zip]
In the tests, the node at 127.0.0.6 changes to 127.0.0.9.
This test performs the following:
* creates a 6 node cluster
* changes the IP of Node6 from {{127.0.0.6}} to {{127.0.0.9}}
* performs a rolling restart on the cluster
* decommissions Node6
* asserts that the log {{"Node /127.0.0.6 is now part of the cluster"}} does
not appear after the rolling restart.
Running nodetool status a few seconds after the decommission looks like this:
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
– Address Load Tokens Owns (effective) Host ID
Rack
UN 127.0.0.1 188.92 KiB 1 16.7%
82d3d6c1-c4c8-4bdc-afc5-5827cd17544a rack1
UN 127.0.0.2 162.84 KiB 1 16.7%
1399d77b-06d0-4d3b-9248-dbe24486a310 rack1
UN 127.0.0.3 162.07 KiB 1 16.7%
1289aa44-e4a6-422f-ab72-b5daf53a55d2 rack1
UN 127.0.0.4 162.48 KiB 1 16.7%
b38c9f92-b651-4660-941c-ca2072d24501 rack1
UN 127.0.0.5 188.36 KiB 1 16.7%
7125bfc7-a519-419b-ab1a-e9995aed40d9 rack1
?N 127.0.0.6 110.25 KiB 1 16.7%
29cbf560-7686-49f6-a06a-7184ebd42aa2 rack1
Gossipinfo looks like this: [^3.11_gossipinfo.zip]|
was (Author: JIRAUSER299246):
I've implemented a DTest here that reproduces the issue.
[https://github.com/apache/cassandra-dtest/pull/215] I've confirmed that this
test fails on v3.0.28, v3.11.14, and v4.0.8. Logs from these tests are
attached. [^test_decommission_after_ip_change_logs.zip]
In the tests, the node at 127.0.0.6 changes to 127.0.0.9.
This test performs the following:
* creates a 6 node cluster
* changes the IP of Node6 from {{127.0.0.6}} to {{127.0.0.9}}
* performs a rolling restart on the cluster
* decommissions Node6
* asserts that the log {{"Node /127.0.0.6 is now part of the cluster"}} does
not appear after the rolling restart.
Running nodetool status a few seconds after the decommission looks like this:
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
– Address Load Tokens Owns (effective) Host ID
Rack
UN 127.0.0.1 188.92 KiB 1 16.7%
82d3d6c1-c4c8-4bdc-afc5-5827cd17544a rack1
UN 127.0.0.2 162.84 KiB 1 16.7%
1399d77b-06d0-4d3b-9248-dbe24486a310 rack1
UN 127.0.0.3 162.07 KiB 1 16.7%
1289aa44-e4a6-422f-ab72-b5daf53a55d2 rack1
UN 127.0.0.4 162.48 KiB 1 16.7%
b38c9f92-b651-4660-941c-ca2072d24501 rack1
UN 127.0.0.5 188.36 KiB 1 16.7%
7125bfc7-a519-419b-ab1a-e9995aed40d9 rack1
?N 127.0.0.6 110.25 KiB 1 16.7%
29cbf560-7686-49f6-a06a-7184ebd42aa2 rack1
Gossipinfo looks like this: [^3.11_gossipinfo.zip]|
> Cassandra in Kubernetes: IP switch decommission issue
> -
>
> Key: CASSANDRA-18319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18319
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ines Potier
>Priority: Normal
> Attachments: 3.11_gossipinfo.zip, node1_gossipinfo.txt,
> test_decommission_after_ip_change_logs.zip,
> v4.0_1678853171792_test_decommission_after_ip_change.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have recently encountered a recurring old IP reappearance issue while
> testing decommissions on some of our Kubernetes Cassandra staging clusters.
> *Issue Description*
> In Kubernetes, a Cassandra node can change IP at each pod bounce. We have
> noticed that this behavior, associated with a decommission operation, can get
> the cluster into an erroneous state.
> Consider the following situation: a Cassandra node {{node1}} , with
> {{{}hostId1{}}}, owning 20.5% of the token ring, bounces and switches IP
> ({{{}old_IP{}}} → {{{}new_IP{}}}). After a couple gossip iterations, all
> other nodes’ nodetool status output includes a {{new_IP}} UN entry owning
> 20.5% of the token ring and no {{old_IP}} entry.
> Shortly after the bounce, {{node1}} gets decommissioned. Our cluster does not
> have a lot of data, and the decommission operation completes pretty qui
[jira] [Updated] (CASSANDRA-18333) Add max_sstable_size and max_sstable_duration metrics virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18333: -- Fix Version/s: 5.0 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/a76286795f4b79da46d8d937e1d697c43144 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add max_sstable_size and max_sstable_duration metrics virtual tables > > > Key: CASSANDRA-18333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18333 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We added max_sstable_size and max_sstable_duration metrics in CASSANDRA-18283 > however there are not system_views vtables for these metrics yet. -- 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-18333) Add max_sstable_size and max_sstable_duration metrics virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18333: -- Status: Ready to Commit (was: Review In Progress) > Add max_sstable_size and max_sstable_duration metrics virtual tables > > > Key: CASSANDRA-18333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18333 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > We added max_sstable_size and max_sstable_duration metrics in CASSANDRA-18283 > however there are not system_views vtables for these metrics yet. -- 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-18333) Add max_sstable_size and max_sstable_duration metrics virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18333: -- Reviewers: Brandon Williams Status: Review In Progress (was: Patch Available) > Add max_sstable_size and max_sstable_duration metrics virtual tables > > > Key: CASSANDRA-18333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18333 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > We added max_sstable_size and max_sstable_duration metrics in CASSANDRA-18283 > however there are not system_views vtables for these metrics yet. -- 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
[cassandra] branch trunk updated: Add system_views.max_sstable_size and system_views.max_sstable_duration tables
This is an automated email from the ASF dual-hosted git repository.
smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new a76286795f Add system_views.max_sstable_size and
system_views.max_sstable_duration tables
a76286795f is described below
commit a76286795f4b79da46d8d937e1d697c43144
Author: Stefan Miklosovic
AuthorDate: Tue Mar 14 21:45:15 2023 +0100
Add system_views.max_sstable_size and system_views.max_sstable_duration
tables
patch by Stefan Miklosovic; reviewed by Brandon Williams for CASSANDRA-18333
---
CHANGES.txt| 1 +
NEWS.txt | 1 +
.../cassandra/db/virtual/TableMetricTables.java| 4 +-
.../org/apache/cassandra/metrics/TableMetrics.java | 2 +-
.../tools/nodetool/stats/TableStatsHolder.java | 2 +-
.../apache/cassandra/metrics/TableMetricsTest.java | 44 ++
6 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index f2b23b1f02..ae7420fbbe 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
5.0
+ * Add system_views.max_sstable_size and system_views.max_sstable_duration
tables (CASSANDRA-18333)
* Extend implicit allow-filtering for virtual tables to clustering columns
(CASSANDRA-18331)
* Upgrade maven-shade-plugin to 3.4.1 to fix shaded dtest JAR build
(CASSANDRA-18136)
* Upgrade to Opcodes.ASM9 (CASSANDRA-17971)
diff --git a/NEWS.txt b/NEWS.txt
index ef582b6aa2..4dc0fe8cc7 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -130,6 +130,7 @@ New features
SSTable of a table or 0 when there is not any SSTable. The latter
returns the maximum duration, computed as
`maxTimestamp - minTimestamp`, effectively non-zero for SSTables
produced by TimeWindowCompactionStrategy.
- Added local read/write ratio to tablestats.
+- Added system_views.max_sstable_size and
system_views.max_sstable_duration tables.
Upgrading
-
diff --git a/src/java/org/apache/cassandra/db/virtual/TableMetricTables.java
b/src/java/org/apache/cassandra/db/virtual/TableMetricTables.java
index 9ff421c188..8368fd9ae5 100644
--- a/src/java/org/apache/cassandra/db/virtual/TableMetricTables.java
+++ b/src/java/org/apache/cassandra/db/virtual/TableMetricTables.java
@@ -77,7 +77,9 @@ public class TableMetricTables
new HistogramTableMetric(name, "tombstones_per_read", t ->
t.tombstoneScannedHistogram.cf),
new HistogramTableMetric(name, "rows_per_read", t ->
t.liveScannedHistogram.cf),
new StorageTableMetric(name, "disk_usage", (TableMetrics t) ->
t.totalDiskSpaceUsed),
-new StorageTableMetric(name, "max_partition_size", (TableMetrics
t) -> t.maxPartitionSize));
+new StorageTableMetric(name, "max_partition_size", (TableMetrics
t) -> t.maxPartitionSize),
+new StorageTableMetric(name, "max_sstable_size", (TableMetrics t)
-> t.maxSSTableSize),
+new TableMetricTable(name, "max_sstable_duration", t ->
t.maxSSTableDuration, "max_sstable_duration", LongType.instance, ""));
}
/**
diff --git a/src/java/org/apache/cassandra/metrics/TableMetrics.java
b/src/java/org/apache/cassandra/metrics/TableMetrics.java
index a8947aa388..dc90318e19 100644
--- a/src/java/org/apache/cassandra/metrics/TableMetrics.java
+++ b/src/java/org/apache/cassandra/metrics/TableMetrics.java
@@ -649,7 +649,7 @@ public class TableMetrics
.filter(sstable -> sstable.getMinTimestamp() !=
Long.MAX_VALUE && sstable.getMaxTimestamp() != Long.MAX_VALUE)
.map(ssTableReader ->
ssTableReader.getMaxTimestamp() - ssTableReader.getMinTimestamp())
.max(Long::compare)
- .orElse(0L);
+ .orElse(0L) / 1000;
}
});
maxSSTableSize = createTableGauge("MaxSSTableSize", new Gauge()
diff --git
a/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java
b/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java
index d15948cc9b..d9eece9afa 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java
@@ -433,7 +433,7 @@ public class TableStatsHolder implements StatsHolder
private String millisToDuration(long millis)
{
-return DurationFormatUtils.formatDurationWords(millis / 1000, true,
true);
+return DurationFormatUtils.formatDurationWords(millis, true, true);
}
/**
diff --git a/test/unit/org/apache/cassandra/metrics/TableMetricsTest.java
b/test/unit/org/apache/cassandra/metrics/TableMetricsTest.java
index 4c9de77207..bbcced43db 100644
--- a/test/unit/org/apache/cassandra/metrics/TableMetricsTest.java
+++ b/test/unit/org/apac
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700856#comment-17700856
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
thanks [~samt], frankly the PR has only few locs :)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700855#comment-17700855 ] Jacek Lewandowski commented on CASSANDRA-18302: --- ok, done, please take a look > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- 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-18213) CEP-15: (Accord) Migrate Accord away from JDK random to a new interface RandomSource
[ https://issues.apache.org/jira/browse/CASSANDRA-18213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18213: -- Fix Version/s: 5.0 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/ea01634739ef09ceef567259637d07095447b28c Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: (Accord) Migrate Accord away from JDK random to a new interface > RandomSource > > > Key: CASSANDRA-18213 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18213 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > JDK Random has basic functions needed, but is lacking and requires custom > utils to add some added methods desired (such as > next[short,int,long,float,double] in a range), so to deal with this we should > own the random interface we use. > This has 2 main context points for accord: Node (breaking API change), and > BurnTest. > By owning our own interface, we could also have C* Simulator’s RandomSource > “extend” it so we don’t have to redefine everything cross both repos. -- 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
[cassandra] branch cep-15-accord updated: CEP-15: (Accord) Migrate Accord away from JDK random to a new interface RandomSource
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cep-15-accord
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cep-15-accord by this push:
new ea01634739 CEP-15: (Accord) Migrate Accord away from JDK random to a
new interface RandomSource
ea01634739 is described below
commit ea01634739ef09ceef567259637d07095447b28c
Author: David Capwell
AuthorDate: Thu Mar 9 18:05:20 2023 -0800
CEP-15: (Accord) Migrate Accord away from JDK random to a new interface
RandomSource
patch by David Capwell; reviewed by Blake Eggleston for CASSANDRA-18213
---
modules/accord | 2 +-
.../cassandra/service/accord/AccordService.java| 4 ++--
.../service/accord/async/AsyncOperationTest.java | 5 +++--
.../serializers/CommandsForKeySerializerTest.java | 3 ++-
.../apache/cassandra/utils/AccordGenerators.java | 26 ++
5 files changed, 10 insertions(+), 30 deletions(-)
diff --git a/modules/accord b/modules/accord
index f607a05b76..bc81f81c75 16
--- a/modules/accord
+++ b/modules/accord
@@ -1 +1 @@
-Subproject commit f607a05b76df32b39c97a6e49068ae35057be98a
+Subproject commit bc81f81c75f93c73989a30bbc51b5c241a893c1a
diff --git a/src/java/org/apache/cassandra/service/accord/AccordService.java
b/src/java/org/apache/cassandra/service/accord/AccordService.java
index 7e68da36b0..a86cb70c53 100644
--- a/src/java/org/apache/cassandra/service/accord/AccordService.java
+++ b/src/java/org/apache/cassandra/service/accord/AccordService.java
@@ -19,7 +19,6 @@
package org.apache.cassandra.service.accord;
import java.util.Arrays;
-import java.util.Random;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
@@ -40,6 +39,7 @@ import accord.messages.Request;
import accord.primitives.Txn;
import accord.primitives.TxnId;
import accord.topology.TopologyManager;
+import accord.utils.DefaultRandom;
import accord.utils.async.AsyncChains;
import org.apache.cassandra.concurrent.Shutdownable;
import accord.utils.async.AsyncResult;
@@ -144,7 +144,7 @@ public class AccordService implements IAccordService,
Shutdownable
() -> null,
new KeyspaceSplitter(new
EvenSplit<>(getConcurrentAccordOps(), getPartitioner().accordSplitter())),
new AccordAgent(),
- new Random(),
+ new DefaultRandom(),
scheduler,
SizeOfIntersectionSorter.SUPPLIER,
SimpleProgressLog::new,
diff --git
a/test/unit/org/apache/cassandra/service/accord/async/AsyncOperationTest.java
b/test/unit/org/apache/cassandra/service/accord/async/AsyncOperationTest.java
index c51afa6412..b76793aaf7 100644
---
a/test/unit/org/apache/cassandra/service/accord/async/AsyncOperationTest.java
+++
b/test/unit/org/apache/cassandra/service/accord/async/AsyncOperationTest.java
@@ -62,6 +62,7 @@ import accord.primitives.TxnId;
import accord.primitives.Writes;
import accord.utils.Gen;
import accord.utils.Gens;
+import accord.utils.RandomSource;
import accord.utils.async.AsyncChains;
import accord.utils.async.AsyncResult;
import org.apache.cassandra.SchemaLoader;
@@ -481,7 +482,7 @@ public class AsyncOperationTest
});
}
-private static void createCommand(AccordCommandStore commandStore,
Gen.Random rs, List ids)
+private static void createCommand(AccordCommandStore commandStore,
RandomSource rs, List ids)
{
// to simulate CommandsForKey not being found, use
createCommittedAndPersist periodically as it does not update
if (rs.nextBoolean()) ids.forEach(id ->
createCommittedAndPersist(commandStore, id));
@@ -489,7 +490,7 @@ public class AsyncOperationTest
commandStore.clearCache();
}
-private static Map selectFailedTxn(Gen.Random rs,
List ids)
+private static Map selectFailedTxn(RandomSource rs,
List ids)
{
Map failed =
Maps.newHashMapWithExpectedSize(ids.size());
for (TxnId id : ids)
diff --git
a/test/unit/org/apache/cassandra/service/accord/serializers/CommandsForKeySerializerTest.java
b/test/unit/org/apache/cassandra/service/accord/serializers/CommandsForKeySerializerTest.java
index 1cc800f5dc..547b03c10c 100644
---
a/test/unit/org/apache/cassandra/service/accord/serializers/CommandsForKeySerializerTest.java
+++
b/test/unit/org/apache/cassandra/service/accord/serializers/CommandsForKeySerializerTest.java
@@ -26,6 +26,7 @@ import org.junit.Test;
import accord.impl.CommandsForKey;
import accord.primitives.TxnId;
+import accord.utils.AccordGens;
import accord.utils.Gens;
import org.apache.cassandra.SchemaLoader;
import org.apache.cassandra.io.util.DataInputBuffer;
@@ -56,7 +5
[cassandra-accord] branch trunk updated: CEP-15: (Accord) Migrate Accord away from JDK random to a new interface RandomSource
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git
The following commit(s) were added to refs/heads/trunk by this push:
new bc81f81c CEP-15: (Accord) Migrate Accord away from JDK random to a new
interface RandomSource
bc81f81c is described below
commit bc81f81c75f93c73989a30bbc51b5c241a893c1a
Author: David Capwell
AuthorDate: Thu Jan 26 12:06:53 2023 -0800
CEP-15: (Accord) Migrate Accord away from JDK random to a new interface
RandomSource
patch by David Capwell; reviewed by Blake Eggleston for CASSANDRA-18213
---
accord-core/build.gradle | 3 -
accord-core/src/main/java/accord/local/Node.java | 10 +-
.../src/main/java/accord/primitives/RangeDeps.java | 9 +-
.../src/main/java/accord/utils/DefaultRandom.java | 44 ++--
.../src/main/java/accord/utils/RandomSource.java | 269 +
.../main/java/accord/utils/RelationMultiMap.java | 4 +-
.../java/accord/utils/WrappedRandomSource.java | 97
.../src/test/java/accord/burn/BurnTest.java| 25 +-
.../accord/burn/BurnTestConfigurationService.java | 13 +-
.../accord/burn/random/FrequentLargeRange.java | 76 ++
.../src/test/java/accord/burn/random/IntRange.java | 41 ++--
.../test/java/accord/burn/random/RandomInt.java| 36 +--
.../test/java/accord/burn/random/RandomLong.java | 34 +--
.../java/accord/burn/random/RandomRangeTest.java | 83 +++
.../java/accord/burn/random/RandomWalkRange.java | 61 +
.../burn/random/SegmentedRandomRangeTest.java | 182 ++
.../tracking/FastPathTrackerReconciler.java| 7 +-
.../tracking/InvalidationTrackerReconciler.java| 6 +-
.../tracking/QuorumTrackerReconciler.java | 6 +-
.../coordinate/tracking/ReadTrackerReconciler.java | 6 +-
.../tracking/RecoveryTrackerReconciler.java| 6 +-
.../coordinate/tracking/TrackerReconciler.java | 18 +-
.../coordinate/tracking/TrackerReconcilerTest.java | 6 +-
.../src/test/java/accord/impl/basic/Cluster.java | 10 +-
.../src/test/java/accord/impl/basic/NodeSink.java | 6 +-
.../java/accord/impl/basic/RandomDelayQueue.java | 13 +-
.../java/accord/impl/basic/UniformRandomQueue.java | 13 +-
.../test/java/accord/impl/mock/MockCluster.java| 9 +-
.../java/accord/local/ImmutableCommandTest.java| 5 +-
.../test/java/accord/messages/PreAcceptTest.java | 4 +-
.../test/java/accord/primitives/KeyDepsTest.java | 41 ++--
.../java/accord/topology/TopologyRandomizer.java | 37 ++-
.../src/test/java/accord/utils/AccordGens.java | 154
accord-core/src/test/java/accord/utils/Gen.java| 108 +++--
accord-core/src/test/java/accord/utils/Gens.java | 145 ++-
.../src/test/java/accord/utils/Property.java | 58 -
accord-maelstrom/build.gradle | 2 +-
.../src/main/java/accord/maelstrom/Cluster.java| 24 +-
.../src/main/java/accord/maelstrom/Datum.java | 16 ++
.../src/main/java/accord/maelstrom/Json.java | 82 ---
.../main/java/accord/maelstrom/MaelstromKey.java | 16 ++
.../src/main/java/accord/maelstrom/Main.java | 4 +-
.../src/test/java/accord/maelstrom/JsonTest.java | 90 +++
.../src/test/java/accord/maelstrom/Runner.java | 244 +--
.../java/accord/maelstrom/SimpleRandomTest.java| 58 ++---
.../src/main/groovy/accord.java-conventions.gradle | 2 +
46 files changed, 1618 insertions(+), 565 deletions(-)
diff --git a/accord-core/build.gradle b/accord-core/build.gradle
index e92e62b5..3c1472bc 100644
--- a/accord-core/build.gradle
+++ b/accord-core/build.gradle
@@ -18,9 +18,6 @@
plugins {
id 'accord.java-conventions'
-// export test classes for subprojects
-id 'java-library'
-id 'java-test-fixtures'
id 'maven-publish'
}
diff --git a/accord-core/src/main/java/accord/local/Node.java
b/accord-core/src/main/java/accord/local/Node.java
index 344e10b9..fbf59874 100644
--- a/accord-core/src/main/java/accord/local/Node.java
+++ b/accord-core/src/main/java/accord/local/Node.java
@@ -18,7 +18,10 @@
package accord.local;
-import java.util.*;
+import java.util.Collection;
+import java.util.HashSet;
+import java.util.Map;
+import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicReference;
import java.util.function.BiConsumer;
@@ -35,6 +38,7 @@ import accord.utils.MapReduceConsume;
import accord.utils.async.AsyncChain;
import accord.utils.async.AsyncResult;
import accord.utils.async.AsyncResults;
+import accord.utils.RandomSource;
import com.google.common.annotations.VisibleForTesting;
import accord.api.*;
@@ -119,7 +123,7 @@ public class Node implements ConfigurationService.Listener,
NodeTimeService
private final LongSupplier nowSupplie
[jira] [Commented] (CASSANDRA-18333) Add max_sstable_size and max_sstable_duration metrics virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700846#comment-17700846 ] Brandon Williams commented on CASSANDRA-18333: -- No failures except our old friend CASSANDRA-16677, +1. > Add max_sstable_size and max_sstable_duration metrics virtual tables > > > Key: CASSANDRA-18333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18333 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > We added max_sstable_size and max_sstable_duration metrics in CASSANDRA-18283 > however there are not system_views vtables for these metrics yet. -- 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-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700826#comment-17700826 ] David Capwell commented on CASSANDRA-18302: --- that works for me. Ill create a ticket that asCQL is still broken as this impacts 4.1 and trunk > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- 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-18333) Add max_sstable_size and max_sstable_duration metrics virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700824#comment-17700824 ] Stefan Miklosovic commented on CASSANDRA-18333: --- [~brandon.williams] builds are finished. > Add max_sstable_size and max_sstable_duration metrics virtual tables > > > Key: CASSANDRA-18333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18333 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > We added max_sstable_size and max_sstable_duration metrics in CASSANDRA-18283 > however there are not system_views vtables for these metrics yet. -- 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-18320) Incompatible file system thrown while running Simulator
[
https://issues.apache.org/jira/browse/CASSANDRA-18320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700814#comment-17700814
]
David Capwell commented on CASSANDRA-18320:
---
CI was unstable yesterday so triggered new circle build to see if things are
better now
> Incompatible file system thrown while running Simulator
> ---
>
> Key: CASSANDRA-18320
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18320
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> {code}
> java.io.UncheckedIOException
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:831)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:816)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:257)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:381)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:395)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at org.apache.cassandra.io.util.PathUtils.forEach(PathUtils.java:155)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:378)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:395)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at org.apache.cassandra.io.util.PathUtils.forEach(PathUtils.java:155)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:378)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1047)
> at
> org.apache.cassandra.simulator.ClusterSimulation.close(ClusterSimulation.java:816)
> at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:370)
> at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:345)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner.main(PaxosSimulationRunner.java:148)
> at
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest(ShortPaxosSimulationTest.java:33)
> Caused by: java.nio.file.DirectoryNotEmptyException:
> /cassandra/node1/commitlog
> at
> com.google.common.jimfs.FileSystemView.checkEmpty(FileSystemView.java:535)
> at
> com.google.common.jimfs.FileSystemView.checkDeletable(FileSystemView.java:517)
> at
> com.google.common.jimfs.FileSystemView.delete(FileSystemView.java:479)
> at
> com.google.common.jimfs.FileSystemView.deleteFile(FileSystemView.java:465)
> at
> com.google.common.jimfs.JimfsFileSystemProvider.delete(JimfsFileSystemProvider.java:261)
> at java.nio.file.Files.delete(Files.java:1126)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:252)
> {code}
--
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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700813#comment-17700813
]
Sam Tunnicliffe commented on CASSANDRA-18153:
-
[~jlewandowski] , I'm afraid I haven't looked at the actual PR yet, I was going
only from your comments here. I'll do my best to check it out tomorrow, but
don't block on that.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700807#comment-17700807
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
[~samt] can I consider it as your review +1 on that?
[~smiklosovic] - are you ok with the fix?
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700806#comment-17700806 ] Jacek Lewandowski commented on CASSANDRA-18302: --- Ok guys, let me finish that - can I just remove storing the raw string (with the current version it will be trivial, just don't create the source text) and avoid printing strings entirely, letting the user to rely on line/position in line? > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- 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-18228) Reorganize Apache C* docs in trunk branch to match the IA
[ https://issues.apache.org/jira/browse/CASSANDRA-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-18228: -- Status: Review In Progress (was: Patch Available) > Reorganize Apache C* docs in trunk branch to match the IA > - > > Key: CASSANDRA-18228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18228 > Project: Cassandra > Issue Type: New Feature > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 5.x > > > An agreed-upon Information Architecture will be used to reorganize the C* 5.0 > docs. > IA doc: > https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing -- 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-18228) Reorganize Apache C* docs in trunk branch to match the IA
[ https://issues.apache.org/jira/browse/CASSANDRA-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-18228: -- Test and Documentation Plan: N/A Status: Patch Available (was: In Progress) > Reorganize Apache C* docs in trunk branch to match the IA > - > > Key: CASSANDRA-18228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18228 > Project: Cassandra > Issue Type: New Feature > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 5.x > > > An agreed-upon Information Architecture will be used to reorganize the C* 5.0 > docs. > IA doc: > https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing -- 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-18302) Fix AIOOBE and improve validation messages for transaction statements
[
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700798#comment-17700798
]
Caleb Rackliffe edited comment on CASSANDRA-18302 at 3/15/23 5:47 PM:
--
So I was almost going to propose that we keep the start/end {{Token}} and
{{TokenStream}} around to _actually_ lazily create our error messages, but
that's even worse than creating and keeping around a raw string per statement.
The original motivation for the lazy evaluation was that {{asCQL()}} would be
too expensive to call on every transaction, when most of the time it wouldn't
be used anyway. With {{describe()}} the extra allocations have already
happened, so the damage is done.
At this point, unless there's a way to avoid creating strings for the raw CQL
for every statement that we won't use 99.99% of the time, I'm still essentially
in favor of doing [what I mentioned
above|https://issues.apache.org/jira/browse/CASSANDRA-18302?focusedCommentId=17700416&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17700416].
I know that doesn't go as far to help w/ normal batch statement error messages
(although they could take advantage of line numbers, which look cheap).
Perhaps later we can expand this once we've merged to trunk and the entire CQL
integration is in its final form?
was (Author: maedhroz):
So I was almost going to propose that we keep the start/end {{Token}} and
{{TokenStream}} around to _actually_ lazily create our error messages, but
that's even worse than creating and keeping around a raw string per statement.
The original motivation for the lazy evaluation was that {{asCQL()}} would be
too expensive to call on every transaction, when most of the time it wouldn't
be used anyway. With {{describe()}} the extra allocations have already
happened, so the damage is done.
At this point, unless there's a way to avoid creating strings for the raw CQL
for every statement that we won't use 99.99% of the time, I'm still essentially
in favor of doing [what I mentioned
above|https://issues.apache.org/jira/browse/CASSANDRA-18302?focusedCommentId=17700416&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17700416].
I know that doesn't go as far to help w/ normal batch statement error messages
(although they could take advantage of line numbers, which look cheap).
> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown
> from asCql method when validation transaction statement. In addition, asCql
> does not return precisely the query user entered so the whole error message
> can be misleading.
--
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-18302) Fix AIOOBE and improve validation messages for transaction statements
[
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700798#comment-17700798
]
Caleb Rackliffe commented on CASSANDRA-18302:
-
So I was almost going to propose that we keep the start/end {{Token}} and
{{TokenStream}} around to _actually_ lazily create our error messages, but
that's even worse than creating and keeping around a raw string per statement.
The original motivation for the lazy evaluation was that {{asCQL()}} would be
too expensive to call on every transaction, when most of the time it wouldn't
be used anyway. With {{describe()}} the extra allocations have already
happened, so the damage is done.
At this point, unless there's a way to avoid creating strings for the raw CQL
for every statement that we won't use 99.99% of the time, I'm still essentially
in favor of doing [what I mentioned
above|https://issues.apache.org/jira/browse/CASSANDRA-18302?focusedCommentId=17700416&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17700416].
I know that doesn't go as far to help w/ normal batch statement error messages
(although they could take advantage of line numbers, which look cheap).
> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown
> from asCql method when validation transaction statement. In addition, asCql
> does not return precisely the query user entered so the whole error message
> can be misleading.
--
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] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302 ]
Caleb Rackliffe deleted comment on CASSANDRA-18302:
-
was (Author: maedhroz):
Looking at the update patch...
It seems like all we need to get the original statement are the arguments
passed to {{StatementSource.create()}}. (i.e. the start/end tokens and the
token stream) What if we just held those in the {{StatementSource}} until we
needed them in {{describe()}}, which I see is now being called lazily. In that
case, can't we avoid materializing those strings until we actually have to
report an error?
> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown
> from asCql method when validation transaction statement. In addition, asCql
> does not return precisely the query user entered so the whole error message
> can be misleading.
--
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-18302) Fix AIOOBE and improve validation messages for transaction statements
[
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700788#comment-17700788
]
Caleb Rackliffe commented on CASSANDRA-18302:
-
Looking at the update patch...
It seems like all we need to get the original statement are the arguments
passed to {{StatementSource.create()}}. (i.e. the start/end tokens and the
token stream) What if we just held those in the {{StatementSource}} until we
needed them in {{describe()}}, which I see is now being called lazily. In that
case, can't we avoid materializing those strings until we actually have to
report an error?
> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown
> from asCql method when validation transaction statement. In addition, asCql
> does not return precisely the query user entered so the whole error message
> can be misleading.
--
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-18302) Fix AIOOBE and improve validation messages for transaction statements
[
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700783#comment-17700783
]
David Capwell commented on CASSANDRA-18302:
---
bq. Regarding `asCQL` there more examples which show that this is invalid, and
actually cannot be, because asCQL is applied to the read command, that is, what
we really read from the sstables/memtables. For example, for a select k, c, v
... it will print only select v ... }}, for a {{select ttl(v), writetime(v)...
it will print select v Also, there is no such method for modification
statements so in case of errors there the messages do not include any pointer
to the broken query - although I missed that and haven't fixed, I can do that
with easily
Maybe another solution is to take advantage of Transactions being sequential
and also has LET statements... so rather than showing the CQL (as this is
proving more annoying than it should be) we show the user which LET, return
select, or mutation index?
So we convert
{code}
for (NamedSelect assignment : assignments)
checkFalse(isSelectingMultipleClusterings(assignment.select,
options), INCOMPLETE_PRIMARY_KEY_SELECT_MESSAGE, "LET assignment", lazy(() ->
assignment.select.source.describe(false)));
{code}
to
{code}
for (NamedSelect assignment : assignments)
checkFalse(isSelectingMultipleClusterings(assignment.select,
options), INCOMPLETE_PRIMARY_KEY_SELECT_MESSAGE, "LET assignment",
assignment.name.name());
{code}
{code}
if (returningSelect != null)
checkFalse(isSelectingMultipleClusterings(returningSelect.select, options),
INCOMPLETE_PRIMARY_KEY_SELECT_MESSAGE, "returning SELECT", lazy(() ->
returningSelect.select.source.describe(false)));
{code}
to
{code}
if (returningSelect != null)
checkFalse(isSelectingMultipleClusterings(returningSelect.select, options),
INCOMPLETE_PRIMARY_KEY_SELECT_MESSAGE, "returning SELECT");
{code}
etc this gives the user all the details they need to know which statements
are an issue
> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown
> from asCql method when validation transaction statement. In addition, asCql
> does not return precisely the query user entered so the whole error message
> can be misleading.
--
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-18302) Fix AIOOBE and improve validation messages for transaction statements
[
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700781#comment-17700781
]
David Capwell commented on CASSANDRA-18302:
---
This still causes memory to expand for a rare case, which gets even worse for
prepared as they do not share the same memory... The argument that this is
matching the user's string is also not correct, as the parser strips things out
and this logic also mutates the string, so you get the following
{code}
-- This is a query
SELECT peer,
peer_port
FROM system.peers_v2
{code}
{code}
Expecting:
<"SELECT peer, peer_port FROM system.peers_v2">
to be equal to:
<"-- This is a query
SELECT peer,
peer_port
FROM system.peers_v2">
but was not.
{code}
So honestly I find this is still complex, adds extra cost, and still violates
the intent of the original string... I am ok with StatementSource(int line,
int position) as that can help transactions, but anything more than that I feel
isn't worth the cost.
> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown
> from asCql method when validation transaction statement. In addition, asCql
> does not return precisely the query user entered so the whole error message
> can be misleading.
--
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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700773#comment-17700773
]
Sam Tunnicliffe commented on CASSANDRA-18153:
-
In {{cep-21-tcm}} we will 100% have a similar problem and what Jacek proposed
sounds sensible, so I'm not suggesting to _not_ fix this in trunk. In the CEP
branch, we will just have to look in slightly different places for pre-existing
ids (TokenMetadata is completely gone, for instance). For brand new instances,
how we deal with "conditionally create a host id...before touching schema or
the commit log" is more of a question and something we need to consider.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18332) Backport CASSANDRA-17205 to 4.0 branch (strong ref leak)
[
https://issues.apache.org/jira/browse/CASSANDRA-18332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700765#comment-17700765
]
Josh McKenzie commented on CASSANDRA-18332:
---
||Item|Link|
|PR|[link|https://github.com/apache/cassandra/pull/2219]|
|JDK8
CI|[link|https://app.circleci.com/pipelines/github/jmckenzie-dev/cassandra/334/workflows/4aad53f0-a6e6-407b-ace3-668b5f0db512]|
|JDK11
CI|[link|https://app.circleci.com/pipelines/github/jmckenzie-dev/cassandra/334/workflows/dfc6f82d-18d0-45cb-8a98-a982a0259da0]|
[~benedict] - almost identical to the 4.1+ patch (CASSANDRA-17205) with the
following 2 changes:
1) Ordering on constructor of checking for illegal state on {{parentRef}} to
immediately after acquisition rather than after initializing the {{Counter}}
potentially unnecessarily
2) Up log level from {{warn}} to {{error}} on {{StrongLeakDetector.run}}
Any chance you have a few minutes to glance over it on review? I'll pull it
forward with just the logging changes on merge up; since it's a 1 token log
level change I'm not too concerned about re-running CI for that if you're good
with it.
> Backport CASSANDRA-17205 to 4.0 branch (strong ref leak)
>
>
> Key: CASSANDRA-18332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18332
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> See description in CASSANDRA-17205; this should have been applied on 4.0 and
> merged up but was overlooked.
>
> Also double-check that strong leaks are logged at ERROR instead of WARN on
> both 4.0, 4.1, and trunk (see
> [comment|https://issues.apache.org/jira/browse/CASSANDRA-18176?focusedCommentId=17687184&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17687184])
--
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-18332) Backport CASSANDRA-17205 to 4.0 branch (strong ref leak)
[ https://issues.apache.org/jira/browse/CASSANDRA-18332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-18332: -- Test and Documentation Plan: No documentation changes needed. Status: Patch Available (was: In Progress) > Backport CASSANDRA-17205 to 4.0 branch (strong ref leak) > > > Key: CASSANDRA-18332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18332 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.x > > > See description in CASSANDRA-17205; this should have been applied on 4.0 and > merged up but was overlooked. > > Also double-check that strong leaks are logged at ERROR instead of WARN on > both 4.0, 4.1, and trunk (see > [comment|https://issues.apache.org/jira/browse/CASSANDRA-18176?focusedCommentId=17687184&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17687184]) -- 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
[cassandra-website] branch asf-staging updated (3eb9e73b -> 69dbf78d)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 3eb9e73b generate docs for c4206294 new 69dbf78d generate docs for c4206294 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (3eb9e73b) \ N -- N -- N refs/heads/asf-staging (69dbf78d) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700759#comment-17700759
]
Stefan Miklosovic edited comment on CASSANDRA-18153 at 3/15/23 3:59 PM:
Thanks for the explanation, Sam. I think it will be better if we wait for this
work in trunk so we do not need to fix that after it. (or you when integrating
cep 21).
But we still need to fix it for older branches, don't we? So what about fixing
this in everything but trunk and we do it in trunk "the proper way"?
Reading it more closely: "Nothing in the {{cep-21-tcm}} branch solves the
problem described in this ticket" ... yeah well ... what do you think,
[~jlewandowski] ? Still good for trunk, after all?
was (Author: smiklosovic):
Thanks for the explanation, Sam. I think it will be better if we wait for this
work in trunk so we do not need to fix that after it. (or you when integrating
cep 21).
But we still need to fix it for older branches, don't we? So what about fixing
this in everything but trunk and we do it in trunk "the proper way"?
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700759#comment-17700759
]
Stefan Miklosovic commented on CASSANDRA-18153:
---
Thanks for the explanation, Sam. I think it will be better if we wait for this
work in trunk so we do not need to fix that after it. (or you when upon
integrating cep 21).
But we still need to fix it for older branches, don't we? So what about fixing
this in everything but trunk and we do it in trunk "the proper way"?
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700759#comment-17700759
]
Stefan Miklosovic edited comment on CASSANDRA-18153 at 3/15/23 3:56 PM:
Thanks for the explanation, Sam. I think it will be better if we wait for this
work in trunk so we do not need to fix that after it. (or you when integrating
cep 21).
But we still need to fix it for older branches, don't we? So what about fixing
this in everything but trunk and we do it in trunk "the proper way"?
was (Author: smiklosovic):
Thanks for the explanation, Sam. I think it will be better if we wait for this
work in trunk so we do not need to fix that after it. (or you when upon
integrating cep 21).
But we still need to fix it for older branches, don't we? So what about fixing
this in everything but trunk and we do it in trunk "the proper way"?
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-17971) Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-17971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700752#comment-17700752
]
Ekaterina Dimitrova commented on CASSANDRA-17971:
-
{code:java}
Should the InterceptClasses#BYTECODE_VERSION = Opcodes.ASM7 but updated also,
or am I missing something here too?
https://github.com/apache/cassandra/blob/trunk/test/simulator/asm/org/apache/cassandra/simulator/asm/InterceptClasses.java#L51{code}
It should when we update the simulator to support JDK17.
This refers to this earlier comment:
{code:java}
I suggest we leave this one the patch as-is and have the simulator upgraded to
be able to handle 17 in its own separate ticket. Same way it was done in
additional ticket for simulator Java 11 support before.{code}
> Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
>
>
> Key: CASSANDRA-17971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17971
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0
>
>
> In CASSANDRA-17873 we updated the ASM opcode inconsistencies for JDK11, we
> need to revise it again before we switch fro jdk8&11 to jdk11&17
--
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-17971) Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-17971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700746#comment-17700746
]
Maxim Muzafarov commented on CASSANDRA-17971:
-
[~e.dimitrova],
Thank you, I missed that script.
Should the {{InterceptClasses#BYTECODE_VERSION = Opcodes.ASM7}} but updated
also, or am I missing something here too?
https://github.com/apache/cassandra/blob/trunk/test/simulator/asm/org/apache/cassandra/simulator/asm/InterceptClasses.java#L51
> Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
>
>
> Key: CASSANDRA-17971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17971
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0
>
>
> In CASSANDRA-17873 we updated the ASM opcode inconsistencies for JDK11, we
> need to revise it again before we switch fro jdk8&11 to jdk11&17
--
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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700743#comment-17700743
]
Sam Tunnicliffe commented on CASSANDRA-18153:
-
I wanted to mention that in CEP-21 we're proposing to move the responsibility
for assigning host identifiers from the local node itself to a cluster wide
service. For compatibility, we have been representing these as UUIDs so that
they can be used everywhere a host id is currently but this was intended as a
temporary measure to make development more straightforward. Actually, these
node ids are simple ints based on a global counter and one part of the
remaining work on CEP-21 is to migrate to these fully.
Of course, for upgrades we will need to retain a mapping between old and new
ids to process hints and this is also marked as a todo.
Nothing in the {{cep-21-tcm}} branch solves the problem described in this
ticket, but something along the lines of what Jacek suggested sounds reasonable
and feasible. I just wanted to mention this here in case you had chance to
factor it the thinking about this ticket.
Here's where we set the host id (including the updating from the old to new id
in an upgrade, currently unfriendly to hints):
[https://github.com/apache/cassandra/blob/cep-21-tcm/src/java/org/apache/cassandra/tcm/transformations/Register.java#L123]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18335: - Change Category: Operability Complexity: Low Hanging Fruit Component/s: Consistency/Repair Status: Open (was: Triage Needed) > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- 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-18335) Push LocalSessions info logs to debug
Brandon Williams created CASSANDRA-18335: Summary: Push LocalSessions info logs to debug Key: CASSANDRA-18335 URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams I don't think these are particularly useful to have at info, but the impetus for this ticket is specifically [this message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] during automatic cleanup about skipping deleting sessions that seems to confuse or alarm people. -- 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-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18335: - Fix Version/s: 4.0.x 4.1.x 5.x > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- 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-18333) Add max_sstable_size and max_sstable_duration metrics virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700729#comment-17700729 ] Stefan Miklosovic commented on CASSANDRA-18333: --- I submitted them few hours ago, it will be done in hour or two. [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1994/workflows/a1c516b0-d09f-49d7-9460-582c97570bdb] [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1994/workflows/b5a35f90-df5a-4e9d-af52-ae5e3ee3e635] > Add max_sstable_size and max_sstable_duration metrics virtual tables > > > Key: CASSANDRA-18333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18333 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > We added max_sstable_size and max_sstable_duration metrics in CASSANDRA-18283 > however there are not system_views vtables for these metrics yet. -- 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-18333) Add max_sstable_size and max_sstable_duration metrics virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-18333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700722#comment-17700722 ] Brandon Williams commented on CASSANDRA-18333: -- LGTM. I see you config'd circle but I'm guessing there are no runs due to the outage? > Add max_sstable_size and max_sstable_duration metrics virtual tables > > > Key: CASSANDRA-18333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18333 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > We added max_sstable_size and max_sstable_duration metrics in CASSANDRA-18283 > however there are not system_views vtables for these metrics yet. -- 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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18153:
--
Reviewers: Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic)
Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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
[cassandra-website] branch asf-staging updated (39914258 -> 3eb9e73b)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 39914258 generate docs for c4206294 new 3eb9e73b generate docs for c4206294 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (39914258) \ N -- N -- N refs/heads/asf-staging (3eb9e73b) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700709#comment-17700709
]
Jacek Lewandowski commented on CASSANDRA-18153:
---
I think it can be reviewed at this point.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18153:
--
Status: Patch Available (was: In Progress)
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18283) Enhance diagnostic nodetool tablestats output
[ https://issues.apache.org/jira/browse/CASSANDRA-18283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-18283: --- Description: The nodetool tablestats command lacks some available details which would be very useful to report upon. This is especially helpful in database-as-a-service environments where servers and their disk files are not directly observable by users. 1. Currently, for LCS tablestats reports useful details about the number of sstables in each level: SSTable count: 6635 SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] This type of additional detail about the sstables is absent from STCS and TWCS as it only reports the table count. 1a) For STCS, tablestats should report the max sstable file size on disk. This is useful to know if compaction has failed due to disk space or if a forced compaction created a jumbo table. 1b) For TWCS, tablestats should report the min & max timestamp, and duration of the sstables representing windows. This is useful to know if out-of-window writes or rows w/out a TTL have lead many more sstables on disk than expected by the time window configuration. STCs example: SSTable count: 6635 SSTable STCS max size: 122,000,000,000 TWCs example: SSTable count: 6635 SSTables Time Window 15 DAYS, max duration : 362d 7h 16m 49s 2. While tablestats reports both memtable and disk file sstable statistics. It is useful these are in the same command, but it would clarify the output to separate mem vs disk into two sections i.e., -- File statistics SSTable count: 6635 SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] -- Memtable statistics Bloom filter false positives: 12184123 Bloom filter false ratio: 0.07203 Bloom filter space used: 16874424 Bloom filter off heap memory used: 16821344 Index summary off heap memory used: 7525546 Space used (live): 1324067896238 3. Read / Write count should also be reported as a ratio, such as: Local read count: 202961459 Local write count: 40554481 Local read/write ratio: 5:1 Local read latency: 1.957 ms Local write count: 40554481 Local write latency: 0.040 ms was: The nodetool tablestats command lacks some available details which would be very useful to report upon. This is especially helpful in database-as-a-service environments where servers and their disk files are not directly observable by users. 1. Currently, for LCS tablestats reports useful details about the number of sstables in each level: SSTable count: 6635 SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] This type of additional detail about the sstables is absent from STCS and TWCS as it only reports the table count. 1a) For STCS, tablestats should report the max sstable file size on disk. This is useful to know if compaction has failed due to disk space or if a forced compaction created a jumbo table. 1b) For TWCS, tablestats should report the min & max timestamp, and duration of the sstables representing windows. This is useful to know if out-of-window writes or rows w/out a TTL have lead many more sstables on disk than expected by the time window configuration. STCs example: SSTable count: 6635 SSTable STCS max size: 122,000,000,000 STCs example: SSTable count: 6635 SSTables Time Window 15 DAYS, max duration : 362d 7h 16m 49s 2. While tablestats reports both memtable and disk file sstable statistics. It is useful these are in the same command, but it would clarify the output to separate mem vs disk into two sections i.e., -- File statistics SSTable count: 6635 SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] -- Memtable statistics Bloom filter false positives: 12184123 Bloom filter false ratio: 0.07203 Bloom filter space used: 16874424 Bloom filter off heap memory used: 16821344 Index summary off heap memory used: 7525546 Space used (live): 1324067896238 3. Read / Write count should also be reported as a ratio, such as: Local read count: 202961459 Local write count: 40554481 Local read/write ratio: 5:1 Local read latency: 1.957 ms Local write count: 40554481 Local write latency: 0.040 ms > Enhance diagnostic nodetool tablestats output > - > > Key: CASSANDRA-18283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18283 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0 > > Attachments: ima
[jira] [Commented] (CASSANDRA-18322) Warnings when using prepared statement with "drop/create keyspace .." ( after 15252)
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700703#comment-17700703
]
Josh McKenzie commented on CASSANDRA-18322:
---
Might be nice to still warn on it but update the warning to indicate why
preparing CREATE/DROP doesn't make sense.
bq. USE with prepared statements is considered to be an anti-pattern
due to ambiguity in non-qualified table names.
Could become something like:
bq. Prepared statements for CREATE/DROP keyspace or table commands is
indicative of programmatic keyspace/table creation or deletion and should be
avoided.
If we wanted to get really crazy we could start considering tying error
messages to documentation on why certain behavior was a bad idea. :D
> Warnings when using prepared statement with "drop/create keyspace .." ( after
> 15252)
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Priority: Urgent
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
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-18334) Change "Cleaned up" log message slightly
[
https://issues.apache.org/jira/browse/CASSANDRA-18334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700702#comment-17700702
]
Josh McKenzie commented on CASSANDRA-18334:
---
We could probably make {{FBUtilities.prettyPrintMemory}} a little smarter in
this regard and configurable for region in the .yaml right?
{code}
public static String prettyPrintMemory(long size, boolean includeSpace)
{
if (size >= 1 << 30)
return String.format("%.3f%sGiB", size / (double) (1 << 30),
includeSpace ? " " : "");
if (size >= 1 << 20)
return String.format("%.3f%sMiB", size / (double) (1 << 20),
includeSpace ? " " : "");
return String.format("%.3f%sKiB", size / (double) (1 << 10),
includeSpace ? " " : "");
}
{code}
> Change "Cleaned up" log message slightly
>
>
> Key: CASSANDRA-18334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18334
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Lapo Luchini
>Priority: Normal
>
> Might seem like a very small change, but it leads me to confusion each and
> every time. 🤣
> I propose to change current message like:
> {{Cleaned up to /var/db/cassandra/data/…/me-19423-big-Data.db. 571.512GiB to
> 502.648GiB (~87% of original) for 11,708,552 keys. Time: 62,321,057 ms.}}
> To only 2 decimal places, to disambiguate the fact that the "." is a decimal
> separator and not a thousands separator.
> {{Cleaned up to /var/db/cassandra/data/…/me-19423-big-Data.db. 571.51GiB to
> 502.65GiB (~87% of original) for 11,708,552 keys. Time: 62,321,057 ms.}}
> I guess this happens less in the USA or countries where "." is always and
> only a decimal separator, but e.g. in Italy we use numbers usually like this
> "1.000,345" and thus, while accustomed to many values in the "international"
> format the period is a bit overloaded in my brain and I always am like "is
> that 571 and a half GiB, again?"
> Changing to two digits would help in that regard and, I think, only removes
> extra detail which was kinda overkill in the first place.
--
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-18043) remove deprecated DateTieredCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18043: -- Status: Review In Progress (was: Patch Available) > remove deprecated DateTieredCompactionStrategy > -- > > Key: CASSANDRA-18043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18043 > Project: Cassandra > Issue Type: Task > Components: Local/Compaction/DTCS >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > DTCS was marked as deprecated in CASSANDRA-9666 which was released in 3.0.8 > and 3.8. If I get our deprecation policies right, we wait one major release > (4.0) and we can remove it in the next one (5.0). Having 4.1 about to be > released soon and 4.2 will be 5.0, I think nothing blocks us from removing > this strategy in trunk. > This also makes CASSANDRA-18042 easier as it would most probably have to > cover this strategy as well. -- 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-18043) remove deprecated DateTieredCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18043: -- Status: Ready to Commit (was: Review In Progress) > remove deprecated DateTieredCompactionStrategy > -- > > Key: CASSANDRA-18043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18043 > Project: Cassandra > Issue Type: Task > Components: Local/Compaction/DTCS >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > DTCS was marked as deprecated in CASSANDRA-9666 which was released in 3.0.8 > and 3.8. If I get our deprecation policies right, we wait one major release > (4.0) and we can remove it in the next one (5.0). Having 4.1 about to be > released soon and 4.2 will be 5.0, I think nothing blocks us from removing > this strategy in trunk. > This also makes CASSANDRA-18042 easier as it would most probably have to > cover this strategy as well. -- 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-17971) Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-17971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700699#comment-17700699 ] Ekaterina Dimitrova commented on CASSANDRA-17971: - Hi [~mmuzaf], Thank you for the ping. >From CASSANDRA-18002: bq. There's a script at ide/nbproject/ide/nbproject/update-netbeans-classpaths.sh that does the update of the ide/nbproject/project.xml for you, so it's not something we need to enforce on the dev community. bq. It's nice to push the update into version control before each major release. > Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra > > > Key: CASSANDRA-17971 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17971 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Feature/UDF >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0 > > > In CASSANDRA-17873 we updated the ASM opcode inconsistencies for JDK11, we > need to revise it again before we switch fro jdk8&11 to jdk11&17 -- 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-18043) remove deprecated DateTieredCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700697#comment-17700697 ] Jacek Lewandowski commented on CASSANDRA-18043: --- looks good to me +1 > remove deprecated DateTieredCompactionStrategy > -- > > Key: CASSANDRA-18043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18043 > Project: Cassandra > Issue Type: Task > Components: Local/Compaction/DTCS >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > DTCS was marked as deprecated in CASSANDRA-9666 which was released in 3.0.8 > and 3.8. If I get our deprecation policies right, we wait one major release > (4.0) and we can remove it in the next one (5.0). Having 4.1 about to be > released soon and 4.2 will be 5.0, I think nothing blocks us from removing > this strategy in trunk. > This also makes CASSANDRA-18042 easier as it would most probably have to > cover this strategy as well. -- 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-18043) remove deprecated DateTieredCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18043: -- Reviewers: Jacek Lewandowski > remove deprecated DateTieredCompactionStrategy > -- > > Key: CASSANDRA-18043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18043 > Project: Cassandra > Issue Type: Task > Components: Local/Compaction/DTCS >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > DTCS was marked as deprecated in CASSANDRA-9666 which was released in 3.0.8 > and 3.8. If I get our deprecation policies right, we wait one major release > (4.0) and we can remove it in the next one (5.0). Having 4.1 about to be > released soon and 4.2 will be 5.0, I think nothing blocks us from removing > this strategy in trunk. > This also makes CASSANDRA-18042 easier as it would most probably have to > cover this strategy as well. -- 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-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700693#comment-17700693 ] Jacek Lewandowski commented on CASSANDRA-18302: --- I get you don't want to make it complex. I managed to simplify it significantly while keeping its benefits. In particular, I've managed to find a way to get a query source directly in the parser and pass it to the prepared statement. Therefore, all that stuff with setting the raw text and then extracting a relevant part of it is now gone. > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- 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-18322) Warnings when using prepared statement with "drop/create keyspace .." ( after 15252)
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700663#comment-17700663
]
Alex Petrov commented on CASSANDRA-18322:
-
I first thought that I have made a mistake and create/drop keyspace is an
instance of QualifiedStatement, but my intention in implementing this was to
pick a statement that can only be applied to insert/update/delete/select, and
create/drop is not an instance of such. So naturally `isFullyQualified` does
not apply to those. Maybe we could use an enum or capital-case boolean to
distinguish between those cases. I think its a reasonable UI/UX change. That
said, unfortunately I won't get to it any time soon, so if anyone has cycles,
it would be great if you could take a stub. Thanks!
> Warnings when using prepared statement with "drop/create keyspace .." ( after
> 15252)
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Alex Petrov
>Priority: Urgent
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
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] [Assigned] (CASSANDRA-18322) Warnings when using prepared statement with "drop/create keyspace .." ( after 15252)
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov reassigned CASSANDRA-18322:
---
Assignee: (was: Alex Petrov)
> Warnings when using prepared statement with "drop/create keyspace .." ( after
> 15252)
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Priority: Urgent
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
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-18322) Warnings when using prepared statement with "drop/create keyspace .." ( after 15252)
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-18322:
Authors: (was: Alex Petrov)
> Warnings when using prepared statement with "drop/create keyspace .." ( after
> 15252)
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Alex Petrov
>Priority: Urgent
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
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-18331) Extend implicit allow-filtering to clustering keys as well
[ https://issues.apache.org/jira/browse/CASSANDRA-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18331: -- Fix Version/s: 5.0 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/4734dfc503e6b4307b63dd61f36da9f9c89d86f9 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Extend implicit allow-filtering to clustering keys as well > -- > > Key: CASSANDRA-18331 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18331 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This was overlooked in CASSANDRA-18238. > We should be able to do selects on vtables not only when selecting on regular > columns but also on clustering ones. Currently we can do that on regulars > only. -- 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-18331) Extend implicit allow-filtering to clustering keys as well
[ https://issues.apache.org/jira/browse/CASSANDRA-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18331: -- Status: Ready to Commit (was: Review In Progress) > Extend implicit allow-filtering to clustering keys as well > -- > > Key: CASSANDRA-18331 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18331 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > This was overlooked in CASSANDRA-18238. > We should be able to do selects on vtables not only when selecting on regular > columns but also on clustering ones. Currently we can do that on regulars > only. -- 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-18331) Extend implicit allow-filtering to clustering keys as well
[ https://issues.apache.org/jira/browse/CASSANDRA-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18331: -- Reviewers: Aleksey Yeschenko Status: Review In Progress (was: Patch Available) > Extend implicit allow-filtering to clustering keys as well > -- > > Key: CASSANDRA-18331 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18331 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > This was overlooked in CASSANDRA-18238. > We should be able to do selects on vtables not only when selecting on regular > columns but also on clustering ones. Currently we can do that on regulars > only. -- 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
[cassandra] branch trunk updated: Extend implicit allow-filtering for virtual tables to clustering columns
This is an automated email from the ASF dual-hosted git repository.
smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 4734dfc503 Extend implicit allow-filtering for virtual tables to
clustering columns
4734dfc503 is described below
commit 4734dfc503e6b4307b63dd61f36da9f9c89d86f9
Author: Stefan Miklosovic
AuthorDate: Mon Mar 13 12:51:34 2023 +0100
Extend implicit allow-filtering for virtual tables to clustering columns
patch by Stefan Miklosovic; reviewed by Aleksey Yeschenko for
CASSANDRA-18331
---
CHANGES.txt| 1 +
.../cql3/restrictions/StatementRestrictions.java | 2 +-
.../cassandra/cql3/statements/SelectStatement.java | 3 ++-
.../cql3/validation/entities/VirtualTableTest.java | 24 --
4 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 93b9125da8..f2b23b1f02 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
5.0
+ * Extend implicit allow-filtering for virtual tables to clustering columns
(CASSANDRA-18331)
* Upgrade maven-shade-plugin to 3.4.1 to fix shaded dtest JAR build
(CASSANDRA-18136)
* Upgrade to Opcodes.ASM9 (CASSANDRA-17971)
* Add MaxSSTableSize and MaxSSTableDuration metrics and propagate them
together with local read/write ratio to tablestats (CASSANDRA-18283)
diff --git
a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
index a7ebc2650b..d522f46d2f 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
@@ -286,7 +286,7 @@ public final class StatementRestrictions
validateSecondaryIndexSelections();
}
-private boolean requiresAllowFilteringIfNotSpecified()
+public boolean requiresAllowFilteringIfNotSpecified()
{
if (!table.isVirtual())
return true;
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index 4d14ffa410..39e887cffd 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -1458,7 +1458,8 @@ public class SelectStatement implements
CQLStatement.SingleKeyspaceCqlStatement
// We will potentially filter data if either:
// - Have more than one IndexExpression
// - Have no index expression and the row filter is not the
identity
-checkFalse(restrictions.needFiltering(),
StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE);
+if (restrictions.requiresAllowFilteringIfNotSpecified())
+checkFalse(restrictions.needFiltering(),
StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE);
}
}
diff --git
a/test/unit/org/apache/cassandra/cql3/validation/entities/VirtualTableTest.java
b/test/unit/org/apache/cassandra/cql3/validation/entities/VirtualTableTest.java
index d27a894d61..a17f74cec2 100644
---
a/test/unit/org/apache/cassandra/cql3/validation/entities/VirtualTableTest.java
+++
b/test/unit/org/apache/cassandra/cql3/validation/entities/VirtualTableTest.java
@@ -1050,7 +1050,7 @@ public class VirtualTableTest extends CQLTester
}
@Test
-public void testDisallowedFilteringOnTable() throws Throwable
+public void testDisallowedFilteringOnRegularColumn() throws Throwable
{
try
{
@@ -1064,11 +1064,31 @@ public class VirtualTableTest extends CQLTester
}
@Test
-public void testAllowedFilteringOnTable() throws Throwable
+public void testDisallowedFilteringOnClusteringColumn() throws Throwable
+{
+try
+{
+executeNet(format("SELECT * FROM %s.%s WHERE c = 'abc'", KS_NAME,
VT5_NAME));
+fail(format("should fail as %s.%s is not allowed to be filtered on
implicitly.", KS_NAME, VT5_NAME));
+}
+catch (InvalidQueryException ex)
+{
+assertTrue(ex.getMessage().contains("Cannot execute this query as
it might involve data filtering and thus may have unpredictable performance"));
+}
+}
+
+@Test
+public void testAllowedFilteringOnRegularColumn() throws Throwable
{
executeNet(format("SELECT * FROM %s.%s WHERE v2 = 5", KS_NAME,
VT1_NAME));
}
+@Test
+public void testAllowedFilteringOnClusteringColumn() throws Throwable
+{
+executeNet(format("SELECT * FROM %s.%s WHERE c = 'abc'", KS_NAME,
VT1_NAME));
+}
+
@FunctionalInterface
private static interface ThrowingRunnable
{
--
[jira] [Commented] (CASSANDRA-18331) Extend implicit allow-filtering to clustering keys as well
[ https://issues.apache.org/jira/browse/CASSANDRA-18331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700631#comment-17700631 ] Aleksey Yeschenko commented on CASSANDRA-18331: --- Sure. +1d with a small nit mentioned. Feel free to ignore it or change on commit. No need to rerun CI. > Extend implicit allow-filtering to clustering keys as well > -- > > Key: CASSANDRA-18331 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18331 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > This was overlooked in CASSANDRA-18238. > We should be able to do selects on vtables not only when selecting on regular > columns but also on clustering ones. Currently we can do that on regulars > only. -- 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-18322) Warnings when using prepared statement with "drop/create keyspace .." ( after 15252)
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700627#comment-17700627
]
Brandon Williams commented on CASSANDRA-18322:
--
bq. But I think Cassandra should be fixed as well, right?
I guess that depends on how it should be fixed. An argument could be made that
warnings should be sent to the client when preparing statements like this,
since it is an indicator of repeated programmatic keyspace/table creation which
is generally a bad practice. Papering over questionable behavior with silence
is another option.
> Warnings when using prepared statement with "drop/create keyspace .." ( after
> 15252)
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Alex Petrov
>Priority: Urgent
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
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-17971) Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-17971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700626#comment-17700626
]
Maxim Muzafarov commented on CASSANDRA-17971:
-
[~mck], [~e.dimitrova]
Hello, I have found that the NetBeans classpath should be updated as well,
right? It still points to 9.3 version instead of 9.4
{code:java}
..
${project.dir}/build/lib/jars/asm-9.3.jar:${project.dir}/build/test/lib/jars/asm-9.3.jar:${project.dir}/build/test/lib/jars/asm-analysis-9.3.jar:${project.dir}/build/test/lib/jars/asm-commons-9.3.jar:${project.dir}/build/test/lib/jars/asm-tree-9.3.jar:${project.dir}/build/test/lib/jars/asm-util-9.3.jar:${project.dir}/build/test/lib/jars/asm-xml-6.0.jar
{code}
> Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
>
>
> Key: CASSANDRA-17971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17971
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0
>
>
> In CASSANDRA-17873 we updated the ASM opcode inconsistencies for JDK11, we
> need to revise it again before we switch fro jdk8&11 to jdk11&17
--
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-18334) Change "Cleaned up" log message slightly
[
https://issues.apache.org/jira/browse/CASSANDRA-18334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700625#comment-17700625
]
Brandon Williams commented on CASSANDRA-18334:
--
The problem with doing this is someone else may make a ticket requesting more
precision in the logs (and over time I would expect that as density grows.)
There's no way to make everyone happy and no correct or incorrect solution.
Accessing this information programmatically via vtables or similar may be a way
around this.
> Change "Cleaned up" log message slightly
>
>
> Key: CASSANDRA-18334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18334
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Lapo Luchini
>Priority: Normal
>
> Might seem like a very small change, but it leads me to confusion each and
> every time. 🤣
> I propose to change current message like:
> {{Cleaned up to /var/db/cassandra/data/…/me-19423-big-Data.db. 571.512GiB to
> 502.648GiB (~87% of original) for 11,708,552 keys. Time: 62,321,057 ms.}}
> To only 2 decimal places, to disambiguate the fact that the "." is a decimal
> separator and not a thousands separator.
> {{Cleaned up to /var/db/cassandra/data/…/me-19423-big-Data.db. 571.51GiB to
> 502.65GiB (~87% of original) for 11,708,552 keys. Time: 62,321,057 ms.}}
> I guess this happens less in the USA or countries where "." is always and
> only a decimal separator, but e.g. in Italy we use numbers usually like this
> "1.000,345" and thus, while accustomed to many values in the "international"
> format the period is a bit overloaded in my brain and I always am like "is
> that 571 and a half GiB, again?"
> Changing to two digits would help in that regard and, I think, only removes
> extra detail which was kinda overkill in the first place.
--
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-18328) Remove deprecated CQL functions dateof and unixtimestampof
[
https://issues.apache.org/jira/browse/CASSANDRA-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700603#comment-17700603
]
Andres de la Peña commented on CASSANDRA-18328:
---
Yep, it seems there was an issue with ccm. Just rebased and started CI again:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2216]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2713/workflows/3b5803fa-e396-4911-98e0-19b75e7d4572]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2713/workflows/b5dbb252-4f5c-48c1-8c00-b59ef5fc83c1]||
> Remove deprecated CQL functions dateof and unixtimestampof
> --
>
> Key: CASSANDRA-18328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18328
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>
> The CQL functions {{dateof}} and {{unixtimestampof}} were [deprecated on
> Cassandra
> 2.2.0|https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa],
> almost eight years ago. They were deprecated in favour of the then new
> {{totimestamp}} and {{tounixtimestamp}} functions.
> A note about their deprecation was added to
> [{{NEWS.txt}}|https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423],
> and they were marked as deprecated on
> [{{CQL.textile}}|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions].
> They are also listed as deprecated on [the new
> doc|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions].
> We can finally remove those functions in 5.0, since they have been deprecated
> for so long.
> Discussion thread
> [here|https://lists.apache.org/thread/0gs824fpsngn5dr0yq2x1h8qsflj5sr0].
--
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-18334) Change "Cleaned up" log message slightly
Lapo Luchini created CASSANDRA-18334:
Summary: Change "Cleaned up" log message slightly
Key: CASSANDRA-18334
URL: https://issues.apache.org/jira/browse/CASSANDRA-18334
Project: Cassandra
Issue Type: Improvement
Components: Observability/Logging
Reporter: Lapo Luchini
Might seem like a very small change, but it leads me to confusion each and
every time. 🤣
I propose to change current message like:
{{Cleaned up to /var/db/cassandra/data/…/me-19423-big-Data.db. 571.512GiB to
502.648GiB (~87% of original) for 11,708,552 keys. Time: 62,321,057 ms.}}
To only 2 decimal places, to disambiguate the fact that the "." is a decimal
separator and not a thousands separator.
{{Cleaned up to /var/db/cassandra/data/…/me-19423-big-Data.db. 571.51GiB to
502.65GiB (~87% of original) for 11,708,552 keys. Time: 62,321,057 ms.}}
I guess this happens less in the USA or countries where "." is always and only
a decimal separator, but e.g. in Italy we use numbers usually like this
"1.000,345" and thus, while accustomed to many values in the "international"
format the period is a bit overloaded in my brain and I always am like "is that
571 and a half GiB, again?"
Changing to two digits would help in that regard and, I think, only removes
extra detail which was kinda overkill in the first place.
--
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-18312) Drop support for sstable formats before `na`
[
https://issues.apache.org/jira/browse/CASSANDRA-18312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700552#comment-17700552
]
Michael Semb Wever commented on CASSANDRA-18312:
dev@ thread: https://lists.apache.org/thread/bxg30nol25oxf1hvpkrqobopxszrnor2
> Drop support for sstable formats before `na`
>
>
> Key: CASSANDRA-18312
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18312
> Project: Cassandra
> Issue Type: Task
> Components: Local/SSTable
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> From 5.0 sstable formats before {{\-na\-}} are unsupported.
> This patch cleans up code related to the older formats.
> https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/18312/trunk
>
> Raises the question whether backward compatibility to the previous major is
> defined by the Cassandra version or by the internal component version
> (sstable format).
> Also raises the question on whether downstream forks are wanting to support
> such upgrade paths, e.g. offline, and to what versions the {{sstableupgrade}}
> tool supports. This also touches on recent discussions around
> [Downgradability|https://lists.apache.org/thread/tcp339k5ph8ql35wxr085to4qgp8tpg7].
>
--
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
[cassandra] branch trunk updated (fb95112427 -> 034e009e93)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from fb95112427 Upgrade maven-shade-plugin to 3.4.1 to fix shaded dtest JAR build add 8d91b469af Prepare debian changelog for 4.1.1 new 034e009e93 Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
