[jira] [Updated] (CASSANDRA-16399) Selecting resource intensive tests is not consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-16399:
--
Source Control Link: https://github.com/apache/cassandra-dtest/pull/115
> Selecting resource intensive tests is not consistent
>
>
> Key: CASSANDRA-16399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16399
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like there are two problems:
> - collection of tests to run fails when there are log messages in stderr
> - collection of resource intensive tests (with
> {code:java}
> --only-resource-intensive-tests{code}
> ) is broken
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16399) Selecting resource intensive tests is not consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-16399:
--
Test and Documentation Plan: Manual testing
Status: Patch Available (was: In Progress)
> Selecting resource intensive tests is not consistent
>
>
> Key: CASSANDRA-16399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16399
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like there are two problems:
> - collection of tests to run fails when there are log messages in stderr
> - collection of resource intensive tests (with
> {code:java}
> --only-resource-intensive-tests{code}
> ) is broken
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16399) Selecting resource intensive tests is not consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-16399:
--
Reviewers: Michael Semb Wever, Tomasz Lasica (was: Michael Semb Wever)
> Selecting resource intensive tests is not consistent
>
>
> Key: CASSANDRA-16399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16399
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like there are two problems:
> - collection of tests to run fails when there are log messages in stderr
> - collection of resource intensive tests (with
> {code:java}
> --only-resource-intensive-tests{code}
> ) is broken
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16399) Selecting resource intensive tests is not consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-16399:
--
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Low Hanging Fruit
Discovered By: Adhoc Test
Reviewers: Michael Semb Wever
Severity: Low
Status: Open (was: Triage Needed)
> Selecting resource intensive tests is not consistent
>
>
> Key: CASSANDRA-16399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16399
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> It looks like there are two problems:
> - collection of tests to run fails when there are log messages in stderr
> - collection of resource intensive tests (with
> {code:java}
> --only-resource-intensive-tests{code}
> ) is broken
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16399) Selecting resource intensive tests is not consistent
Jacek Lewandowski created CASSANDRA-16399:
-
Summary: Selecting resource intensive tests is not consistent
Key: CASSANDRA-16399
URL: https://issues.apache.org/jira/browse/CASSANDRA-16399
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Jacek Lewandowski
Assignee: Jacek Lewandowski
It looks like there are two problems:
- collection of tests to run fails when there are log messages in stderr
- collection of resource intensive tests (with
{code:java}
--only-resource-intensive-tests{code}
) is broken
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16339) LCS steady state load of table with vs. w/o GC performance test
[
https://issues.apache.org/jira/browse/CASSANDRA-16339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269790#comment-17269790
]
Yifan Cai commented on CASSANDRA-16339:
---
I ran several experiments that avoid running the garbage skipping step when
there are over N shadow source candidates for the compaction task. With a small
threshold value, flame graph shows the cpu time % of GarbageSkipper is lowered.
(Below graph is obtained with threshold == 10)
!flamegraph_garbageskipper_with_threshold.png|width=684,height=350!
The full report can be found at
[https://github.com/yifan-c/CASSANDRA-15581-COMPACTION-TEST/blob/main/CASSANDRA-16339/7019-Test:%20Perf%20Comparison%20%5BLCS%20-%20provide_overlapping_tombstones%20%2B%20experiments%5D.pdf]
The smaller the threshold, the read latency gets more stable. However, they are
not as stable as in the steady state. In steady state, we can consider the
threshold is 0.
We can observe some latency reduction in different time spans. Now I think they
are coming from the slower compaction. According to the charts of the report,
when the compaction throughput is low, the read latency goes low too. The
garbage skipping step is CPU heavy. When the step is active, it greatly lower
the I/O ops from the compaction. So in the meantime, the system can serve read
queries faster.
The gain we are expecting from the step is to reduce the file size and the disk
usage. However, in all the runs, there is no noticeable difference after
enabling for the workload (read : write : delete = 5 : 4 : 1).
Since the reward is too little comparing to the price paid. I think it is
probably better to advice not using this feature, unless there is a suitable
use case that have the a lot of deletes and few reads.
> LCS steady state load of table with vs. w/o GC performance test
> ---
>
> Key: CASSANDRA-16339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16339
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/benchmark
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Attachments: flamegraph_garbageskipper_with_threshold.png,
> flamegraph_grabageskipper.png
>
>
> The testing cluster should be pre-populated with ~200GB data in each node.
> The baseline cluster has the table created with
> {{provide_overlapping_tombstones}} disabled. The other cluster has the table
> with {{provide_overlapping_tombstones == row}}. Compare the read, write and
> compaction performance between those 2 clusters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16339) LCS steady state load of table with vs. w/o GC performance test
[
https://issues.apache.org/jira/browse/CASSANDRA-16339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-16339:
--
Attachment: flamegraph_garbageskipper_with_threshold.png
> LCS steady state load of table with vs. w/o GC performance test
> ---
>
> Key: CASSANDRA-16339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16339
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/benchmark
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Attachments: flamegraph_garbageskipper_with_threshold.png,
> flamegraph_grabageskipper.png
>
>
> The testing cluster should be pre-populated with ~200GB data in each node.
> The baseline cluster has the table created with
> {{provide_overlapping_tombstones}} disabled. The other cluster has the table
> with {{provide_overlapping_tombstones == row}}. Compare the read, write and
> compaction performance between those 2 clusters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16343) STCS steady state load of 4.0 vs 3.x performance test.
[ https://issues.apache.org/jira/browse/CASSANDRA-16343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-16343: -- Test and Documentation Plan: Perf. Test Plan # Run data prepopulation for both 3.0 and 4.0 clusters. 200GB per node. # Run steady state load for X seconds and compare the compaction performance. The workload used in the test was generated from tlp-stress. Steady state load, Write : Delete == 4 : 1, and the QPS was kept at 1500/s. Status: Patch Available (was: Open) Result report link: [https://github.com/yifan-c/CASSANDRA-15581-COMPACTION-TEST/blob/main/CASSANDRA-16342-16343/Compaction%20Perf%20Comparison%20Between%203.0%20and%204.0%20(STCS%20and%20LCS).pdf] The compaction performance comparison mainly focuses on the compaction related metrics, e.g. compaction throughput, pending tasks, etc. Query latency is *not* compared, since is can be affected by many other components that changed between 3.0 and 4.0. Under the same load, both 3.0 and 4.0 clusters show a similar compaction performance for STCS. The compaction in 4.0 runs slightly more actively. Details can be found in the report linked above. > STCS steady state load of 4.0 vs 3.x performance test. > --- > > Key: CASSANDRA-16343 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16343 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > The testing cluster should be pre-populated with ~200GB data in each node. > Run the steady state workload to compare the read, write and compaction > performance between baseline (3.x cluster) and 4.0 cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16343) STCS steady state load of 4.0 vs 3.x performance test.
[ https://issues.apache.org/jira/browse/CASSANDRA-16343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-16343: -- Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > STCS steady state load of 4.0 vs 3.x performance test. > --- > > Key: CASSANDRA-16343 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16343 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > The testing cluster should be pre-populated with ~200GB data in each node. > Run the steady state workload to compare the read, write and compaction > performance between baseline (3.x cluster) and 4.0 cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16342) LCS steady state load of 4.0 vs. 3.x performance test
[ https://issues.apache.org/jira/browse/CASSANDRA-16342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-16342: -- Test and Documentation Plan: Perf. Test Plan # Run data prepopulation for both 3.0 and 4.0 clusters. 200GB per node. # Run steady state load for X seconds and compare the compaction performance. The workload used in the test was generated from tlp-stress. Steady state load, Write : Delete == 4 : 1, and the QPS was kept at 1500/s. Status: Patch Available (was: Open) Result report link: [https://github.com/yifan-c/CASSANDRA-15581-COMPACTION-TEST/blob/main/CASSANDRA-16342-16343/Compaction%20Perf%20Comparison%20Between%203.0%20and%204.0%20(STCS%20and%20LCS).pdf] The compaction performance comparison mainly focuses on the compaction related metrics, e.g. compaction throughput, pending tasks, the number of unleveled sstables (LCS only), etc. Query latency is *not* compared, since is can be affected by many other components that changed between 3.0 and 4.0. Under the same load, the LCS compaction in 4.0 has better performance. The compaction throughput is higher and the 4.0 cluster keeps up with the load. However, the compaction in 3.0 cluster is lagging behind as the number of the unleveled sstables increases during the test. Details can be found in the report linked above. > LCS steady state load of 4.0 vs. 3.x performance test > - > > Key: CASSANDRA-16342 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16342 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > The testing cluster should be pre-populated with ~200GB data in each node. > Run the steady state workload to compare the read, write and compaction > performance between baseline (3.x cluster) and 4.0 cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16342) LCS steady state load of 4.0 vs. 3.x performance test
[ https://issues.apache.org/jira/browse/CASSANDRA-16342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-16342: -- Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > LCS steady state load of 4.0 vs. 3.x performance test > - > > Key: CASSANDRA-16342 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16342 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > The testing cluster should be pre-populated with ~200GB data in each node. > Run the steady state workload to compare the read, write and compaction > performance between baseline (3.x cluster) and 4.0 cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16286) Make TokenMetadata's ring version increments atomic
[
https://issues.apache.org/jira/browse/CASSANDRA-16286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269765#comment-17269765
]
Caleb Rackliffe commented on CASSANDRA-16286:
-
[~cscotta] I know this has been a potential problem for years (and certainly
before 4.0), but I'd like to try to throw a patch together first to see if it's
as simple as I think it is. If I don't get around to it by the end of the
month, I won't argue against pushing it to an early 4.0.x release.
> Make TokenMetadata's ring version increments atomic
> ---
>
> Key: CASSANDRA-16286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16286
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> The update semantics of the ring version in {{TokenMetadata}} are not clear.
> The instance variable itself is {{volatile}}, but it is still incremented by
> a non-atomic check-and-set, and not all codepaths do that while holding the
> {{TokenMetadata}} write lock. We could make this more intelligible by forcing
> the external callers to use both the write when invalidating the ring and
> read lock when reading the current ring version. Most of the readers of the
> ring version (ex. compaction) don't need it to be fast, but it shouldn't be a
> problem even if they do. If we do this, we should be able to avoid a
> situation where concurrent invalidations don't produce two distinct version
> increments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15892) JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269760#comment-17269760 ] Gianluca Righetto commented on CASSANDRA-15892: --- I believe it was added here https://github.com/apache/cassandra-dtest/commit/49b2dda4e6643d2b18376d504b5fea4c0b3354a7 > JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild > > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-rc > > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15892) JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269759#comment-17269759 ] Ekaterina Dimitrova commented on CASSANDRA-15892: - [~gianluca] thank you for the quick response and looking into it! That is an important point, I didn't know it was already marked @flaky. Then I can check tomorrow who and why added this and whether this means we can leave it for now. It's good to know the history. Thanks again > JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild > > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-rc > > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16083) Missing JMX objects and attributes upgrading from 3.0 to 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269754#comment-17269754
]
Ekaterina Dimitrova edited comment on CASSANDRA-16083 at 1/22/21, 1:45 AM:
---
Back to this one.
It is still planned for 4.0 beta right? (Checking as there were other metrics
related tickets moved for later)
So I just looked a bit in the code, we need this time alias for the scope name
which was changed for the below metrics, not directly the MetricName name as in
CASSANDRA-15909.
I can probably do this tomorrow.
?? *"org.apache.cassandra.metrics:type=DroppedMessage.*" *---> as part of
CASSANDRA-15066 verbs have been changed. Many are now seen split to Verb_RSP
and Verb_REQ, for example MUTATION_RSP and MUTATION_RSQ.??
??
*"org.apache.cassandra.metrics:type=ClientRequest,scope=CASRead,name=ConditionNotMet"*
---> conditionNotMet has been moved to CASClientWriteRequestMetrics as part of
CASSANDRA-12649.??
was (Author: e.dimitrova):
Back to this one.
It is still planned for 4.0 beta right? (Checking as there were other metrics
related tickets moved for later)
So I just looked a bit in the code, we need this time alias for the scope name
which was changed for the below metrics, not the MetricName name as in
CASSANDRA-15909.
I can probably do this tomorrow.
?? *"org.apache.cassandra.metrics:type=DroppedMessage.*" *---> as part of
CASSANDRA-15066 verbs have been changed. Many are now seen split to Verb_RSP
and Verb_REQ, for example MUTATION_RSP and MUTATION_RSQ.??
??
*"org.apache.cassandra.metrics:type=ClientRequest,scope=CASRead,name=ConditionNotMet"*
---> conditionNotMet has been moved to CASClientWriteRequestMetrics as part of
CASSANDRA-12649.??
> Missing JMX objects and attributes upgrading from 3.0 to 4.0
>
>
> Key: CASSANDRA-16083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16083
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Using the tools added in CASSANDRA-16082, below are the list of metrics
> missing in 4.0 but present in 3.0. The work here is to make sure we had
> proper deprecation for each metric, and if not to add it back.
> {code}
> $ tools/bin/jmxtool diff -f yaml cassandra-3.0-jmx.yaml trunk-jmx.yaml
> --ignore-missing-on-left
> Objects not in right:
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=EstimatedPartitionSizeHistogram
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=BloomFilterFalseRatio
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ReplicaFilteringProtectionRequests
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=RowCacheHitOutOfRange
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=CounterMutationStage,name=MaxPoolSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=ColUpdateTimeDeltaHistogram
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=TombstoneScannedHistogram
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=ReadStage,name=ActiveTasks
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=WaitingOnFreeMemtableSpace
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasCommitTotalLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_aggregates,name=CasProposeLatency
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=AllMemtablesLiveDataSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=ViewReadTime
> org.apache.cassandra.db:type=HintedHandoffManager
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=BloomFilterDiskSpaceUsed
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=RequestResponseStage,name=PendingTasks
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=MemtableSwitchCount
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=range_xfers,name=ReplicaFi
[jira] [Commented] (CASSANDRA-15892) JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269756#comment-17269756 ] Gianluca Righetto commented on CASSANDRA-15892: --- [~e.dimitrova] I did some initial investigation to narrow the problem down, but I got sidetracked with some QA work on k8s and couldn't come up with a patch for this yet. But I just started looking into it again. So, I just rebased with latest trunk and I can still reproduce it locally. I think it just doesn't fail more often on CI because the test has a @flaky annotation, so it gives another chance for the test to pass. The behavior I'm seeing is that one of the nodes keeps waiting for a message that never arrives and it will simply sit idle for as long as I let it (I think in CI it times out and reruns). > JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild > > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-rc > > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16083) Missing JMX objects and attributes upgrading from 3.0 to 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269754#comment-17269754
]
Ekaterina Dimitrova commented on CASSANDRA-16083:
-
Back to this one.
It is still planned for 4.0 beta right? (Checking as there were other metrics
related tickets moved for later)
So I just looked a bit in the code, we need this time alias for the scope name
which was changed for the below metrics, not the MetricName name as in
CASSANDRA-15909.
I can probably do this tomorrow.
?? *"org.apache.cassandra.metrics:type=DroppedMessage.*" *---> as part of
CASSANDRA-15066 verbs have been changed. Many are now seen split to Verb_RSP
and Verb_REQ, for example MUTATION_RSP and MUTATION_RSQ.??
??
*"org.apache.cassandra.metrics:type=ClientRequest,scope=CASRead,name=ConditionNotMet"*
---> conditionNotMet has been moved to CASClientWriteRequestMetrics as part of
CASSANDRA-12649.??
> Missing JMX objects and attributes upgrading from 3.0 to 4.0
>
>
> Key: CASSANDRA-16083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16083
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Using the tools added in CASSANDRA-16082, below are the list of metrics
> missing in 4.0 but present in 3.0. The work here is to make sure we had
> proper deprecation for each metric, and if not to add it back.
> {code}
> $ tools/bin/jmxtool diff -f yaml cassandra-3.0-jmx.yaml trunk-jmx.yaml
> --ignore-missing-on-left
> Objects not in right:
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=EstimatedPartitionSizeHistogram
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=BloomFilterFalseRatio
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ReplicaFilteringProtectionRequests
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=RowCacheHitOutOfRange
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=CounterMutationStage,name=MaxPoolSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=ColUpdateTimeDeltaHistogram
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=TombstoneScannedHistogram
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=ReadStage,name=ActiveTasks
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=WaitingOnFreeMemtableSpace
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasCommitTotalLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_aggregates,name=CasProposeLatency
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=AllMemtablesLiveDataSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=ViewReadTime
> org.apache.cassandra.db:type=HintedHandoffManager
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=BloomFilterDiskSpaceUsed
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=RequestResponseStage,name=PendingTasks
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=MemtableSwitchCount
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=range_xfers,name=ReplicaFilteringProtectionRowsCachedPerQuery
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=SnapshotsSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=RecentBloomFilterFalsePositives
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ColUpdateTimeDeltaHistogram
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=range_xfers,name=SpeculativeRetries
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=LiveDiskSpaceUsed
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ViewReadTime
> org.apache.cassandra.metrics:type=ThreadPools,path=internal,scope=MigrationStage,name=CompletedTasks
> org.apache.cassandra.metrics:type=
[jira] [Commented] (CASSANDRA-15537) 4.0 quality testing: Local Read/Write Path: Upgrade and Diff Test
[ https://issues.apache.org/jira/browse/CASSANDRA-15537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269749#comment-17269749 ] Yifan Cai commented on CASSANDRA-15537: --- Found CASSANDRA-16398 during diff testing. Linking them. > 4.0 quality testing: Local Read/Write Path: Upgrade and Diff Test > - > > Key: CASSANDRA-15537 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15537 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python >Reporter: Josh McKenzie >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0-rc > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > Execution of upgrade and diff tests via cassandra-diff have proven to be one > of the most effective approaches toward identifying issues with the local > read/write path. These include instances of data loss, data corruption, data > resurrection, incorrect responses to queries, incomplete responses, and > others. Upgrade and diff tests can be executed concurrent with fault > injection (such as host or network failure); as well as during mixed-version > scenarios (such as upgrading half of the instances in a cluster, and running > upgradesstables on only half of the upgraded instances). > Upgrade and diff tests are expected to continue through the release cycle, > and are a great way for contributors to gain confidence in the correctness of > the database under their own workloads. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16398) CQL fails to parse "access" and "datacenters" in DDL statements
Yifan Cai created CASSANDRA-16398: - Summary: CQL fails to parse "access" and "datacenters" in DDL statements Key: CASSANDRA-16398 URL: https://issues.apache.org/jira/browse/CASSANDRA-16398 Project: Cassandra Issue Type: Bug Components: CQL/Interpreter, CQL/Syntax Reporter: Yifan Cai The terms, "ACCESS TO ALL DATACENTERS" (for role control,) are introduced in CASSANDRA-13985. They are not marked as unreserved keywords. So in the non-role related DDL statements, for example, create table statement, the parser fails. cqlsh> CREATE TABLE test.test_access ( foo text PRIMARY KEY, access text, bar text); SyntaxException: line 1:54 mismatched input 'access' expecting ')' (... foo text PRIMARY KEY, [access]...) cqlsh> CREATE TABLE test.test_datacenters ( foo text PRIMARY KEY, datacenters text, bar text); SyntaxException: line 1:59 mismatched input 'datacenters' expecting ')' (... foo text PRIMARY KEY, [datacenters]...) Since ACCESS and DATACENTERS are only applicable to the role defining statements. We should mark them as unreserved keywords in order to allow to use them in the DDL statement. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16286) Make TokenMetadata's ring version increments atomic
[
https://issues.apache.org/jira/browse/CASSANDRA-16286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269718#comment-17269718
]
C. Scott Andreas commented on CASSANDRA-16286:
--
[~maedhroz] Would it be reasonable to target this for 4.0.x?
> Make TokenMetadata's ring version increments atomic
> ---
>
> Key: CASSANDRA-16286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16286
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> The update semantics of the ring version in {{TokenMetadata}} are not clear.
> The instance variable itself is {{volatile}}, but it is still incremented by
> a non-atomic check-and-set, and not all codepaths do that while holding the
> {{TokenMetadata}} write lock. We could make this more intelligible by forcing
> the external callers to use both the write when invalidating the ring and
> read lock when reading the current ring version. Most of the readers of the
> ring version (ex. compaction) don't need it to be fast, but it shouldn't be a
> problem even if they do. If we do this, we should be able to avoid a
> situation where concurrent invalidations don't produce two distinct version
> increments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15181) Ensure Nodes can Start and Stop
[ https://issues.apache.org/jira/browse/CASSANDRA-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269717#comment-17269717 ] C. Scott Andreas commented on CASSANDRA-15181: -- [~b.le...@gmail.com] Thanks for untagging this for beta. This ticket may be a candidate for deferral as well. While we don't have exhaustive metrics for the items listed in the description, I'm not aware of regression in these areas and regularly exercise the host replacement path on trunk. > Ensure Nodes can Start and Stop > --- > > Key: CASSANDRA-15181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15181 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Streaming and Messaging, Test/benchmark >Reporter: Joey Lynch >Assignee: Vinay Chella >Priority: High > Fix For: 4.0-rc > > > Let's load a cluster up with data and start killing nodes. We can do hard > failures (node terminations) and soft failures (process kills) We plan to > observe the following: > * Can nodes successfully bootstrap? > * How long does it take to bootstrap > * What are the effects of TLS on and off (e.g. on stream time) > * Are hints properly played after a node restart > * Do nodes properly shutdown and start back up. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16364) Simultaneous bootstrap can cause token collision
[
https://issues.apache.org/jira/browse/CASSANDRA-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269711#comment-17269711
]
C. Scott Andreas commented on CASSANDRA-16364:
--
Hi [~paulo], do you know if this is a regression from 3.0.x/3.11.x? If not,
would it be worth considering targeting 4.0.x?
Apologies for asking if work's active on it - just doing a spot-check of open
issues tagged for beta.
> Simultaneous bootstrap can cause token collision
>
>
> Key: CASSANDRA-16364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16364
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
> Fix For: 4.0-beta
>
>
> While raising a 6-node ccm cluster to test 4.0-beta4, 2 nodes chosen the same
> tokens using the default {{allocate_tokens_for_local_rf}}. However they both
> succeeded bootstrap with colliding tokens.
> We were familiar with this issue from CASSANDRA-13701 and CASSANDRA-16079,
> and the workaround to fix this is to avoid parallel bootstrap when using
> {{allocate_tokens_for_local_rf}}.
> However, since this is the default behavior, we should try to detect and
> prevent this situation when possible, since it can break users relying on
> parallel bootstrap behavior.
> I think we could prevent this as following:
> 1. announce intent to bootstrap via gossip (ie. add node on gossip without
> token information)
> 2. wait for gossip to settle for a longer period (ie. ring delay)
> 3. allocate tokens (if multiple bootstrap attempts are detected, tie break
> via node-id)
> 4. broadcast tokens and move on with bootstrap
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15472) Read failure due to exception from metrics-core dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-15472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269706#comment-17269706
]
C. Scott Andreas commented on CASSANDRA-15472:
--
(Alternately as the issue isn't a regression, it may also be reasonable to
designate the ticket as not being a release blocker by updating the fix version
to 4.0.x).
> Read failure due to exception from metrics-core dependency
> --
>
> Key: CASSANDRA-15472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15472
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> Stacktrace
> {code:java}
> Uncaught exception on thread Thread[SharedPool-Worker-27,5,main]: {}
> java.util.NoSuchElementException: null
> at
> java.util.concurrent.ConcurrentSkipListMap.firstKey(ConcurrentSkipListMap.java:2053)
> ~[na:1.8.0_222]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:102)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:81)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.update(Histogram.java:110)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:198)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:76)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:108)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:114)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1897)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_222]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
> {code}
> This [issue|https://github.com/dropwizard/metrics/issues/1278] has been
> [fixed|https://github.com/dropwizard/metrics/pull/1436] in
> [v4.0.6|https://github.com/dropwizard/metrics/releases/tag/v4.0.6].
> This is observed on a 2.1.19 cluster, but this would impact pretty much any
> version of C* since we depend on lower versions of metrics-core that do not
> have the fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15892) JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269698#comment-17269698 ] Ekaterina Dimitrova commented on CASSANDRA-15892: - [~gianluca], I was wondering whether you are still working on this one? Also, I haven't actually seen this one failing lately in CircleCI? [~Bereng], have you seen it by chance? Maybe [~gianluca] will surprise us in a nice way by saying he can't reproduce it on the latest trunk? :) > JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild > > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-rc > > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16358) Minor Flakiness in ProxyHandlerConnectionsTest#testExpireSomeFromBatch
[
https://issues.apache.org/jira/browse/CASSANDRA-16358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269689#comment-17269689
]
Ekaterina Dimitrova commented on CASSANDRA-16358:
-
Unfortunately, I saw it again in the latest build:
https://jenkins-cm4.apache.org/job/Cassandra-trunk/244/testReport/junit/org.apache.cassandra.net/ProxyHandlerConnectionsTest/testExpireSomeFromBatch/
> Minor Flakiness in ProxyHandlerConnectionsTest#testExpireSomeFromBatch
> --
>
> Key: CASSANDRA-16358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16358
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Caleb Rackliffe
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta5, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This seems only to be failing in ci-cassandra, but it fails across cdc,
> compression, and normal configurations there. The only failure recent enough
> to be retained is here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/268/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/testExpireSomeFromBatch_compression_2/
> {noformat}
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testExpireSomeFromBatch-compression
> (from org.apache.cassandra.net.ProxyHandlerConnectionsTest-compression)
> Error Message
> Expired: 8, Arrived: 10
> Stacktrace
> junit.framework.AssertionFailedError: Expired: 8, Arrived: 10
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:285)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$testExpireSomeFromBatch$23(ProxyHandlerConnectionsTest.java:210)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:378)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:337)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testExpireSomeFromBatch(ProxyHandlerConnectionsTest.java:169)
> 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] 2020-12-15 20:36:43,018 InternalLoggerFactory.java:45 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2020-12-15 20:36:43,043 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] 2020-12-15 20:36:43,044 PlatformDependent0.java:897 - Java
> version: 8
> DEBUG [main] 2020-12-15 20:36:43,044 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] 2020-12-15 20:36:43,045 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> ...[truncated 394654 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:501)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440)
> ... 29 common frames omitted
> {noformat}
> There are a number of historical failures listed here, but the runs that
> produced them have not been retained:
> https://ci-cassandra.apache.org/job/Cassandra-trunk/207/testReport/junit/org.apache.cassandra.net/ProxyHandlerConnectionsTest/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16244) Create a jvm upgrade dtest for mixed versions repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-16244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16244: -- Test and Documentation Plan: The patch is a test. Status: Patch Available (was: In Progress) > Create a jvm upgrade dtest for mixed versions repairs > - > > Key: CASSANDRA-16244 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16244 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alexander Dejanovski >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > Repair during upgrades should fail on mixed version clusters. > We'd need an in-jvm upgrade dtest to check that repair indeed fails as > expected with mixed current version+previous major version clusters. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16244) Create a jvm upgrade dtest for mixed versions repairs
[
https://issues.apache.org/jira/browse/CASSANDRA-16244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269606#comment-17269606
]
Andres de la Peña commented on CASSANDRA-16244:
---
It seems that CASSANDRA-13944 added a descriptive error for this case. The JVM
upgrade test in the PR shows how this works when the repair attempt is done for
the node in 4.0 in a mixed cluster. However, if the repair is done in the not
upgraded node of the same mixed cluster, then it seems that there isn't any
specific error management and the used {{nodetool repair}} command doesn't end.
> Create a jvm upgrade dtest for mixed versions repairs
> -
>
> Key: CASSANDRA-16244
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16244
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
>Reporter: Alexander Dejanovski
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Repair during upgrades should fail on mixed version clusters.
> We'd need an in-jvm upgrade dtest to check that repair indeed fails as
> expected with mixed current version+previous major version clusters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15698) DOC - Review Download page
[ https://issues.apache.org/jira/browse/CASSANDRA-15698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland reassigned CASSANDRA-15698: - Assignee: Lorina Poland (was: Erick Ramirez) > DOC - Review Download page > -- > > Key: CASSANDRA-15698 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15698 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Lorina Poland >Priority: Low > > h2. Background > With updates to the [Installing > Cassandra|http://cassandra.apache.org/doc/latest/getting_started/installing.html] > page in CASSANDRA-15466, there's an opportunity to review and tidy up the > [Downloading Cassandra|http://cassandra.apache.org/download/] page. > h2. Scope > Retire sections of the document relating to C* installation and direct users > to the Installation page instead so we don't have to main installation > instructions in multiple places. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15903) Doc update: stream-entire-sstable supports all compaction strategies and internode encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-15903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland reassigned CASSANDRA-15903: - Assignee: Lorina Poland > Doc update: stream-entire-sstable supports all compaction strategies and > internode encryption > - > > Key: CASSANDRA-15903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15903 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Zhao Yang >Assignee: Lorina Poland >Priority: Normal > Fix For: 4.0.x > > > As [~mck] point out, doc needs to be updated for CASSANDRA-15657 and > CASSANDRA-15740. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15093) update hardware recommendations
[ https://issues.apache.org/jira/browse/CASSANDRA-15093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland reassigned CASSANDRA-15093: - Assignee: Lorina Poland > update hardware recommendations > --- > > Key: CASSANDRA-15093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15093 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jon Haddad >Assignee: Lorina Poland >Priority: Normal > > The recommendations on > http://cassandra.apache.org/doc/latest/operating/hardware.html are pretty out > of date. We should improve the following: > * GC recommendations. We (The Last Pickle) routinely use 16GB heaps with > 8-10GB of new gen, Survivor ratio of 4-6 and max tenuring threshold of 6. It > works far better than G1GC > * The instance sizes in AWS are pretty outdated. M1s are years out of date. > i3's work well with NVMe disks, EBS works OK if you want easy backups and > replacements. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15609) Update patches doc to remove references to sending patches attached to JIRA
[ https://issues.apache.org/jira/browse/CASSANDRA-15609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland reassigned CASSANDRA-15609: - Assignee: Lorina Poland > Update patches doc to remove references to sending patches attached to JIRA > --- > > Key: CASSANDRA-15609 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15609 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: David Capwell >Assignee: Lorina Poland >Priority: Normal > > When a new person joins and goes through our docs they see the process is to > create patches and attach to JIRA; this is not the process most people follow. > We should update the document to encourage newer norms to make it easier for > new developers to contribute. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15801) Tiny documentation fix in Architecture/Overview
[ https://issues.apache.org/jira/browse/CASSANDRA-15801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269593#comment-17269593 ] Lorina Poland commented on CASSANDRA-15801: --- I've incorporated the information in this ticket with other edits to this page. It will be included in the C* 4.0 GA release. > Tiny documentation fix in Architecture/Overview > --- > > Key: CASSANDRA-15801 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15801 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Philip White >Assignee: Lorina Poland >Priority: Normal > Attachments: > 0001-CASSANDRA-15801-Fix-typo-in-Architecture-Overview-do.patch > > > I noticed a small issue in the documentation, so I'd like to fix it. > This issue also exists to guide me to the proper way to make contributions to > Cassandra, hopefully larger ones in the future, so please forgive the > trivialness of this fix. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15904) nodetool getendpoints man page improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-15904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269585#comment-17269585 ] Lorina Poland commented on CASSANDRA-15904: --- The docs that are currently generated for nodetool come from the --help for nodetool. If there is missing information, the source code for the inline help needs to be changed. This ticket is actually a source code ticket, [~flightc] > nodetool getendpoints man page improvements > --- > > Key: CASSANDRA-15904 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15904 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Arvinder Singh >Assignee: Erick Ramirez >Priority: Normal > Fix For: 4.x > > > Please include support for compound primary key. Ex: > nodetool getendpoints keyspace1 table1 pk1:pk2:pk2 > Thanks. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15831) Please update Apache Cassandra Repo link in install docs
[ https://issues.apache.org/jira/browse/CASSANDRA-15831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269582#comment-17269582 ] Lorina Poland commented on CASSANDRA-15831: --- Looks like both URLs work and locate the same file. Not sure why the command in the current documents didn't work for the reporter. I think this ticket can be closed. > Please update Apache Cassandra Repo link in install docs > > > Key: CASSANDRA-15831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15831 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: I N V A L I D >Assignee: Lorina Poland >Priority: Normal > > In the very first section of Install Docs > Add the Apache Cassandra repository keys to the list of trusted keys on the > server: > > $ curl https://www.apache.org/dist/cassandra/KEYS | sudo apt-key - [Not > working] > > Please change the address. I found this working: > > curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15472) Read failure due to exception from metrics-core dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-15472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269516#comment-17269516
]
Adam Holmberg commented on CASSANDRA-15472:
---
[~sumanth.pasupuleti] I noticed this has been stalled for some time. Do you
have plans to return to it? Care to have someone help out?
> Read failure due to exception from metrics-core dependency
> --
>
> Key: CASSANDRA-15472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15472
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> Stacktrace
> {code:java}
> Uncaught exception on thread Thread[SharedPool-Worker-27,5,main]: {}
> java.util.NoSuchElementException: null
> at
> java.util.concurrent.ConcurrentSkipListMap.firstKey(ConcurrentSkipListMap.java:2053)
> ~[na:1.8.0_222]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:102)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:81)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.update(Histogram.java:110)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:198)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:76)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:108)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:114)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1897)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_222]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
> {code}
> This [issue|https://github.com/dropwizard/metrics/issues/1278] has been
> [fixed|https://github.com/dropwizard/metrics/pull/1436] in
> [v4.0.6|https://github.com/dropwizard/metrics/releases/tag/v4.0.6].
> This is observed on a 2.1.19 cluster, but this would impact pretty much any
> version of C* since we depend on lower versions of metrics-core that do not
> have the fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16283) Incorrect output in "nodetool status -r"
[
https://issues.apache.org/jira/browse/CASSANDRA-16283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269475#comment-17269475
]
Adam Holmberg commented on CASSANDRA-16283:
---
[~wolfenhaut] Just checking to see if you're going to have time to get back to
this review? If not, I have no problem carrying the work forward. Just wanted
to check in first.
> Incorrect output in "nodetool status -r"
>
>
> Key: CASSANDRA-16283
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16283
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Yakir Gibraltar
>Assignee: Scott Wolfenhaut
>Priority: Low
> Fix For: 4.0-beta
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> nodetool status -r not working well on C* 4,
> Version:
> {code:java}
> [root@foo001 ~]# nodetool version
> ReleaseVersion: 4.0-beta3
> {code}
> Without resolving:
> {code:java}
> [root@foo001 ~]# nodetool status
> Datacenter: V4CH
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address LoadTokens Owns(effective) Host ID
> Rack
> UN 1.2.3.4 363.68 KiB 128 ?
> 92ae4c39-edb3-4e67-8623-b49fd8301b66 RAC1
> UN 1.2.3.5 109.71 KiB 128 ?
> d80647a8-32b2-4a8f-8022-f5ae3ce8fbb2 RAC1
> {code}
> With resolving:
> {code:java}
> [root@foo001 ~]# nodetool status -r
> Datacenter: V4CH
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> ?N foo001.tab.com ? 128 ? RAC1
> ?N foo002.tab.com ? 128 ? RAC1
> {code}
> I only changed here IPs and hostnames.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16244) Create a jvm upgrade dtest for mixed versions repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-16244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269392#comment-17269392 ] Alexander Dejanovski commented on CASSANDRA-16244: -- Thanks for picking this up [~adelapena]! :) > Create a jvm upgrade dtest for mixed versions repairs > - > > Key: CASSANDRA-16244 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16244 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alexander Dejanovski >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.0-rc > > > Repair during upgrades should fail on mixed version clusters. > We'd need an in-jvm upgrade dtest to check that repair indeed fails as > expected with mixed current version+previous major version clusters. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16397) Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16397:
---
Fix Version/s: 4.0
4.0-beta5
Since Version: 4.0-beta2
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/7ed2daf38699fa9555feb9049c1c27a410f1520e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[7ed2daf38699fa9555feb9049c1c27a410f1520e|https://github.com/apache/cassandra-dtest/commit/7ed2daf38699fa9555feb9049c1c27a410f1520e].
Thanks [~tomasz.lasica] for the report!
> Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
>
>
> Key: CASSANDRA-16397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16397
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Tomasz Lasica
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta5, 4.0
>
>
> There is a new flag, added in CASSANDRA-16070: "--keep-failed-test-dir".
> In some cases (I am not sure if always),
> when this flag is set and when test is SKIP-ed it will cause test ERROR.
>
> Good run (without --keep-failed-test-dir)
> {code:java}
> pytest --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .ss
>
> [100%]
> ===Flaky Test Report===test_defaults passed 1 out of the required 1 times.
> Success!===End Flaky Test
> Report===
> 1 passed, 2 skipped in 11.25 seconds
> ={code}
> and bad one (with flag):
> {code:java}
> pytest --keep-failed-test-dir
> --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .sEsE
>
>
> [100%]===
> ERRORS
>
> _ ERROR at
> teardown of TestClientNetworkStopStart.test_hsha_defaults
> __request =
> >,
> dtest_config =
> fixture_dtest_setup_overrides = object at 0x7fd313263048>, fixture_logging_setup = None,
> fixture_dtest_cluster_name = 'test'
> fixture_dtest_create_cluster_func = at 0x7fd313b15488>@pytest.fixture(scope='function', autouse=False)
> def fixture_dtest_setup(request,
> dtest_config,
> fixture_dtest_setup_overrides,
> fixture_logging_setup,
> fixture_dtest_cluster_name,
> fixture_dtest_create_cluster_func):
> if running_in_docker():
> cleanup_docker_environment_before_test_execution()
>
> # do all of our setup operations to get the enviornment ready for the
> actual test
> # to
[jira] [Updated] (CASSANDRA-16397) Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16397:
---
Status: Ready to Commit (was: Review In Progress)
> Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
>
>
> Key: CASSANDRA-16397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16397
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Tomasz Lasica
>Assignee: Michael Semb Wever
>Priority: Normal
>
> There is a new flag, added in CASSANDRA-16070: "--keep-failed-test-dir".
> In some cases (I am not sure if always),
> when this flag is set and when test is SKIP-ed it will cause test ERROR.
>
> Good run (without --keep-failed-test-dir)
> {code:java}
> pytest --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .ss
>
> [100%]
> ===Flaky Test Report===test_defaults passed 1 out of the required 1 times.
> Success!===End Flaky Test
> Report===
> 1 passed, 2 skipped in 11.25 seconds
> ={code}
> and bad one (with flag):
> {code:java}
> pytest --keep-failed-test-dir
> --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .sEsE
>
>
> [100%]===
> ERRORS
>
> _ ERROR at
> teardown of TestClientNetworkStopStart.test_hsha_defaults
> __request =
> >,
> dtest_config =
> fixture_dtest_setup_overrides = object at 0x7fd313263048>, fixture_logging_setup = None,
> fixture_dtest_cluster_name = 'test'
> fixture_dtest_create_cluster_func = at 0x7fd313b15488>@pytest.fixture(scope='function', autouse=False)
> def fixture_dtest_setup(request,
> dtest_config,
> fixture_dtest_setup_overrides,
> fixture_logging_setup,
> fixture_dtest_cluster_name,
> fixture_dtest_create_cluster_func):
> if running_in_docker():
> cleanup_docker_environment_before_test_execution()
>
> # do all of our setup operations to get the enviornment ready for the
> actual test
> # to run (e.g. bring up a cluster with the necessary config, populate
> variables, etc)
> initial_environment = copy.deepcopy(os.environ)
> dtest_setup = DTestSetup(dtest_config=dtest_config,
>
> setup_overrides=fixture_dtest_setup_overrides,
> cluster_name=fixture_dtest_cluster_name)
> dtest_setup.initialize_cluster(fixture_dtest_create_cluster_func)
>
> if not dtest_config.d
[cassandra-dtest] branch trunk updated: Fix `--keep-failed-test-dir` on skipped 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-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 7ed2daf Fix `--keep-failed-test-dir` on skipped dtests
7ed2daf is described below
commit 7ed2daf38699fa9555feb9049c1c27a410f1520e
Author: Mick Semb Wever
AuthorDate: Thu Jan 21 14:58:53 2021 +0100
Fix `--keep-failed-test-dir` on skipped dtests
patch by Mick Semb Wever; reviewed by Tomek Lasica for CASSANDRA-16397
---
dtest_setup.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dtest_setup.py b/dtest_setup.py
index b3f4838..f613ab2 100644
--- a/dtest_setup.py
+++ b/dtest_setup.py
@@ -348,7 +348,8 @@ class DTestSetup(object):
def cleanup_cluster(self, request=None):
with log_filter('cassandra'): # quiet noise from driver when nodes
start going down
-if self.dtest_config.keep_test_dir or
(self.dtest_config.keep_failed_test_dir and request and
request.node.rep_call.failed):
+test_failed = request and hasattr(request.node, 'rep_call') and
request.node.rep_call.failed
+if self.dtest_config.keep_test_dir or
(self.dtest_config.keep_failed_test_dir and test_failed):
self.cluster.stop(gently=self.dtest_config.enable_jacoco_code_coverage)
else:
# when recording coverage the jvm has to exit normally
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16397) Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269358#comment-17269358
]
Tomasz Lasica commented on CASSANDRA-16397:
---
LGTM.
I confirmed manually that indeed it fixes the problem and code looks good.
> Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
>
>
> Key: CASSANDRA-16397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16397
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Tomasz Lasica
>Assignee: Michael Semb Wever
>Priority: Normal
>
> There is a new flag, added in CASSANDRA-16070: "--keep-failed-test-dir".
> In some cases (I am not sure if always),
> when this flag is set and when test is SKIP-ed it will cause test ERROR.
>
> Good run (without --keep-failed-test-dir)
> {code:java}
> pytest --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .ss
>
> [100%]
> ===Flaky Test Report===test_defaults passed 1 out of the required 1 times.
> Success!===End Flaky Test
> Report===
> 1 passed, 2 skipped in 11.25 seconds
> ={code}
> and bad one (with flag):
> {code:java}
> pytest --keep-failed-test-dir
> --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .sEsE
>
>
> [100%]===
> ERRORS
>
> _ ERROR at
> teardown of TestClientNetworkStopStart.test_hsha_defaults
> __request =
> >,
> dtest_config =
> fixture_dtest_setup_overrides = object at 0x7fd313263048>, fixture_logging_setup = None,
> fixture_dtest_cluster_name = 'test'
> fixture_dtest_create_cluster_func = at 0x7fd313b15488>@pytest.fixture(scope='function', autouse=False)
> def fixture_dtest_setup(request,
> dtest_config,
> fixture_dtest_setup_overrides,
> fixture_logging_setup,
> fixture_dtest_cluster_name,
> fixture_dtest_create_cluster_func):
> if running_in_docker():
> cleanup_docker_environment_before_test_execution()
>
> # do all of our setup operations to get the enviornment ready for the
> actual test
> # to run (e.g. bring up a cluster with the necessary config, populate
> variables, etc)
> initial_environment = copy.deepcopy(os.environ)
> dtest_setup = DTestSetup(dtest_config=dtest_config,
>
> setup_overrides=fixture_dtest_setup_overrides,
> cluster_name=fixture_dtest_cluster_name)
> dtest_setup.initialize_cluste
[jira] [Updated] (CASSANDRA-16397) Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Lasica updated CASSANDRA-16397:
--
Reviewers: Tomasz Lasica, Tomasz Lasica (was: Tomasz Lasica)
Tomasz Lasica, Tomasz Lasica
Status: Review In Progress (was: Patch Available)
> Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
>
>
> Key: CASSANDRA-16397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16397
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Tomasz Lasica
>Assignee: Michael Semb Wever
>Priority: Normal
>
> There is a new flag, added in CASSANDRA-16070: "--keep-failed-test-dir".
> In some cases (I am not sure if always),
> when this flag is set and when test is SKIP-ed it will cause test ERROR.
>
> Good run (without --keep-failed-test-dir)
> {code:java}
> pytest --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .ss
>
> [100%]
> ===Flaky Test Report===test_defaults passed 1 out of the required 1 times.
> Success!===End Flaky Test
> Report===
> 1 passed, 2 skipped in 11.25 seconds
> ={code}
> and bad one (with flag):
> {code:java}
> pytest --keep-failed-test-dir
> --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .sEsE
>
>
> [100%]===
> ERRORS
>
> _ ERROR at
> teardown of TestClientNetworkStopStart.test_hsha_defaults
> __request =
> >,
> dtest_config =
> fixture_dtest_setup_overrides = object at 0x7fd313263048>, fixture_logging_setup = None,
> fixture_dtest_cluster_name = 'test'
> fixture_dtest_create_cluster_func = at 0x7fd313b15488>@pytest.fixture(scope='function', autouse=False)
> def fixture_dtest_setup(request,
> dtest_config,
> fixture_dtest_setup_overrides,
> fixture_logging_setup,
> fixture_dtest_cluster_name,
> fixture_dtest_create_cluster_func):
> if running_in_docker():
> cleanup_docker_environment_before_test_execution()
>
> # do all of our setup operations to get the enviornment ready for the
> actual test
> # to run (e.g. bring up a cluster with the necessary config, populate
> variables, etc)
> initial_environment = copy.deepcopy(os.environ)
> dtest_setup = DTestSetup(dtest_config=dtest_config,
>
> setup_overrides=fixture_dtest_setup_overrides,
> cluster_name=fixture_dtest_cluster_name)
> d
[jira] [Updated] (CASSANDRA-16374) Restore check for consistent native protocol versions for connection
[ https://issues.apache.org/jira/browse/CASSANDRA-16374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16374: --- Status: Ready to Commit (was: Review In Progress) +1 > Restore check for consistent native protocol versions for connection > > > Key: CASSANDRA-16374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16374 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Labels: protocolv5 > Fix For: 4.0-beta > > > In protocol v4 and earlier, the frame header is checked during > deserialization to ensure that the version matches the one negotiated for the > connection. > The original intention was to remove this version id from the frame (renamed > to envelope in v5) header. However, there is value in keeping this check as > well as the the one for the beta flag, so it remains in the frame/envelope > format. The validation itself however, was removed by some refactoring as > part of CASSANDRA-15299 and should be added back for all protocol versions > before finalizing v5 and cutting a release candidate. The text detailing its > removal also remains in the proposed spec update attached to CASSANDRA-14688, > which also needs to be updated. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16374) Restore check for consistent native protocol versions for connection
[ https://issues.apache.org/jira/browse/CASSANDRA-16374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16374: --- Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Michael Semb Wever, Michael Semb Wever Status: Review In Progress (was: Patch Available) > Restore check for consistent native protocol versions for connection > > > Key: CASSANDRA-16374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16374 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Labels: protocolv5 > Fix For: 4.0-beta > > > In protocol v4 and earlier, the frame header is checked during > deserialization to ensure that the version matches the one negotiated for the > connection. > The original intention was to remove this version id from the frame (renamed > to envelope in v5) header. However, there is value in keeping this check as > well as the the one for the beta flag, so it remains in the frame/envelope > format. The validation itself however, was removed by some refactoring as > part of CASSANDRA-15299 and should be added back for all protocol versions > before finalizing v5 and cutting a release candidate. The text detailing its > removal also remains in the proposed spec update attached to CASSANDRA-14688, > which also needs to be updated. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14541) Order of warning and custom payloads is unspecified in the protocol specification
[ https://issues.apache.org/jira/browse/CASSANDRA-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14541: --- Status: Ready to Commit (was: Review In Progress) > Order of warning and custom payloads is unspecified in the protocol > specification > - > > Key: CASSANDRA-14541 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14541 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Avi Kivity >Assignee: Sam Tunnicliffe >Priority: Low > Labels: protocolv4, protocolv5 > Fix For: 3.11.x, 4.x > > Attachments: > v1-0001-Document-order-of-tracing-warning-and-custom-payl.patch > > > Section 2.2 of the protocol specification documents the types of tracing, > warning, and custom payloads, but does not document their order in the body. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14541) Order of warning and custom payloads is unspecified in the protocol specification
[ https://issues.apache.org/jira/browse/CASSANDRA-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14541: --- Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Status: Review In Progress (was: Patch Available) > Order of warning and custom payloads is unspecified in the protocol > specification > - > > Key: CASSANDRA-14541 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14541 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Avi Kivity >Assignee: Sam Tunnicliffe >Priority: Low > Labels: protocolv4, protocolv5 > Fix For: 3.11.x, 4.x > > Attachments: > v1-0001-Document-order-of-tracing-warning-and-custom-payl.patch > > > Section 2.2 of the protocol specification documents the types of tracing, > warning, and custom payloads, but does not document their order in the body. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14541) Order of warning and custom payloads is unspecified in the protocol specification
[ https://issues.apache.org/jira/browse/CASSANDRA-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269349#comment-17269349 ] Michael Semb Wever commented on CASSANDRA-14541: [~samt], your updates to v4 and v5 specs look good to me! > Order of warning and custom payloads is unspecified in the protocol > specification > - > > Key: CASSANDRA-14541 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14541 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Avi Kivity >Assignee: Sam Tunnicliffe >Priority: Low > Labels: protocolv4, protocolv5 > Fix For: 3.11.x, 4.x > > Attachments: > v1-0001-Document-order-of-tracing-warning-and-custom-payl.patch > > > Section 2.2 of the protocol specification documents the types of tracing, > warning, and custom payloads, but does not document their order in the body. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14688) Update protocol spec and class level doc with protocol checksumming details
[
https://issues.apache.org/jira/browse/CASSANDRA-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269346#comment-17269346
]
Michael Semb Wever commented on CASSANDRA-14688:
+1
> Update protocol spec and class level doc with protocol checksumming details
> ---
>
> Key: CASSANDRA-14688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14688
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-rc
>
>
> CASSANDRA-13304 provides an option to add checksumming to the frame body of
> native protocol messages. The native protocol spec needs to be updated to
> reflect this ASAP. We should also verify that the javadoc comments describing
> the on-wire format in
> {{o.a.c.transport.frame.checksum.ChecksummingTransformer}} are up to date.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16397) Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16397:
---
Authors: Michael Semb Wever
Test and Documentation Plan: manual
Status: Patch Available (was: Open)
> Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
>
>
> Key: CASSANDRA-16397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16397
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Tomasz Lasica
>Priority: Normal
>
> There is a new flag, added in CASSANDRA-16070: "--keep-failed-test-dir".
> In some cases (I am not sure if always),
> when this flag is set and when test is SKIP-ed it will cause test ERROR.
>
> Good run (without --keep-failed-test-dir)
> {code:java}
> pytest --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .ss
>
> [100%]
> ===Flaky Test Report===test_defaults passed 1 out of the required 1 times.
> Success!===End Flaky Test
> Report===
> 1 passed, 2 skipped in 11.25 seconds
> ={code}
> and bad one (with flag):
> {code:java}
> pytest --keep-failed-test-dir
> --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .sEsE
>
>
> [100%]===
> ERRORS
>
> _ ERROR at
> teardown of TestClientNetworkStopStart.test_hsha_defaults
> __request =
> >,
> dtest_config =
> fixture_dtest_setup_overrides = object at 0x7fd313263048>, fixture_logging_setup = None,
> fixture_dtest_cluster_name = 'test'
> fixture_dtest_create_cluster_func = at 0x7fd313b15488>@pytest.fixture(scope='function', autouse=False)
> def fixture_dtest_setup(request,
> dtest_config,
> fixture_dtest_setup_overrides,
> fixture_logging_setup,
> fixture_dtest_cluster_name,
> fixture_dtest_create_cluster_func):
> if running_in_docker():
> cleanup_docker_environment_before_test_execution()
>
> # do all of our setup operations to get the enviornment ready for the
> actual test
> # to run (e.g. bring up a cluster with the necessary config, populate
> variables, etc)
> initial_environment = copy.deepcopy(os.environ)
> dtest_setup = DTestSetup(dtest_config=dtest_config,
>
> setup_overrides=fixture_dtest_setup_overrides,
> cluster_name=fixture_dtest_cluster_name)
> dtest_setup.initialize_cluster(fixture_dtest_cr
[jira] [Assigned] (CASSANDRA-16397) Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever reassigned CASSANDRA-16397:
--
Assignee: Michael Semb Wever
> Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
>
>
> Key: CASSANDRA-16397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16397
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Tomasz Lasica
>Assignee: Michael Semb Wever
>Priority: Normal
>
> There is a new flag, added in CASSANDRA-16070: "--keep-failed-test-dir".
> In some cases (I am not sure if always),
> when this flag is set and when test is SKIP-ed it will cause test ERROR.
>
> Good run (without --keep-failed-test-dir)
> {code:java}
> pytest --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .ss
>
> [100%]
> ===Flaky Test Report===test_defaults passed 1 out of the required 1 times.
> Success!===End Flaky Test
> Report===
> 1 passed, 2 skipped in 11.25 seconds
> ={code}
> and bad one (with flag):
> {code:java}
> pytest --keep-failed-test-dir
> --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .sEsE
>
>
> [100%]===
> ERRORS
>
> _ ERROR at
> teardown of TestClientNetworkStopStart.test_hsha_defaults
> __request =
> >,
> dtest_config =
> fixture_dtest_setup_overrides = object at 0x7fd313263048>, fixture_logging_setup = None,
> fixture_dtest_cluster_name = 'test'
> fixture_dtest_create_cluster_func = at 0x7fd313b15488>@pytest.fixture(scope='function', autouse=False)
> def fixture_dtest_setup(request,
> dtest_config,
> fixture_dtest_setup_overrides,
> fixture_logging_setup,
> fixture_dtest_cluster_name,
> fixture_dtest_create_cluster_func):
> if running_in_docker():
> cleanup_docker_environment_before_test_execution()
>
> # do all of our setup operations to get the enviornment ready for the
> actual test
> # to run (e.g. bring up a cluster with the necessary config, populate
> variables, etc)
> initial_environment = copy.deepcopy(os.environ)
> dtest_setup = DTestSetup(dtest_config=dtest_config,
>
> setup_overrides=fixture_dtest_setup_overrides,
> cluster_name=fixture_dtest_cluster_name)
> dtest_setup.initialize_cluster(fixture_dtest_create_cluster_func)
>
> if not dtest_config.disable_active_l
[jira] [Commented] (CASSANDRA-16397) Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269319#comment-17269319
]
Michael Semb Wever commented on CASSANDRA-16397:
Patch at
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16397
Just add additional check that 'rep_call' exists, i.e. the test was setup. If
it wasn't setup then we know it hasn't failed.
> Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
>
>
> Key: CASSANDRA-16397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16397
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Tomasz Lasica
>Priority: Normal
>
> There is a new flag, added in CASSANDRA-16070: "--keep-failed-test-dir".
> In some cases (I am not sure if always),
> when this flag is set and when test is SKIP-ed it will cause test ERROR.
>
> Good run (without --keep-failed-test-dir)
> {code:java}
> pytest --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .ss
>
> [100%]
> ===Flaky Test Report===test_defaults passed 1 out of the required 1 times.
> Success!===End Flaky Test
> Report===
> 1 passed, 2 skipped in 11.25 seconds
> ={code}
> and bad one (with flag):
> {code:java}
> pytest --keep-failed-test-dir
> --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .sEsE
>
>
> [100%]===
> ERRORS
>
> _ ERROR at
> teardown of TestClientNetworkStopStart.test_hsha_defaults
> __request =
> >,
> dtest_config =
> fixture_dtest_setup_overrides = object at 0x7fd313263048>, fixture_logging_setup = None,
> fixture_dtest_cluster_name = 'test'
> fixture_dtest_create_cluster_func = at 0x7fd313b15488>@pytest.fixture(scope='function', autouse=False)
> def fixture_dtest_setup(request,
> dtest_config,
> fixture_dtest_setup_overrides,
> fixture_logging_setup,
> fixture_dtest_cluster_name,
> fixture_dtest_create_cluster_func):
> if running_in_docker():
> cleanup_docker_environment_before_test_execution()
>
> # do all of our setup operations to get the enviornment ready for the
> actual test
> # to run (e.g. bring up a cluster with the necessary config, populate
> variables, etc)
> initial_environment = copy.deepcopy(os.environ)
> dtest_setup = DTestSetup(dtest_config=dtest_config,
>
> setup_overrides=fixture_dtest_setup_overrides,
>
[jira] [Comment Edited] (CASSANDRA-16397) Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269314#comment-17269314
]
Michael Semb Wever edited comment on CASSANDRA-16397 at 1/21/21, 1:57 PM:
--
It looks to be a new failure… (though I can't see how the setup of skipped
tests was happening before but isn't now 🤷🏻♀️)
{code}
E AttributeError: 'Function' object has no attribute
'rep_call'dtest_setup.py:351: AttributeError
{code}
was (Author: michaelsembwever):
This is a new failure…
{code}
E AttributeError: 'Function' object has no attribute
'rep_call'dtest_setup.py:351: AttributeError
{code}
> Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
>
>
> Key: CASSANDRA-16397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16397
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Tomasz Lasica
>Priority: Normal
>
> There is a new flag, added in CASSANDRA-16070: "--keep-failed-test-dir".
> In some cases (I am not sure if always),
> when this flag is set and when test is SKIP-ed it will cause test ERROR.
>
> Good run (without --keep-failed-test-dir)
> {code:java}
> pytest --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .ss
>
> [100%]
> ===Flaky Test Report===test_defaults passed 1 out of the required 1 times.
> Success!===End Flaky Test
> Report===
> 1 passed, 2 skipped in 11.25 seconds
> ={code}
> and bad one (with flag):
> {code:java}
> pytest --keep-failed-test-dir
> --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .sEsE
>
>
> [100%]===
> ERRORS
>
> _ ERROR at
> teardown of TestClientNetworkStopStart.test_hsha_defaults
> __request =
> >,
> dtest_config =
> fixture_dtest_setup_overrides = object at 0x7fd313263048>, fixture_logging_setup = None,
> fixture_dtest_cluster_name = 'test'
> fixture_dtest_create_cluster_func = at 0x7fd313b15488>@pytest.fixture(scope='function', autouse=False)
> def fixture_dtest_setup(request,
> dtest_config,
> fixture_dtest_setup_overrides,
> fixture_logging_setup,
> fixture_dtest_cluster_name,
> fixture_dtest_create_cluster_func):
> if running_in_docker():
> cleanup_docker_environment_before_test_execution()
>
> # do all of our setup operations to get the enviornment ready for the
> actual test
> # to run (e.g. bring up a cluster with the
[jira] [Updated] (CASSANDRA-16397) Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16397:
---
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
This is a new failure…
{code}
E AttributeError: 'Function' object has no attribute
'rep_call'dtest_setup.py:351: AttributeError
{code}
> Running python dtest with --keep-failed-test-dir causes ERROR for SKIP tests
>
>
> Key: CASSANDRA-16397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16397
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Tomasz Lasica
>Priority: Normal
>
> There is a new flag, added in CASSANDRA-16070: "--keep-failed-test-dir".
> In some cases (I am not sure if always),
> when this flag is set and when test is SKIP-ed it will cause test ERROR.
>
> Good run (without --keep-failed-test-dir)
> {code:java}
> pytest --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .ss
>
> [100%]
> ===Flaky Test Report===test_defaults passed 1 out of the required 1 times.
> Success!===End Flaky Test
> Report===
> 1 passed, 2 skipped in 11.25 seconds
> ={code}
> and bad one (with flag):
> {code:java}
> pytest --keep-failed-test-dir
> --cassandra-dir=/home/tomek/repos/apache/cassandra
> client_network_stop_start_test.py
> =
> test session starts
> =
> platform linux -- Python 3.6.12, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
> rootdir: /home/tomek/repos/tlasica/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.4.2, flaky-3.7.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 3 items
>
> client_network_stop_start_test.py .sEsE
>
>
> [100%]===
> ERRORS
>
> _ ERROR at
> teardown of TestClientNetworkStopStart.test_hsha_defaults
> __request =
> >,
> dtest_config =
> fixture_dtest_setup_overrides = object at 0x7fd313263048>, fixture_logging_setup = None,
> fixture_dtest_cluster_name = 'test'
> fixture_dtest_create_cluster_func = at 0x7fd313b15488>@pytest.fixture(scope='function', autouse=False)
> def fixture_dtest_setup(request,
> dtest_config,
> fixture_dtest_setup_overrides,
> fixture_logging_setup,
> fixture_dtest_cluster_name,
> fixture_dtest_create_cluster_func):
> if running_in_docker():
> cleanup_docker_environment_before_test_execution()
>
> # do all of our setup operations to get the enviornment ready for the
> actual test
> # to run (e.g. bring up a cluster with the necessary config, populate
> variables, etc)
> initial_environment = copy.deepcopy(os.environ)
> dtest_setup = DTestSetup(dtest_config=dtest_config,
>
[jira] [Commented] (CASSANDRA-16395) Increase node start timeout for selected bootstrap and replace node tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269279#comment-17269279 ] Michael Semb Wever commented on CASSANDRA-16395: Committed as [e8c2b94b6f106e276800aa3de2628a73a70ac5e6|https://github.com/apache/cassandra-dtest/commit/e8c2b94b6f106e276800aa3de2628a73a70ac5e6]. > Increase node start timeout for selected bootstrap and replace node tests > - > > Key: CASSANDRA-16395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16395 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Tomasz Lasica >Assignee: Tomasz Lasica >Priority: Low > Fix For: 2.2.20, 3.0.24, 3.11.10, 4.0-beta5, 4.0 > > Time Spent: 40m > Remaining Estimate: 0h > > *Summary* > Node start timeouts should be explicitly extended to more than default 90s > (boostrap with reset state, replace node tests) because the default 90s will > start to work after ccm changes. > *Why we need this change* > There is a bug in [https://github.com/riptano/ccm] that node.start() timeout > (or more precisely node.wait_for_binary_proto() timeout is in practice 600s. > This is the time to wait for certain log message: > [https://github.com/riptano/ccm/blob/484476494bda6d71f895826358722a7b1c47a3cf/ccmlib/node.py#L642|https://github.com/riptano/ccm/blob/cassandra-test/ccmlib/node.py#L642] > This bug will be fixed by: [https://github.com/riptano/ccm/pull/725] > *Proposed improvement* > Explicitly raise node start timeout to 120s or 180s (depending on the > scenario) by using existing `Node` api to provide timeout as int (in seconds) > instead of bool. > Note that this is available after [https://github.com/riptano/ccm/pull/725] > is merged but should not break test logic before it is merged. > *PR* > [https://github.com/apache/cassandra-dtest/pull/113/files] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16395) Increase node start timeout for selected bootstrap and replace node tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16395: --- Fix Version/s: (was: 4.0.x) (was: 3.11.x) 4.0 4.0-beta5 3.11.10 3.0.24 2.2.20 Source Control Link: https://github.com/apache/cassandra-dtest/commit/e8c2b94b6f106e276800aa3de2628a73a70ac5e6 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Increase node start timeout for selected bootstrap and replace node tests > - > > Key: CASSANDRA-16395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16395 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Tomasz Lasica >Assignee: Tomasz Lasica >Priority: Low > Fix For: 2.2.20, 3.0.24, 3.11.10, 4.0-beta5, 4.0 > > Time Spent: 40m > Remaining Estimate: 0h > > *Summary* > Node start timeouts should be explicitly extended to more than default 90s > (boostrap with reset state, replace node tests) because the default 90s will > start to work after ccm changes. > *Why we need this change* > There is a bug in [https://github.com/riptano/ccm] that node.start() timeout > (or more precisely node.wait_for_binary_proto() timeout is in practice 600s. > This is the time to wait for certain log message: > [https://github.com/riptano/ccm/blob/484476494bda6d71f895826358722a7b1c47a3cf/ccmlib/node.py#L642|https://github.com/riptano/ccm/blob/cassandra-test/ccmlib/node.py#L642] > This bug will be fixed by: [https://github.com/riptano/ccm/pull/725] > *Proposed improvement* > Explicitly raise node start timeout to 120s or 180s (depending on the > scenario) by using existing `Node` api to provide timeout as int (in seconds) > instead of bool. > Note that this is available after [https://github.com/riptano/ccm/pull/725] > is merged but should not break test logic before it is merged. > *PR* > [https://github.com/apache/cassandra-dtest/pull/113/files] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: Explicit node start timeouts
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-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new e8c2b94 Explicit node start timeouts
e8c2b94 is described below
commit e8c2b94b6f106e276800aa3de2628a73a70ac5e6
Author: Tomek Lasica
AuthorDate: Mon Jan 18 20:47:09 2021 +0100
Explicit node start timeouts
Some tests require longer start timeout than default 90s:
* bootstrap with reset state
* node replacement
* cdc tests (due to checks for other seeds connectivity)
Before: use default timeout, 90s or rather 600s (due to bug in ccm)
After: use explicit timeout per test case: 120s or 180s
patch by Tomek Lasica; reviewed by Mick Semb Wever for CASSANDRA-16395
---
bootstrap_test.py | 4 ++--
cdc_test.py | 4 ++--
disk_balance_test.py| 2 +-
replace_address_test.py | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/bootstrap_test.py b/bootstrap_test.py
index 599bf66..1184b8c 100644
--- a/bootstrap_test.py
+++ b/bootstrap_test.py
@@ -415,8 +415,8 @@ class TestBootstrap(Tester):
node3.start(jvm_args=["-Dcassandra.reset_bootstrap_progress=true"])
# check if we reset bootstrap state
node3.watch_log_for("Resetting bootstrap progress to start fresh",
from_mark=mark)
-# wait for node3 ready to query
-node3.wait_for_binary_interface(from_mark=mark)
+# wait for node3 ready to query, 180s as the node needs to bootstrap
+node3.wait_for_binary_interface(from_mark=mark, timeout=180)
# check if 2nd bootstrap succeeded
assert_bootstrap_state(self, node3, 'COMPLETED')
diff --git a/cdc_test.py b/cdc_test.py
index df21f7d..87d337b 100644
--- a/cdc_test.py
+++ b/cdc_test.py
@@ -547,7 +547,7 @@ class TestCDC(Tester):
logger.debug('adding node')
self.cluster.add(loading_node, is_seed=True)
logger.debug('starting new node')
-loading_node.start(wait_for_binary_proto=True)
+loading_node.start(wait_for_binary_proto=120)
logger.debug('recreating ks and table')
loading_session = self.patient_exclusive_cql_connection(loading_node)
create_ks(loading_session, ks_name, rf=1)
@@ -615,7 +615,7 @@ class TestCDC(Tester):
os.path.join(generation_node.get_path(), 'cdc_raw'),
os.path.join(loading_node.get_path(), 'commitlogs')
)
-loading_node.start(wait_for_binary_proto=True)
+loading_node.start(wait_for_binary_proto=120)
logger.debug('node successfully started; waiting on log replay')
loading_node.grep_log('Log replay complete')
logger.debug('log replay complete')
diff --git a/disk_balance_test.py b/disk_balance_test.py
index bfd3d8e..1c1a759 100644
--- a/disk_balance_test.py
+++ b/disk_balance_test.py
@@ -97,7 +97,7 @@ class TestDiskBalance(Tester):
binary_interface=(node5_address, 9042))
self.cluster.add(node5, False)
node5.start(jvm_args=["-Dcassandra.replace_address_first_boot={}".format(node2.address())],
-wait_for_binary_proto=True,
+wait_for_binary_proto=180,
wait_other_notice=True)
logger.debug("Checking replacement node is balanced")
diff --git a/replace_address_test.py b/replace_address_test.py
index 2fa76f9..0645571 100644
--- a/replace_address_test.py
+++ b/replace_address_test.py
@@ -484,13 +484,13 @@ class TestReplaceAddress(BaseReplaceAddressTest):
if mode == 'reset_resume_state':
mark = self.replacement_node.mark_log()
logger.debug("Restarting replacement node with
-Dcassandra.reset_bootstrap_progress=true")
-# restart replacement node with resetting bootstrap state
+# restart replacement node with resetting bootstrap state (with
180s timeout)
self.replacement_node.stop()
self.replacement_node.start(jvm_args=[
"-Dcassandra.replace_address_first_boot={}".format(self.replaced_node.address()),
"-Dcassandra.reset_bootstrap_progress=true"
],
-wait_for_binary_proto=True)
+wait_for_binary_proto=180)
# check if we reset bootstrap state
self.replacement_node.watch_log_for("Resetting bootstrap progress
to start fresh", from_mark=mark)
elif mode == 'resume':
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16395) Increase node start timeout for selected bootstrap and replace node tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16395: --- Status: Ready to Commit (was: Review In Progress) > Increase node start timeout for selected bootstrap and replace node tests > - > > Key: CASSANDRA-16395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16395 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Tomasz Lasica >Assignee: Tomasz Lasica >Priority: Low > Fix For: 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > *Summary* > Node start timeouts should be explicitly extended to more than default 90s > (boostrap with reset state, replace node tests) because the default 90s will > start to work after ccm changes. > *Why we need this change* > There is a bug in [https://github.com/riptano/ccm] that node.start() timeout > (or more precisely node.wait_for_binary_proto() timeout is in practice 600s. > This is the time to wait for certain log message: > [https://github.com/riptano/ccm/blob/484476494bda6d71f895826358722a7b1c47a3cf/ccmlib/node.py#L642|https://github.com/riptano/ccm/blob/cassandra-test/ccmlib/node.py#L642] > This bug will be fixed by: [https://github.com/riptano/ccm/pull/725] > *Proposed improvement* > Explicitly raise node start timeout to 120s or 180s (depending on the > scenario) by using existing `Node` api to provide timeout as int (in seconds) > instead of bool. > Note that this is available after [https://github.com/riptano/ccm/pull/725] > is merged but should not break test logic before it is merged. > *PR* > [https://github.com/apache/cassandra-dtest/pull/113/files] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16395) Increase node start timeout for selected bootstrap and replace node tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269113#comment-17269113 ] Michael Semb Wever edited comment on CASSANDRA-16395 at 1/21/21, 12:46 PM: --- CI - 2.2 :: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/311/pipeline - 3.0 :: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/312/pipeline - 3.11 :: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/313/pipeline - circleci :: https://app.circleci.com/pipelines/github/tlasica/cassandra?branch=CASSANDRA-16395-trunk was (Author: michaelsembwever): CI - 2.2 :: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/311/pipeline - 3.0 :: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/312/pipeline - 3.11 :: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/313/pipeline > Increase node start timeout for selected bootstrap and replace node tests > - > > Key: CASSANDRA-16395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16395 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Tomasz Lasica >Assignee: Tomasz Lasica >Priority: Low > Fix For: 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > *Summary* > Node start timeouts should be explicitly extended to more than default 90s > (boostrap with reset state, replace node tests) because the default 90s will > start to work after ccm changes. > *Why we need this change* > There is a bug in [https://github.com/riptano/ccm] that node.start() timeout > (or more precisely node.wait_for_binary_proto() timeout is in practice 600s. > This is the time to wait for certain log message: > [https://github.com/riptano/ccm/blob/484476494bda6d71f895826358722a7b1c47a3cf/ccmlib/node.py#L642|https://github.com/riptano/ccm/blob/cassandra-test/ccmlib/node.py#L642] > This bug will be fixed by: [https://github.com/riptano/ccm/pull/725] > *Proposed improvement* > Explicitly raise node start timeout to 120s or 180s (depending on the > scenario) by using existing `Node` api to provide timeout as int (in seconds) > instead of bool. > Note that this is available after [https://github.com/riptano/ccm/pull/725] > is merged but should not break test logic before it is merged. > *PR* > [https://github.com/apache/cassandra-dtest/pull/113/files] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16395) Increase node start timeout for selected bootstrap and replace node tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16395: --- Summary: Increase node start timeout for selected bootstrap and replace node tests (was: Increate node start timeout for selected bootstrap and replace node tests) > Increase node start timeout for selected bootstrap and replace node tests > - > > Key: CASSANDRA-16395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16395 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Tomasz Lasica >Assignee: Tomasz Lasica >Priority: Low > Fix For: 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > *Summary* > Node start timeouts should be explicitly extended to more than default 90s > (boostrap with reset state, replace node tests) because the default 90s will > start to work after ccm changes. > *Why we need this change* > There is a bug in [https://github.com/riptano/ccm] that node.start() timeout > (or more precisely node.wait_for_binary_proto() timeout is in practice 600s. > This is the time to wait for certain log message: > [https://github.com/riptano/ccm/blob/484476494bda6d71f895826358722a7b1c47a3cf/ccmlib/node.py#L642|https://github.com/riptano/ccm/blob/cassandra-test/ccmlib/node.py#L642] > This bug will be fixed by: [https://github.com/riptano/ccm/pull/725] > *Proposed improvement* > Explicitly raise node start timeout to 120s or 180s (depending on the > scenario) by using existing `Node` api to provide timeout as int (in seconds) > instead of bool. > Note that this is available after [https://github.com/riptano/ccm/pull/725] > is merged but should not break test logic before it is merged. > *PR* > [https://github.com/apache/cassandra-dtest/pull/113/files] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16395) Increate node start timeout for selected bootstrap and replace node tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16395: --- Test and Documentation Plan: I plan to run CircleCI tests or ask Mick to run some tests for me. Acceptance criteria: no new regression. was: I plan to run CircleCI tests or ask Mike to run some tests for me. Acceptance criteria: no new regression. > Increate node start timeout for selected bootstrap and replace node tests > - > > Key: CASSANDRA-16395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16395 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Tomasz Lasica >Assignee: Tomasz Lasica >Priority: Low > Fix For: 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > *Summary* > Node start timeouts should be explicitly extended to more than default 90s > (boostrap with reset state, replace node tests) because the default 90s will > start to work after ccm changes. > *Why we need this change* > There is a bug in [https://github.com/riptano/ccm] that node.start() timeout > (or more precisely node.wait_for_binary_proto() timeout is in practice 600s. > This is the time to wait for certain log message: > [https://github.com/riptano/ccm/blob/484476494bda6d71f895826358722a7b1c47a3cf/ccmlib/node.py#L642|https://github.com/riptano/ccm/blob/cassandra-test/ccmlib/node.py#L642] > This bug will be fixed by: [https://github.com/riptano/ccm/pull/725] > *Proposed improvement* > Explicitly raise node start timeout to 120s or 180s (depending on the > scenario) by using existing `Node` api to provide timeout as int (in seconds) > instead of bool. > Note that this is available after [https://github.com/riptano/ccm/pull/725] > is merged but should not break test logic before it is merged. > *PR* > [https://github.com/apache/cassandra-dtest/pull/113/files] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16395) Increate node start timeout for selected bootstrap and replace node tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269113#comment-17269113 ] Michael Semb Wever commented on CASSANDRA-16395: CI - 2.2 :: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/311/pipeline - 3.0 :: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/312/pipeline - 3.11 :: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/313/pipeline > Increate node start timeout for selected bootstrap and replace node tests > - > > Key: CASSANDRA-16395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16395 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Tomasz Lasica >Assignee: Tomasz Lasica >Priority: Low > Fix For: 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > *Summary* > Node start timeouts should be explicitly extended to more than default 90s > (boostrap with reset state, replace node tests) because the default 90s will > start to work after ccm changes. > *Why we need this change* > There is a bug in [https://github.com/riptano/ccm] that node.start() timeout > (or more precisely node.wait_for_binary_proto() timeout is in practice 600s. > This is the time to wait for certain log message: > [https://github.com/riptano/ccm/blob/484476494bda6d71f895826358722a7b1c47a3cf/ccmlib/node.py#L642|https://github.com/riptano/ccm/blob/cassandra-test/ccmlib/node.py#L642] > This bug will be fixed by: [https://github.com/riptano/ccm/pull/725] > *Proposed improvement* > Explicitly raise node start timeout to 120s or 180s (depending on the > scenario) by using existing `Node` api to provide timeout as int (in seconds) > instead of bool. > Note that this is available after [https://github.com/riptano/ccm/pull/725] > is merged but should not break test logic before it is merged. > *PR* > [https://github.com/apache/cassandra-dtest/pull/113/files] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16395) Increate node start timeout for selected bootstrap and replace node tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16395: --- Reviewers: Michael Semb Wever Status: Review In Progress (was: Patch Available) > Increate node start timeout for selected bootstrap and replace node tests > - > > Key: CASSANDRA-16395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16395 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Tomasz Lasica >Assignee: Tomasz Lasica >Priority: Low > Fix For: 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > *Summary* > Node start timeouts should be explicitly extended to more than default 90s > (boostrap with reset state, replace node tests) because the default 90s will > start to work after ccm changes. > *Why we need this change* > There is a bug in [https://github.com/riptano/ccm] that node.start() timeout > (or more precisely node.wait_for_binary_proto() timeout is in practice 600s. > This is the time to wait for certain log message: > [https://github.com/riptano/ccm/blob/484476494bda6d71f895826358722a7b1c47a3cf/ccmlib/node.py#L642|https://github.com/riptano/ccm/blob/cassandra-test/ccmlib/node.py#L642] > This bug will be fixed by: [https://github.com/riptano/ccm/pull/725] > *Proposed improvement* > Explicitly raise node start timeout to 120s or 180s (depending on the > scenario) by using existing `Node` api to provide timeout as int (in seconds) > instead of bool. > Note that this is available after [https://github.com/riptano/ccm/pull/725] > is merged but should not break test logic before it is merged. > *PR* > [https://github.com/apache/cassandra-dtest/pull/113/files] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15691) DOC - Review Testing section, update builds info to ci-cassandra.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever reassigned CASSANDRA-15691: -- Assignee: Michael Semb Wever > DOC - Review Testing section, update builds info to ci-cassandra.apache.org > --- > > Key: CASSANDRA-15691 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15691 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Michael Semb Wever >Priority: Normal > > h2. Background > While discussing doc updates to CASSANDRA-15466 on [ASF > Slack|https://the-asf.slack.com/archives/CK23JSY2K/p1585985233187200], I > discovered that the > [Testing|http://cassandra.apache.org/doc/latest/development/testing.html] > page requires a review. > h2. Sample section > [~mck] advised that the linked CI server here: > bq. Using dtests helps us to prevent regression bugs by continually executing > tests on the [CI server|https://builds.apache.org/] against new patches. > should be https://ci-cassandra.apache.org/. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
