[jira] [Comment Edited] (CASSANDRA-18200) Cassandra messaging to self changed behavior
[ https://issues.apache.org/jira/browse/CASSANDRA-18200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681203#comment-17681203 ] Maciej Sokol edited comment on CASSANDRA-18200 at 1/27/23 7:13 AM: --- If I understand you correctly, you want prefer_local to affect the local node as well and not always use local IP? I have also tried to use prefer_local, it only affects the peers not the messaging to node itself. I've tested Cassandra 4 with my patch and now it works correctly, previously ranged queries and other communication within node through messaging did not work (because the pod behind LB cannot connect to itself through LB). was (Author: JIRAUSER285315): If I understand you correctly, you want prefer_local to affect the local node as well and not always use local IP? I have also tried to use prefer_local despite the ticket you linked, it only affects the peers not the messaging to node itself. Btw, I've tested Cassandra 4 with my patch and now it works correctly, previously ranged queries and other communication within node through messaging did not work (because the pod behind LB cannot connect to itself through LB). > Cassandra messaging to self changed behavior > > > Key: CASSANDRA-18200 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18200 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Maciej Sokol >Priority: Normal > Attachments: patch.txt > > > During testing of Cassandra on AWS, we noticed some behavior changes between > Cassandra 3.11 and Cassandra 4.0 when it comes to messaging. > When performing a range query with consistency local_quorum, Cassandra sents > a request to itself and some peers. > In case of Cassandra 4.0, it's trying to connect to itself using the > broadcast_address while in Cassandra 3.11 it's connecting using the local > address (see > [https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java#L152]. > This translation seems to be missing in Cassandra 4.X. I think the best place > to fix it would be here (see attached file): > [https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451] -- 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-18200) Cassandra messaging to self changed behavior
[ https://issues.apache.org/jira/browse/CASSANDRA-18200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681203#comment-17681203 ] Maciej Sokol commented on CASSANDRA-18200: -- If I understand you correctly, you want prefer_local to affect the local node as well and not always use local IP? I have also tried to use prefer_local despite the ticket you linked, it only affects the peers not the messaging to node itself. Btw, I've tested Cassandra 4 with my patch and now it works correctly, previously ranged queries and other communication within node through messaging did not work (because the pod behind LB cannot connect to itself through LB). > Cassandra messaging to self changed behavior > > > Key: CASSANDRA-18200 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18200 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Maciej Sokol >Priority: Normal > Attachments: patch.txt > > > During testing of Cassandra on AWS, we noticed some behavior changes between > Cassandra 3.11 and Cassandra 4.0 when it comes to messaging. > When performing a range query with consistency local_quorum, Cassandra sents > a request to itself and some peers. > In case of Cassandra 4.0, it's trying to connect to itself using the > broadcast_address while in Cassandra 3.11 it's connecting using the local > address (see > [https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java#L152]. > This translation seems to be missing in Cassandra 4.X. I think the best place > to fix it would be here (see attached file): > [https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451] -- 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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18155:
Status: Ready to Commit (was: Review In Progress)
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18155:
Status: Review In Progress (was: Patch Available)
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681201#comment-17681201
]
Berenguer Blasi commented on CASSANDRA-18155:
-
Good I just wanted you to give the vtables options a thought. Considering the
circleci thing is orthogonal and will get resolved +1.
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681200#comment-17681200
]
Caleb Rackliffe commented on CASSANDRA-18155:
-
The CircleCI config was generated by a tool [~dcapwell] wrote that just
segregates J8 and J11, and then cleans up the targets that aren’t run anyway
from the report. (We’ve been using it for quite a while.) The issue of the
wrongly identified repeats needs another look. I messed one of these up
recently when my clone’s trunk branch wasn’t up-to-date w/ upstream trunk, so
it might have been that. Hopefully I can figure it out in the morning…
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681198#comment-17681198
]
Caleb Rackliffe commented on CASSANDRA-18155:
-
It looks like we agreed not to add more JMX stuff *after* CASSANDRA-15254 lands?
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681195#comment-17681195
]
Berenguer Blasi commented on CASSANDRA-18155:
-
I retract the +1 to commit. I just remembered about JMX and vtables. I re-read
a couple threads in the dev ML and it seems we agreed to not add JMX anymore
unless the author absolutely needs it iiuc. What's your take here?
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18155:
Status: Patch Available (was: Ready to Commit)
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681188#comment-17681188
]
Berenguer Blasi commented on CASSANDRA-18155:
-
I see:
* The schema reset test is CASSANDRA-18151
* invalidSingleCredetial shouldn't be there. That has been wrongly identified
by the multiplexer as a new or modified test. Do you have an explanation or is
it a bug we need to fix bc of the waste of money? Either way the multiplexer
did run the test you added so we're good.
* reloadtrie is CASSANDRA-18144
* CS one is CASSANDRA-17674
I have 2 worry points
* This CI run is not the std one. I'll +1 if you assure me they both are the
same as I can't visually match them
* I'm worried about the wrongly identified repeat tests, we should open a
ticket or find out what happened.
LGTM +1 conditional to the 2 points above
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18155:
Status: Ready to Commit (was: Review In Progress)
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-14468) "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
[
https://issues.apache.org/jira/browse/CASSANDRA-14468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
junwen yang reassigned CASSANDRA-14468:
---
Assignee: junwen yang (was: Jordan West)
> "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
> -
>
> Key: CASSANDRA-14468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Wade Simmons
>Assignee: junwen yang
>Priority: Normal
> Fix For: 3.0.18, 3.11.4
>
> Attachments: data.tar.gz
>
>
> I am attempting to upgrade from Cassandra 2.2.10 to 3.0.16. I am getting this
> error:
> {code}
> org.apache.cassandra.exceptions.ConfigurationException: Unable to parse
> targets for index idx_foo ("666f6f")
> at
> org.apache.cassandra.index.internal.CassandraIndex.parseTarget(CassandraIndex.java:800)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.index.internal.CassandraIndex.indexCfsMetadata(CassandraIndex.java:747)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:645)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:251)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.16.jar:3.0.16]
> {code}
> It looks like this might be related to CASSANDRA-14104 that was just added to
> 3.0.16
--
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-18001) Add missing tests suites to CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681124#comment-17681124
]
Ekaterina Dimitrova edited comment on CASSANDRA-18001 at 1/27/23 2:12 AM:
--
{quote}I have also commented a couple of typos on [the
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/514e07dfee300b1b972e860c2f61674fae0793c6].
{quote}
Thank you for spotting those, I will fix them
{quote}Just one nit, I think that in the pre-commit workflow the jobs for large
dtests should share a single approval button. That button would approve regular
and repeated large dtests, possibly with and without vnodes. That would
simplify the workflow of the pre-commit workflow, while we still have the
separate workflow for fine tuning.
{quote}
We can do that. It was done that way in 4.1 and trunk so we will have to change
it there too. The only thing maybe is that those are resource intensive and I
think that's why we kept them separate
You actually also reminded me I should also add config to test the repeated
runs jobs for the Python large DTests (we do not have for the cqlshlib)
was (Author: e.dimitrova):
{quote}I have also commented a couple of typos on [the
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/514e07dfee300b1b972e860c2f61674fae0793c6].
{quote}
Thank you for spotting those, I will fix them
{quote}Just one nit, I think that in the pre-commit workflow the jobs for large
dtests should share a single approval button. That button would approve regular
and repeated large dtests, possibly with and without vnodes. That would
simplify the workflow of the pre-commit workflow, while we still have the
separate workflow for fine tuning.
{quote}
We can do that. It was done that way in 4.1 and trunk so we will have to change
it there too. The only thing maybe is that those are resource intensive and I
think that's why we kept them separate
You actually also reminded me I should add some test change to trigger the
testing also for the repeated runs jobs
> Add missing tests suites to CircleCI
>
>
> Key: CASSANDRA-18001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18001
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1-rc1, 4.1, 4.1.x, 4.2, 4.x
>
>
> Burn tests to all branches, large Python DTests (with/without vnodes),
> cqlshlib not tested in all branches and with all jdks; Java distributed tests
> not running with J8/J11 4.0+
--
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-18204) CEP-15: (C*) Add git submodule for Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681149#comment-17681149 ] David Capwell commented on CASSANDRA-18204: --- pushed my code as is, still working on what was talked about in dev@ so not ready for review > CEP-15: (C*) Add git submodule for Accord > - > > Key: CASSANDRA-18204 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18204 > Project: Cassandra > Issue Type: Task > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > As talked about in dev@ thread "Intra-project dependencies”, we talked about > adding git submodules but before doing this had to work out a few issues > first; this ticket is to track this work. > Goals > * when checking out an older commit, or pulling in newer commits, the > submodule should also be updated automatically > * release artifact must include the submodule and must be able to build > without issue > * build.xml must be updated to build the submodule > * build.xml must be updated to release the submodule jar -- 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-18100) Support CAS and serial read on Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18100: --- Fix Version/s: 4.2 (was: 5.x) > Support CAS and serial read on Accord > - > > Key: CASSANDRA-18100 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18100 > Project: Cassandra > Issue Type: Sub-task > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 4.2 > > Time Spent: 19.5h > Remaining Estimate: 0h > > This is a pre-requisite for live migration and roll back. -- 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-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17112: --- Fix Version/s: 4.2 (was: 5.x) > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.2 > > Time Spent: 7h 10m > Remaining Estimate: 0h > -- 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-accord] branch trunk updated (1eb0090 -> 1230ece)
This is an automated email from the ASF dual-hosted git repository. benedict pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git discard 1eb0090 Introduce Range transactions (#23) new 1230ece Introduce Range transactions (#23) 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 (1eb0090) \ N -- N -- N refs/heads/trunk (1230ece) 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: accord-core/src/test/java/accord/impl/IntHashKey.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-accord] branch trunk updated (27cbec2 -> 1eb0090)
This is an automated email from the ASF dual-hosted git repository. benedict pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git discard 27cbec2 Introduce Range transactions (#23) new 1eb0090 Introduce Range transactions (#23) 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 (27cbec2) \ N -- N -- N refs/heads/trunk (1eb0090) 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: accord-maelstrom/src/main/java/accord/maelstrom/Json.java | 2 +- 1 file 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-18001) Add missing tests suites to CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681124#comment-17681124
]
Ekaterina Dimitrova commented on CASSANDRA-18001:
-
{quote}I have also commented a couple of typos on [the
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/514e07dfee300b1b972e860c2f61674fae0793c6].
{quote}
Thank you for spotting those, I will fix them
{quote}Just one nit, I think that in the pre-commit workflow the jobs for large
dtests should share a single approval button. That button would approve regular
and repeated large dtests, possibly with and without vnodes. That would
simplify the workflow of the pre-commit workflow, while we still have the
separate workflow for fine tuning.
{quote}
We can do that. It was done that way in 4.1 and trunk so we will have to change
it there too. The only thing maybe is that those are resource intensive and I
think that's why we kept them separate
You actually also reminded me I should add some test change to trigger the
testing also for the repeated runs jobs
> Add missing tests suites to CircleCI
>
>
> Key: CASSANDRA-18001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18001
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1-rc1, 4.1, 4.1.x, 4.2, 4.x
>
>
> Burn tests to all branches, large Python DTests (with/without vnodes),
> cqlshlib not tested in all branches and with all jdks; Java distributed tests
> not running with J8/J11 4.0+
--
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 (41f4290c -> 69a89fce)
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 41f4290c generate docs for 5dd84ab2 new 69a89fce generate docs for 5dd84ab2 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 (41f4290c) \ N -- N -- N refs/heads/asf-staging (69a89fce) 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/doc/4.2/cassandra/architecture/dynamo.html | 53 ++--- .../doc/4.2/cassandra/architecture/guarantees.html | 46 ++-- .../doc/4.2/cassandra/architecture/overview.html | 16 +- content/doc/4.2/cassandra/architecture/snitch.html | 2 +- .../4.2/cassandra/architecture/storage_engine.html | 78 +++--- content/doc/4.2/cassandra/cql/ddl.html | 11 +- content/doc/4.2/cassandra/cql/definitions.html | 2 +- content/doc/4.2/cassandra/cql/dml.html | 2 +- content/doc/4.2/cassandra/cql/types.html | 17 +- .../data_modeling/data_modeling_rdbms.html | 2 +- .../data_modeling/data_modeling_schema.html| 2 +- .../data_modeling/data_modeling_tools.html | 2 +- content/doc/4.2/cassandra/faq/index.html | 5 +- .../doc/4.2/cassandra/getting_started/drivers.html | 2 +- .../4.2/cassandra/getting_started/production.html | 10 +- .../doc/4.2/cassandra/operating/auditlogging.html | 261 +++-- content/doc/4.2/cassandra/operating/backups.html | 2 +- content/doc/4.2/cassandra/tools/cqlsh.html | 47 +++- .../cassandra/tools/sstable/sstablelevelreset.html | 2 +- .../doc/trunk/cassandra/architecture/dynamo.html | 53 ++--- .../trunk/cassandra/architecture/guarantees.html | 46 ++-- .../doc/trunk/cassandra/architecture/overview.html | 16 +- .../doc/trunk/cassandra/architecture/snitch.html | 2 +- .../cassandra/architecture/storage_engine.html | 78 +++--- content/doc/trunk/cassandra/cql/ddl.html | 11 +- content/doc/trunk/cassandra/cql/definitions.html | 2 +- content/doc/trunk/cassandra/cql/dml.html | 2 +- content/doc/trunk/cassandra/cql/types.html | 17 +- .../data_modeling/data_modeling_rdbms.html | 2 +- .../data_modeling/data_modeling_schema.html| 2 +- .../data_modeling/data_modeling_tools.html | 2 +- content/doc/trunk/cassandra/faq/index.html | 5 +- .../trunk/cassandra/getting_started/drivers.html | 2 +- .../cassandra/getting_started/production.html | 10 +- .../trunk/cassandra/operating/auditlogging.html| 261 +++-- content/doc/trunk/cassandra/operating/backups.html | 2 +- content/doc/trunk/cassandra/tools/cqlsh.html | 47 +++- .../cassandra/tools/sstable/sstablelevelreset.html | 2 +- site-ui/build/ui-bundle.zip| Bin 4970898 -> 4970898 bytes 39 files changed, 824 insertions(+), 300 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18204) CEP-15: (C*) Add git submodule for Accord
David Capwell created CASSANDRA-18204: - Summary: CEP-15: (C*) Add git submodule for Accord Key: CASSANDRA-18204 URL: https://issues.apache.org/jira/browse/CASSANDRA-18204 Project: Cassandra Issue Type: Task Components: Accord Reporter: David Capwell Assignee: David Capwell As talked about in dev@ thread "Intra-project dependencies”, we talked about adding git submodules but before doing this had to work out a few issues first; this ticket is to track this work. Goals * when checking out an older commit, or pulling in newer commits, the submodule should also be updated automatically * release artifact must include the submodule and must be able to build without issue * build.xml must be updated to build the submodule * build.xml must be updated to release the submodule jar -- 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-18204) CEP-15: (C*) Add git submodule for Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18204: -- Change Category: Code Clarity Complexity: Normal Fix Version/s: 4.x Status: Open (was: Triage Needed) > CEP-15: (C*) Add git submodule for Accord > - > > Key: CASSANDRA-18204 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18204 > Project: Cassandra > Issue Type: Task > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > As talked about in dev@ thread "Intra-project dependencies”, we talked about > adding git submodules but before doing this had to work out a few issues > first; this ticket is to track this work. > Goals > * when checking out an older commit, or pulling in newer commits, the > submodule should also be updated automatically > * release artifact must include the submodule and must be able to build > without issue > * build.xml must be updated to build the submodule > * build.xml must be updated to release the submodule jar -- 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-18203) CEP-15: (C*) Improve Burn Tests to include thread scheduling
[ https://issues.apache.org/jira/browse/CASSANDRA-18203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18203: -- Change Category: Quality Assurance Complexity: Low Hanging Fruit Fix Version/s: 4.x Status: Open (was: Triage Needed) > CEP-15: (C*) Improve Burn Tests to include thread scheduling > > > Key: CASSANDRA-18203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18203 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > To improve burn test coverage, should have CommandStore actions run in a > interleaved manner with jitter -- 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-18203) CEP-15: (C*) Improve Burn Tests to include thread scheduling
David Capwell created CASSANDRA-18203: - Summary: CEP-15: (C*) Improve Burn Tests to include thread scheduling Key: CASSANDRA-18203 URL: https://issues.apache.org/jira/browse/CASSANDRA-18203 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: David Capwell Assignee: David Capwell To improve burn test coverage, should have CommandStore actions run in a interleaved manner with jitter -- 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-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681030#comment-17681030 ] Paulo Motta edited comment on CASSANDRA-16325 at 1/26/23 7:12 PM: -- build failed due to CASSANDRA-18197 Resubmitted CI: [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2234/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2234/pipeline] was (Author: paulo): build failed due to CASSANDRA-18197 Resubmitted CI: !https://ci-cassandra.apache.org/job/Cassandra-devbranch/2234/badge/icon! > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 4.2 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- 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-18198) "AttributeError: module 'py' has no attribute 'io'" reported in multiple tests
[
https://issues.apache.org/jira/browse/CASSANDRA-18198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681082#comment-17681082
]
Brandon Williams edited comment on CASSANDRA-18198 at 1/26/23 7:05 PM:
---
What I was missing here is that the virtualenvs in the /env3.x locations are
for cqlsh, and dtest creates its own venv from inside the docker image. If I
follow what that does, I end up in a venv like this:
{noformat}
(venv) cassandra@0b4fc44433d6:~$ python -c 'import py;
print(py.io.get_terminal_width());'
Traceback (most recent call last):
File "", line 1, in
AttributeError: module 'py' has no attribute 'io'
(venv) cassandra@0b4fc44433d6:~$ pip install py
Collecting py
Using cached py-1.11.0-py2.py3-none-any.whl (98 kB)
Installing collected packages: py
Successfully installed py-1.11.0
WARNING: You are using pip version 22.0.4; however, version 22.3.1 is available.
You should consider upgrading via the '/home/cassandra/venv/bin/python -m pip
install --upgrade pip' command.
(venv) cassandra@0b4fc44433d6:~$
{noformat}
this is because the virtualenv is created with the system python3.8 from
/usr/bin/python3.8, which is missing the py module:
{noformat}
cassandra@9186bcbeb831:~$ /usr/bin/python3.8
Python 3.8.10 (default, Mar 15 2022, 12:22:08)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import py
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'py'
>>>
{noformat}
The simplest solution is probably to declare it as a dependency in the dtests,
as I did above
[here|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-18198].
was (Author: brandon.williams):
What I was missing here is that the virtualenvs in the /env3.x locations are
for cqlsh, and dtest create their own venv in the docker image. If I follow
what that does, I end up in venv like this:
{noformat}
(venv) cassandra@0b4fc44433d6:~$ python -c 'import py;
print(py.io.get_terminal_width());'
Traceback (most recent call last):
File "", line 1, in
AttributeError: module 'py' has no attribute 'io'
(venv) cassandra@0b4fc44433d6:~$ pip install py
Collecting py
Using cached py-1.11.0-py2.py3-none-any.whl (98 kB)
Installing collected packages: py
Successfully installed py-1.11.0
WARNING: You are using pip version 22.0.4; however, version 22.3.1 is available.
You should consider upgrading via the '/home/cassandra/venv/bin/python -m pip
install --upgrade pip' command.
(venv) cassandra@0b4fc44433d6:~$
{noformat}
this is because the virtualenv is created with the system python3.8 from
/usr/bin/python3.8, which is missing the py module:
{noformat}
cassandra@9186bcbeb831:~$ /usr/bin/python3.8
Python 3.8.10 (default, Mar 15 2022, 12:22:08)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import py
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'py'
>>>
{noformat}
The simplest solution is probably to declare it as a dependency in the dtests,
as I did above
[here|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-18198].
> "AttributeError: module 'py' has no attribute 'io'" reported in multiple tests
> --
>
> Key: CASSANDRA-18198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18198
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Claude Warren
>Assignee: Brandon Williams
>Priority: Normal
>
> {{title = 'Timeout'}}
> {{stream = <_io.TextIOWrapper name='' mode='w' encoding='utf-8'>}}
> {{{}sep = '+'{}}}{{{}def write_title(title, stream=None, sep="~"):{}}}
> {{{}"""Write a section title.{}}}{{{}If *stream* is None sys.stderr will be
> used, *sep* is used to{}}}
> {{draw the line.}}
> {{"""}}
> {{if stream is None:}}
> {{stream = sys.stderr}}
> {{> width = py.io.get_terminal_width()}}
> {{E AttributeError: module 'py' has no attribute 'io}}
>
> is reported in multiple tests as noted below.
> possibly a class loader issue associated with CASSANDRA-18150
> 4.1
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/256/testReport/dtest-offheap.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_full_repairs_lcs]
> 3.11
> [https://ci-cassandra.apache.org/job/Cassandra-3.11/424/testReport/dtest.bootstrap_test/TestBootstrap/test_simultaneous_bootstrap/]
> 3.0
> [https://ci-cassandra.apache.org/job/Cassandra-3.0/328/testReport/dtest-upgrade.upgrade_tests.upgrade_supercolumns_test/TestSCUpgrade/test_upgrade_super_columns_through_all_versions/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail:
[jira] [Updated] (CASSANDRA-18198) "AttributeError: module 'py' has no attribute 'io'" reported in multiple tests
[
https://issues.apache.org/jira/browse/CASSANDRA-18198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18198:
-
Test and Documentation Plan: fix CI
Status: Patch Available (was: Open)
> "AttributeError: module 'py' has no attribute 'io'" reported in multiple tests
> --
>
> Key: CASSANDRA-18198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18198
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Claude Warren
>Assignee: Brandon Williams
>Priority: Normal
>
> {{title = 'Timeout'}}
> {{stream = <_io.TextIOWrapper name='' mode='w' encoding='utf-8'>}}
> {{{}sep = '+'{}}}{{{}def write_title(title, stream=None, sep="~"):{}}}
> {{{}"""Write a section title.{}}}{{{}If *stream* is None sys.stderr will be
> used, *sep* is used to{}}}
> {{draw the line.}}
> {{"""}}
> {{if stream is None:}}
> {{stream = sys.stderr}}
> {{> width = py.io.get_terminal_width()}}
> {{E AttributeError: module 'py' has no attribute 'io}}
>
> is reported in multiple tests as noted below.
> possibly a class loader issue associated with CASSANDRA-18150
> 4.1
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/256/testReport/dtest-offheap.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_full_repairs_lcs]
> 3.11
> [https://ci-cassandra.apache.org/job/Cassandra-3.11/424/testReport/dtest.bootstrap_test/TestBootstrap/test_simultaneous_bootstrap/]
> 3.0
> [https://ci-cassandra.apache.org/job/Cassandra-3.0/328/testReport/dtest-upgrade.upgrade_tests.upgrade_supercolumns_test/TestSCUpgrade/test_upgrade_super_columns_through_all_versions/]
--
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-18062) On-disk string index with index building and on-disk query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18062: - Test and Documentation Plan: Current CI run for this patch is here: https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/104/workflows/79cefe33-099a-422f-b8b5-de4ea0df5ca2 Status: Patch Available (was: In Progress) The PR for this patch is here: https://github.com/maedhroz/cassandra/pull/9 > On-disk string index with index building and on-disk query path > --- > > Key: CASSANDRA-18062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18062 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > > An on-disk index for string (literal) datatypes. This index is used for the > following datatypes: > * UTF8Type > * AsciiType > * CompositeType > * Frozen types > This includes the ability to write the index to disk at index creation, by > specific index rebuild and during SSTable compaction. > Also the ability to query the on-disk index and combine the results with > those from the in-memory indexes created by CASSANDRA-18058. -- 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-18198) "AttributeError: module 'py' has no attribute 'io'" reported in multiple tests
[
https://issues.apache.org/jira/browse/CASSANDRA-18198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681082#comment-17681082
]
Brandon Williams commented on CASSANDRA-18198:
--
What I was missing here is that the virtualenvs in the /env3.x locations are
for cqlsh, and dtest create their own venv in the docker image. If I follow
what that does, I end up in venv like this:
{noformat}
(venv) cassandra@0b4fc44433d6:~$ python -c 'import py;
print(py.io.get_terminal_width());'
Traceback (most recent call last):
File "", line 1, in
AttributeError: module 'py' has no attribute 'io'
(venv) cassandra@0b4fc44433d6:~$ pip install py
Collecting py
Using cached py-1.11.0-py2.py3-none-any.whl (98 kB)
Installing collected packages: py
Successfully installed py-1.11.0
WARNING: You are using pip version 22.0.4; however, version 22.3.1 is available.
You should consider upgrading via the '/home/cassandra/venv/bin/python -m pip
install --upgrade pip' command.
(venv) cassandra@0b4fc44433d6:~$
{noformat}
this is because the virtualenv is created with the system python3.8 from
/usr/bin/python3.8, which is missing the py module:
{noformat}
cassandra@9186bcbeb831:~$ /usr/bin/python3.8
Python 3.8.10 (default, Mar 15 2022, 12:22:08)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import py
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'py'
>>>
{noformat}
The simplest solution is probably to declare it as a dependency in the dtests,
as I did above
[here|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-18198].
> "AttributeError: module 'py' has no attribute 'io'" reported in multiple tests
> --
>
> Key: CASSANDRA-18198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18198
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Claude Warren
>Assignee: Brandon Williams
>Priority: Normal
>
> {{title = 'Timeout'}}
> {{stream = <_io.TextIOWrapper name='' mode='w' encoding='utf-8'>}}
> {{{}sep = '+'{}}}{{{}def write_title(title, stream=None, sep="~"):{}}}
> {{{}"""Write a section title.{}}}{{{}If *stream* is None sys.stderr will be
> used, *sep* is used to{}}}
> {{draw the line.}}
> {{"""}}
> {{if stream is None:}}
> {{stream = sys.stderr}}
> {{> width = py.io.get_terminal_width()}}
> {{E AttributeError: module 'py' has no attribute 'io}}
>
> is reported in multiple tests as noted below.
> possibly a class loader issue associated with CASSANDRA-18150
> 4.1
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/256/testReport/dtest-offheap.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_full_repairs_lcs]
> 3.11
> [https://ci-cassandra.apache.org/job/Cassandra-3.11/424/testReport/dtest.bootstrap_test/TestBootstrap/test_simultaneous_bootstrap/]
> 3.0
> [https://ci-cassandra.apache.org/job/Cassandra-3.0/328/testReport/dtest-upgrade.upgrade_tests.upgrade_supercolumns_test/TestSCUpgrade/test_upgrade_super_columns_through_all_versions/]
--
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-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18144:
--
Reviewers: David Capwell, David Capwell
David Capwell, David Capwell (was: David Capwell)
Status: Review In Progress (was: Patch Available)
Tested locally and see it passes with SkipList. I found out that the reason
why SkipList is passing is that AbstractShardedMemtable isn't used by SkipList
and the issue is with AbstractShardedMemtable; the test is using tokens that
don't match the partitioner, so the test was at fault to begin with
+1
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
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-18068) Allow to attach native masking functions to table columns
[
https://issues.apache.org/jira/browse/CASSANDRA-18068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681063#comment-17681063
]
Andres de la Peña commented on CASSANDRA-18068:
---
Another CI run after doing some changes on the PR:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2110]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2594/workflows/bea76329-4e68-4753-8c03-22270df42b32]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2594/workflows/c5fb4e87-e363-4182-be14-af348c190547]|
> Allow to attach native masking functions to table columns
> -
>
> Key: CASSANDRA-18068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18068
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Allow to attach the native masking functions added by CASSANDRA-17941 to
> table columns, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> {{CREATE TABLE}} statements would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH partial(2, 1),
> birth date MASKED WITH default()
> );
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21);
>
> > SELECT name, birth FROM patients;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
> {{ALTER TABLE}} statements would look like:
> {code}
> > ALTER TABLE patients ALTER name MASKED WITH partial(2, 1);
> > ALTER TABLE patients ALTER name WITHOUT MASK;
> {code}
> It won't be possible to use masked columns in the WHERE and IF clauses of
> SELECT and UPDATE statements.
--
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-13460) Diag. Events: Add local persistency
[
https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681052#comment-17681052
]
Ekaterina Dimitrova commented on CASSANDRA-13460:
-
I think probably raising in #cassandra-dev you are looking for reviewer might
help to find someone with cycles faster
> Diag. Events: Add local persistency
> ---
>
> Key: CASSANDRA-13460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Add-persistency-for-events-to-system-keyspace.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Some generated events will be rather less frequent but very useful for
> retroactive troubleshooting. E.g. all events related to bootstraping and
> gossip would probably be worth saving, as they might provide valuable
> insights and will consume very little resources in low quantities. Imaging if
> we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool
> like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log
> of all relevant events- provide a dump of all events as described in the
> [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst].
>
> This could be done by saving events white-listed in cassandra.yaml to a local
> table. Maybe using a TTL.
--
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-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681048#comment-17681048
]
Ekaterina Dimitrova commented on CASSANDRA-18051:
-
{quote}bq. I still think those tests can run with 2 DCs instead of 3. That is a
trivial change in the dtests that would eliminate the need of running large
dtests with xlarge.
{quote}
Definitely quick and trivial change. Just those tests are added as part of an
effort to raise the coverage on the critical path and the person who did that
after code coverage runs, etc is not around anymore. Thus when talking about
the critical path and we are pressed from other priorities now I would
personally be more conservative, but I am open to different feedback.
{quote}If I'm missing something and the dtests actually need the 3 DCs, I think
I would just first move the job to xlarge in midres so the job isn't broken,
and then we can think on splitting the job when we eliminate highres.
{quote}
Considering my previous comment this is probably the path I'd recommend to go
for at this particular moment and revisit later when time is not a concern
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
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-13460) Diag. Events: Add local persistency
[
https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681045#comment-17681045
]
Ekaterina Dimitrova commented on CASSANDRA-13460:
-
I am sorry, I also don't think I will have time to pick it up any time soon,
even If I would be happy to help.
Watchers - I watch many tickets quite often as I try to keep up with the
project developments but unfortunately I wouldn't be able to review all of them
:(
> Diag. Events: Add local persistency
> ---
>
> Key: CASSANDRA-13460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Add-persistency-for-events-to-system-keyspace.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Some generated events will be rather less frequent but very useful for
> retroactive troubleshooting. E.g. all events related to bootstraping and
> gossip would probably be worth saving, as they might provide valuable
> insights and will consume very little resources in low quantities. Imaging if
> we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool
> like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log
> of all relevant events- provide a dump of all events as described in the
> [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst].
>
> This could be done by saving events white-listed in cassandra.yaml to a local
> table. Maybe using a TTL.
--
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-13460) Diag. Events: Add local persistency
[
https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681038#comment-17681038
]
Stefan Miklosovic commented on CASSANDRA-13460:
---
[~e.dimitrova] would this be something you consider to review? I am picking
people from reviewers ...
> Diag. Events: Add local persistency
> ---
>
> Key: CASSANDRA-13460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Add-persistency-for-events-to-system-keyspace.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Some generated events will be rather less frequent but very useful for
> retroactive troubleshooting. E.g. all events related to bootstraping and
> gossip would probably be worth saving, as they might provide valuable
> insights and will consume very little resources in low quantities. Imaging if
> we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool
> like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log
> of all relevant events- provide a dump of all events as described in the
> [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst].
>
> This could be done by saving events white-listed in cassandra.yaml to a local
> table. Maybe using a TTL.
--
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-13460) Diag. Events: Add local persistency
[
https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681038#comment-17681038
]
Stefan Miklosovic edited comment on CASSANDRA-13460 at 1/26/23 4:49 PM:
[~e.dimitrova] would this be something you consider to review? I am picking
people from watchers ...
was (Author: smiklosovic):
[~e.dimitrova] would this be something you consider to review? I am picking
people from reviewers ...
> Diag. Events: Add local persistency
> ---
>
> Key: CASSANDRA-13460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Add-persistency-for-events-to-system-keyspace.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Some generated events will be rather less frequent but very useful for
> retroactive troubleshooting. E.g. all events related to bootstraping and
> gossip would probably be worth saving, as they might provide valuable
> insights and will consume very little resources in low quantities. Imaging if
> we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool
> like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log
> of all relevant events- provide a dump of all events as described in the
> [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst].
>
> This could be done by saving events white-listed in cassandra.yaml to a local
> table. Maybe using a TTL.
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681037#comment-17681037
]
Caleb Rackliffe commented on CASSANDRA-18155:
-
[~bereng] There are a couple timeouts and other completely unrelated failures,
but overall, the tests look clean to me. Anything else you're worried about?
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-13460) Diag. Events: Add local persistency
[
https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-13460:
Reviewers: Michael Semb Wever (was: Marcus Eriksson, Michael Semb Wever)
> Diag. Events: Add local persistency
> ---
>
> Key: CASSANDRA-13460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Add-persistency-for-events-to-system-keyspace.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Some generated events will be rather less frequent but very useful for
> retroactive troubleshooting. E.g. all events related to bootstraping and
> gossip would probably be worth saving, as they might provide valuable
> insights and will consume very little resources in low quantities. Imaging if
> we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool
> like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log
> of all relevant events- provide a dump of all events as described in the
> [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst].
>
> This could be done by saving events white-listed in cassandra.yaml to a local
> table. Maybe using a TTL.
--
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-13460) Diag. Events: Add local persistency
[
https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681031#comment-17681031
]
Marcus Eriksson commented on CASSANDRA-13460:
-
Sorry, don't see myself having time to review this soon, unassigning
> Diag. Events: Add local persistency
> ---
>
> Key: CASSANDRA-13460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Add-persistency-for-events-to-system-keyspace.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Some generated events will be rather less frequent but very useful for
> retroactive troubleshooting. E.g. all events related to bootstraping and
> gossip would probably be worth saving, as they might provide valuable
> insights and will consume very little resources in low quantities. Imaging if
> we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool
> like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log
> of all relevant events- provide a dump of all events as described in the
> [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst].
>
> This could be done by saving events white-listed in cassandra.yaml to a local
> table. Maybe using a TTL.
--
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-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681030#comment-17681030 ] Paulo Motta commented on CASSANDRA-16325: - build failed due to CASSANDRA-18197 Resubmitted CI: !https://ci-cassandra.apache.org/job/Cassandra-devbranch/2234/badge/icon! > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 4.2 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- 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-18185) Accumulate all the `docs` PR from GitHub into a single patch
[ https://issues.apache.org/jira/browse/CASSANDRA-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18185: -- Status: Ready to Commit (was: Review In Progress) > Accumulate all the `docs` PR from GitHub into a single patch > > > Key: CASSANDRA-18185 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18185 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Nikita Eshkeev >Assignee: Nikita Eshkeev >Priority: Low > Fix For: 4.x > > Time Spent: 6h > Remaining Estimate: 0h > > In order to make it easier to review the `docs` labeled pull-requests all of > them should be accumulated into a single commit as per the > [request|https://github.com/apache/cassandra/pull/2062#issuecomment-1385002289] > from [~smiklosovic] -- 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-18185) Accumulate all the `docs` PR from GitHub into a single patch
[ https://issues.apache.org/jira/browse/CASSANDRA-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18185: -- Fix Version/s: 4.2 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/f27790c96912ac9a83f052d8e6d0bfcdfe60ca0e Resolution: Fixed Status: Resolved (was: Ready to Commit) > Accumulate all the `docs` PR from GitHub into a single patch > > > Key: CASSANDRA-18185 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18185 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Nikita Eshkeev >Assignee: Nikita Eshkeev >Priority: Low > Fix For: 4.2 > > Time Spent: 6h > Remaining Estimate: 0h > > In order to make it easier to review the `docs` labeled pull-requests all of > them should be accumulated into a single commit as per the > [request|https://github.com/apache/cassandra/pull/2062#issuecomment-1385002289] > from [~smiklosovic] -- 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-18185) Accumulate all the `docs` PR from GitHub into a single patch
[ https://issues.apache.org/jira/browse/CASSANDRA-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18185: -- Status: Review In Progress (was: Patch Available) > Accumulate all the `docs` PR from GitHub into a single patch > > > Key: CASSANDRA-18185 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18185 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Nikita Eshkeev >Assignee: Nikita Eshkeev >Priority: Low > Fix For: 4.x > > Time Spent: 6h > Remaining Estimate: 0h > > In order to make it easier to review the `docs` labeled pull-requests all of > them should be accumulated into a single commit as per the > [request|https://github.com/apache/cassandra/pull/2062#issuecomment-1385002289] > from [~smiklosovic] -- 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: Improve and clean up documentation and fix typos
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 f27790c969 Improve and clean up documentation and fix typos f27790c969 is described below commit f27790c96912ac9a83f052d8e6d0bfcdfe60ca0e Author: Nikita Eshkeev AuthorDate: Thu Jan 26 13:28:16 2023 +0100 Improve and clean up documentation and fix typos This patch includes all the changes from the PRs that introduce small changes related to typos and similar in the documentation. The changes are accumulated from the following PRs: - https://github.com/apache/cassandra/pull/206 - https://github.com/apache/cassandra/pull/359 - https://github.com/apache/cassandra/pull/366 - https://github.com/apache/cassandra/pull/390 - https://github.com/apache/cassandra/pull/450 - https://github.com/apache/cassandra/pull/567 - https://github.com/apache/cassandra/pull/615 - https://github.com/apache/cassandra/pull/618 - https://github.com/apache/cassandra/pull/746 - https://github.com/apache/cassandra/pull/984 - https://github.com/apache/cassandra/pull/1052 - https://github.com/apache/cassandra/pull/1088 - https://github.com/apache/cassandra/pull/1274 - https://github.com/apache/cassandra/pull/1378 - https://github.com/apache/cassandra/pull/1404 - https://github.com/apache/cassandra/pull/1504 - https://github.com/apache/cassandra/pull/1540 - https://github.com/apache/cassandra/pull/1544 - https://github.com/apache/cassandra/pull/1673 - https://github.com/apache/cassandra/pull/1697 - https://github.com/apache/cassandra/pull/1722 - https://github.com/apache/cassandra/pull/1815 - https://github.com/apache/cassandra/pull/1830 - https://github.com/apache/cassandra/pull/1863 - https://github.com/apache/cassandra/pull/1865 - https://github.com/apache/cassandra/pull/1879 - https://github.com/apache/cassandra/pull/2062 patch by Nikita Eshkeev, reviewed by Stefan Miklosovic, Lorina Poland, Michael Semb Wever for CASSANDRA-18185 Co-authored-by: kalmant Co-authored-by: Dmitry Co-authored-by: Tibor Répási Co-authored-by: Tzach Livyatan Co-authored-by: Jérôme BAROTIN Co-authored-by: Giorgio Giuffrè Co-authored-by: Siddhartha Tiwari <201851...@iiitvadodara.ac.in> Co-authored-by: Angelo Polo Co-authored-by: Tjeu Kayim <15987676+tjeuka...@users.noreply.github.com> Co-authored-by: 陳傑夫 Co-authored-by: Bhouse99 Co-authored-by: Matthew Hardwick Co-authored-by: Paul Wouters Co-authored-by: Romain Hardouin Co-authored-by: Guilherme Poleto Co-authored-by: 陳傑夫 Co-authored-by: etc-crontab Co-authored-by: Prashant Bhuruk Co-authored-by: Jingchuan Zhu <56401528+codingswag...@users.noreply.github.com> Co-authored-by: Ryan Stewart Co-authored-by: utkarsh-agrawal-jm <107914361+utkarsh-agrawal...@users.noreply.github.com> Co-authored-by: Ben Dalling Co-authored-by: Terry L. Blessing Co-authored-by: gruzilkin Co-authored-by: Kevin Co-authored-by: yziadeh <121903189+yzia...@users.noreply.github.com> Co-authored-by: Lorina Poland Co-authored-by: Stefan Miklosovic --- TESTING.md | 6 +- conf/cassandra.yaml| 28 +++--- conf/cqlshrc.sample| 12 ++- doc/modules/cassandra/examples/BNF/alter_table.bnf | 2 +- .../cassandra/pages/architecture/dynamo.adoc | 51 +- .../cassandra/pages/architecture/guarantees.adoc | 46 - .../cassandra/pages/architecture/overview.adoc | 16 +-- .../cassandra/pages/architecture/snitch.adoc | 2 +- .../pages/architecture/storage_engine.adoc | 57 ++- doc/modules/cassandra/pages/cql/ddl.adoc | 9 +- doc/modules/cassandra/pages/cql/definitions.adoc | 2 +- doc/modules/cassandra/pages/cql/dml.adoc | 2 +- doc/modules/cassandra/pages/cql/types.adoc | 17 ++-- .../pages/data_modeling/data_modeling_rdbms.adoc | 2 +- .../pages/data_modeling/data_modeling_schema.adoc | 2 +- .../pages/data_modeling/data_modeling_tools.adoc | 2 +- doc/modules/cassandra/pages/faq/index.adoc | 5 +- .../cassandra/pages/getting_started/drivers.adoc | 2 +- .../pages/getting_started/production.adoc | 10 +- .../cassandra/pages/operating/auditlogging.adoc| 110 + doc/modules/cassandra/pages/operating/backups.adoc | 2 +- doc/modules/cassandra/pages/tools/cqlsh.adoc | 37 +-- .../pages/tools/sstable/sstablelevelreset.adoc | 2 +- .../org/apache/cassandra/db/tries/InMemoryTrie.md | 2 +- 24 files changed, 267 insertions(+), 159 deletions(-) diff --git
[jira] [Commented] (CASSANDRA-18202) MessagingService should be able deliver local messages (messages to self) without using a network interface.
[
https://issues.apache.org/jira/browse/CASSANDRA-18202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681018#comment-17681018
]
Benedict Elliott Smith commented on CASSANDRA-18202:
I agree there should be a short-cut in MessagingService. But I disagree we
should eliminate the `isSelf` branches.
> MessagingService should be able deliver local messages (messages to self)
> without using a network interface.
>
>
> Key: CASSANDRA-18202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18202
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Jaroslaw Grabowski
>Priority: Normal
>
> At the moment, in various places in the code, there are special code paths
> for local message handling. It usually looks like this:
>
> {code:java}
> if (replica.isSelf)
> // deal with the message locally by manually invoking a handling method
> else
> messagingService.send(...){code}
>
> This pattern is error-prone, as failing to recognize local messages results
> in pushing them through a local network interface. This may introduce a
> significant performance penalty.
> It also makes understanding the code harder, as there are two separate code
> paths for message handling (local path and IVerbHandler).
> Instead, MessagingService should pass local messages directly to the
> appropriate IVerbHandler. Once this is done, all the `if (replica.isSelf) ...
> else ...` occurrences could be refactored to simply calling
> `messagingService.send(...)`. This would move message handling logic into a
> single place (IVerbHandler).
--
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-18202) MessagingService should be able deliver local messages (messages to self) without using a network interface.
[
https://issues.apache.org/jira/browse/CASSANDRA-18202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaroslaw Grabowski updated CASSANDRA-18202:
---
Description:
At the moment, in various places in the code, there are special code paths for
local message handling. It usually looks like this:
{code:java}
if (replica.isSelf)
// deal with the message locally by manually invoking a handling method
else
messagingService.send(...){code}
This pattern is error-prone, as failing to recognize local messages results in
pushing them through a local network interface. This may introduce a
significant performance penalty.
It also makes understanding the code harder, as there are two separate code
paths for message handling (local path and IVerbHandler).
Instead, MessagingService should pass local messages directly to the
appropriate IVerbHandler. Once this is done, all the `if (replica.isSelf) ...
else ...` occurrences could be refactored to simply calling
`messagingService.send(...)`. This would move message handling logic into a
single place (IVerbHandler).
was:
At the moment, in various places in the code, there are special code paths for
local message handling. It usually looks like this:
{code:java}
if (replica.isSelf)
// deal with the message locally by manually invoking a handling method
else
messagingService.send(...){code}
This pattern is error-prone, as failing to recognize local messages results in
pushing them through a local network interface. This may introduce a
significant performance penalty.
It also makes understanding the code harder, as there are two separate code
paths for message handling (local path and IVerbHandler).
Instead, MessagingService should pass local messages directly to the
appropriate IVerbHandler. Once this is done, all the `if (replica.isSelf) ...
else ...` occurrences could be refactored to simply calling
`messagingService.send(...)`. This would would move message handling logic into
a single place (IVerbHandler).
> MessagingService should be able deliver local messages (messages to self)
> without using a network interface.
>
>
> Key: CASSANDRA-18202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18202
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Jaroslaw Grabowski
>Priority: Normal
>
> At the moment, in various places in the code, there are special code paths
> for local message handling. It usually looks like this:
>
> {code:java}
> if (replica.isSelf)
> // deal with the message locally by manually invoking a handling method
> else
> messagingService.send(...){code}
>
> This pattern is error-prone, as failing to recognize local messages results
> in pushing them through a local network interface. This may introduce a
> significant performance penalty.
> It also makes understanding the code harder, as there are two separate code
> paths for message handling (local path and IVerbHandler).
> Instead, MessagingService should pass local messages directly to the
> appropriate IVerbHandler. Once this is done, all the `if (replica.isSelf) ...
> else ...` occurrences could be refactored to simply calling
> `messagingService.send(...)`. This would move message handling logic into a
> single place (IVerbHandler).
--
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-18179) Update build.xml for experimental JDK17 use
[ https://issues.apache.org/jira/browse/CASSANDRA-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681016#comment-17681016 ] Michael Semb Wever commented on CASSANDRA-18179: bq. Could be separate ticket if we want in general to add some additional info around JDK. Yes, let's do that as part of the final CASSANDRA-16895 work (i.e. when we remove jdk8 and properly add jdk17 experimental suport). bq. Just mentioning so we do not forget about it and confuse people. I am referring to this page - https://cassandra.apache.org/doc/latest/cassandra/getting_started/java11.html Good catch. I've fixed that page in the patch to adapt to the new approach. bq. I think we should change the commit message as I think it is too early to say that we add support for J17 in this ticket. done. > Update build.xml for experimental JDK17 use > --- > > Key: CASSANDRA-18179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18179 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.x > > > To support JDK17 we need to make changes to build.xml and our scripts. There > is a preliminary patch which makes a switch from JDK8+JDK11 to JDK11+JDK17 > but it will need a change considering CASSANDRA-18133 > CC [~mck] -- 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-18202) MessagingService should be able deliver local messages (messages to self) without using a network interface.
Jaroslaw Grabowski created CASSANDRA-18202:
--
Summary: MessagingService should be able deliver local messages
(messages to self) without using a network interface.
Key: CASSANDRA-18202
URL: https://issues.apache.org/jira/browse/CASSANDRA-18202
Project: Cassandra
Issue Type: Improvement
Components: Messaging/Internode
Reporter: Jaroslaw Grabowski
At the moment, in various places in the code, there are special code paths for
local message handling. It usually looks like this:
{code:java}
if (replica.isSelf)
// deal with the message locally by manually invoking a handling method
else
messagingService.send(...){code}
This pattern is error-prone, as failing to recognize local messages results in
pushing them through a local network interface. This may introduce a
significant performance penalty.
It also makes understanding the code harder, as there are two separate code
paths for message handling (local path and IVerbHandler).
Instead, MessagingService should pass local messages directly to the
appropriate IVerbHandler. Once this is done, all the `if (replica.isSelf) ...
else ...` occurrences could be refactored to simply calling
`messagingService.send(...)`. This would would move message handling logic into
a single place (IVerbHandler).
--
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-17940) CEP-20: Dynamic Data Masking
[ https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17940: --- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > CEP-20: Dynamic Data Masking > > > Key: CASSANDRA-17940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17940 > Project: Cassandra > Issue Type: Epic > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.x > > > Implementation of dynamic data masking as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > Dynamic data masking (DDM) allows to obscure sensitive information while > still allowing access to the masked columns, and without changing the stored > data. The CEP aims to provide DDM for Apache Cassandra using both native and > user-defined CQL functions. These functions can be either be used on their > own or be attached to specific columns in the table definition. -- 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-18200) Cassandra messaging to self changed behavior
[ https://issues.apache.org/jira/browse/CASSANDRA-18200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680992#comment-17680992 ] Brandon Williams commented on CASSANDRA-18200: -- Yes but these methods in OTC and OCS are used by everything. > Cassandra messaging to self changed behavior > > > Key: CASSANDRA-18200 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18200 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Maciej Sokol >Priority: Normal > Attachments: patch.txt > > > During testing of Cassandra on AWS, we noticed some behavior changes between > Cassandra 3.11 and Cassandra 4.0 when it comes to messaging. > When performing a range query with consistency local_quorum, Cassandra sents > a request to itself and some peers. > In case of Cassandra 4.0, it's trying to connect to itself using the > broadcast_address while in Cassandra 3.11 it's connecting using the local > address (see > [https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java#L152]. > This translation seems to be missing in Cassandra 4.X. I think the best place > to fix it would be here (see attached file): > [https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451] -- 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-18200) Cassandra messaging to self changed behavior
[ https://issues.apache.org/jira/browse/CASSANDRA-18200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680990#comment-17680990 ] Maciej Sokol edited comment on CASSANDRA-18200 at 1/26/23 1:23 PM: --- [~brandon.williams] From my understanding, prefer_local is only used for the peers, in this case the node is trying to message itself. was (Author: JIRAUSER285315): >From my understanding, prefer_local is only used for the peers, in this case >the node is trying to message itself. > Cassandra messaging to self changed behavior > > > Key: CASSANDRA-18200 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18200 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Maciej Sokol >Priority: Normal > Attachments: patch.txt > > > During testing of Cassandra on AWS, we noticed some behavior changes between > Cassandra 3.11 and Cassandra 4.0 when it comes to messaging. > When performing a range query with consistency local_quorum, Cassandra sents > a request to itself and some peers. > In case of Cassandra 4.0, it's trying to connect to itself using the > broadcast_address while in Cassandra 3.11 it's connecting using the local > address (see > [https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java#L152]. > This translation seems to be missing in Cassandra 4.X. I think the best place > to fix it would be here (see attached file): > [https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451] -- 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-18200) Cassandra messaging to self changed behavior
[ https://issues.apache.org/jira/browse/CASSANDRA-18200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680990#comment-17680990 ] Maciej Sokol commented on CASSANDRA-18200: -- >From my understanding, prefer_local is only used for the peers, in this case >the node is trying to message itself. > Cassandra messaging to self changed behavior > > > Key: CASSANDRA-18200 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18200 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Maciej Sokol >Priority: Normal > Attachments: patch.txt > > > During testing of Cassandra on AWS, we noticed some behavior changes between > Cassandra 3.11 and Cassandra 4.0 when it comes to messaging. > When performing a range query with consistency local_quorum, Cassandra sents > a request to itself and some peers. > In case of Cassandra 4.0, it's trying to connect to itself using the > broadcast_address while in Cassandra 3.11 it's connecting using the local > address (see > [https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java#L152]. > This translation seems to be missing in Cassandra 4.X. I think the best place > to fix it would be here (see attached file): > [https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451] -- 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-18201) Store min and max partition key in sstable stats metadata rather than in some index component
Jacek Lewandowski created CASSANDRA-18201: - Summary: Store min and max partition key in sstable stats metadata rather than in some index component Key: CASSANDRA-18201 URL: https://issues.apache.org/jira/browse/CASSANDRA-18201 Project: Cassandra Issue Type: Improvement Components: Local/SSTable Reporter: Jacek Lewandowski Assignee: Jacek Lewandowski Currently min and max partition key is stored in the index summary. Firstly, that informat better fits stats metadata as there are other similar statistics (like min and max clusterings) Secondly, opening index summary is costly. Though, index summary and the index itself are loaded upon opening an sstable just because we need to read min and max partition keys. Min and max partition keys need to be know for an sstable so that when some data are queried, we can select the sstable which may contain that data - that is, whether the queried partition is included in the min/max key range of the sstable. With the proposed solution, we could postpone loading index components to the time when the data from such sstable is really requested. It will be enough to read lightweight stats metadata as it will be sufficient to know everything about data ranges included in that sstable. It will also let to save memory used by those components until data from those sstables are requested. -- 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-18200) Cassandra messaging to self changed behavior
[ https://issues.apache.org/jira/browse/CASSANDRA-18200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680981#comment-17680981 ] Brandon Williams commented on CASSANDRA-18200: -- I think this may actually be a bug in 3.11, since it is not checking the preferred IP, which is what is stored when the snitch is configured with prefer_local set to true. I need to think about this a bit more, but I am interested in the context of CASSANDRA-16718. > Cassandra messaging to self changed behavior > > > Key: CASSANDRA-18200 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18200 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Maciej Sokol >Priority: Normal > Attachments: patch.txt > > > During testing of Cassandra on AWS, we noticed some behavior changes between > Cassandra 3.11 and Cassandra 4.0 when it comes to messaging. > When performing a range query with consistency local_quorum, Cassandra sents > a request to itself and some peers. > In case of Cassandra 4.0, it's trying to connect to itself using the > broadcast_address while in Cassandra 3.11 it's connecting using the local > address (see > [https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java#L152]. > This translation seems to be missing in Cassandra 4.X. I think the best place > to fix it would be here (see attached file): > [https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451] -- 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: Introduce RangeDeps
This is an automated email from the ASF dual-hosted git repository.
benedict 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 208af4c658 Introduce RangeDeps
208af4c658 is described below
commit 208af4c658df3779fbca5d7826125d37424deb37
Author: Benedict Elliott Smith
AuthorDate: Mon Jan 9 13:19:16 2023 +
Introduce RangeDeps
Refactor Deps into KeyDeps and RangeDeps
patch by Benedict; reviewed by Aleksey Yeschenko for CASSANDRA-18173
---
.build/include-accord.sh | 2 +-
.../service/accord/AccordObjectSizes.java | 35 +++--
.../service/accord/serializers/DepsSerializer.java | 163 +++--
.../service/accord/AccordCommandStoreTest.java | 11 +-
.../service/accord/AccordCommandTest.java | 9 +-
5 files changed, 156 insertions(+), 64 deletions(-)
diff --git a/.build/include-accord.sh b/.build/include-accord.sh
index eabe4d204b..e7cedab46e 100755
--- a/.build/include-accord.sh
+++ b/.build/include-accord.sh
@@ -25,7 +25,7 @@ set -o nounset
bin="$(cd "$(dirname "$0")" > /dev/null; pwd)"
accord_repo='https://github.com/apache/cassandra-accord.git'
-accord_branch='5626c7c11400d4cf6d01a8e22517b53a83f5c512'
+accord_branch='686326eedc8d2553c98a30abc81a925be3942b8c'
accord_src="$bin/cassandra-accord"
checkout() {
diff --git
a/src/java/org/apache/cassandra/service/accord/AccordObjectSizes.java
b/src/java/org/apache/cassandra/service/accord/AccordObjectSizes.java
index 0246ee6780..ca18f67c75 100644
--- a/src/java/org/apache/cassandra/service/accord/AccordObjectSizes.java
+++ b/src/java/org/apache/cassandra/service/accord/AccordObjectSizes.java
@@ -18,8 +18,6 @@
package org.apache.cassandra.service.accord;
-import java.util.Map;
-
import accord.api.Key;
import accord.api.RoutingKey;
import accord.local.Node;
@@ -28,16 +26,17 @@ import accord.primitives.AbstractRanges;
import accord.primitives.Deps;
import accord.primitives.FullKeyRoute;
import accord.primitives.FullRangeRoute;
+import accord.primitives.KeyDeps;
import accord.primitives.Keys;
import accord.primitives.PartialKeyRoute;
import accord.primitives.PartialRangeRoute;
import accord.primitives.PartialTxn;
import accord.primitives.Range;
+import accord.primitives.RangeDeps;
import accord.primitives.Ranges;
import accord.primitives.RoutingKeys;
import accord.primitives.Seekables;
import accord.primitives.Timestamp;
-import accord.primitives.TxnId;
import accord.primitives.Unseekables;
import accord.primitives.Writes;
import org.apache.cassandra.service.accord.api.PartitionKey;
@@ -61,16 +60,16 @@ public class AccordObjectSizes
return ((AccordRoutingKey) key).estimatedSizeOnHeap();
}
-private static final long EMPTY_KEY_RANGE_SIZE =
ObjectSizes.measure(TokenRange.fullRange(""));
+private static final long EMPTY_RANGE_SIZE =
ObjectSizes.measure(TokenRange.fullRange(""));
public static long range(Range range)
{
-return EMPTY_KEY_RANGE_SIZE + key(range.start()) + key(range.end());
+return EMPTY_RANGE_SIZE + key(range.start()) + key(range.end());
}
-private static final long EMPTY_KEY_RANGES_SIZE =
ObjectSizes.measure(Ranges.of());
+private static final long EMPTY_RANGES_SIZE =
ObjectSizes.measure(Ranges.of());
public static long ranges(Ranges ranges)
{
-long size = EMPTY_KEY_RANGES_SIZE;
+long size = EMPTY_RANGES_SIZE;
size += ObjectSizes.sizeOfReferenceArray(ranges.size());
// TODO: many ranges are fixed size, can compute by multiplication
for (int i = 0, mi = ranges.size() ; i < mi ; i++)
@@ -196,12 +195,22 @@ public class AccordObjectSizes
private static final long EMPTY_DEPS_SIZE =
ObjectSizes.measureDeep(Deps.NONE);
public static long dependencies(Deps dependencies)
{
-long size = EMPTY_DEPS_SIZE;
-for (Map.Entry entry : dependencies)
-{
-size += key(entry.getKey());
-size += timestamp(entry.getValue());
-}
+// TODO (expected): this doesn't measure the backing arrays, is
inefficient;
+// doesn't account for txnIdToKeys, txnIdToRanges, and searchable
fields;
+// fix to accunt for, in case caching isn't redone
+long size = EMPTY_DEPS_SIZE - EMPTY_KEYS_SIZE -
ObjectSizes.sizeOfReferenceArray(0);
+size += keys(dependencies.keyDeps.keys());
+for (int i = 0 ; i < dependencies.rangeDeps.rangeCount() ; ++i)
+size += range(dependencies.rangeDeps.range(i));
+size +=
ObjectSizes.sizeOfReferenceArray(dependencies.rangeDeps.rangeCount());
+
+for (int i = 0 ; i < dependencies.keyDeps.txnIdCount() ; ++i)
+size += timestamp(dependencies.keyDeps.txnId(i));
+for (int i = 0 ; i < dependencies.rangeDeps.txnIdCount() ;
[jira] [Commented] (CASSANDRA-18193) Provide design and API documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680955#comment-17680955
]
Benedict Elliott Smith commented on CASSANDRA-18193:
bq. What I don't agree with is the bar for what needs to be documented is by
the existing reviewers
The only feedback I want to see about documentation is precisely that, feedback
from a _reviewer_ who has invested some time trying to understand the code with
a view to contributing to it, with _specific_ clarifying remarks that would
help them. This is the standard target of our documentation.
bq. would you mind ranking where you value comments being added please.
Ranking remains a drive-by low effort contribution, and not particularly
actionable in my opinion, though I intend to time box some general
documentation improvements that look helpful to me, and I will use any ranking
to guide my time investment. I do not consider it directly actionable review
feedback, however.
Review involves some proper investment, with specific feedback about how
clarity can be improved. Better would be to open an empty PR you can use to
annotate the codebase with such feedback.
> Provide design and API documentation
>
>
> Key: CASSANDRA-18193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18193
> Project: Cassandra
> Issue Type: Task
> Components: Accord
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> Would be great if we have at minimum:
> - white paper in a form of an AsciiDoc or Markdown somewhere in the project
> tree
> - all interfaces and all methods in {{acccord.api}} have API docs explaining
> the requirements for the implementations
> - enums and their values across the project are documented
> - interfaces, abstract classes, or classes that do not inherit from anything
> in the project have at least some class level explanation
> Eventually, it would really awesome if concepts from the whitepaper are
> somehow referenced in the code (or vice-versa). It would make it much easier
> to understand the implementation and I believe it would improve reuse of this
> project for external applications
--
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-18193) Provide design and API documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680953#comment-17680953
]
Michael Semb Wever commented on CASSANDRA-18193:
I agree with [~benedict]'s statement. We don't want every method and enum value
commented. (The design and the naming should make as much as possible
intuitive, the suggestion to cross-reference to the whitepaper was very good
for this reason.) Comments on whatever is not intuitive, particularly that
helping to understand contract and intent, is valuable. What I don't agree with
is the bar for what needs to be documented is by the existing reviewers (who
have already invested a lot of time into understanding it). IMHO it needs to be
documented with the new reader in mind. [~jlewandowski], would you mind ranking
where you value comments being added please.
> Provide design and API documentation
>
>
> Key: CASSANDRA-18193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18193
> Project: Cassandra
> Issue Type: Task
> Components: Accord
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> Would be great if we have at minimum:
> - white paper in a form of an AsciiDoc or Markdown somewhere in the project
> tree
> - all interfaces and all methods in {{acccord.api}} have API docs explaining
> the requirements for the implementations
> - enums and their values across the project are documented
> - interfaces, abstract classes, or classes that do not inherit from anything
> in the project have at least some class level explanation
> Eventually, it would really awesome if concepts from the whitepaper are
> somehow referenced in the code (or vice-versa). It would make it much easier
> to understand the implementation and I believe it would improve reuse of this
> project for external applications
--
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-18001) Add missing tests suites to CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680950#comment-17680950 ] Andres de la Peña commented on CASSANDRA-18001: --- Looks good. Just one nit, I think that in the pre-commit workflow the jobs for large dtests should share a single approval button. That button would approve regular and repeated large dtests, possibly with and without vnodes. That would simplify the workflow of the pre-commit workflow, while we still have the separate workflow for fine tuning. I have also commented a couple of typos on [the commit|https://github.com/ekaterinadimitrova2/cassandra/commit/514e07dfee300b1b972e860c2f61674fae0793c6]. > Add missing tests suites to CircleCI > > > Key: CASSANDRA-18001 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18001 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Urgent > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1-rc1, 4.1, 4.1.x, 4.2, 4.x > > > Burn tests to all branches, large Python DTests (with/without vnodes), > cqlshlib not tested in all branches and with all jdks; Java distributed tests > not running with J8/J11 4.0+ -- 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-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680949#comment-17680949
]
Andres de la Peña commented on CASSANDRA-18051:
---
I still think those tests can run with 2 DCs instead of 3. That is a trivial
change in the dtests that would eliminate the need of running large dtests with
xlarge.
If I'm missing something and the dtests actually need the 3 DCs, I think I
would just first move the job to xlarge in midres so the job isn't broken, and
then we can think on splitting the job when we eliminate highres.
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
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-18185) Accumulate all the `docs` PR from GitHub into a single patch
[ https://issues.apache.org/jira/browse/CASSANDRA-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680938#comment-17680938 ] Stefan Miklosovic edited comment on CASSANDRA-18185 at 1/26/23 10:21 AM: - thanks [~neshkeev] and [~polandll] [~mck] I have question about non-documentation changes (changes related non-asciidoc files) NEWS.txt CHANGES.txt build.xml I would not commit these changes. We might have a separate ticket for that which would cover it systematically in all branches. For example when we change typos in CHANGES.txt (Cassanda / Cassanra ...) to CASSANDRA, it might cause some conflicts when merging up from 3.0 to trunk, for example ... no? Same with NEWS.txt etc. I would basically commit just adocs plus some minor changes in cassandra.yaml (redundant spaces plus some commentary formulated little bit differently). This is basically what we would like to commit to trunk _minus_ these three files I mentioned above. wdyt? https://github.com/instaclustr/cassandra/commit/2ba97f2df6fee7bdc531576f331c57ce186139e8 was (Author: smiklosovic): thanks [~neshkeev] and [~polandll] [~mck] I have question about non-documentation changes (changes related non-asciidoc files) NEWS.txt CHANGES.txt build.xml I would not commit these changes. We might have a separate ticket for that which would cover it systematically in all branches. For example when we change typos in CHANGES.txt (Cassanda / Cassanra ...) to CASSANDRA, it might case some conflicts when merging up from 3.0 to trunk, for example ... no? Same with NEWS.txt etc. I would basically commit just adocs plus some minor changes in cassandra.yaml (redundant spaces plus some commentary formulated little bit differently). This is basically what we would like to commit to trunk _minus_ these three files I mentioned above. wdyt? https://github.com/instaclustr/cassandra/commit/2ba97f2df6fee7bdc531576f331c57ce186139e8 > Accumulate all the `docs` PR from GitHub into a single patch > > > Key: CASSANDRA-18185 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18185 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Nikita Eshkeev >Assignee: Nikita Eshkeev >Priority: Low > Fix For: 4.x > > Time Spent: 6h > Remaining Estimate: 0h > > In order to make it easier to review the `docs` labeled pull-requests all of > them should be accumulated into a single commit as per the > [request|https://github.com/apache/cassandra/pull/2062#issuecomment-1385002289] > from [~smiklosovic] -- 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-18185) Accumulate all the `docs` PR from GitHub into a single patch
[ https://issues.apache.org/jira/browse/CASSANDRA-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680944#comment-17680944 ] Michael Semb Wever commented on CASSANDRA-18185: I agree [~smiklosovic] (with your previous comment). > Accumulate all the `docs` PR from GitHub into a single patch > > > Key: CASSANDRA-18185 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18185 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Nikita Eshkeev >Assignee: Nikita Eshkeev >Priority: Low > Fix For: 4.x > > Time Spent: 6h > Remaining Estimate: 0h > > In order to make it easier to review the `docs` labeled pull-requests all of > them should be accumulated into a single commit as per the > [request|https://github.com/apache/cassandra/pull/2062#issuecomment-1385002289] > from [~smiklosovic] -- 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 (1b86a79b -> 41f4290c)
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 1b86a79b generate docs for 5dd84ab2 new 41f4290c generate docs for 5dd84ab2 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 (1b86a79b) \ N -- N -- N refs/heads/asf-staging (41f4290c) 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 4970898 -> 4970898 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] [Updated] (CASSANDRA-18181) Fix tests post JDK-8210522 (rewrite reflection of "modifiers" field)
[
https://issues.apache.org/jira/browse/CASSANDRA-18181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18181:
---
Summary: Fix tests post JDK-8210522 (rewrite reflection of "modifiers"
field) (was: Fix tests post JDK-8210522)
> Fix tests post JDK-8210522 (rewrite reflection of "modifiers" field)
>
>
> Key: CASSANDRA-18181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18181
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
>
> From JDK-8210522:
> {code:java}
> Core reflection has a filtering mechanism to hide security and integrity
> sensitive fields and methods from Class getXXXField(s) and getXXXMethod(s).
> The filtering mechanism has been used for several releases to hide security
> sensitive fields such as System.security and Class.classLoader.
> This CSR proposes to extend the filters to hide fields from a number of
> highly security sensitive classes in java.lang.reflect and java.lang.invoke.
> {code}
> We are using at a few places in our tests
> {code:java}
> Field.class.getDeclaredField("modifiers");{code}
> This breaks as expected when tests are run with JDK17, example:
>
> {code:java}
> java.lang.RuntimeException: java.lang.NoSuchFieldException: modifiers
> at
> org.apache.cassandra.transport.MessagePayloadTest.makeCqlQueryHandlerAccessible(MessagePayloadTest.java:79)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: java.lang.NoSuchFieldException: modifiers at
> java.base/java.lang.Class.getDeclaredField(Class.java:2610)
> at
> org.apache.cassandra.transport.MessagePayloadTest.makeCqlQueryHandlerAccessible(MessagePayloadTest.java:70)
>
> ... 15 more{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-18185) Accumulate all the `docs` PR from GitHub into a single patch
[ https://issues.apache.org/jira/browse/CASSANDRA-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680938#comment-17680938 ] Stefan Miklosovic commented on CASSANDRA-18185: --- thanks [~neshkeev] and [~polandll] [~mck] I have question about non-documentation changes (changes related non-asciidoc files) NEWS.txt CHANGES.txt build.xml I would not commit these changes. We might have a separate ticket for that which would cover it systematically in all branches. For example when we change typos in CHANGES.txt (Cassanda / Cassanra ...) to CASSANDRA, it might case some conflicts when merging up from 3.0 to trunk, for example ... no? Same with NEWS.txt etc. I would basically commit just adocs plus some minor changes in cassandra.yaml (redundant spaces plus some commentary formulated little bit differently). This is basically what we would like to commit to trunk _minus_ these three files I mentioned above. wdyt? https://github.com/instaclustr/cassandra/commit/2ba97f2df6fee7bdc531576f331c57ce186139e8 > Accumulate all the `docs` PR from GitHub into a single patch > > > Key: CASSANDRA-18185 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18185 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Nikita Eshkeev >Assignee: Nikita Eshkeev >Priority: Low > Fix For: 4.x > > Time Spent: 5h 50m > Remaining Estimate: 0h > > In order to make it easier to review the `docs` labeled pull-requests all of > them should be accumulated into a single commit as per the > [request|https://github.com/apache/cassandra/pull/2062#issuecomment-1385002289] > from [~smiklosovic] -- 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 (5d984b10 -> 1b86a79b)
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 5d984b10 generate docs for 5dd84ab2 new 1b86a79b generate docs for 5dd84ab2 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 (5d984b10) \ N -- N -- N refs/heads/asf-staging (1b86a79b) 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 4970898 -> 4970898 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
