[jira] [Commented] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482934#comment-17482934
]
Michael Semb Wever commented on CASSANDRA-17182:
bq. I was about to make the last push and I noticed this jenkins docs huge
commit . Is this fine? It merged after my commit
Yes. That's the generation (build) of the full website (everything built goes
under {{content/}})
bq. I didn't find any other previous Jenkins commits in the history, so
double-checking.
That's correct. After each CI/CD build, asf-staging is reset to trunk and then
this "generated" commit added. That way we can see precisely which SHA has been
built and deployed to both staging and prod.
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17126:
Reviewers: Berenguer Blasi, Brandon Williams (was: Brandon Williams)
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482908#comment-17482908
]
Berenguer Blasi commented on CASSANDRA-17126:
-
Code lgtm. The failing junit passes locally. I left a few nits that can be
addressed on commit. +1
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17140) Broken test_rolling_upgrade - upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
[
https://issues.apache.org/jira/browse/CASSANDRA-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482884#comment-17482884
]
Berenguer Blasi commented on CASSANDRA-17140:
-
Fell free to take it. I was taking a break dur to excessive hair pulling lol.
Happy to have sbdy else help give it a go. It is an important one as it's
almost the last one towards a mostly green CI.
> Broken test_rolling_upgrade -
> upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
>
>
> Key: CASSANDRA-17140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17140
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Yifan Cai
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> The tests "test_rolling_upgrade" fail with the below error.
>
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/279/workflows/6340cd42-0b27-42c2-8418-9f8b56c57bea/jobs/1990]
>
> I am able to alway produce it by running the test locally too.
> {{$ pytest --execute-upgrade-tests-only --upgrade-target-version-only
> --upgrade-version-selection all --cassandra-version=4.0
> upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_3_11_x_To_indev_4_0_x::test_rolling_upgrade}}
>
> {code:java}
> self =
> object at 0x7ffba4242fd0>
> subprocs = [,
> ]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17140) Broken test_rolling_upgrade - upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
[
https://issues.apache.org/jira/browse/CASSANDRA-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482884#comment-17482884
]
Berenguer Blasi edited comment on CASSANDRA-17140 at 1/27/22, 6:07 AM:
---
Fell free to take it. I was taking a break due to excessive hair pulling lol.
Happy to have sbdy else help give it a go. It is an important one as it's
almost the last one towards a mostly green CI.
was (Author: bereng):
Fell free to take it. I was taking a break dur to excessive hair pulling lol.
Happy to have sbdy else help give it a go. It is an important one as it's
almost the last one towards a mostly green CI.
> Broken test_rolling_upgrade -
> upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
>
>
> Key: CASSANDRA-17140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17140
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Yifan Cai
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> The tests "test_rolling_upgrade" fail with the below error.
>
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/279/workflows/6340cd42-0b27-42c2-8418-9f8b56c57bea/jobs/1990]
>
> I am able to alway produce it by running the test locally too.
> {{$ pytest --execute-upgrade-tests-only --upgrade-target-version-only
> --upgrade-version-selection all --cassandra-version=4.0
> upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_3_11_x_To_indev_4_0_x::test_rolling_upgrade}}
>
> {code:java}
> self =
> object at 0x7ffba4242fd0>
> subprocs = [,
> ]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17294) Fix generate-eclipse-files
[
https://issues.apache.org/jira/browse/CASSANDRA-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482882#comment-17482882
]
Berenguer Blasi commented on CASSANDRA-17294:
-
I am also using eclipse. Yes trunk was broken but it has to be sthg recent bc I
was ok using it all the time. The PR fixes it. I am not so sure about adding
all those new jars but I don't think that will hurt. We can always remove that
if needed for any reason at a later time. +1 from me.
> Fix generate-eclipse-files
> --
>
> Key: CASSANDRA-17294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17294
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Yash Ladha
>Assignee: Yash Ladha
>Priority: Normal
>
> I was doing the local setup of cassandra and using the
> [https://github.com/eclipse/eclipse.jdt.ls] for development. When i visited
> the `CassandraDaemon.java` greeted with an error that the file is not in
> classpath, which was very weird. Upon investigation found out that the
> `classpath` was not closed and due to which that error is occuring.
> This issue is to solve the generation of correct .{_}classpath{_} file and
> inclusion of correct libs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17294) Fix generate-eclipse-files
[
https://issues.apache.org/jira/browse/CASSANDRA-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17294:
Status: Needs Committer (was: Review In Progress)
> Fix generate-eclipse-files
> --
>
> Key: CASSANDRA-17294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17294
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Yash Ladha
>Assignee: Yash Ladha
>Priority: Normal
>
> I was doing the local setup of cassandra and using the
> [https://github.com/eclipse/eclipse.jdt.ls] for development. When i visited
> the `CassandraDaemon.java` greeted with an error that the file is not in
> classpath, which was very weird. Upon investigation found out that the
> `classpath` was not closed and due to which that error is occuring.
> This issue is to solve the generation of correct .{_}classpath{_} file and
> inclusion of correct libs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17294) Fix generate-eclipse-files
[
https://issues.apache.org/jira/browse/CASSANDRA-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17294:
Reviewers: Berenguer Blasi
Status: Review In Progress (was: Needs Committer)
> Fix generate-eclipse-files
> --
>
> Key: CASSANDRA-17294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17294
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Yash Ladha
>Assignee: Yash Ladha
>Priority: Normal
>
> I was doing the local setup of cassandra and using the
> [https://github.com/eclipse/eclipse.jdt.ls] for development. When i visited
> the `CassandraDaemon.java` greeted with an error that the file is not in
> classpath, which was very weird. Upon investigation found out that the
> `classpath` was not closed and due to which that error is occuring.
> This issue is to solve the generation of correct .{_}classpath{_} file and
> inclusion of correct libs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17293) Update python test framework from nose to nose2
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17293: --- Description: I had trouble trying to install and run the python nose test from pip (nosetest not found). According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] h1. _Note to Users_ _Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using [Nose2|https://github.com/nose-devs/nose2], [py.test|http://pytest.org/], or just plain unittest/unittest2._ Upgrading to nose2 is likely the least effort. was: I had trouble trying to install and run the python nose test from pip (nosetest not found). According to the homepage of nose at https://nose.readthedocs.io/en/latest/ h1. _Note to Users_ _Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using [Nose2|https://github.com/nose-devs/nose2], [py.test|http://pytest.org/], or just plain unittest/unittest2._ Upgrading to nose2 is likely the least effort. __ > Update python test framework from nose to nose2 > --- > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to nose2 is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482816#comment-17482816
]
David Capwell commented on CASSANDRA-15399:
---
[~stefan.miklosovic] think this patch is in a good enough shape to start
reviewing; need to improve testing a bit more but core logic is ready.
I sent out a patch for CASSANDRA-17295 to enable vtables to be read from
internode messaging, with this we can now query participate vtables; this patch
does not leverage that, the thinking is with this we can start to refactor the
coordinator to make some of the operators more resilient; this patch does NOT
store the Merkel trees, leaving making validation resilience to future work
(thought process was to store in a physical table, but need to confirm this is
safe in call cases).
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
> progress_percentage float,
> queue_duration_ms bigint,
> runtime_duration_ms bigint,
> total_duration_ms bigint,
> estimated_partitions bigint,
> partitions_processed bigint,
> estimated_total_bytes bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name )
> )
> {code}
> The main reason for exposing virtual tables rather than exposing through
> durable tables is to make sure what is exposed is accurate. In cases of
> write failures or node failures, the durable tables could become in-accurate
> and could add edge cases where the repair is not running but the tables say
> it is; by relying on repair's internal in-memory bookkeeping, these problems
> go away.
> This jira does not try to solve the following:
> 1) repair resiliency - there are edge cases where repair hits an error and
> runs forever (at least from nodetool's perspective).
> 2) repair stream tracking - I have not learned the streaming side yet and
> what I see is multiple implementations exist, so seems like high scope. My
> hope is to punt from this jira and tackle separately.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482815#comment-17482815
]
David Capwell edited comment on CASSANDRA-15399 at 1/27/22, 12:43 AM:
--
{code}
cqlsh:ks> Select * from system_views.repairs where keyspace_name ='ks' ALLOW
FILTERING;
@ Row 1
---+--
id| d373a480-7f08-11ec-b73e-87a2fc152add
command_id| 1
duration_millis | 172
failure_cause | null
keyspace_name | ks
last_updated_at | 2022-01-27 00:34:02.74+
options_column_families | {}
options_data_centers | {}
options_force_repair | False
options_hosts | {}
options_ignore_unreplicated_keyspaces | False
options_incremental | null
options_job_threads | 1
options_optimise_streams | False
options_parallelism | PARALLEL
options_preview_kind | NONE
options_primary_range | False
options_pull_repair | False
options_ranges|
{'(-3074457345618258603,3074457345618258602]',
'(3074457345618258602,-9223372036854775808]'}
options_subrange_repair | False
options_trace | False
participants | ['/127.0.0.2:7000', '/127.0.0.3:7000']
progress_percentage | 100
ranges|
[['(3074457345618258602,-9223372036854775808]'],
['(-3074457345618258603,3074457345618258602]']]
sessions | {d38027a0-7f08-11ec-b73e-87a2fc152add,
d3822370-7f08-11ec-b73e-87a2fc152add}
state | success
state_failure_timestamp | null
state_init_timestamp | 2022-01-27 00:34:02.568000+
state_prepare_complete_timestamp | 2022-01-27 00:34:02.601000+
state_prepare_submit_timestamp| 2022-01-27 00:34:02.586000+
state_repair_complete_timestamp | 2022-01-27 00:34:02.739000+
state_repair_submit_timestamp | 2022-01-27 00:34:02.603000+
state_setup_timestamp | 2022-01-27 00:34:02.568000+
state_skipped_timestamp | null
state_started_timestamp | 2022-01-27 00:34:02.575000+
state_success_timestamp | 2022-01-27 00:34:02.74+
success_message | Repair completed successfully
table_names | ['users']
type | incremental
unfiltered_ranges |
[['(3074457345618258602,-9223372036854775808]'],
['(-3074457345618258603,3074457345618258602]']]
(1 rows)
cqlsh:ks> select * from system_views.repair_jobs where
repair_id=d373a480-7f08-11ec-b73e-87a2fc152add ALLOW FILTERING;
@ Row 1
-+
id | 15183e2e-bdf1-3ba0-b039-72057b2d0317
duration_millis | 48
failure_cause | null
keyspace_name | ks
last_updated_at | 2022-01-27 00:34:02.713000+
progress_percentage | 100
ranges |
['(-3074457345618258603,3074457345618258602]']
repair_id | d373a480-7f08-11ec-b73e-87a2fc152add
session_id | d3822370-7f08-11ec-b73e-87a2fc152add
state | success
state_failure_timestamp | null
state_init_timestamp| 2022-01-27 00:34:02.665000+
state_snapshot_complete_timestamp | null
state_snapshot_submit_timestamp | null
state_started_timestamp | 2022-01-27 00:34:02.665000+
state_stream_submit_timestamp | 2022-01-27 00:34:02.712000+
state_success_timestamp | 2022-01-27 00:34:02.713000+
state_validation_complete_timestamp | 2022-01-27 00:34:02.712000+
state_validation_submit_timestamp | 2022-01-27 00:34:02.665000+
success_message | null
table_name | users
@ Row 2
-+
id | 730585a5-e105-32f3-a8e4-be6771827819
duration_millis | 53
failure_cause | null
keyspace_name | ks
last_updated_at | 2022-01-27 00:34:02.712000+
progress_percentage | 100
ranges
[jira] [Commented] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482815#comment-17482815
]
David Capwell commented on CASSANDRA-15399:
---
{code}
cqlsh:ks> select * from system_views.repair_validations where
repair_id=d373a480-7f08-11ec-b73e-87a2fc152add ALLOW FILTERING;
@ Row 1
---+
id| 15183e2e-bdf1-3ba0-b039-72057b2d0317
duration_millis | 36
estimated_partitions | 128
estimated_total_bytes | 27
failure_cause | null
initiator | /127.0.0.1:7000
keyspace_name | ks
last_updated_at | 2022-01-27 00:34:02.708000+
partitions_processed | 1
progress_percentage | 100
ranges| ['(-3074457345618258603,3074457345618258602]']
repair_id | d373a480-7f08-11ec-b73e-87a2fc152add
session_id| d3822370-7f08-11ec-b73e-87a2fc152add
state | success
state_failure_timestamp | null
state_init_timestamp | 2022-01-27 00:34:02.672000+
state_sending_trees_timestamp | 2022-01-27 00:34:02.705000+
state_skipped_timestamp | null
state_started_timestamp | 2022-01-27 00:34:02.678000+
state_success_timestamp | 2022-01-27 00:34:02.708000+
success_message | null
table_name| users
@ Row 2
---+
id| 730585a5-e105-32f3-a8e4-be6771827819
duration_millis | 37
estimated_partitions | 1
estimated_total_bytes | 26
failure_cause | null
initiator | /127.0.0.1:7000
keyspace_name | ks
last_updated_at | 2022-01-27 00:34:02.706000+
partitions_processed | 1
progress_percentage | 100
ranges| ['(3074457345618258602,-9223372036854775808]']
repair_id | d373a480-7f08-11ec-b73e-87a2fc152add
session_id| d38027a0-7f08-11ec-b73e-87a2fc152add
state | success
state_failure_timestamp | null
state_init_timestamp | 2022-01-27 00:34:02.669000+
state_sending_trees_timestamp | 2022-01-27 00:34:02.703000+
state_skipped_timestamp | null
state_started_timestamp | 2022-01-27 00:34:02.676000+
state_success_timestamp | 2022-01-27 00:34:02.706000+
success_message | null
table_name| users
(2 rows)
{code}
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
>
[jira] [Updated] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15399:
--
Test and Documentation Plan: tests
Status: Patch Available (was: In Progress)
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
> progress_percentage float,
> queue_duration_ms bigint,
> runtime_duration_ms bigint,
> total_duration_ms bigint,
> estimated_partitions bigint,
> partitions_processed bigint,
> estimated_total_bytes bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name )
> )
> {code}
> The main reason for exposing virtual tables rather than exposing through
> durable tables is to make sure what is exposed is accurate. In cases of
> write failures or node failures, the durable tables could become in-accurate
> and could add edge cases where the repair is not running but the tables say
> it is; by relying on repair's internal in-memory bookkeeping, these problems
> go away.
> This jira does not try to solve the following:
> 1) repair resiliency - there are edge cases where repair hits an error and
> runs forever (at least from nodetool's perspective).
> 2) repair stream tracking - I have not learned the streaming side yet and
> what I see is multiple implementations exist, so seems like high scope. My
> hope is to punt from this jira and tackle separately.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17182:
Status: Ready to Commit (was: Review In Progress)
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17126:
-
Status: Needs Committer (was: Review In Progress)
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482788#comment-17482788
]
Brandon Williams commented on CASSANDRA-17126:
--
+1
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17126:
-
Status: Review In Progress (was: Changes Suggested)
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482766#comment-17482766
]
Ekaterina Dimitrova edited comment on CASSANDRA-17182 at 1/26/22, 10:50 PM:
[~mck] I was about to make the last push and I noticed this jenkins docs huge
[commit|https://github.com/apache/cassandra-website/commit/2bcdce9982ed5c3cc29af7f707b084bb230ca293]
. Is this fine? It merged after my commit
I didn't find any other previous Jenkins commits in the history, so
double-checking On a quick check I didn't see any doc issues in the
[https://cassandra.staged.apache.org|https://cassandra.staged.apache.org/]
was (Author: e.dimitrova):
[~mck] I was about to commit and I noticed this jenkins docs huge
[commit|https://github.com/apache/cassandra-website/commit/2bcdce9982ed5c3cc29af7f707b084bb230ca293]
. Is this fine? It merged after my commit
I didn't find any other previous Jenkins commits in the history, so
double-checking On a quick check I didn't see any doc issues in the
[https://cassandra.staged.apache.org|https://cassandra.staged.apache.org/]
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482766#comment-17482766
]
Ekaterina Dimitrova commented on CASSANDRA-17182:
-
[~mck] I was about to commit and I noticed this jenkins docs huge
[commit|https://github.com/apache/cassandra-website/commit/2bcdce9982ed5c3cc29af7f707b084bb230ca293]
. Is this fine?
I didn't find any other previous Jenkins commits in the history, so
double-checking On a quick check I didn't see any doc issues in the
[https://cassandra.staged.apache.org|https://cassandra.staged.apache.org/]
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482766#comment-17482766
]
Ekaterina Dimitrova edited comment on CASSANDRA-17182 at 1/26/22, 10:38 PM:
[~mck] I was about to commit and I noticed this jenkins docs huge
[commit|https://github.com/apache/cassandra-website/commit/2bcdce9982ed5c3cc29af7f707b084bb230ca293]
. Is this fine? It merged after my commit
I didn't find any other previous Jenkins commits in the history, so
double-checking On a quick check I didn't see any doc issues in the
[https://cassandra.staged.apache.org|https://cassandra.staged.apache.org/]
was (Author: e.dimitrova):
[~mck] I was about to commit and I noticed this jenkins docs huge
[commit|https://github.com/apache/cassandra-website/commit/2bcdce9982ed5c3cc29af7f707b084bb230ca293]
. Is this fine?
I didn't find any other previous Jenkins commits in the history, so
double-checking On a quick check I didn't see any doc issues in the
[https://cassandra.staged.apache.org|https://cassandra.staged.apache.org/]
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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 (335e65f -> 2bcdce9)
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 335e65f generate docs for d31287a8 add ea04202 Update instructions for testing with your own CCM branch patch by Ekaterina Dimitrova, reviewed by Josh McKenzie and Berenguer Blasi for CASSANDRA-17182 new 2bcdce9 generate docs for ea04202b 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 (335e65f) \ N -- N -- N refs/heads/asf-staging (2bcdce9) 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/_/development/index.html | 4 content/_/development/testing.html | 4 .../modules/ROOT/pages/development/testing.adoc| 3 +++ site-ui/build/ui-bundle.zip| Bin 4740061 -> 4740061 bytes 4 files changed, 11 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17140) Broken test_rolling_upgrade - upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
[
https://issues.apache.org/jira/browse/CASSANDRA-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482731#comment-17482731
]
Ekaterina Dimitrova commented on CASSANDRA-17140:
-
Hey [~jmckenzie] , thanks for checking. I am not looking into it on my end.
Normally if I do I assign tickets to myself if I actively work on them or plan
to work on them soon.
> Broken test_rolling_upgrade -
> upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
>
>
> Key: CASSANDRA-17140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17140
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Yifan Cai
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> The tests "test_rolling_upgrade" fail with the below error.
>
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/279/workflows/6340cd42-0b27-42c2-8418-9f8b56c57bea/jobs/1990]
>
> I am able to alway produce it by running the test locally too.
> {{$ pytest --execute-upgrade-tests-only --upgrade-target-version-only
> --upgrade-version-selection all --cassandra-version=4.0
> upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_3_11_x_To_indev_4_0_x::test_rolling_upgrade}}
>
> {code:java}
> self =
> object at 0x7ffba4242fd0>
> subprocs = [,
> ]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17140) Broken test_rolling_upgrade - upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
[
https://issues.apache.org/jira/browse/CASSANDRA-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie reassigned CASSANDRA-17140:
-
Assignee: Josh McKenzie
> Broken test_rolling_upgrade -
> upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
>
>
> Key: CASSANDRA-17140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17140
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Yifan Cai
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> The tests "test_rolling_upgrade" fail with the below error.
>
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/279/workflows/6340cd42-0b27-42c2-8418-9f8b56c57bea/jobs/1990]
>
> I am able to alway produce it by running the test locally too.
> {{$ pytest --execute-upgrade-tests-only --upgrade-target-version-only
> --upgrade-version-selection all --cassandra-version=4.0
> upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_3_11_x_To_indev_4_0_x::test_rolling_upgrade}}
>
> {code:java}
> self =
> object at 0x7ffba4242fd0>
> subprocs = [,
> ]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17140) Broken test_rolling_upgrade - upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
[
https://issues.apache.org/jira/browse/CASSANDRA-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482726#comment-17482726
]
Josh McKenzie commented on CASSANDRA-17140:
---
[~bereng] / [~e.dimitrova] either of you have any concerns w/me taking this on?
Was unassigned but want to make sure neither of you are active on it.
> Broken test_rolling_upgrade -
> upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
>
>
> Key: CASSANDRA-17140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17140
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Yifan Cai
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> The tests "test_rolling_upgrade" fail with the below error.
>
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/279/workflows/6340cd42-0b27-42c2-8418-9f8b56c57bea/jobs/1990]
>
> I am able to alway produce it by running the test locally too.
> {{$ pytest --execute-upgrade-tests-only --upgrade-target-version-only
> --upgrade-version-selection all --cassandra-version=4.0
> upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_3_11_x_To_indev_4_0_x::test_rolling_upgrade}}
>
> {code:java}
> self =
> object at 0x7ffba4242fd0>
> subprocs = [,
> ]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482717#comment-17482717
]
Brandon Williams commented on CASSANDRA-17126:
--
[Circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17126=all]
in progress.
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17310) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
Josh McKenzie created CASSANDRA-17310:
-
Summary: Test Failure:
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
Key: CASSANDRA-17310
URL: https://issues.apache.org/jira/browse/CASSANDRA-17310
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/java
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-4.0/312/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV3XTest/testAvailability/
Failed 1 times in the last 5 runs. Flakiness: 25%, Stability: 80%
Error Message
Unexpected error while reading in case write-read consistency ONE-ALL with
upgraded coordinator and 2 nodes down
{code}
Stacktrace
junit.framework.AssertionFailedError: Unexpected error while reading in case
write-read consistency ONE-ALL with upgraded coordinator and 2 nodes down
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:142)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:91)
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:231)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:93)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:61)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:56)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability(MixedModeAvailabilityV3XTest.java:33)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:166)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:134)
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17310) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
[
https://issues.apache.org/jira/browse/CASSANDRA-17310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482697#comment-17482697
]
Josh McKenzie commented on CASSANDRA-17310:
---
Possibly related to CASSANDRA-17307 though the error on the two failures
differs.
> Test Failure:
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
>
>
> Key: CASSANDRA-17310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17310
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/312/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV3XTest/testAvailability/
> Failed 1 times in the last 5 runs. Flakiness: 25%, Stability: 80%
> Error Message
> Unexpected error while reading in case write-read consistency ONE-ALL with
> upgraded coordinator and 2 nodes down
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Unexpected error while reading in case
> write-read consistency ONE-ALL with upgraded coordinator and 2 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:142)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:91)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:231)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:93)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:61)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:56)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability(MixedModeAvailabilityV3XTest.java:33)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:166)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:134)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17309) Test Failure: dtest-upgrade.upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_indev_3_0_x_To_indev_4_0_x.test_edge_2i_on_complex_pk
Josh McKenzie created CASSANDRA-17309:
-
Summary: Test Failure:
dtest-upgrade.upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_indev_3_0_x_To_indev_4_0_x.test_edge_2i_on_complex_pk
Key: CASSANDRA-17309
URL: https://issues.apache.org/jira/browse/CASSANDRA-17309
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
Failed 1 times in the last 30 runs. Flakiness: 3%, Stability: 96%
Error Message
cassandra.cluster.NoHostAvailable: ('Unable to connect to any servers',
{'127.0.0.1:9042': DriverException('ProtocolError returned from server while
using explicitly set client protocol_version 4')})
{code}
Stacktrace
self =
def test_edge_2i_on_complex_pk(self):
> cursor = self.prepare()
upgrade_tests/cql_tests.py:2796:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
upgrade_tests/upgrade_base.py:138: in prepare
session = self.patient_cql_connection(node1,
protocol_version=protocol_version, **kwargs)
dtest_setup.py:238: in patient_cql_connection
session = retry_till_success(
dtest_setup.py:39: in retry_till_success
return fun(*args, **kwargs)
dtest_setup.py:176: in cql_connection
return self._create_session(node, keyspace, user, password, compression,
dtest_setup.py:216: in _create_session
session = cluster.connect(wait_for_all_pools=True)
../venv/src/cassandra-driver/cassandra/cluster.py:1690: in connect
self.control_connection.connect()
../venv/src/cassandra-driver/cassandra/cluster.py:3488: in connect
self._set_new_connection(self._reconnect_internal())
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
def _reconnect_internal(self):
"""
Tries to connect to each host in the query plan until one succeeds
or every attempt fails. If successful, a new Connection will be
returned. Otherwise, :exc:`NoHostAvailable` will be raised
with an "errors" arg that is a dict mapping host addresses
to the exception that was raised when an attempt was made to open
a connection to that host.
"""
errors = {}
lbp = (
self._cluster.load_balancing_policy
if self._cluster._config_mode == _ConfigMode.LEGACY else
self._cluster._default_load_balancing_policy
)
for host in lbp.make_query_plan():
try:
return self._try_connect(host)
except ConnectionException as exc:
errors[str(host.endpoint)] = exc
log.warning("[control connection] Error connecting to %s:",
host, exc_info=True)
self._cluster.signal_connection_failure(host, exc,
is_host_addition=False)
except Exception as exc:
errors[str(host.endpoint)] = exc
log.warning("[control connection] Error connecting to %s:",
host, exc_info=True)
if self._is_shutdown:
raise DriverException("[control connection] Reconnection in
progress during shutdown")
> raise NoHostAvailable("Unable to connect to any servers", errors)
E cassandra.cluster.NoHostAvailable: ('Unable to connect to any servers',
{'127.0.0.1:9042': DriverException('ProtocolError returned from server while
using explicitly set client protocol_version 4')})
../venv/src/cassandra-driver/cassandra/cluster.py:3533: NoHostAvailable
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16061) transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482693#comment-17482693
]
Josh McKenzie commented on CASSANDRA-16061:
---
Possibly related:
[https://ci-cassandra.apache.org/job/Cassandra-4.0/308/testReport/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
{code:java}
Error Message
ccmlib.node.TimeoutError: 12 Jan 2022 00:01:53 [node1] after 120.13/120 seconds
Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log: Head: INFO
[Messaging-EventLoop-3-5] 2022-01-11 23:59:5 Tail:
0.0.1:7000(/127.0.0.1:50014)->/127.0.0.4:7000-URGENT_MESSAGES-36cbc506
successfully connected, version = 12, framing = CRC, encryption = unencrypted
Stacktrace
self =
@flaky(max_runs=1)
@pytest.mark.no_vnodes
def test_move_backwards_and_cleanup(self):
"""Test moving a node backwards without moving past a neighbor token"""
move_token = '5'
expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
gen_expected(range(0, 21, 2)),
gen_expected(range(1, 6, 2), range(6, 31)),
gen_expected(range(7, 20, 2), range(21, 40))]
expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
gen_expected(range(0, 21)),
gen_expected(range(6, 31)),
gen_expected(range(21, 40))]
> self.move_test(move_token, expected_after_move, expected_after_repair)
transient_replication_ring_test.py:335:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
transient_replication_ring_test.py:237: in move_test
node4.start(wait_for_binary_proto=NODE_WAIT_TIMEOUT_IN_SECS * 2)
transient_replication_ring_test.py:52: in new_start
return old_start(*args, **kwargs)
../venv/lib/python3.8/site-packages/ccmlib/node.py:895: in start
node.watch_log_for_alive(self, from_mark=mark)
../venv/lib/python3.8/site-packages/ccmlib/node.py:664: in watch_log_for_alive
self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
filename=filename)
../venv/lib/python3.8/site-packages/ccmlib/node.py:588: in watch_log_for
TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
start = 1641945593.295578, timeout = 120
msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n Head:
INFO [Messaging-EventLoop-3-5] 2022-01-11
2...27.0.0.4:7000-URGENT_MESSAGES-36cbc506 successfully connected, version =
12, framing = CRC, encryption = unencrypted\n"
node = 'node1'
@staticmethod
def raise_if_passed(start, timeout, msg, node=None):
if start + timeout < time.time():
> raise TimeoutError.create(start, timeout, msg, node)
E ccmlib.node.TimeoutError: 12 Jan 2022 00:01:53 [node1] after
120.13/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
system.log:
EHead: INFO [Messaging-EventLoop-3-5] 2022-01-11 23:59:5
ETail:
0.0.1:7000(/127.0.0.1:50014)->/127.0.0.4:7000-URGENT_MESSAGES-36cbc506
successfully connected, version = 12, framing = CRC, encryption = unencrypted
../venv/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
{code}
> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
>
>
> Key: CASSANDRA-16061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16061
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> Failing here, also locally:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/312/workflows/da4ce69c-e778-467e-b9f3-27ab166a8321/jobs/1945]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17308) Test Failure: dtest-upgrade.upgrade_tests.bootstrap_upgrade_test.TestBootstrapUpgrade.test_failed_bootstrap_wiped_node_can_join
[
https://issues.apache.org/jira/browse/CASSANDRA-17308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17308:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> dtest-upgrade.upgrade_tests.bootstrap_upgrade_test.TestBootstrapUpgrade.test_failed_bootstrap_wiped_node_can_join
> ---
>
> Key: CASSANDRA-17308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17308
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/308/testReport/dtest-upgrade.upgrade_tests.bootstrap_upgrade_test/TestBootstrapUpgrade/test_failed_bootstrap_wiped_node_can_join/
> Failed 1 times in the last 24 runs. Flakiness: 4%, Stability: 95%
> Error Message
> assert not True + where True = >() +where Node.is_running of > =
> .is_running
> {code}
> Stacktrace
> self = 0x7f47fc370ee0>
> def test_failed_bootstrap_wiped_node_can_join(self):
> """
> @jira_ticket CASSANDRA-9765
> Test that if a node fails to bootstrap, it can join the cluster
> even if the data is wiped.
> """
> cluster = self.cluster
>
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
> cluster.populate(1)
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.start()
>
> stress_table = 'keyspace1.standard1'
>
> # write some data, enough for the bootstrap to fail later on
> node1 = cluster.nodelist()[0]
> node1.stress(['write', 'n=100K', 'no-warmup', '-rate', 'threads=8'])
> node1.flush()
>
> session = self.patient_cql_connection(node1)
> original_rows = list(session.execute("SELECT * FROM
> {}".format(stress_table,)))
>
> # Add a new node, bootstrap=True ensures that it is not a seed
> node2 = new_node(cluster, bootstrap=True)
>
> # kill node2 in the middle of bootstrap
> t = KillOnBootstrap(node2)
> t.start()
>
> node2.start()
> t.join()
> > assert not node2.is_running()
> E assert not True
> E+ where True = object at 0x7f47fc3591f0>>()
> E+where at 0x7f47fc3591f0>> = .is_running
> bootstrap_test.py:742: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17308) Test Failure: dtest-upgrade.upgrade_tests.bootstrap_upgrade_test.TestBootstrapUpgrade.test_failed_bootstrap_wiped_node_can_join
Josh McKenzie created CASSANDRA-17308:
-
Summary: Test Failure:
dtest-upgrade.upgrade_tests.bootstrap_upgrade_test.TestBootstrapUpgrade.test_failed_bootstrap_wiped_node_can_join
Key: CASSANDRA-17308
URL: https://issues.apache.org/jira/browse/CASSANDRA-17308
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-4.0/308/testReport/dtest-upgrade.upgrade_tests.bootstrap_upgrade_test/TestBootstrapUpgrade/test_failed_bootstrap_wiped_node_can_join/
Failed 1 times in the last 24 runs. Flakiness: 4%, Stability: 95%
Error Message
assert not True + where True = >() +where > =
.is_running
{code}
Stacktrace
self =
def test_failed_bootstrap_wiped_node_can_join(self):
"""
@jira_ticket CASSANDRA-9765
Test that if a node fails to bootstrap, it can join the cluster
even if the data is wiped.
"""
cluster = self.cluster
cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
'True')
cluster.populate(1)
cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
1})
cluster.start()
stress_table = 'keyspace1.standard1'
# write some data, enough for the bootstrap to fail later on
node1 = cluster.nodelist()[0]
node1.stress(['write', 'n=100K', 'no-warmup', '-rate', 'threads=8'])
node1.flush()
session = self.patient_cql_connection(node1)
original_rows = list(session.execute("SELECT * FROM
{}".format(stress_table,)))
# Add a new node, bootstrap=True ensures that it is not a seed
node2 = new_node(cluster, bootstrap=True)
# kill node2 in the middle of bootstrap
t = KillOnBootstrap(node2)
t.start()
node2.start()
t.join()
> assert not node2.is_running()
E assert not True
E+ where True = >()
E+where > = .is_running
bootstrap_test.py:742: AssertionError
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17295) Make vtables accessible via internode messaging
[ https://issues.apache.org/jira/browse/CASSANDRA-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17295: -- Test and Documentation Plan: existing tests Status: Patch Available (was: In Progress) > Make vtables accessible via internode messaging > --- > > Key: CASSANDRA-17295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17295 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > As an extension of CASSANDRA-15399 and needed to solve CASSANDRA-15566, we > need the ability to perform queries against vtables using internode > messaging; currently this is limited to CQL which isn’t exposed in internode -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17303) Test Failure: dtest-offheap.cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_single_core
[
https://issues.apache.org/jira/browse/CASSANDRA-17303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17303:
-
Resolution: Not A Problem
Status: Resolved (was: Triage Needed)
> Test Failure:
> dtest-offheap.cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_single_core
> ---
>
> Key: CASSANDRA-17303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17303
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/dtest-offheap.cqlsh_tests.test_cqlsh_copy/TestCqlshCopy/test_bulk_round_trip_with_single_core_2/
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> {code}
> Stacktrace
> self =
> def test_bulk_round_trip_with_single_core(self):
> """
> Perform a round trip on a simulated single core machine. When
> determining the number of cores,
> copyutil.py will return the number carried by the environment
> variable CQLSH_COPY_TEST_NUM_CORES if it has
> been set.
>
> @jira_ticket CASSANDRA-11053
> """
> os.environ['CQLSH_COPY_TEST_NUM_CORES'] = '1'
> > ret = self._test_bulk_round_trip(nodes=3, partitioner="murmur3",
> > num_operations=10)
> cqlsh_tests/test_cqlsh_copy.py:2539:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> cqlsh_tests/test_cqlsh_copy.py:2436: in _test_bulk_round_trip
> num_records = create_records()
> cqlsh_tests/test_cqlsh_copy.py:2409: in create_records
> ret = rows_to_list(self.session.execute(count_statement))[0][0]
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> coordinator_host=None>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
> request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042
> ../venv/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17303) Test Failure: dtest-offheap.cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_single_core
[
https://issues.apache.org/jira/browse/CASSANDRA-17303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482667#comment-17482667
]
Brandon Williams commented on CASSANDRA-17303:
--
No other failures, this is just a timeout.
> Test Failure:
> dtest-offheap.cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_single_core
> ---
>
> Key: CASSANDRA-17303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17303
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/dtest-offheap.cqlsh_tests.test_cqlsh_copy/TestCqlshCopy/test_bulk_round_trip_with_single_core_2/
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> {code}
> Stacktrace
> self =
> def test_bulk_round_trip_with_single_core(self):
> """
> Perform a round trip on a simulated single core machine. When
> determining the number of cores,
> copyutil.py will return the number carried by the environment
> variable CQLSH_COPY_TEST_NUM_CORES if it has
> been set.
>
> @jira_ticket CASSANDRA-11053
> """
> os.environ['CQLSH_COPY_TEST_NUM_CORES'] = '1'
> > ret = self._test_bulk_round_trip(nodes=3, partitioner="murmur3",
> > num_operations=10)
> cqlsh_tests/test_cqlsh_copy.py:2539:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> cqlsh_tests/test_cqlsh_copy.py:2436: in _test_bulk_round_trip
> num_records = create_records()
> cqlsh_tests/test_cqlsh_copy.py:2409: in create_records
> ret = rows_to_list(self.session.execute(count_statement))[0][0]
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> coordinator_host=None>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
> request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042
> ../venv/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17307) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability
Josh McKenzie created CASSANDRA-17307:
-
Summary: Test Failure:
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability
Key: CASSANDRA-17307
URL: https://issues.apache.org/jira/browse/CASSANDRA-17307
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/java
Reporter: Josh McKenzie
No known failures. Flakiness 0%, Stability 100%
Error Message
Unexpected error while reading in case write-read consistency QUORUM-QUORUM
with not upgraded coordinator and 1 nodes down
{code}
Stacktrace
junit.framework.AssertionFailedError: Unexpected error while reading in case
write-read consistency QUORUM-QUORUM with not upgraded coordinator and 1 nodes
down
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:142)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:91)
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:231)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:93)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:62)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:56)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability(MixedModeAvailabilityV30Test.java:33)
Caused by: java.lang.RuntimeException:
org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
received only 1 responses.
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:218)
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
at
org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
at
org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:135)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:155)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:134)
Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
timed out - received only 1 responses.
at
org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
at
org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
at
org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1833)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1782)
at
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1720)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1629)
at
org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1166)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
at
org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
at
org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17306) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_3_11_X.test_parallel_upgrade
Josh McKenzie created CASSANDRA-17306:
-
Summary: Test Failure:
dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_3_11_X.test_parallel_upgrade
Key: CASSANDRA-17306
URL: https://issues.apache.org/jira/browse/CASSANDRA-17306
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-4.0/320/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestProtoV3Upgrade_AllVersions_EndsAt_3_11_X/test_parallel_upgrade/
Failed 2 times in the last 30 runs. Flakiness: 6%, Stability: 93%
Error Message
test teardown failure
{code}
Stacktrace
Unexpected error found in node logs (see stdout for full details). Errors:
[WARN [MessagingService-Incoming-/127.0.0.1] 2022-01-25 18:46:40,431
IncomingTcpConnection.java:100 - UnknownColumnFamilyException reading from
socket; closing
org.apache.cassandra.db.UnknownColumnFamilyException: Got slice command for
nonexistent table system_auth.roles. If the table was just created, this is
likely due to the schema not being fully propagated. Please wait for schema
agreement on table creation.
at
org.apache.cassandra.db.SliceFromReadCommandSerializer.deserialize(SliceFromReadCommand.java:184)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:158)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:132)
~[apache-cassandra-2.2.19.jar:2.2.19]
at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:200)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:177)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:91)
~[apache-cassandra-2.2.19.jar:2.2.19], WARN
[MessagingService-Incoming-/127.0.0.1] 2022-01-25 18:46:40,431
IncomingTcpConnection.java:100 - UnknownColumnFamilyException reading from
socket; closing
org.apache.cassandra.db.UnknownColumnFamilyException: Got slice command for
nonexistent table system_auth.roles. If the table was just created, this is
likely due to the schema not being fully propagated. Please wait for schema
agreement on table creation.
at
org.apache.cassandra.db.SliceFromReadCommandSerializer.deserialize(SliceFromReadCommand.java:184)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:158)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:132)
~[apache-cassandra-2.2.19.jar:2.2.19]
at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:200)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:177)
~[apache-cassandra-2.2.19.jar:2.2.19]
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:91)
~[apache-cassandra-2.2.19.jar:2.2.19]]
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17305) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD.test_parallel_upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17305:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD.test_parallel_upgrade
> -
>
> Key: CASSANDRA-17305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17305
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> Failed 2 times in the last 29 runs. Flakiness: 7%, Stability: 93%
> Error Message
> Failed: Timeout >900.0s
> {code}
> Stacktrace
> self =
> object at 0x7f19858d59d0>
> def test_parallel_upgrade(self):
> """
> Test upgrading cluster all at once (requires cluster downtime).
> """
> > self.upgrade_scenario()
> upgrade_tests/upgrade_through_versions_test.py:313:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:435: in upgrade_scenario
> cluster.stop()
> ../venv/lib/python3.8/site-packages/ccmlib/cluster.py:576: in stop
> if not node.stop(wait=wait, signal_event=signal_event, **kwargs):
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = , wait = True
> wait_other_notice = False, signal_event = , kwargs = {}
> still_running = True, wait_time_sec = 16, i = 4
> def stop(self, wait=True, wait_other_notice=False,
> signal_event=signal.SIGTERM, **kwargs):
> """
> Stop the node.
> - wait: if True (the default), wait for the Cassandra process
> to be
> really dead. Otherwise return after having sent the kill
> signal.
> - wait_other_notice: return only when the other live nodes of
> the
> cluster have marked this node has dead.
> - signal_event: Signal event to send to Cassandra; default is to
> let Cassandra clean up and shut down properly (SIGTERM [15])
> - Optional:
> + gently: Let Cassandra clean up and shut down properly;
> unless
>false perform a 'kill -9' which shuts down faster.
> """
> if self.is_running():
> if wait_other_notice:
> marks = [(node, node.mark_log()) for node in
> list(self.cluster.nodes.values()) if node.is_live() and node is not self]
>
> if common.is_win():
> # Just taskkill the instance, don't bother trying to shut it
> down gracefully.
> # Node recovery should prevent data loss from hard shutdown.
> # We have recurring issues with nodes not stopping /
> releasing files in the CI
> # environment so it makes more sense just to murder it hard
> since there's
> # really little downside.
>
> # We want the node to flush its data before shutdown as some
> tests rely on small writes being present.
> # The default Periodic sync at 10 ms may not have flushed
> data yet, causing tests to fail.
> # This is not a hard requirement, however, so we swallow any
> exceptions this may throw and kill anyway.
> if signal_event is signal.SIGTERM:
> try:
> self.flush()
> except:
> common.warning("Failed to flush node: {0} on
> shutdown.".format(self.name))
> pass
>
> os.system("taskkill /F /PID " + str(self.pid))
> if self._find_pid_on_windows():
> common.warning("Failed to terminate node: {0} with pid:
> {1}".format(self.name, self.pid))
> else:
> # Determine if the signal event should be updated to keep API
> compatibility
> if 'gently' in kwargs and kwargs['gently'] is False:
> signal_event = signal.SIGKILL
>
> os.kill(self.pid, signal_event)
>
> if wait_other_notice:
> for node, mark in marks:
> node.watch_log_for_death(self, from_mark=mark)
> else:
> time.sleep(.1)
>
> still_running = self.is_running()
> if still_running and wait:
> wait_time_sec = 1
> for i in xrange(0, 7):
> # we'll double the wait time each try and
[jira] [Created] (CASSANDRA-17305) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD.test_parallel_upgrade
Josh McKenzie created CASSANDRA-17305:
-
Summary: Test Failure:
dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD.test_parallel_upgrade
Key: CASSANDRA-17305
URL: https://issues.apache.org/jira/browse/CASSANDRA-17305
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
Failed 2 times in the last 29 runs. Flakiness: 7%, Stability: 93%
Error Message
Failed: Timeout >900.0s
{code}
Stacktrace
self =
def test_parallel_upgrade(self):
"""
Test upgrading cluster all at once (requires cluster downtime).
"""
> self.upgrade_scenario()
upgrade_tests/upgrade_through_versions_test.py:313:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
upgrade_tests/upgrade_through_versions_test.py:435: in upgrade_scenario
cluster.stop()
../venv/lib/python3.8/site-packages/ccmlib/cluster.py:576: in stop
if not node.stop(wait=wait, signal_event=signal_event, **kwargs):
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = , wait = True
wait_other_notice = False, signal_event = , kwargs = {}
still_running = True, wait_time_sec = 16, i = 4
def stop(self, wait=True, wait_other_notice=False,
signal_event=signal.SIGTERM, **kwargs):
"""
Stop the node.
- wait: if True (the default), wait for the Cassandra process to
be
really dead. Otherwise return after having sent the kill signal.
- wait_other_notice: return only when the other live nodes of the
cluster have marked this node has dead.
- signal_event: Signal event to send to Cassandra; default is to
let Cassandra clean up and shut down properly (SIGTERM [15])
- Optional:
+ gently: Let Cassandra clean up and shut down properly; unless
false perform a 'kill -9' which shuts down faster.
"""
if self.is_running():
if wait_other_notice:
marks = [(node, node.mark_log()) for node in
list(self.cluster.nodes.values()) if node.is_live() and node is not self]
if common.is_win():
# Just taskkill the instance, don't bother trying to shut it
down gracefully.
# Node recovery should prevent data loss from hard shutdown.
# We have recurring issues with nodes not stopping / releasing
files in the CI
# environment so it makes more sense just to murder it hard
since there's
# really little downside.
# We want the node to flush its data before shutdown as some
tests rely on small writes being present.
# The default Periodic sync at 10 ms may not have flushed data
yet, causing tests to fail.
# This is not a hard requirement, however, so we swallow any
exceptions this may throw and kill anyway.
if signal_event is signal.SIGTERM:
try:
self.flush()
except:
common.warning("Failed to flush node: {0} on
shutdown.".format(self.name))
pass
os.system("taskkill /F /PID " + str(self.pid))
if self._find_pid_on_windows():
common.warning("Failed to terminate node: {0} with pid:
{1}".format(self.name, self.pid))
else:
# Determine if the signal event should be updated to keep API
compatibility
if 'gently' in kwargs and kwargs['gently'] is False:
signal_event = signal.SIGKILL
os.kill(self.pid, signal_event)
if wait_other_notice:
for node, mark in marks:
node.watch_log_for_death(self, from_mark=mark)
else:
time.sleep(.1)
still_running = self.is_running()
if still_running and wait:
wait_time_sec = 1
for i in xrange(0, 7):
# we'll double the wait time each try and cassandra should
# not take more than 1 minute to shutdown
> time.sleep(wait_time_sec)
E Failed: Timeout >900.0s
../venv/lib/python3.8/site-packages/ccmlib/node.py:970: Failed
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17002) Cassandra Ring state transitions should be available through a Virtual Table
[ https://issues.apache.org/jira/browse/CASSANDRA-17002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRA-17002: --- Reviewers: Dinesh Joshi, Yifan Cai (was: Dinesh Joshi) > Cassandra Ring state transitions should be available through a Virtual Table > > > Key: CASSANDRA-17002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17002 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: Dinesh Joshi >Assignee: Francisco Guerrero >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > In many situations it is beneficial to see the last N Gossip state > transitions for debugging and other purposes. We should expose the last N > state transitions through a bounded Virtual Table. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17002) Cassandra Ring state transitions should be available through a Virtual Table
[ https://issues.apache.org/jira/browse/CASSANDRA-17002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRA-17002: --- Test and Documentation Plan: Added tests and added the feature to CHANGES.txt Status: Patch Available (was: In Progress) PR: https://github.com/apache/cassandra/pull/1428 CI: https://app.circleci.com/pipelines/github/frankgh/cassandra?branch=CASSANDRA-17002=all > Cassandra Ring state transitions should be available through a Virtual Table > > > Key: CASSANDRA-17002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17002 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: Dinesh Joshi >Assignee: Francisco Guerrero >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > In many situations it is beneficial to see the last N Gossip state > transitions for debugging and other purposes. We should expose the last N > state transitions through a bounded Virtual Table. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17304) Test Failure: dtest.snapshot_test.TestArchiveCommitlog.test_dont_archive_commitlog
[
https://issues.apache.org/jira/browse/CASSANDRA-17304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17304:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> dtest.snapshot_test.TestArchiveCommitlog.test_dont_archive_commitlog
> --
>
> Key: CASSANDRA-17304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17304
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/321/testReport/dtest.snapshot_test/TestArchiveCommitlog/test_dont_archive_commitlog/
> Failed 1 times in the last 30 runs. Flakiness: 3%, Stability: 96%
> Error Message
> AssertionError: It's been over a {s}s and we haven't written a new commitlog
> segment. Something is wrong.
> {code}
> Stacktrace
> self =
> def test_dont_archive_commitlog(self):
> """
> Run the archive commitlog test, but forget to add the restore
> commands
> """
> > self.run_archive_commitlog(restore_point_in_time=False,
> > restore_archived_commitlog=False)
> snapshot_test.py:253:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> snapshot_test.py:300: in run_archive_commitlog
> advance_to_next_cl_segment(
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> session =
> commitlog_dir =
> '/home/cassandra/cassandra/cassandra-dtest/tmp/dtest-1mc01m0r/test/node1/commitlogs'
> keyspace_name = 'ks', table_name = 'junk_table', timeout = 120
> def advance_to_next_cl_segment(session, commitlog_dir,
>keyspace_name='ks',
> table_name='junk_table',
>timeout=120):
> """
> This is a hack to work around problems like CASSANDRA-11811.
>
> The problem happens in commitlog-replaying tests, like the snapshot
> and CDC
> tests. If we replay the first commitlog that's created, we wind up
> replaying some mutations that initialize system tables, so this
> function
> advances the node to the next CL by filling up the first one.
> """
> session.execute(
> 'CREATE TABLE {ks}.{tab} ('
> 'a uuid PRIMARY KEY, b uuid, c uuid, d uuid, '
> 'e uuid, f uuid, g uuid, h uuid'
> ')'.format(ks=keyspace_name, tab=table_name)
> )
> prepared_insert = session.prepare(
> 'INSERT INTO {ks}.{tab} '
> '(a, b, c, d, e, f, g, h) '
> 'VALUES ('
> 'uuid(), uuid(), uuid(), uuid(), '
> 'uuid(), uuid(), uuid(), uuid()'
> ')'.format(ks=keyspace_name, tab=table_name)
> )
>
> # record segments that we want to advance past
> initial_cl_files = _files_in(commitlog_dir)
>
> start = time.time()
> stop_time = start + timeout
> rate_limited_debug_logger = get_rate_limited_function(logger.debug, 5)
> logger.debug('attempting to write until we start writing to new CL
> segments: {}'.format(initial_cl_files))
>
> while _files_in(commitlog_dir) <= initial_cl_files:
> elapsed = time.time() - start
> rate_limited_debug_logger(' commitlog-advancing load step has
> lasted {s:.2f}s'.format(s=elapsed))
> > assert (
> time.time() <= stop_time), "It's been over a {s}s and we
> haven't written a new " + \
> "commitlog segment. Something is wrong.".format(s=timeout)
> E AssertionError: It's been over a {s}s and we haven't written a
> new commitlog segment. Something is wrong.
> tools/hacks.py:59: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17304) Test Failure: dtest.snapshot_test.TestArchiveCommitlog.test_dont_archive_commitlog
Josh McKenzie created CASSANDRA-17304:
-
Summary: Test Failure:
dtest.snapshot_test.TestArchiveCommitlog.test_dont_archive_commitlog
Key: CASSANDRA-17304
URL: https://issues.apache.org/jira/browse/CASSANDRA-17304
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-4.0/321/testReport/dtest.snapshot_test/TestArchiveCommitlog/test_dont_archive_commitlog/
Failed 1 times in the last 30 runs. Flakiness: 3%, Stability: 96%
Error Message
AssertionError: It's been over a {s}s and we haven't written a new commitlog
segment. Something is wrong.
{code}
Stacktrace
self =
def test_dont_archive_commitlog(self):
"""
Run the archive commitlog test, but forget to add the restore
commands
"""
> self.run_archive_commitlog(restore_point_in_time=False,
> restore_archived_commitlog=False)
snapshot_test.py:253:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
snapshot_test.py:300: in run_archive_commitlog
advance_to_next_cl_segment(
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
session =
commitlog_dir =
'/home/cassandra/cassandra/cassandra-dtest/tmp/dtest-1mc01m0r/test/node1/commitlogs'
keyspace_name = 'ks', table_name = 'junk_table', timeout = 120
def advance_to_next_cl_segment(session, commitlog_dir,
keyspace_name='ks', table_name='junk_table',
timeout=120):
"""
This is a hack to work around problems like CASSANDRA-11811.
The problem happens in commitlog-replaying tests, like the snapshot and
CDC
tests. If we replay the first commitlog that's created, we wind up
replaying some mutations that initialize system tables, so this function
advances the node to the next CL by filling up the first one.
"""
session.execute(
'CREATE TABLE {ks}.{tab} ('
'a uuid PRIMARY KEY, b uuid, c uuid, d uuid, '
'e uuid, f uuid, g uuid, h uuid'
')'.format(ks=keyspace_name, tab=table_name)
)
prepared_insert = session.prepare(
'INSERT INTO {ks}.{tab} '
'(a, b, c, d, e, f, g, h) '
'VALUES ('
'uuid(), uuid(), uuid(), uuid(), '
'uuid(), uuid(), uuid(), uuid()'
')'.format(ks=keyspace_name, tab=table_name)
)
# record segments that we want to advance past
initial_cl_files = _files_in(commitlog_dir)
start = time.time()
stop_time = start + timeout
rate_limited_debug_logger = get_rate_limited_function(logger.debug, 5)
logger.debug('attempting to write until we start writing to new CL
segments: {}'.format(initial_cl_files))
while _files_in(commitlog_dir) <= initial_cl_files:
elapsed = time.time() - start
rate_limited_debug_logger(' commitlog-advancing load step has
lasted {s:.2f}s'.format(s=elapsed))
> assert (
time.time() <= stop_time), "It's been over a {s}s and we
haven't written a new " + \
"commitlog segment. Something is wrong.".format(s=timeout)
E AssertionError: It's been over a {s}s and we haven't written a new
commitlog segment. Something is wrong.
tools/hacks.py:59: AssertionError
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17303) Test Failure: dtest-offheap.cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_single_core
[
https://issues.apache.org/jira/browse/CASSANDRA-17303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17303:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> dtest-offheap.cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_single_core
> ---
>
> Key: CASSANDRA-17303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17303
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/dtest-offheap.cqlsh_tests.test_cqlsh_copy/TestCqlshCopy/test_bulk_round_trip_with_single_core_2/
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> {code}
> Stacktrace
> self =
> def test_bulk_round_trip_with_single_core(self):
> """
> Perform a round trip on a simulated single core machine. When
> determining the number of cores,
> copyutil.py will return the number carried by the environment
> variable CQLSH_COPY_TEST_NUM_CORES if it has
> been set.
>
> @jira_ticket CASSANDRA-11053
> """
> os.environ['CQLSH_COPY_TEST_NUM_CORES'] = '1'
> > ret = self._test_bulk_round_trip(nodes=3, partitioner="murmur3",
> > num_operations=10)
> cqlsh_tests/test_cqlsh_copy.py:2539:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> cqlsh_tests/test_cqlsh_copy.py:2436: in _test_bulk_round_trip
> num_records = create_records()
> cqlsh_tests/test_cqlsh_copy.py:2409: in create_records
> ret = rows_to_list(self.session.execute(count_statement))[0][0]
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> coordinator_host=None>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
> request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042
> ../venv/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17303) Test Failure: dtest-offheap.cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_single_core
Josh McKenzie created CASSANDRA-17303:
-
Summary: Test Failure:
dtest-offheap.cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_single_core
Key: CASSANDRA-17303
URL: https://issues.apache.org/jira/browse/CASSANDRA-17303
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/dtest-offheap.cqlsh_tests.test_cqlsh_copy/TestCqlshCopy/test_bulk_round_trip_with_single_core_2/
Error Message
cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request timeout.
See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
{code}
Stacktrace
self =
def test_bulk_round_trip_with_single_core(self):
"""
Perform a round trip on a simulated single core machine. When
determining the number of cores,
copyutil.py will return the number carried by the environment
variable CQLSH_COPY_TEST_NUM_CORES if it has
been set.
@jira_ticket CASSANDRA-11053
"""
os.environ['CQLSH_COPY_TEST_NUM_CORES'] = '1'
> ret = self._test_bulk_round_trip(nodes=3, partitioner="murmur3",
> num_operations=10)
cqlsh_tests/test_cqlsh_copy.py:2539:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
cqlsh_tests/test_cqlsh_copy.py:2436: in _test_bulk_round_trip
num_records = create_records()
cqlsh_tests/test_cqlsh_copy.py:2409: in create_records
ret = rows_to_list(self.session.execute(count_statement))[0][0]
../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state, host, execute_as).result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
def result(self):
"""
Return the final result or raise an Exception if errors were
encountered. If the final result or error has not been set
yet, this method will block until it is set, or the timeout
set for the request expires.
Timeout is specified in the Session request execution functions.
If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
will be raised.
This is a client-side timeout. For more information
about server-side coordinator timeouts, see
:class:`.policies.RetryPolicy`.
Example usage::
>>> future = session.execute_async("SELECT * FROM mycf")
>>> # do other stuff...
>>> try:
... rows = future.result()
... for row in rows:
... ... # process results
... except Exception:
... log.exception("Operation failed:")
"""
self._event.wait()
if self._final_result is not _NOT_SET:
return ResultSet(self, self._final_result)
else:
> raise self._final_exception
E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
request timeout. See Session.execute[_async](timeout)'},
last_host=127.0.0.1:9042
../venv/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17302) Test Failure: dtest-offheap.topology_test.TestTopology.test_decommissioned_node_cant_rejoin
Josh McKenzie created CASSANDRA-17302:
-
Summary: Test Failure:
dtest-offheap.topology_test.TestTopology.test_decommissioned_node_cant_rejoin
Key: CASSANDRA-17302
URL: https://issues.apache.org/jira/browse/CASSANDRA-17302
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-4.0/317/testReport/dtest-offheap.topology_test/TestTopology/test_decommissioned_node_cant_rejoin/
Failed 1 times in the last 20 runs. Flakiness: 5%, Stability: 95%
Error Message
AssertionError: assert None + where None = ('This node was decommissioned and will not rejoin the ring',
'', re.MULTILINE) +where = re.search
+and '' = ([]) +
where = '\n'.join +
and re.MULTILINE = re.MULTILINE
{code}
Stacktrace
self =
@since('3.0')
def test_decommissioned_node_cant_rejoin(self):
"""
@jira_ticket CASSANDRA-8801
Test that a decommissioned node can't rejoin the cluster by:
- creating a cluster,
- decommissioning a node, and
- asserting that the "decommissioned node won't rejoin" error is in
the
logs for that node and
- asserting that the node is not running.
"""
rejoin_err = 'This node was decommissioned and will not rejoin the ring'
self.fixture_dtest_setup.ignore_log_patterns =
list(self.fixture_dtest_setup.ignore_log_patterns) + [
rejoin_err]
self.cluster.populate(3).start()
node1, node2, node3 = self.cluster.nodelist()
logger.debug('decommissioning...')
node3.decommission(force=self.cluster.version() >= '4.0')
logger.debug('stopping...')
node3.stop()
logger.debug('attempting restart...')
node3.start(wait_other_notice=False)
try:
# usually takes 3 seconds, so give it a generous 15
node3.watch_log_for(rejoin_err, timeout=15)
except TimeoutError:
# TimeoutError is not very helpful to the reader of the test output;
# let that pass and move on to string assertion below
pass
> assert re.search(rejoin_err,
'\n'.join(['\n'.join(err_list) for err_list in
node3.grep_log_for_errors()]), re.MULTILINE)
E AssertionError: assert None
E+ where None = ('This node was
decommissioned and will not rejoin the ring', '', re.MULTILINE)
E+where = re.search
E+and '' = ([])
E+ where =
'\n'.join
E+and re.MULTILINE = re.MULTILINE
topology_test.py:416: AssertionError
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17301:
--
Description:
https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
See same failure on
org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-compression
as well
Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
{code}
Stacktrace
java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Standard Output
DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
SLF4J as the default logging framework
DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
-Dio.netty.noUnsafe: false
DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
version: 8
DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
sun.misc.Unsafe.theUnsafe: available
DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
sun.misc.Unsafe.copyMemory: available
...[truncated 417667 chars]...
ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
at
org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
at
org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
... 29 common frames omitted
{code}
was:
https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
{code}
Stacktrace
java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Standard Output
DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
SLF4J as the default logging framework
DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
-Dio.netty.noUnsafe: false
DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
version: 8
DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
sun.misc.Unsafe.theUnsafe: available
DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
sun.misc.Unsafe.copyMemory: available
...[truncated 417667 chars]...
ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
at
org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
at
[jira] [Updated] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17301:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
> ---
>
> Key: CASSANDRA-17301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17301
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> {code}
> Stacktrace
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
> version: 8
> DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> ...[truncated 417667 chars]...
> ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 29 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
Josh McKenzie created CASSANDRA-17301:
-
Summary: Test Failure:
org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
Key: CASSANDRA-17301
URL: https://issues.apache.org/jira/browse/CASSANDRA-17301
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
{code}
Stacktrace
java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
at
org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Standard Output
DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
SLF4J as the default logging framework
DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
-Dio.netty.noUnsafe: false
DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
version: 8
DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
sun.misc.Unsafe.theUnsafe: available
DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
sun.misc.Unsafe.copyMemory: available
...[truncated 417667 chars]...
ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
at
org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
at
org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
... 29 common frames omitted
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17299) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD.test_parallel_upgrade_with
[
https://issues.apache.org/jira/browse/CASSANDRA-17299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17299:
--
Description:
https://ci-cassandra.apache.org/job/Cassandra-4.0/317/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD/test_parallel_upgrade_with_internode_ssl/
Failed 3 times in the last 30 runs. Flakiness: 17%, Stability: 90%
Error Message
Failed: Timeout >900.0s
{code}
Stacktrace
self =
def test_parallel_upgrade_with_internode_ssl(self):
"""
Test upgrading cluster all at once (requires cluster downtime),
with internode ssl.
"""
> self.upgrade_scenario(internode_ssl=True)
upgrade_tests/upgrade_through_versions_test.py:326:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
upgrade_tests/upgrade_through_versions_test.py:420: in upgrade_scenario
self.upgrade_to_version(version_meta, internode_ssl=internode_ssl)
upgrade_tests/upgrade_through_versions_test.py:481: in upgrade_to_version
node.drain()
../venv/lib/python3.8/site-packages/ccmlib/node.py:1540: in drain
self.nodetool("drain")
../venv/lib/python3.8/site-packages/ccmlib/node.py:1005: in nodetool
return handle_external_tool_process(p, ['nodetool', '-h', 'localhost',
'-p', str(self.jmx_port)] + shlex.split(cmd))
../venv/lib/python3.8/site-packages/ccmlib/node.py:2297: in
handle_external_tool_process
out, err = process.communicate()
/usr/lib/python3.8/subprocess.py:1028: in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
/usr/lib/python3.8/subprocess.py:1868: in _communicate
ready = selector.select(timeout)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = , timeout = None
def select(self, timeout=None):
# This is shared between poll() and epoll().
# epoll() has a different signature and handling of timeout parameter.
if timeout is None:
timeout = None
elif timeout <= 0:
timeout = 0
else:
# poll() has a resolution of 1 millisecond, round away from
# zero to wait *at least* timeout seconds.
timeout = math.ceil(timeout * 1e3)
ready = []
try:
> fd_event_list = self._selector.poll(timeout)
E Failed: Timeout >900.0s
/usr/lib/python3.8/selectors.py:415: Failed
{code}
was:
https://ci-cassandra.apache.org/job/Cassandra-4.0/317/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD/test_parallel_upgrade_with_internode_ssl/
Failed 3 times in the last 30 runs. Flakiness: 17%, Stability: 90%
Error Message
Failed: Timeout >900.0s
Stacktrace
self =
def test_parallel_upgrade_with_internode_ssl(self):
"""
Test upgrading cluster all at once (requires cluster downtime),
with internode ssl.
"""
> self.upgrade_scenario(internode_ssl=True)
upgrade_tests/upgrade_through_versions_test.py:326:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
upgrade_tests/upgrade_through_versions_test.py:420: in upgrade_scenario
self.upgrade_to_version(version_meta, internode_ssl=internode_ssl)
upgrade_tests/upgrade_through_versions_test.py:481: in upgrade_to_version
node.drain()
../venv/lib/python3.8/site-packages/ccmlib/node.py:1540: in drain
self.nodetool("drain")
../venv/lib/python3.8/site-packages/ccmlib/node.py:1005: in nodetool
return handle_external_tool_process(p, ['nodetool', '-h', 'localhost',
'-p', str(self.jmx_port)] + shlex.split(cmd))
../venv/lib/python3.8/site-packages/ccmlib/node.py:2297: in
handle_external_tool_process
out, err = process.communicate()
/usr/lib/python3.8/subprocess.py:1028: in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
/usr/lib/python3.8/subprocess.py:1868: in _communicate
ready = selector.select(timeout)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = , timeout = None
def select(self, timeout=None):
# This is shared between poll() and epoll().
# epoll() has a different signature and handling of timeout parameter.
if timeout is None:
timeout = None
elif timeout <= 0:
timeout = 0
else:
# poll() has a resolution of 1 millisecond, round away from
# zero to wait *at least* timeout seconds.
timeout = math.ceil(timeout * 1e3)
ready = []
try:
> fd_event_list = self._selector.poll(timeout)
E Failed: Timeout >900.0s
/usr/lib/python3.8/selectors.py:415: Failed
> Test Failure:
>
[jira] [Created] (CASSANDRA-17300) Test Failure: dtest-offheap.auth_test.TestNetworkAuth.test_revoked_dc_access
Josh McKenzie created CASSANDRA-17300:
-
Summary: Test Failure:
dtest-offheap.auth_test.TestNetworkAuth.test_revoked_dc_access
Key: CASSANDRA-17300
URL: https://issues.apache.org/jira/browse/CASSANDRA-17300
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-4.0/315/testReport/dtest-offheap.auth_test/TestNetworkAuth/test_revoked_dc_access/
Failed 1 times in the last 29 runs. Flakiness: 3%, Stability: 96%
Error Message
subprocess.CalledProcessError: Command
'('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp',
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:lib/jolokia-jvm-1.6.2-agent.jar',
'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.2', 'start',
'1147')' returned non-zero exit status 1.
{code}
Stacktrace
self =
def test_revoked_dc_access(self):
"""
if a user's access to a dc is revoked while they're connected,
all of their requests should fail once the cache is cleared
"""
def test_revoked_access(cache_name):
logger.debug('Testing with cache name: %s' % cache_name)
username = self.username()
self.create_user("CREATE ROLE %s WITH password = 'password' AND
LOGIN = true", username)
self.assertConnectsTo(username, self.dc1_node)
self.assertConnectsTo(username, self.dc2_node)
# connect to the dc2 node, then remove permission for it
session = self.exclusive_cql_connection(self.dc2_node,
user=username, password='password')
self.superuser.execute("ALTER ROLE %s WITH ACCESS TO DATACENTERS
{'dc1'}" % username)
self.clear_network_auth_cache(self.dc2_node, cache_name)
self.assertUnauthorized(lambda: session.execute("SELECT * FROM
ks.tbl"))
if self.dtest_config.cassandra_version_from_build >= '4.1':
test_revoked_access("NetworkPermissionsCache")
# deprecated cache name, scheduled for removal in 5.0
if self.dtest_config.cassandra_version_from_build < '5.0':
> test_revoked_access("NetworkAuthCache")
auth_test.py:3131:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
auth_test.py:3123: in test_revoked_access
self.clear_network_auth_cache(self.dc2_node, cache_name)
auth_test.py:3093: in clear_network_auth_cache
with JolokiaAgent(node) as jmx:
tools/jmxutils.py:309: in __enter__
self.start()
tools/jmxutils.py:187: in start
subprocess.check_output(args, stderr=subprocess.STDOUT)
/usr/lib/python3.8/subprocess.py:415: in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
input = None, capture_output = False, timeout = None, check = True
popenargs = (('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp',
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:lib/jolokia-jvm-1.6.2-agent.jar',
'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.2', ...),)
kwargs = {'stderr': -2, 'stdout': -1}
process =
stdout = b"Couldn't start agent for PID 1147\nPossible reason could be that
port '8778' is already occupied.\nPlease check the standard output of the
target process for a detailed error message.\n"
stderr = None, retcode = 1
def run(*popenargs,
input=None, capture_output=False, timeout=None, check=False,
**kwargs):
"""Run command with arguments and return a CompletedProcess instance.
The returned instance will have attributes args, returncode, stdout and
stderr. By default, stdout and stderr are not captured, and those
attributes
will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
them.
If check is True and the exit code was non-zero, it raises a
CalledProcessError. The CalledProcessError object will have the return
code
in the returncode attribute, and output & stderr attributes if those
streams
were captured.
If timeout is given, and the process takes too long, a TimeoutExpired
exception will be raised.
There is an optional argument "input", allowing you to
pass bytes or a string to the subprocess's stdin. If you use this
argument
you may not also use the Popen constructor's "stdin" argument, as
it will be used internally.
By default, all communication is in bytes, and therefore any "input"
should
be bytes, and the stdout and stderr will be bytes. If in text mode, any
"input" should be a string, and stdout and stderr will be strings
decoded
according to locale encoding, or by "encoding" if set. Text mode is
triggered by setting any of text, encoding, errors or
[jira] [Created] (CASSANDRA-17299) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD.test_parallel_upgrade_with
Josh McKenzie created CASSANDRA-17299:
-
Summary: Test Failure:
dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD.test_parallel_upgrade_with_internode_ssl
Key: CASSANDRA-17299
URL: https://issues.apache.org/jira/browse/CASSANDRA-17299
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-4.0/317/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD/test_parallel_upgrade_with_internode_ssl/
Failed 3 times in the last 30 runs. Flakiness: 17%, Stability: 90%
Error Message
Failed: Timeout >900.0s
Stacktrace
self =
def test_parallel_upgrade_with_internode_ssl(self):
"""
Test upgrading cluster all at once (requires cluster downtime),
with internode ssl.
"""
> self.upgrade_scenario(internode_ssl=True)
upgrade_tests/upgrade_through_versions_test.py:326:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
upgrade_tests/upgrade_through_versions_test.py:420: in upgrade_scenario
self.upgrade_to_version(version_meta, internode_ssl=internode_ssl)
upgrade_tests/upgrade_through_versions_test.py:481: in upgrade_to_version
node.drain()
../venv/lib/python3.8/site-packages/ccmlib/node.py:1540: in drain
self.nodetool("drain")
../venv/lib/python3.8/site-packages/ccmlib/node.py:1005: in nodetool
return handle_external_tool_process(p, ['nodetool', '-h', 'localhost',
'-p', str(self.jmx_port)] + shlex.split(cmd))
../venv/lib/python3.8/site-packages/ccmlib/node.py:2297: in
handle_external_tool_process
out, err = process.communicate()
/usr/lib/python3.8/subprocess.py:1028: in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
/usr/lib/python3.8/subprocess.py:1868: in _communicate
ready = selector.select(timeout)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = , timeout = None
def select(self, timeout=None):
# This is shared between poll() and epoll().
# epoll() has a different signature and handling of timeout parameter.
if timeout is None:
timeout = None
elif timeout <= 0:
timeout = 0
else:
# poll() has a resolution of 1 millisecond, round away from
# zero to wait *at least* timeout seconds.
timeout = math.ceil(timeout * 1e3)
ready = []
try:
> fd_event_list = self._selector.poll(timeout)
E Failed: Timeout >900.0s
/usr/lib/python3.8/selectors.py:415: Failed
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17299) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD.test_parallel_upgrade_with
[
https://issues.apache.org/jira/browse/CASSANDRA-17299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17299:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD.test_parallel_upgrade_with_internode_ssl
> ---
>
> Key: CASSANDRA-17299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17299
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/317/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD/test_parallel_upgrade_with_internode_ssl/
> Failed 3 times in the last 30 runs. Flakiness: 17%, Stability: 90%
> Error Message
> Failed: Timeout >900.0s
> Stacktrace
> self =
> object at 0x7fb2116ae970>
> def test_parallel_upgrade_with_internode_ssl(self):
> """
> Test upgrading cluster all at once (requires cluster downtime),
> with internode ssl.
> """
> > self.upgrade_scenario(internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:326:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:420: in upgrade_scenario
> self.upgrade_to_version(version_meta, internode_ssl=internode_ssl)
> upgrade_tests/upgrade_through_versions_test.py:481: in upgrade_to_version
> node.drain()
> ../venv/lib/python3.8/site-packages/ccmlib/node.py:1540: in drain
> self.nodetool("drain")
> ../venv/lib/python3.8/site-packages/ccmlib/node.py:1005: in nodetool
> return handle_external_tool_process(p, ['nodetool', '-h', 'localhost',
> '-p', str(self.jmx_port)] + shlex.split(cmd))
> ../venv/lib/python3.8/site-packages/ccmlib/node.py:2297: in
> handle_external_tool_process
> out, err = process.communicate()
> /usr/lib/python3.8/subprocess.py:1028: in communicate
> stdout, stderr = self._communicate(input, endtime, timeout)
> /usr/lib/python3.8/subprocess.py:1868: in _communicate
> ready = selector.select(timeout)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = , timeout = None
> def select(self, timeout=None):
> # This is shared between poll() and epoll().
> # epoll() has a different signature and handling of timeout parameter.
> if timeout is None:
> timeout = None
> elif timeout <= 0:
> timeout = 0
> else:
> # poll() has a resolution of 1 millisecond, round away from
> # zero to wait *at least* timeout seconds.
> timeout = math.ceil(timeout * 1e3)
> ready = []
> try:
> > fd_event_list = self._selector.poll(timeout)
> E Failed: Timeout >900.0s
> /usr/lib/python3.8/selectors.py:415: Failed
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17298) Test Failure: org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace
Josh McKenzie created CASSANDRA-17298:
-
Summary: Test Failure:
org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace
Key: CASSANDRA-17298
URL: https://issues.apache.org/jira/browse/CASSANDRA-17298
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Josh McKenzie
[https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/org.apache.cassandra.cql3/MemtableSizeTest/testTruncationReleasesLogSpace_2/]
Failed 4 times in the last 30 runs. Flakiness: 27%, Stability: 86%
Error Message
Expected heap usage close to 49.930MiB, got 41.542MiB.
{code}
Stacktrace
junit.framework.AssertionFailedError: Expected heap usage close to 49.930MiB,
got 41.542MiB.
at
org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:130)
at org.apache.cassandra.Util.runCatchingAssertionError(Util.java:644)
at org.apache.cassandra.Util.flakyTest(Util.java:669)
at
org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace(MemtableSizeTest.java:61)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17298) Test Failure: org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace
[
https://issues.apache.org/jira/browse/CASSANDRA-17298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17298:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace
> ---
>
> Key: CASSANDRA-17298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17298
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
>
> [https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/org.apache.cassandra.cql3/MemtableSizeTest/testTruncationReleasesLogSpace_2/]
> Failed 4 times in the last 30 runs. Flakiness: 27%, Stability: 86%
> Error Message
> Expected heap usage close to 49.930MiB, got 41.542MiB.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Expected heap usage close to 49.930MiB,
> got 41.542MiB.
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:130)
> at org.apache.cassandra.Util.runCatchingAssertionError(Util.java:644)
> at org.apache.cassandra.Util.flakyTest(Util.java:669)
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace(MemtableSizeTest.java:61)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17297) Test Failure: junit.framework.TestSuite.org.apache.cassandra.distributed.test.PreviewRepairCoordinatorFastTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17297:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> junit.framework.TestSuite.org.apache.cassandra.distributed.test.PreviewRepairCoordinatorFastTest
>
> ---
>
> Key: CASSANDRA-17297
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17297
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/321/testReport/junit.framework/TestSuite/org_apache_cassandra_distributed_test_PreviewRepairCoordinatorFastTest/
> Failed 1 times in the last 1 runs. Flakiness: 0%, Stability: 0%
> Error Message
> Uncaught exceptions were thrown during test
> {code}
> Stacktrace
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught
> exceptions were thrown during test
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:874)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:860)
> at
> org.apache.cassandra.distributed.test.RepairCoordinatorBase.teardownCluster(RepairCoordinatorBase.java:87)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Suppressed: java.lang.AssertionError: java.lang.InterruptedException
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:308)
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:287)
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.logExceptionsAfterExecute(DebuggableThreadPoolExecutor.java:252)
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.afterExecute(DebuggableThreadPoolExecutor.java:211)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1131)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.InterruptedException
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:509)
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:304)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17297) Test Failure: junit.framework.TestSuite.org.apache.cassandra.distributed.test.PreviewRepairCoordinatorFastTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17297:
--
Description:
https://ci-cassandra.apache.org/job/Cassandra-4.0/321/testReport/junit.framework/TestSuite/org_apache_cassandra_distributed_test_PreviewRepairCoordinatorFastTest/
Failed 1 times in the last 1 runs. Flakiness: 0%, Stability: 0%
Error Message
Uncaught exceptions were thrown during test
{code}
Stacktrace
org.apache.cassandra.distributed.shared.ShutdownException: Uncaught exceptions
were thrown during test
at
org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:874)
at
org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:860)
at
org.apache.cassandra.distributed.test.RepairCoordinatorBase.teardownCluster(RepairCoordinatorBase.java:87)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Suppressed: java.lang.AssertionError: java.lang.InterruptedException
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:308)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:287)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.logExceptionsAfterExecute(DebuggableThreadPoolExecutor.java:252)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.afterExecute(DebuggableThreadPoolExecutor.java:211)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1131)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.InterruptedException
at
com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:509)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:304)
{code}
was:
https://ci-cassandra.apache.org/job/Cassandra-4.0/321/testReport/junit.framework/TestSuite/org_apache_cassandra_distributed_test_PreviewRepairCoordinatorFastTest/
Failed 1 times in the last 1 runs. Flakiness: 0%, Stability: 0%
Error Message
Uncaught exceptions were thrown during test
Stacktrace
org.apache.cassandra.distributed.shared.ShutdownException: Uncaught exceptions
were thrown during test
at
org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:874)
at
org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:860)
at
org.apache.cassandra.distributed.test.RepairCoordinatorBase.teardownCluster(RepairCoordinatorBase.java:87)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Suppressed: java.lang.AssertionError: java.lang.InterruptedException
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:308)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:287)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.logExceptionsAfterExecute(DebuggableThreadPoolExecutor.java:252)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.afterExecute(DebuggableThreadPoolExecutor.java:211)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1131)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.InterruptedException
at
com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:509)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:304)
> Test
[jira] [Updated] (CASSANDRA-17296) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD.test_rolling_upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17296:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
> Test Failure:
> dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD.test_rolling_upgrade
> ---
>
> Key: CASSANDRA-17296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17296
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> 2 failures in 30, looks flaky on timing / subprocess termination.
> https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD/test_rolling_upgrade/
> Failed 2 times in the last 30 runs. Flakiness: 10%, Stability: 93%
> Error Message
> RuntimeError: A subprocess has terminated early. Subprocess statuses:
> Process-1 (is_alive: True), Process-2 (is_alive: False), attempting to
> terminate remaining subprocesses now.
> Stacktrace
> self =
> object at 0x7f22685cebb0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade(self):
> """
> Test rolling upgrade of the cluster, so we have mixed versions
> part way through.
> """
> > self.upgrade_scenario(rolling=True)
> upgrade_tests/upgrade_through_versions_test.py:320:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:398: in upgrade_scenario
> self._check_on_subprocs(self.fixture_dtest_setup.subprocs)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f22685cebb0>
> subprocs = [ exitcode=-SIGKILL daemon>, stopped exitcode=1 daemon>]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.
> upgrade_tests/upgrade_through_versions_test.py:456: RuntimeError
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17297) Test Failure: junit.framework.TestSuite.org.apache.cassandra.distributed.test.PreviewRepairCoordinatorFastTest
Josh McKenzie created CASSANDRA-17297: - Summary: Test Failure: junit.framework.TestSuite.org.apache.cassandra.distributed.test.PreviewRepairCoordinatorFastTest Key: CASSANDRA-17297 URL: https://issues.apache.org/jira/browse/CASSANDRA-17297 Project: Cassandra Issue Type: Bug Components: Test/unit Reporter: Josh McKenzie https://ci-cassandra.apache.org/job/Cassandra-4.0/321/testReport/junit.framework/TestSuite/org_apache_cassandra_distributed_test_PreviewRepairCoordinatorFastTest/ Failed 1 times in the last 1 runs. Flakiness: 0%, Stability: 0% Error Message Uncaught exceptions were thrown during test Stacktrace org.apache.cassandra.distributed.shared.ShutdownException: Uncaught exceptions were thrown during test at org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:874) at org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:860) at org.apache.cassandra.distributed.test.RepairCoordinatorBase.teardownCluster(RepairCoordinatorBase.java:87) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Suppressed: java.lang.AssertionError: java.lang.InterruptedException at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:308) at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:287) at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.logExceptionsAfterExecute(DebuggableThreadPoolExecutor.java:252) at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.afterExecute(DebuggableThreadPoolExecutor.java:211) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1131) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.InterruptedException at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:509) at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:304) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17296) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD.test_rolling_upgrade
Josh McKenzie created CASSANDRA-17296:
-
Summary: Test Failure:
dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD.test_rolling_upgrade
Key: CASSANDRA-17296
URL: https://issues.apache.org/jira/browse/CASSANDRA-17296
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Josh McKenzie
2 failures in 30, looks flaky on timing / subprocess termination.
https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD/test_rolling_upgrade/
Failed 2 times in the last 30 runs. Flakiness: 10%, Stability: 93%
Error Message
RuntimeError: A subprocess has terminated early. Subprocess statuses: Process-1
(is_alive: True), Process-2 (is_alive: False), attempting to terminate
remaining subprocesses now.
Stacktrace
self =
@pytest.mark.timeout(3000)
def test_rolling_upgrade(self):
"""
Test rolling upgrade of the cluster, so we have mixed versions part
way through.
"""
> self.upgrade_scenario(rolling=True)
upgrade_tests/upgrade_through_versions_test.py:320:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
upgrade_tests/upgrade_through_versions_test.py:398: in upgrade_scenario
self._check_on_subprocs(self.fixture_dtest_setup.subprocs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
subprocs = [, ]
def _check_on_subprocs(self, subprocs):
"""
Check on given subprocesses.
If any are not alive, we'll go ahead and terminate any remaining
alive subprocesses since this test is going to fail.
"""
subproc_statuses = [s.is_alive() for s in subprocs]
if not all(subproc_statuses):
message = "A subprocess has terminated early. Subprocess statuses: "
for s in subprocs:
message += "{name} (is_alive: {aliveness}),
".format(name=s.name, aliveness=s.is_alive())
message += "attempting to terminate remaining subprocesses now."
self._terminate_subprocs()
> raise RuntimeError(message)
E RuntimeError: A subprocess has terminated early. Subprocess
statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
to terminate remaining subprocesses now.
upgrade_tests/upgrade_through_versions_test.py:456: RuntimeError
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482638#comment-17482638
]
Benedict Elliott Smith commented on CASSANDRA-17188:
My original ask was only that this work produced its own internally consistent
changes, but I am disinclined to argue this matter further, and think we should
just move the discussion to CASSANDRA-17292 as you suggest.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17295) Make vtables accessible via internode messaging
[ https://issues.apache.org/jira/browse/CASSANDRA-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17295: -- Change Category: Operability Complexity: Normal Fix Version/s: 4.x Assignee: David Capwell Status: Open (was: Triage Needed) > Make vtables accessible via internode messaging > --- > > Key: CASSANDRA-17295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17295 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > As an extension of CASSANDRA-15399 and needed to solve CASSANDRA-15566, we > need the ability to perform queries against vtables using internode > messaging; currently this is limited to CQL which isn’t exposed in internode -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17295) Make vtables accessible via internode messaging
[ https://issues.apache.org/jira/browse/CASSANDRA-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482637#comment-17482637 ] David Capwell commented on CASSANDRA-17295: --- Slack thread: https://the-asf.slack.com/archives/CK23JSY2K/p1643151451099500 > Make vtables accessible via internode messaging > --- > > Key: CASSANDRA-17295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17295 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > As an extension of CASSANDRA-15399 and needed to solve CASSANDRA-15566, we > need the ability to perform queries against vtables using internode > messaging; currently this is limited to CQL which isn’t exposed in internode -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17295) Make vtables accessible via internode messaging
David Capwell created CASSANDRA-17295: - Summary: Make vtables accessible via internode messaging Key: CASSANDRA-17295 URL: https://issues.apache.org/jira/browse/CASSANDRA-17295 Project: Cassandra Issue Type: Improvement Components: Feature/Virtual Tables Reporter: David Capwell As an extension of CASSANDRA-15399 and needed to solve CASSANDRA-15566, we need the ability to perform queries against vtables using internode messaging; currently this is limited to CQL which isn’t exposed in internode -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482623#comment-17482623
]
Caleb Rackliffe edited comment on CASSANDRA-17188 at 1/26/22, 5:12 PM:
---
[~benedict] So what does this mean, in concrete terms? Is your ask essentially
that we come up with at least a _design_ for CASSANDRA-17292 (i.e. a design we
broadly agree on as a long term guide, but don't need to actually complete
until 5.0 at the earliest) and then make a reasonable effort to have guardrails
fit into that for 4.1 (where it will be released for the first time and not
create compatibility burdens)? If we can do that incrementally, I'm not opposed
to that strategy, assuming we actually want to move the config in that
direction in our lifetimes :)
[~adelapena] [~dcapwell] Thoughts?
(Again, I think CASSANDRA-17148 is where the rubber meets the road on this.)
was (Author: maedhroz):
[~benedict] So what does this mean, in concrete terms? Is your ask essentially
that we come up with at least a _design_ for CASSANDRA-17292 (i.e. a design we
broadly agree on as a long term guide, but don't need to actually complete
until 5.0 at the earliest) and then make a reasonable effort to have guardrails
fit into that for 4.1 (where it will be released for the first time and not
create compatibility burdens)? If we can do that incrementally, I'm not opposed
to that strategy, assuming we actually want to move the config in that
direction in our lifetimes :)
[~adelapena] [~dcapwell] Thoughts?
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482623#comment-17482623
]
Caleb Rackliffe commented on CASSANDRA-17188:
-
[~benedict] So what does this mean, in concrete terms? Is your ask essentially
that we come up with at least a _design_ for CASSANDRA-17292 (i.e. a design we
broadly agree on as a long term guide, but don't need to actually complete
until 5.0 at the earliest) and then make a reasonable effort to have guardrails
fit into that for 4.1 (where it will be released for the first time and not
create compatibility burdens)? If we can do that incrementally, I'm not opposed
to that strategy, assuming we actually want to move the config in that
direction in our lifetimes :)
[~adelapena] [~dcapwell] Thoughts?
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17242: - Fix Version/s: 4.1 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/1eb777946434a578f2aa673063ba992692c358d4 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks. > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/02: remove python 2 code which is now EOL and unsupported
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 1eb777946434a578f2aa673063ba992692c358d4
Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com>
AuthorDate: Thu Jan 20 06:19:45 2022 -0500
remove python 2 code which is now EOL and unsupported
Patch by Brad Schoening; reviewed by brandonwilliams and bereng for
CASSANDRA-17242
---
CHANGES.txt | 1 +
README.asc | 2 +-
bin/cqlsh| 8 +---
bin/cqlsh.py | 9 +
pylib/Dockerfile.ubuntu.py2 | 2 --
pylib/README.asc | 6 ++
pylib/cqlshlib/test/test_cqlsh_output.py | 17 -
7 files changed, 10 insertions(+), 35 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 71a91a3..03a97fa 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Remove python 2.x support from cqlsh (CASSANDRA-17242)
* Prewarm role and credential caches to avoid timeouts at startup
(CASSANDRA-16958)
* Make capacity/validity/updateinterval/activeupdate for Auth Caches
configurable via nodetool (CASSANDRA-17063)
* Added startup check for read_ahead_kb setting (CASSANDRA-16436)
diff --git a/README.asc b/README.asc
index f1270a8..27850cd 100644
--- a/README.asc
+++ b/README.asc
@@ -12,7 +12,7 @@ For more information, see http://cassandra.apache.org/[the
Apache Cassandra web
Requirements
. Java >= 1.8 (OpenJDK and Oracle JVMS have been tested)
-. Python 3.6+ (for cqlsh; 2.7 works but is deprecated)
+. Python 3.6+ (for cqlsh)
Getting started
---
diff --git a/bin/cqlsh b/bin/cqlsh
index a962e11..90c9b00 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -62,8 +62,8 @@ is_supported_version() {
version=$1
major_version="${version%.*}"
minor_version="${version#*.}"
-# python3.6+ is supported. python2.7 is deprecated but still compatible.
-if [ "$major_version" = 3 ] && [ "$minor_version" -ge 6 ] || [ "$version"
= "2.7" ]; then
+# python3.6+ is supported
+if [ "$major_version" = 3 ] && [ "$minor_version" -ge 6 ]; then
echo "supported"
else
echo "unsupported"
@@ -79,6 +79,8 @@ run_if_supported_version() {
if [ "$(is_supported_version "$version")" = "supported" ]; then
exec "$interpreter" "$($interpreter -c "import os;
print(os.path.dirname(os.path.realpath('$0')))")/cqlsh.py" "$@"
exit
+else
+echo "Warning: unsupported version of Python:" $version >&2
fi
fi
}
@@ -88,7 +90,7 @@ if [ "$USER_SPECIFIED_PYTHON" != "" ]; then
# run a user specified Python interpreter
run_if_supported_version "$USER_SPECIFIED_PYTHON" "$@"
else
-for interpreter in python3 python python2.7; do
+for interpreter in python3 python; do
run_if_supported_version "$interpreter" "$@"
done
fi
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 3c711a9..1a5f84a 100755
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -37,7 +37,7 @@ from glob import glob
from uuid import UUID
if sys.version_info < (3, 6) and sys.version_info[0:2] != (2, 7):
-sys.exit("\ncqlsh requires Python 3.6+ or Python 2.7 (deprecated)\n")
+sys.exit("\ncqlsh requires Python 3.6+\n")
# see CASSANDRA-10428
if platform.python_implementation().startswith('Jython'):
@@ -522,7 +522,6 @@ class Shell(cmd.Cmd):
if tty:
self.reset_prompt()
-self.maybe_warn_py2()
self.report_connection()
print('Use HELP for help.')
else:
@@ -609,12 +608,6 @@ class Shell(cmd.Cmd):
vers['cql'] = self.cql_version
print("[cqlsh %(shver)s | Cassandra %(build)s | CQL spec %(cql)s |
Native protocol v%(protocol)s]" % vers)
-def maybe_warn_py2(self):
-py2_suppress_warn = 'CQLSH_NO_WARN_PY2'
-if sys.version_info[0:2] == (2, 7) and not
os.environ.get(py2_suppress_warn):
-print("Python 2.7 support is deprecated. "
- "Install Python 3.6+ or set %s to suppress this message.\n"
% (py2_suppress_warn,))
-
def show_session(self, sessionid, partial_session=False):
print_trace_session(self, self.session, sessionid, partial_session)
diff --git a/pylib/Dockerfile.ubuntu.py2 b/pylib/Dockerfile.ubuntu.py2
deleted file mode 100644
index 93016f0..000
--- a/pylib/Dockerfile.ubuntu.py2
+++ /dev/null
@@ -1,2 +0,0 @@
-FROM ubuntu:bionic
-RUN apt-get update && apt-get install -y python-minimal
diff --git a/pylib/README.asc b/pylib/README.asc
index b0b6c7d..a192393 100644
--- a/pylib/README.asc
+++ b/pylib/README.asc
@@ -1,11 +1,9 @@
== Overview
This directory contains code primarily for cqlsh. cqlsh uses cqlshlib in this
directory.
-Currently, cqlshlib supports Python 2 as well as Python 3. Support
[cassandra] 02/02: remove py2 circle tests
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ab4919880793e43b361054754b65f750f9f56c2e Author: Brandon Williams AuthorDate: Mon Jan 24 12:14:46 2022 -0600 remove py2 circle tests Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17242 --- .circleci/config-2_1.yml | 102 .circleci/config-2_1.yml.mid_res.patch | 416 +++- .circleci/config.yml.HIGHRES | 424 - .circleci/config.yml.LOWRES| 424 - .circleci/config.yml.MIDRES| 424 - 5 files changed, 137 insertions(+), 1653 deletions(-) diff --git a/.circleci/config-2_1.yml b/.circleci/config-2_1.yml index b270a52..1692e95 100644 --- a/.circleci/config-2_1.yml +++ b/.circleci/config-2_1.yml @@ -284,10 +284,6 @@ j8_with_dtests_jobs: _with_dtests_jobs # Java 8 cqlsh dtests - start_j8_cqlsh_tests: type: approval -- j8_cqlsh-dtests-py2-with-vnodes: -requires: -- start_j8_cqlsh_tests -- j8_build - j8_cqlsh-dtests-py3-with-vnodes: requires: - start_j8_cqlsh_tests @@ -296,10 +292,6 @@ j8_with_dtests_jobs: _with_dtests_jobs requires: - start_j8_cqlsh_tests - j8_build -- j8_cqlsh-dtests-py2-no-vnodes: -requires: -- start_j8_cqlsh_tests -- j8_build - j8_cqlsh-dtests-py3-no-vnodes: requires: - start_j8_cqlsh_tests @@ -311,10 +303,6 @@ j8_with_dtests_jobs: _with_dtests_jobs # Java 11 cqlsh dtests - start_j11_cqlsh_tests: type: approval -- j11_cqlsh-dtests-py2-with-vnodes: -requires: -- start_j11_cqlsh_tests -- j8_build - j11_cqlsh-dtests-py3-with-vnodes: requires: - start_j11_cqlsh_tests @@ -323,10 +311,6 @@ j8_with_dtests_jobs: _with_dtests_jobs requires: - start_j11_cqlsh_tests - j8_build -- j11_cqlsh-dtests-py2-no-vnodes: -requires: - - start_j11_cqlsh_tests - - j8_build - j11_cqlsh-dtests-py3-no-vnodes: requires: - start_j11_cqlsh_tests @@ -464,18 +448,12 @@ j8_pre-commit_jobs: _pre-commit_jobs - j8_build - start_upgrade_tests # Java 8 cqlsh dtests -- j8_cqlsh-dtests-py2-with-vnodes: -requires: - - j8_build - j8_cqlsh-dtests-py3-with-vnodes: requires: - j8_build - j8_cqlsh-dtests-py38-with-vnodes: requires: - j8_build -- j8_cqlsh-dtests-py2-no-vnodes: -requires: - - j8_build - j8_cqlsh-dtests-py3-no-vnodes: requires: - j8_build @@ -483,18 +461,12 @@ j8_pre-commit_jobs: _pre-commit_jobs requires: - j8_build # Java 11 cqlsh dtests -- j11_cqlsh-dtests-py2-with-vnodes: -requires: - - j8_build - j11_cqlsh-dtests-py3-with-vnodes: requires: - j8_build - j11_cqlsh-dtests-py38-with-vnodes: requires: - j8_build -- j11_cqlsh-dtests-py2-no-vnodes: -requires: - - j8_build - j11_cqlsh-dtests-py3-no-vnodes: requires: - j8_build @@ -583,10 +555,6 @@ j11_with_dtests_jobs: _with_dtests_jobs - j11_build - start_j11_cqlsh_tests: type: approval -- j11_cqlsh-dtests-py2-with-vnodes: -requires: - - start_j11_cqlsh_tests - - j11_build - j11_cqlsh-dtests-py3-with-vnodes: requires: - start_j11_cqlsh_tests @@ -595,10 +563,6 @@ j11_with_dtests_jobs: _with_dtests_jobs requires: - start_j11_cqlsh_tests - j11_build -- j11_cqlsh-dtests-py2-no-vnodes: -requires: - - start_j11_cqlsh_tests - - j11_build - j11_cqlsh-dtests-py3-no-vnodes: requires: - start_j11_cqlsh_tests @@ -650,18 +614,12 @@ j11_pre-commit_jobs: _pre-commit_jobs - j11_dtests-no-vnodes: requires: - j11_build -- j11_cqlsh-dtests-py2-with-vnodes: -requires: - - j11_build - j11_cqlsh-dtests-py3-with-vnodes: requires: - j11_build - j11_cqlsh-dtests-py38-with-vnodes: requires: - j11_build -- j11_cqlsh-dtests-py2-no-vnodes: -requires: - - j11_build - j11_cqlsh-dtests-py3-no-vnodes: requires: - j11_build @@ -943,21 +901,6 @@ jobs: file_tag: j8_upgradetests_without_vnodes pytest_extra_args: '--execute-upgrade-tests-only --upgrade-target-version-only --upgrade-version-selection all' - j8_cqlsh-dtests-py2-with-vnodes: -<<: *j8_par_executor -steps: - - attach_workspace: - at:
[cassandra] branch trunk updated (d543dae -> ab491988)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d543dae Fix restarting a node when other nodes are down in dtests new 1eb7779 remove python 2 code which is now EOL and unsupported new ab491988 remove py2 circle tests The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config-2_1.yml | 102 .circleci/config-2_1.yml.mid_res.patch | 416 ++ .circleci/config.yml.HIGHRES | 424 --- .circleci/config.yml.LOWRES | 424 --- .circleci/config.yml.MIDRES | 424 --- CHANGES.txt | 1 + README.asc | 2 +- bin/cqlsh| 8 +- bin/cqlsh.py | 9 +- pylib/Dockerfile.ubuntu.py2 | 2 - pylib/README.asc | 6 +- pylib/cqlshlib/test/test_cqlsh_output.py | 17 -- 12 files changed, 147 insertions(+), 1688 deletions(-) delete mode 100644 pylib/Dockerfile.ubuntu.py2 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482612#comment-17482612
]
Benedict Elliott Smith edited comment on CASSANDRA-17188 at 1/26/22, 4:55 PM:
--
bq. That's why any potential rearrangement of the config should be easier to do
with guardrails than with the current scattered properties.
You seem to be missing my point. You have already created changes to the config
file, introducing a concept that relates to existing concepts in the config
file. By doing so you have created an inconsistency. You are suggesting this is
fine, because you think it is unimportant and somebody can fix it later. I am
saying it is not fine, and I want you to address it now. I am saying this
because that is, in my view, how software is properly developed: you address
problems as you introduce them.
was (Author: benedict):
bq. That's why any potential rearrangement of the config should be easier to do
with guardrails than with the current scattered properties.
You seem to be missing my point. You have already created changes to the config
file, introducing a concept that relates to existing concepts in the config
file. By doing so you have created an inconsistency. You are suggesting this is
fine, because you think it is unimportant and somebody can fix it later. I am
saying it is not fine, and I want you to address it now. I am saying this
because that is, in my view, how software is properly developed: you address
problems as you introduce them. Otherwise you are creating work for others.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482612#comment-17482612
]
Benedict Elliott Smith edited comment on CASSANDRA-17188 at 1/26/22, 4:47 PM:
--
bq. That's why any potential rearrangement of the config should be easier to do
with guardrails than with the current scattered properties.
You seem to be missing my point. You have already created changes to the config
file, introducing a concept that relates to existing concepts in the config
file. By doing so you have created an inconsistency. You are suggesting this is
fine, because you think it is unimportant and somebody can fix it later. I am
saying it is not fine, and I want you to address it now. I am saying this
because that is, in my view, how software is properly developed: you address
problems as you introduce them. Otherwise you are creating work for others.
was (Author: benedict):
bq. That's why any potential rearrangement of the config should be easier to do
with guardrails than with the current scattered properties.
You seem to be missing my point. You have already created changes to the config
file, introducing a concept that relates to existing concepts in the config
file. By doing so you have created an inconsistency. You are suggesting this is
fine, because you think it is unimportant and somebody can fix it later. I am
saying it is not fine, and I want you to address it now.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482612#comment-17482612
]
Benedict Elliott Smith commented on CASSANDRA-17188:
bq. That's why any potential rearrangement of the config should be easier to do
with guardrails than with the current scattered properties.
You seem to be missing my point. You have already created changes to the config
file, introducing a concept that relates to existing concepts in the config
file. By doing so you have created an inconsistency. You are suggesting this is
fine, because you think it is unimportant and somebody can fix it later. I am
saying it is not fine, and I want you to address it now.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482594#comment-17482594
]
Ekaterina Dimitrova commented on CASSANDRA-17182:
-
Thank you for the detailed response [~mck] !
I committed both
[dtest|https://github.com/apache/cassandra-dtest/commit/2138acc178f5fb08e641883c044eb5c54a89c1de]
and
[website|https://github.com/apache/cassandra-website/commit/ea04202b1da227d04acab55ab3bccee39e89a48d]
patches. I will check CI and verify staging, then do the rest of the steps
mentioned and close the ticket later today.
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482593#comment-17482593
]
Andres de la Peña commented on CASSANDRA-17188:
---
Multiple properties spread over the section for safety thresholds match this
criterion, although without the global enable/disable flag and without being
restricted to ordinary users. The migration tickets are for considering the
migration of those properties, which might make more sense as a guardrail
strictly associated to ordinary user queries.
The important part of guardrails is not how we arrange those properties on the
yaml, but having an internal framework reusing validation, behaviour, error
messages, etc. so we avoid code duplication and have a more consistent
behaviour. That should ease both adding new limits and consistently modifying
all of them at once. That's why any potential rearrangement of the config
should be easier to do with guardrails than with the current scattered
properties.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: Update instructions for testing with your own CCM branch patch by Ekaterina Dimitrova, reviewed by Berenguer Blasi and Josh McKenzie for CASSANDRA-17182
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git The following commit(s) were added to refs/heads/trunk by this push: new 2138acc Update instructions for testing with your own CCM branch patch by Ekaterina Dimitrova, reviewed by Berenguer Blasi and Josh McKenzie for CASSANDRA-17182 2138acc is described below commit 2138acc178f5fb08e641883c044eb5c54a89c1de Author: Ekaterina Dimitrova AuthorDate: Fri Jan 21 17:00:24 2022 -0500 Update instructions for testing with your own CCM branch patch by Ekaterina Dimitrova, reviewed by Berenguer Blasi and Josh McKenzie for CASSANDRA-17182 --- README.md| 2 ++ requirements.txt | 3 +++ 2 files changed, 5 insertions(+) diff --git a/README.md b/README.md index 072f05a..edaa746 100644 --- a/README.md +++ b/README.md @@ -90,6 +90,8 @@ test fails, the logs for the node are saved in a `logs/` directory for analysis (it's not perfect but has been good enough so far, I'm open to better suggestions). +In case you want to run tests using your own CCM branch, please, refer to the comments in requirements.txt for details how to do that. + Writing Tests - diff --git a/requirements.txt b/requirements.txt index 64a9cb5..d7c396a 100644 --- a/requirements.txt +++ b/requirements.txt @@ -6,6 +6,9 @@ # git tag -a -f cassandra-test # git push origin :refs/tags/cassandra-test # git push -f origin refs/tags/cassandra-test +# +# In case you want to test a patch with your own CCM branch, further to changing below CCM repo and branch name, you need to add -e flag at the beginning +# Example: -e git+https://github.com/userb/ccm.git@cassandra-17182#egg=ccm git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm decorator docopt - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: Update instructions for testing with your own CCM branch patch by Ekaterina Dimitrova, reviewed by Josh McKenzie and Berenguer Blasi for CASSANDRA-17182
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new ea04202 Update instructions for testing with your own CCM branch patch by Ekaterina Dimitrova, reviewed by Josh McKenzie and Berenguer Blasi for CASSANDRA-17182 ea04202 is described below commit ea04202b1da227d04acab55ab3bccee39e89a48d Author: Ekaterina Dimitrova AuthorDate: Fri Jan 21 17:46:41 2022 -0500 Update instructions for testing with your own CCM branch patch by Ekaterina Dimitrova, reviewed by Josh McKenzie and Berenguer Blasi for CASSANDRA-17182 --- site-content/source/modules/ROOT/pages/development/testing.adoc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/site-content/source/modules/ROOT/pages/development/testing.adoc b/site-content/source/modules/ROOT/pages/development/testing.adoc index 6e04d53..3eb5537 100644 --- a/site-content/source/modules/ROOT/pages/development/testing.adoc +++ b/site-content/source/modules/ROOT/pages/development/testing.adoc @@ -36,6 +36,9 @@ test Cassandra via https://github.com/riptano/ccm[CCM] verifying operation results, logs, and cluster state. Python Distributed tests are Cassandra version agnostic. They include upgrade tests. +In case you want to run DTests with your own version of CCM, please refer to requirements.txt in +https://github.com/apache/cassandra-dtest[apache/cassandra-dtest] how to do it. + The recipes for running those tests can be found in the cassandra-builds repository https://github.com/apache/cassandra-builds/tree/trunk/build-scripts[here]. Running full test suites locally takes hours, if not days. Beyond running specific tests you know are applicable, or are failing, to the work at hand, it is recommended to rely upon the project's https://cassandra.apache.org/_/development/ci.html[Continuous Integration systems]. If you are not a committer, and don't have access to a premium CircleCI plan, ask one of the committers to test your patch on the project's https://ci-cassandra.apache.org/[ci-cassandra.apache.org]. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17294) Fix generate-eclipse-files
[
https://issues.apache.org/jira/browse/CASSANDRA-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482555#comment-17482555
]
Ekaterina Dimitrova commented on CASSANDRA-17294:
-
[~blerer] , was it using Eclipse? Do you think you can take a moment to check
this one, please?
> Fix generate-eclipse-files
> --
>
> Key: CASSANDRA-17294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17294
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Yash Ladha
>Assignee: Yash Ladha
>Priority: Normal
>
> I was doing the local setup of cassandra and using the
> [https://github.com/eclipse/eclipse.jdt.ls] for development. When i visited
> the `CassandraDaemon.java` greeted with an error that the file is not in
> classpath, which was very weird. Upon investigation found out that the
> `classpath` was not closed and due to which that error is occuring.
> This issue is to solve the generation of correct .{_}classpath{_} file and
> inclusion of correct libs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17294) Fix generate-eclipse-files
[
https://issues.apache.org/jira/browse/CASSANDRA-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17294:
Test and Documentation Plan:
[https://github.com/apache/cassandra/pull/1426]
Looking for someone with eclipse to verify it
Status: Patch Available (was: In Progress)
> Fix generate-eclipse-files
> --
>
> Key: CASSANDRA-17294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17294
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Yash Ladha
>Assignee: Yash Ladha
>Priority: Normal
>
> I was doing the local setup of cassandra and using the
> [https://github.com/eclipse/eclipse.jdt.ls] for development. When i visited
> the `CassandraDaemon.java` greeted with an error that the file is not in
> classpath, which was very weird. Upon investigation found out that the
> `classpath` was not closed and due to which that error is occuring.
> This issue is to solve the generation of correct .{_}classpath{_} file and
> inclusion of correct libs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17294) Fix generate-eclipse-files
[
https://issues.apache.org/jira/browse/CASSANDRA-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17294:
Status: Needs Committer (was: Patch Available)
> Fix generate-eclipse-files
> --
>
> Key: CASSANDRA-17294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17294
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Yash Ladha
>Assignee: Yash Ladha
>Priority: Normal
>
> I was doing the local setup of cassandra and using the
> [https://github.com/eclipse/eclipse.jdt.ls] for development. When i visited
> the `CassandraDaemon.java` greeted with an error that the file is not in
> classpath, which was very weird. Upon investigation found out that the
> `classpath` was not closed and due to which that error is occuring.
> This issue is to solve the generation of correct .{_}classpath{_} file and
> inclusion of correct libs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482543#comment-17482543
]
Benedict Elliott Smith commented on CASSANDRA-17188:
bq. What currently identifies a limit as a guardrail is that it's an optional
safety limit that is triggered exclusively by queries of ordinary users.
Do you accept that such properties exist that already meet this criterion?
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482533#comment-17482533
]
Andres de la Peña commented on CASSANDRA-17188:
---
{quote}
I am not proposing anything as draconian as reverting existing guardrails work,
only that you consider this now before committing further work on the epic.
This does not absolutely require engaging with other discussions about how to
refactor the rest of the yaml, or pausing work until that completes, although
that might overall be less burdensome for the project.
{quote}
What currently identifies a limit as a guardrail is that it's an optional
safety limit that is triggered exclusively by queries of ordinary users. They
can be globally and/or individually disabled, and they don't affect superusers
nor internal queries. In the future we might move in different directions and
use them for asynchronous background processes such as compaction, or perhaps
adapt them to be used on every limit defined in a future configuration, but we
are not there yet.
I understand that we should discuss whether current config properties should be
migrated to guardrails or not, and we can do that in the tickets for migrating
existing properties. However, this particular guardrail doesn't migrate any
existing property, nor seems inconsistent with what is currently in the yaml.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482511#comment-17482511 ] Benedict Elliott Smith commented on CASSANDRA-17164: So, if we _Commit_ a record with a different ballot to one we have previously _Promised_ with the same timestamp, we won't be guaranteed to update the _Promised_ register on disk (it should happen 50% of the time). Which may or may not be a problem. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482510#comment-17482510
]
Benedict Elliott Smith edited comment on CASSANDRA-17164 at 1/26/22, 2:20 PM:
--
I think this would be fine, I need to think through why I did not do this
originally, as I did consider it. It may simply have been to minimise the
change in semantics to {{system.paxos}}, without there having been any
particularly good reason. Perhaps also for debugging purposes, it helps to be
able to see whether something had been promised before it was
accepted/committed.
was (Author: benedict):
I think this would be fine, I need to think through why I did not do this
originally, as I did consider it. It may simply have been to minimise the
change in semantics to {{system.paxos}}, without there having been any
particularly good reason. Perhaps also for debugging purposes, it helps to be
able to see whether something had been promised before it was
accepted/committed.
I think there is perhaps also some additional complexity when a replica has
promised a ballot with a timestamp, and then proceeds to accept a different one
with the same timestamp. I don't think we would resolve these reliably, so we
might not actually overwrite it anyway, and I don't think there is a trivial
solution to this problem in the storage layer. I'm not certain if this would
actually cause problems, but it would require some careful consideration to
rule it out.
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482510#comment-17482510
]
Benedict Elliott Smith edited comment on CASSANDRA-17164 at 1/26/22, 2:19 PM:
--
I think this would be fine, I need to think through why I did not do this
originally, as I did consider it. It may simply have been to minimise the
change in semantics to {{system.paxos}}, without there having been any
particularly good reason. Perhaps also for debugging purposes, it helps to be
able to see whether something had been promised before it was
accepted/committed.
I think there is perhaps also some additional complexity when a replica has
promised a ballot with a timestamp, and then proceeds to accept a different one
with the same timestamp. I don't think we would resolve these reliably, so we
might not actually overwrite it anyway, and I don't think there is a trivial
solution to this problem in the storage layer. I'm not certain if this would
actually cause problems, but it would require some careful consideration to
rule it out.
was (Author: benedict):
I think this would be fine, I need to think through why I did not do this
originally, as I did consider it. It may simply have been to minimise the
change in semantics to {{system.paxos}}, without there having been any
particularly good reason. Perhaps also for debugging purposes, it helps to be
able to see whether something had been promised before it was
accepted/committed.
I think there is perhaps also some additional complexity when a replica has
promised a ballot with the same timestamp, and then proceed to accept it. I
don't think we would resolve these reliably, so we might not actually overwrite
it anyway, and I don't think there is a trivial solution to this problem in the
storage layer. I'm not certain if this would actually cause problems, but it
would require some careful consideration to rule it out.
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482510#comment-17482510
]
Benedict Elliott Smith edited comment on CASSANDRA-17164 at 1/26/22, 2:18 PM:
--
I think this would be fine, I need to think through why I did not do this
originally, as I did consider it. It may simply have been to minimise the
change in semantics to {{system.paxos}}, without there having been any
particularly good reason. Perhaps also for debugging purposes, it helps to be
able to see whether something had been promised before it was
accepted/committed.
I think there is perhaps also some additional complexity when a replica has
promised a ballot with the same timestamp, and then proceed to accept it. I
don't think we would resolve these reliably, so we might not actually overwrite
it anyway, and I don't think there is a trivial solution to this problem in the
storage layer. I'm not certain if this would actually cause problems, but it
would require some careful consideration to rule it out.
was (Author: benedict):
I think this would be fine, I need to think through why I did not do this
originally, as I did consider it. It may simply have been to minimise the
change in semantics to {{system.paxos}}, without there having been any
particularly good reason. Perhaps also for debugging purposes, it helps to be
able to see whether something had been promised before it was
accepted/committed.
I think there is perhaps also some additional complexity when a replica has
promised a ballot with the same timestamp, and then proceed to accept it. I
don't think we would resolve these reliably, so we might not actually overwrite
it anyway, and I don't think there is a trivial solution to this problem in the
storage layer.
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482510#comment-17482510
]
Benedict Elliott Smith commented on CASSANDRA-17164:
I think this would be fine, I need to think through why I did not do this
originally, as I did consider it. It may simply have been to minimise the
change in semantics to {{system.paxos}}, without there having been any
particularly good reason. Perhaps also for debugging purposes, it helps to be
able to see whether something had been promised before it was
accepted/committed.
I think there is perhaps also some additional complexity when a replica has
promised a ballot with the same timestamp, and then proceed to accept it. I
don't think we would resolve these reliably, so we might not actually overwrite
it anyway, and I don't think there is a trivial solution to this problem in the
storage layer.
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482504#comment-17482504
]
Branimir Lambov commented on CASSANDRA-17164:
-
What do you think of applying the following simplifications:
- The {{promised}} ballot number to be updated whenever a proposal or commit
with higher ballot number is received by a replica.
Every time we use the promised number we compute it as the max of the three
values – why not just store that instead?
- Storing and sending only the higher-ballot value of the "committed" and
"accepted" registers, with a flag that identifies if the value has been
committed or only accepted.
The decisions that a proposer makes are taken based on the maximum ballot
number among "committed" and "accepted", and we only proceed using the newer of
the two (except in the case of newer empty accepted proposal, where we may
decide to distribute a commit which can already be shown to have been committed
to a quorum of replicas).
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17048) Replace sequential sstable generation identifier with UUID v1
[ https://issues.apache.org/jira/browse/CASSANDRA-17048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482487#comment-17482487 ] Jacek Lewandowski edited comment on CASSANDRA-17048 at 1/26/22, 1:41 PM: - ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/1276]|[j11 (!)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/173/workflows/e90fa232-9af4-4088-b12b-d3f7d71934e1/jobs/877] was (Author: jlewandowski): ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/1276]|[j11|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/173/workflows/e90fa232-9af4-4088-b12b-d3f7d71934e1/jobs/877 (!)] > Replace sequential sstable generation identifier with UUID v1 > - > > Key: CASSANDRA-17048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17048 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1 > > Time Spent: 7.5h > Remaining Estimate: 0h > > Replace the current sequential sstable generation identifier with ULID based. > ULID is better because we do not need to scan the existing files to pick the > starting number as well as we can generate globally unique identifiers. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17048) Replace sequential sstable generation identifier with UUID v1
[ https://issues.apache.org/jira/browse/CASSANDRA-17048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482487#comment-17482487 ] Jacek Lewandowski commented on CASSANDRA-17048: --- ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/1276]|[j11|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/173/workflows/e90fa232-9af4-4088-b12b-d3f7d71934e1/jobs/877 (!)] > Replace sequential sstable generation identifier with UUID v1 > - > > Key: CASSANDRA-17048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17048 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1 > > Time Spent: 7.5h > Remaining Estimate: 0h > > Replace the current sequential sstable generation identifier with ULID based. > ULID is better because we do not need to scan the existing files to pick the > starting number as well as we can generate globally unique identifiers. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17265) dtest byteman errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17265: - Fix Version/s: NA (was: 4.0.x) Since Version: NA Source Control Link: https://github.com/apache/cassandra-dtest/commit/a0872a76650b6c850bf429fd2a123ed9cfd59858 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed! Thanks. > dtest byteman errors > > > Key: CASSANDRA-17265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17265 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: NA > > > Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on > missing btm files. I checked and the files _are there_. Also it doesn't repro > locally. See 4.0 vanilla runs > [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] 01/02: Use function to generate explicit byteman path
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
commit 963dbba6f44ea3ca9f40279b82dd43a2095c25ab
Author: Brandon Williams
AuthorDate: Tue Jan 25 14:37:38 2022 -0600
Use function to generate explicit byteman path
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17265
---
batch_test.py | 2 +-
bootstrap_test.py | 10 ++---
counter_test.py| 12 +++---
cql_test.py| 4 +-
dtest.py | 5 +++
materialized_views_test.py | 20 +-
read_repair_test.py| 78 +++---
rebuild_test.py| 6 +--
repair_tests/repair_test.py| 4 +-
replace_address_test.py| 6 +--
replica_side_filtering_test.py | 4 +-
secondary_indexes_test.py | 10 ++---
sstable_generation_loading_test.py | 4 +-
topology_test.py | 6 +--
transient_replication_test.py | 22 +--
15 files changed, 99 insertions(+), 94 deletions(-)
diff --git a/batch_test.py b/batch_test.py
index 2dad0d3..2d928d8 100644
--- a/batch_test.py
+++ b/batch_test.py
@@ -377,7 +377,7 @@ class TestBatch(Tester):
protocol_version=protocol_version,
install_byteman=True)
coordinator = self.cluster.nodelist()[coordinator_idx]
-coordinator.byteman_submit(['./byteman/fail_after_batchlog_write.btm'])
+
coordinator.byteman_submit([mk_bman_path('fail_after_batchlog_write.btm')])
logger.debug("Injected byteman scripts to enable batchlog replay
{}".format(coordinator.name))
query = """
diff --git a/bootstrap_test.py b/bootstrap_test.py
index 9678f56..06190e9 100644
--- a/bootstrap_test.py
+++ b/bootstrap_test.py
@@ -17,7 +17,7 @@ import pytest
from distutils.version import LooseVersion
-from dtest import Tester, create_ks, create_cf, data_size
+from dtest import Tester, create_ks, create_cf, data_size, mk_bman_path
from tools.assertions import (assert_almost_equal, assert_bootstrap_state,
assert_not_running,
assert_one, assert_stderr_clean)
from tools.data import query_c1c2
@@ -30,8 +30,8 @@ logger = logging.getLogger(__name__)
class BootstrapTester(Tester):
-byteman_submit_path_pre_4_0 = './byteman/pre4.0/stream_failure.btm'
-byteman_submit_path_4_0 = './byteman/4.0/stream_failure.btm'
+byteman_submit_path_pre_4_0 = mk_bman_path('pre4.0/stream_failure.btm')
+byteman_submit_path_4_0 = mk_bman_path('4.0/stream_failure.btm')
@pytest.fixture(autouse=True)
def fixture_add_additional_log_patterns(self, fixture_dtest_setup):
@@ -189,7 +189,7 @@ class BootstrapTester(Tester):
logger.debug("Submitting byteman script to {} to".format(node1.name))
# Sleep longer than streaming_socket_timeout_in_ms to make sure the
node will not be killed
-node1.byteman_submit(['./byteman/stream_5s_sleep.btm'])
+node1.byteman_submit([mk_bman_path('stream_5s_sleep.btm')])
# Bootstraping a new node with very small
streaming_socket_timeout_in_ms
node2 = new_node(cluster)
@@ -286,7 +286,7 @@ class BootstrapTester(Tester):
logger.debug("Bootstrap node 2 with delay")
node2 = new_node(cluster, byteman_port='4200')
-
node2.update_startup_byteman_script('./byteman/bootstrap_5s_sleep.btm')
+
node2.update_startup_byteman_script(mk_bman_path('bootstrap_5s_sleep.btm'))
node2.start(wait_for_binary_proto=True)
assert_bootstrap_state(self, node2, 'COMPLETED')
diff --git a/counter_test.py b/counter_test.py
index 6b7587a..b596874 100644
--- a/counter_test.py
+++ b/counter_test.py
@@ -8,7 +8,7 @@ from cassandra import ConsistencyLevel
from cassandra.query import SimpleStatement
from tools.assertions import assert_invalid, assert_length_equal, assert_one
-from dtest import Tester, create_ks, create_cf
+from dtest import Tester, create_ks, create_cf, mk_bman_path
from tools.data import rows_to_list
since = pytest.mark.since
@@ -97,11 +97,11 @@ class TestCounters(Tester):
# Have node 1 and 3 cheat a bit during the leader election for a
counter mutation; note that cheating
# takes place iff there is an actual chance for node 2 to be picked.
if cluster.version() < '4.0':
-
nodes[0].update_startup_byteman_script('./byteman/pre4.0/election_counter_leader_favor_node2.btm')
-
nodes[2].update_startup_byteman_script('./byteman/pre4.0/election_counter_leader_favor_node2.btm')
+
nodes[0].update_startup_byteman_script(mk_bman_path('pre4.0/election_counter_leader_favor_node2.btm'))
+
[cassandra-dtest] branch trunk updated (d62b03d -> a0872a7)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git. from d62b03d Pin dtest-timeout to 1.4.2 new 963dbba Use function to generate explicit byteman path new a0872a7 Use explicit path for the jolokia jar The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: batch_test.py | 2 +- bootstrap_test.py | 10 ++--- counter_test.py| 12 +++--- cql_test.py| 4 +- dtest.py | 5 +++ materialized_views_test.py | 20 +- read_repair_test.py| 78 +++--- rebuild_test.py| 6 +-- repair_tests/repair_test.py| 4 +- replace_address_test.py| 6 +-- replica_side_filtering_test.py | 4 +- secondary_indexes_test.py | 10 ++--- sstable_generation_loading_test.py | 4 +- tools/jmxutils.py | 2 +- topology_test.py | 6 +-- transient_replication_test.py | 22 +-- 16 files changed, 100 insertions(+), 95 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] 02/02: Use explicit path for the jolokia jar
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
commit a0872a76650b6c850bf429fd2a123ed9cfd59858
Author: Brandon Williams
AuthorDate: Tue Jan 25 16:38:20 2022 -0600
Use explicit path for the jolokia jar
Patch by brandonwilliams; reviwewed by bereng for CASSANDRA-17265
---
tools/jmxutils.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/jmxutils.py b/tools/jmxutils.py
index 165fa0d..05957f1 100644
--- a/tools/jmxutils.py
+++ b/tools/jmxutils.py
@@ -9,7 +9,7 @@ import ccmlib.common as common
logger = logging.getLogger(__name__)
-JOLOKIA_JAR = os.path.join('lib', 'jolokia-jvm-1.6.2-agent.jar')
+JOLOKIA_JAR = os.path.join(os.path.dirname(__file__), '..', 'lib',
'jolokia-jvm-1.6.2-agent.jar')
CLASSPATH_SEP = ';' if common.is_win() else ':'
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17265) dtest byteman errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482456#comment-17482456 ] Berenguer Blasi commented on CASSANDRA-17265: - Aha you manually retriggered them ok icwym. > dtest byteman errors > > > Key: CASSANDRA-17265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17265 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on > missing btm files. I checked and the files _are there_. Also it doesn't repro > locally. See 4.0 vanilla runs > [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17294) Fix generate-eclipse-files
[
https://issues.apache.org/jira/browse/CASSANDRA-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17294:
-
Change Category: Operability
Complexity: Low Hanging Fruit
Status: Open (was: Triage Needed)
> Fix generate-eclipse-files
> --
>
> Key: CASSANDRA-17294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17294
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Yash Ladha
>Assignee: Yash Ladha
>Priority: Normal
>
> I was doing the local setup of cassandra and using the
> [https://github.com/eclipse/eclipse.jdt.ls] for development. When i visited
> the `CassandraDaemon.java` greeted with an error that the file is not in
> classpath, which was very weird. Upon investigation found out that the
> `classpath` was not closed and due to which that error is occuring.
> This issue is to solve the generation of correct .{_}classpath{_} file and
> inclusion of correct libs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17293) Update python test framework from nose to nose2
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17293: - Change Category: Operability Complexity: Low Hanging Fruit Component/s: CQL/Interpreter Fix Version/s: 4.x Status: Open (was: Triage Needed) > Update python test framework from nose to nose2 > --- > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at https://nose.readthedocs.io/en/latest/ > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to nose2 is likely the least effort. __ -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17214) Cannot restart a node when there are other nodes being down in in-jvm dtest framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17214:
---
Fix Version/s: 4.1
(was: 4.x)
Since Version: 2.2.17
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[d543dae2cd0d6540d95eb3252d79e75393fd993d|https://github.com/apache/cassandra/commit/d543dae2cd0d6540d95eb3252d79e75393fd993d].
> Cannot restart a node when there are other nodes being down in in-jvm dtest
> framework
> -
>
> Key: CASSANDRA-17214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17214
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1
>
>
> Such scenario:
> {code:java}
> @Test
> public void test() throws Exception
> {
> try (Cluster cluster =
> init(Cluster.build(2).withDataDirCount(1)).start()))
> {
> FBUtilities.waitOnFuture(cluster.get(2).shutdown());
> FBUtilities.waitOnFuture(cluster.get(1).shutdown());
> cluster.get(1).startup();
> cluster.get(2).startup();
> }
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalStateException: Can't use shut down instances, delegate is
> null
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:210)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.getMessagingVersion(DelegatingInvokableInstance.java:90)
> at
> org.apache.cassandra.distributed.action.GossipHelper.unsafeStatusToNormal(GossipHelper.java:95)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$10(Instance.java:640)
> {noformat}
> when we do not use {{Gossiper}} feature flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17214) Cannot restart a node when there are other nodes being down in in-jvm dtest framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17214:
---
Source Control Link:
https://github.com/apache/cassandra-in-jvm-dtest-api/commit/2aea316f85e68b4e4739b61260faf5ed91552d5f
https://github.com/apache/cassandra/commit/d543dae2cd0d6540d95eb3252d79e75393fd993d
(was:
https://github.com/apache/cassandra-in-jvm-dtest-api/commit/2aea316f85e68b4e4739b61260faf5ed91552d5f)
> Cannot restart a node when there are other nodes being down in in-jvm dtest
> framework
> -
>
> Key: CASSANDRA-17214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17214
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.x
>
>
> Such scenario:
> {code:java}
> @Test
> public void test() throws Exception
> {
> try (Cluster cluster =
> init(Cluster.build(2).withDataDirCount(1)).start()))
> {
> FBUtilities.waitOnFuture(cluster.get(2).shutdown());
> FBUtilities.waitOnFuture(cluster.get(1).shutdown());
> cluster.get(1).startup();
> cluster.get(2).startup();
> }
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalStateException: Can't use shut down instances, delegate is
> null
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:210)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.getMessagingVersion(DelegatingInvokableInstance.java:90)
> at
> org.apache.cassandra.distributed.action.GossipHelper.unsafeStatusToNormal(GossipHelper.java:95)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$10(Instance.java:640)
> {noformat}
> when we do not use {{Gossiper}} feature flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17265) dtest byteman errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482441#comment-17482441 ] Brandon Williams edited comment on CASSANDRA-17265 at 1/26/22, 12:47 PM: - bq. But I don't understand how you managed to get 2 runs in circle against the same SHA where one passes and the other one has 40+ failures. The cassandra SHA is the same because that is simply the circle commit to use my dtest repo, where the real action was happening... somewhat poorly, as the 40+ failure runs were stupid mistakes I made, but circle was my test env. If you look closely the runs with lot of failures were cancelled as I noticed that and then manually retriggered when fixed. was (Author: brandon.williams): bq. But I don't understand how you managed to get 2 runs in circle against the same SHA where one passes and the other one has 40+ failures. The cassandra SHA is same because that is simply the circle commit to use my dtest repo, where the real action was happening... somewhat poorly, as the 40+ failure runs were stupid mistakes I made, but circle was my test env. If you look closely the runs with lot of failures were cancelled as I noticed that and then manually retriggered when fixed. > dtest byteman errors > > > Key: CASSANDRA-17265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17265 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on > missing btm files. I checked and the files _are there_. Also it doesn't repro > locally. See 4.0 vanilla runs > [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix restarting a node when other nodes are down in dtests
This is an automated email from the ASF dual-hosted git repository.
mck 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 d543dae Fix restarting a node when other nodes are down in dtests
d543dae is described below
commit d543dae2cd0d6540d95eb3252d79e75393fd993d
Author: Jacek Lewandowski
AuthorDate: Thu Dec 16 08:45:05 2021 +0100
Fix restarting a node when other nodes are down in dtests
patch by Jacek Lewandowski; reviewed by Michael Semb Wever for
CASSANDRA-17214
---
build.xml | 2 +-
.../distributed/impl/AbstractCluster.java | 6
.../cassandra/distributed/impl/Instance.java | 8 +++--
.../cassandra/distributed/test/RestartTest.java| 39 ++
4 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/build.xml b/build.xml
index 69c96cf..67a758c 100644
--- a/build.xml
+++ b/build.xml
@@ -538,7 +538,7 @@
-
+
diff --git
a/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
b/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
index fc70ce1..753f874 100644
---
a/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
+++
b/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
@@ -282,6 +282,12 @@ public abstract class AbstractCluster
implements ICluster
((IInstance) instance).isValid());
if (config.has(BLANK_GOSSIP))
-cluster.stream().forEach(peer ->
GossipHelper.statusToBlank((IInvokableInstance) peer).accept(this));
+peers.forEach(peer ->
GossipHelper.statusToBlank((IInvokableInstance) peer).accept(this));
else if (cluster instanceof Cluster)
-cluster.stream().forEach(peer ->
GossipHelper.statusToNormal((IInvokableInstance) peer).accept(this));
+peers.forEach(peer ->
GossipHelper.statusToNormal((IInvokableInstance) peer).accept(this));
else
-cluster.stream().forEach(peer ->
GossipHelper.unsafeStatusToNormal(this, (IInstance) peer));
+peers.forEach(peer ->
GossipHelper.unsafeStatusToNormal(this, (IInstance) peer));
StorageService.instance.setUpDistributedSystemKeyspaces();
StorageService.instance.setNormalModeUnsafe();
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/RestartTest.java
b/test/distributed/org/apache/cassandra/distributed/test/RestartTest.java
new file mode 100644
index 000..4d3049b
--- /dev/null
+++ b/test/distributed/org/apache/cassandra/distributed/test/RestartTest.java
@@ -0,0 +1,39 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.distributed.test;
+
+import org.junit.Test;
+
+import org.apache.cassandra.distributed.Cluster;
+import org.apache.cassandra.utils.FBUtilities;
+
+public class RestartTest extends TestBaseImpl
+{
+@Test
+public void test() throws Exception
+{
+try (Cluster cluster =
init(Cluster.build(2).withDataDirCount(1).start()))
+{
+FBUtilities.waitOnFuture(cluster.get(2).shutdown());
+FBUtilities.waitOnFuture(cluster.get(1).shutdown());
+cluster.get(1).startup();
+cluster.get(2).startup();
+}
+}
+}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
