[jira] [Comment Edited] (CASSANDRA-18013) Splitter sometimes creates different number of splits than requested
[
https://issues.apache.org/jira/browse/CASSANDRA-18013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630273#comment-17630273
]
Jacek Lewandowski edited comment on CASSANDRA-18013 at 11/9/22 7:30 AM:
||PR||j8||j11||
|[trunk|https://github.com/apache/cassandra/pull/1985]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/a00cd8c0-7a50-4b83-ba2e-cb99b0c8b319]|[j11
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/0a9922aa-53ea-4b05-91ba-148eec2a49a7]|
|[4.1|https://github.com/apache/cassandra/pull/1986]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/fa3cd055-763a-4db6-9106-c1ae3691cd02]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/2ec96e61-5593-4802-9ff1-33dd6a0bd562]|
|[4.0|https://github.com/apache/cassandra/pull/1987]|[j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]|
|[3.11|https://github.com/apache/cassandra/pull/1968]|[(/) - same failures as
on base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]|-|
was (Author: jlewandowski):
||PR||j8||j11||
|[trunk|https://github.com/apache/cassandra/pull/1985]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/a00cd8c0-7a50-4b83-ba2e-cb99b0c8b319]|[j11
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/0a9922aa-53ea-4b05-91ba-148eec2a49a7]|
|[4.1|https://github.com/apache/cassandra/pull/1986]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/fa3cd055-763a-4db6-9106-c1ae3691cd02]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/2ec96e61-5593-4802-9ff1-33dd6a0bd562]|
|[4.0|https://github.com/apache/cassandra/pull/1987]|[j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]|
|[3.11|https://github.com/apache/cassandra/pull/1968]|[(/) - same failures as
on base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]||
> Splitter sometimes creates different number of splits than requested
>
>
> Key: CASSANDRA-18013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18013
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.11.x, 4.1, 4.2, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Splitter}} in some cases may produce one split more than requested. When it
> happens, it fails with assertion error when assertions are enabled.
> Test to reproduce the issue:
> {code:java}
> Splitter splitter = getSplitter(Murmur3Partitioner.instance);
> long lt = 0;
> long rt = 31;
> Range range = new
> Range<>(getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(lt)),
>
> getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(rt)));
> for (int i = 1; i <= (rt - lt); i++)
> {
> List splits = splitter.splitOwnedRanges(i,
> Arrays.asList(new Splitter.WeightedRange(1.0d, range)), false);
> logger.info("{} splits of {} are: {}", i, range, splits);
> Assertions.assertThat(splits).hasSize(i);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18013) Splitter sometimes creates different number of splits than requested
[
https://issues.apache.org/jira/browse/CASSANDRA-18013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630273#comment-17630273
]
Jacek Lewandowski edited comment on CASSANDRA-18013 at 11/9/22 7:30 AM:
||PR||j8||j11||
|[trunk|https://github.com/apache/cassandra/pull/1985]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/a00cd8c0-7a50-4b83-ba2e-cb99b0c8b319]|[j11
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/0a9922aa-53ea-4b05-91ba-148eec2a49a7]|
|[4.1|https://github.com/apache/cassandra/pull/1986]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/fa3cd055-763a-4db6-9106-c1ae3691cd02]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/2ec96e61-5593-4802-9ff1-33dd6a0bd562]|
|[4.0|https://github.com/apache/cassandra/pull/1987]|[j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]|
|[3.11|https://github.com/apache/cassandra/pull/1968]|[(/) - same failures as
on base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]||
was (Author: jlewandowski):
||PR||j8||j11||
|[trunk|https://github.com/apache/cassandra/pull/1985]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/a00cd8c0-7a50-4b83-ba2e-cb99b0c8b319]|[j11
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/0a9922aa-53ea-4b05-91ba-148eec2a49a7]|
|[4.1|https://github.com/apache/cassandra/pull/1986]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/fa3cd055-763a-4db6-9106-c1ae3691cd02]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/2ec96e61-5593-4802-9ff1-33dd6a0bd562]|
|[4.0|https://github.com/apache/cassandra/pull/1987]|[j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]|
|[3.11|https://github.com/apache/cassandra/pull/1968]|[(/) - same failures as
on base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]|
> Splitter sometimes creates different number of splits than requested
>
>
> Key: CASSANDRA-18013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18013
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.11.x, 4.1, 4.2, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Splitter}} in some cases may produce one split more than requested. When it
> happens, it fails with assertion error when assertions are enabled.
> Test to reproduce the issue:
> {code:java}
> Splitter splitter = getSplitter(Murmur3Partitioner.instance);
> long lt = 0;
> long rt = 31;
> Range range = new
> Range<>(getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(lt)),
>
> getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(rt)));
> for (int i = 1; i <= (rt - lt); i++)
> {
> List splits = splitter.splitOwnedRanges(i,
> Arrays.asList(new Splitter.WeightedRange(1.0d, range)), false);
> logger.info("{} splits of {} are: {}", i, range, splits);
> Assertions.assertThat(splits).hasSize(i);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18013) Splitter sometimes creates different number of splits than requested
[
https://issues.apache.org/jira/browse/CASSANDRA-18013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630273#comment-17630273
]
Jacek Lewandowski edited comment on CASSANDRA-18013 at 11/9/22 7:30 AM:
||PR||j8||j11||
|[trunk|https://github.com/apache/cassandra/pull/1985]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/a00cd8c0-7a50-4b83-ba2e-cb99b0c8b319]|[j11
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/307/workflows/0a9922aa-53ea-4b05-91ba-148eec2a49a7]|
|[4.1|https://github.com/apache/cassandra/pull/1986]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/fa3cd055-763a-4db6-9106-c1ae3691cd02]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/2ec96e61-5593-4802-9ff1-33dd6a0bd562]|
|[4.0|https://github.com/apache/cassandra/pull/1987]|[j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]|
|[3.11|https://github.com/apache/cassandra/pull/1968]|[(/) - same failures as
on base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]|
was (Author: jlewandowski):
||PR||j8||j11||
|[trunk|https://github.com/apache/cassandra/pull/1985]||
|[4.1|https://github.com/apache/cassandra/pull/1986]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/fa3cd055-763a-4db6-9106-c1ae3691cd02]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/2ec96e61-5593-4802-9ff1-33dd6a0bd562]|
|[4.0|https://github.com/apache/cassandra/pull/1987]|[j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]|
|[3.11|https://github.com/apache/cassandra/pull/1968]|[(/) - same failures as
on base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]||
> Splitter sometimes creates different number of splits than requested
>
>
> Key: CASSANDRA-18013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18013
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.11.x, 4.1, 4.2, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Splitter}} in some cases may produce one split more than requested. When it
> happens, it fails with assertion error when assertions are enabled.
> Test to reproduce the issue:
> {code:java}
> Splitter splitter = getSplitter(Murmur3Partitioner.instance);
> long lt = 0;
> long rt = 31;
> Range range = new
> Range<>(getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(lt)),
>
> getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(rt)));
> for (int i = 1; i <= (rt - lt); i++)
> {
> List splits = splitter.splitOwnedRanges(i,
> Arrays.asList(new Splitter.WeightedRange(1.0d, range)), false);
> logger.info("{} splits of {} are: {}", i, range, splits);
> Assertions.assertThat(splits).hasSize(i);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18024) Circle repeated jobs shouldn't appear on default config files
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630774#comment-17630774 ] Berenguer Blasi commented on CASSANDRA-18024: - Thx for all the hard work! > Circle repeated jobs shouldn't appear on default config files > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1-beta2, 4.2 > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[
https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630765#comment-17630765
]
Berenguer Blasi edited comment on CASSANDRA-17964 at 11/9/22 6:06 AM:
--
Why are we changing {{CompactStorageTest.java}} in 4.0? It is correctly named
and we change the asserts. Also are you going to add circle runs for them?
was (Author: bereng):
Why are we changing {{CompactStorageTest.java}} in 4.0? It is correctly named
and we change the asserts? Also are you going to add circle runs for them?
> Some tests are never executed due to naming violation - fix it and add
> checkstyle where applicable
> --
>
> Key: CASSANDRA-17964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17964
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Ruslan Fomkin
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java]
> doesn't follow naming convention to be run as unit tests and, thus, is never
> run.
> The rule in build expects names as `*Test`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[
https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630765#comment-17630765
]
Berenguer Blasi commented on CASSANDRA-17964:
-
Why are we changing {{CompactStorageTest.java}} in 4.0? It is correctly named
and we change the asserts? Also are you going to add circle runs for them?
> Some tests are never executed due to naming violation - fix it and add
> checkstyle where applicable
> --
>
> Key: CASSANDRA-17964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17964
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Ruslan Fomkin
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java]
> doesn't follow naming convention to be run as unit tests and, thus, is never
> run.
> The rule in build expects names as `*Test`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17848) LIST PERMISSION can display incorrect resource name
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630762#comment-17630762
]
Berenguer Blasi commented on CASSANDRA-17848:
-
#1 is the obvious preference. The problem is going to be with backwards
compatibility. I think we can safely and reasonably argue this is a bug and an
accident waiting to happen that needs fixing. It might impact some users
obviously but then again, it's a bug in my eyes. Happy to hear more opinions.
> LIST PERMISSION can display incorrect resource name
> ---
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630759#comment-17630759
]
Berenguer Blasi commented on CASSANDRA-17928:
-
[~brandon.williams] sthg went south in circle bc we have 30K runs on 4.0 where
it was already passing. The 4.1 run only has 500 repeats which is not enough
and trunk has no repeats at all. I would suggest rebasing for CASSANDRA-18000
as well and do 30K repeats for 4.1 and trunk. Did I miss anything?
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> 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)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (c921bda1 -> 671b16b0)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard c921bda1 generate docs for a67d0561 new 671b16b0 generate docs for a67d0561 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (c921bda1) \ N -- N -- N refs/heads/asf-staging (671b16b0) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (678bbaae -> c921bda1)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 678bbaae generate docs for a67d0561 new c921bda1 generate docs for a67d0561 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (678bbaae) \ N -- N -- N refs/heads/asf-staging (c921bda1) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630745#comment-17630745 ] Ekaterina Dimitrova commented on CASSANDRA-17950: - ||Patch||LOWRES||MIDRES||HIGHRES|| |[3.11|https://github.com/ekaterinadimitrova2/cassandra/commit/e4672b6d266eccc43c74c5f75c421b857d043c42]|[CI #2054|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=offheap-circleci-cassandra-3.11-pr]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-3.11-mid]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-3.11-highres]| |[4.0|https://github.com/ekaterinadimitrova2/cassandra/tree/17950-4.0]|[CI 2048|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-4.0]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-4.0-mid]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-4.0-high]| |[4.1|https://github.com/ekaterinadimitrova2/cassandra/tree/17950-4.1]|[CI #2059|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-4.1]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-4.1-mid]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-4.1-high]| |[trunk|https://github.com/ekaterinadimitrova2/cassandra/tree/17950-trunk]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-trunk]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-trunk-mid]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17950-trunk-high]| Just pushed CI for all branches, only the separate jobs for now. I will check the results tomorrow morning and I suggest we push 4.0/4.1 pre_commit but not all branches as that will be crazy amount of resources... > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}
[
https://issues.apache.org/jira/browse/CASSANDRA-17783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630693#comment-17630693
]
Doug Rohrer commented on CASSANDRA-17783:
-
No problem, and thanks for getting it committed.
> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}}
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Low
> Fix For: 4.1-beta2, 4.2
>
> Attachments: CASSANDRA-17783-rebased.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to
> {{CassandraRelevantProps}} for two reasons.
> # Generally speaking, this is where these kinds of things live.
> # By having them in Schema, you can't actually use
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static
> initializers... and you want to use
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before
> the static initializer runs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (690b77ae -> 678bbaae)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 690b77ae generate docs for a67d0561 new 678bbaae generate docs for a67d0561 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (690b77ae) \ N -- N -- N refs/heads/asf-staging (678bbaae) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17848) LIST PERMISSION can display incorrect resource name
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630674#comment-17630674
]
Yifan Cai commented on CASSANDRA-17848:
---
Basically there are 2 possible solutions.
1. Reject at the UDF creation when its name contains any of the special
character '/', '[' and ']'. Those characters should be rarely needed as part of
the function names. It requires to update the disallowed characters list when a
new special character is introduced in the future.
2. Patch the {{FunctionResource#fromName}} implementation to first locate the
last `[...]` segment (as the function's argument list) and treat whatever
appears before it as the function name. Sounds error-prone.
I'd lean towards the approach 1.
[~samt] and [~bereng], wondering what is your preference since you both have
touched the method in question.
> LIST PERMISSION can display incorrect resource name
> ---
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (aed72905 -> 690b77ae)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard aed72905 generate docs for a67d0561 new 690b77ae generate docs for a67d0561 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (aed72905) \ N -- N -- N refs/heads/asf-staging (690b77ae) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630449#comment-17630449
]
Brandon Williams edited comment on CASSANDRA-17928 at 11/9/22 12:23 AM:
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/701/workflows/a1093b26-9c80-455a-871c-da9493642571],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/698/workflows/a65d9619-106f-449d-8cd3-1e4b9eba423e],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/697/workflows/13882701-c4ac-48a1-bff7-27dc7d9c58f8]|
was (Author: brandon.williams):
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/701/workflows/a1093b26-9c80-455a-871c-da9493642571],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/698/workflows/a65d9619-106f-449d-8cd3-1e4b9eba423e],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> 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)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by
[jira] [Comment Edited] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630449#comment-17630449
]
Brandon Williams edited comment on CASSANDRA-17928 at 11/9/22 12:22 AM:
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/701/workflows/a1093b26-9c80-455a-871c-da9493642571],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/698/workflows/a65d9619-106f-449d-8cd3-1e4b9eba423e],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
was (Author: brandon.williams):
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/701/workflows/a1093b26-9c80-455a-871c-da9493642571],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> 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)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by
[jira] [Commented] (CASSANDRA-17848) LIST PERMISSION can display incorrect resource name
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630665#comment-17630665
]
Yifan Cai commented on CASSANDRA-17848:
---
The root cause of the confusing value for the {{resource}} column is located at
{{org.apache.cassandra.auth.FunctionResource#fromName}}. The implementation
assumes the special characters (i.e. /, [ and ]) are not used in the function
name, and uses those characters to parse the encoded function name string read
from role_permissions table.
However, quoted text is allowed as function names. It is permitted to have
those characters in the function names, which breaks the parsing logic.
In addition to the example in the description, it is allowed to create a
function with `/` in the name, as long as it is quoted.
{code:java}
CREATE FUNCTION cql_test_keyspace."my/amazing/udf"(input int) RETURNS NULL ON
NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
{code}
Once the UDF is created, listing permission on the role breaks since `/` is
used to determine if a resource is valid or not.
> LIST PERMISSION can display incorrect resource name
> ---
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17848) LIST PERMISSION can display incorrect resource name
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17848:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Implementation(12988)
Complexity: Normal
Component/s: CQL/Interpreter
Discovered By: User Report
Severity: Normal
Assignee: Yifan Cai
Status: Open (was: Triage Needed)
> LIST PERMISSION can display incorrect resource name
> ---
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17870) nodetool/rebuild: Add flag to exclude nodes from local datacenter
[ https://issues.apache.org/jira/browse/CASSANDRA-17870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630660#comment-17630660 ] Francisco Guerrero commented on CASSANDRA-17870: Another +1 from me as well (non-committer +1 :( ) > nodetool/rebuild: Add flag to exclude nodes from local datacenter > - > > Key: CASSANDRA-17870 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17870 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > Attachments: fix_nodetool_rebuild.diff > > Time Spent: 1.5h > Remaining Estimate: 0h > > During expansion by Dc, when we issue nodetool/rebuild from new dc to rebuild > the data from other DCs. If src-dc is not passed explicitly, then C* tries to > rebuild the data from the same (new dc) dc. > We don’t exclude other nodes in the same DC. Only down sources and the local > node itself are excluded. > ``` > // We're _always_ filtering out a local node and down sources > addSourceFilter(new > RangeStreamer.FailureDetectorSourceFilter(failureDetector)); > addSourceFilter(new RangeStreamer.ExcludeLocalNodeFilter()); > ``` > We should fix nodetool/rebuild to exclude the local DC (from where we’re > executing the command) while issuing nodetool/rebuild without passing src dc > > Example: > in a 3 DC cluster, > ks1 has DC1, DC2 > ks2 has DC1, DC2, DC3 > ks3 has DC2 > now, we add a new DC [DC4] and configured it to all 3 keyspaces. > if we run rebuild with src DC as DC1, ks3 will fail as it does not have DC1. > Now, without src DC, the expectation is rebuild would auto pick up DCs for > each keyspace (let's say ks1: DC1, ks2: DC1, ks3: DC2) and would never fail > due to under-replicated keyspaces. > The issue with this approach (without src dc) is that, DC4 is getting picked > up during rebuild (as src), but DC4 does not have any data yet! > so, with the patch (ignore local dc flag), DC4 can be filtered out and let > the database pick up the right dc for each keyspace [from existing 3 DCs]. > -- this is what is the expectation after the patch. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-47) Introduce JMX foundation in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630655#comment-17630655 ] Yifan Cai commented on CASSANDRASC-47: -- +1 on the patch. > Introduce JMX foundation in Sidecar > --- > > Key: CASSANDRASC-47 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-47 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > Currently, Sidecar supports CQL access to the Cassandra instances it manages. > However, JMX support is not available at the moment. We need to introduce the > JMX foundation in Sidecar to support additional interactions with Cassandra > instances that are not available through the CQL protocol. > This ticket is intended for introducing the JMX foundation, that can later be > used for adding new functionality to Sidecar interactions with Cassandra > through JMX. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-47) Introduce JMX foundation in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-47: - Status: Needs Committer (was: Review In Progress) > Introduce JMX foundation in Sidecar > --- > > Key: CASSANDRASC-47 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-47 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > Currently, Sidecar supports CQL access to the Cassandra instances it manages. > However, JMX support is not available at the moment. We need to introduce the > JMX foundation in Sidecar to support additional interactions with Cassandra > instances that are not available through the CQL protocol. > This ticket is intended for introducing the JMX foundation, that can later be > used for adding new functionality to Sidecar interactions with Cassandra > through JMX. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17870) nodetool/rebuild: Add flag to exclude nodes from local datacenter
[ https://issues.apache.org/jira/browse/CASSANDRA-17870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630654#comment-17630654 ] Yifan Cai commented on CASSANDRA-17870: --- +1 on the patch. Thanks for addressing all my comments > nodetool/rebuild: Add flag to exclude nodes from local datacenter > - > > Key: CASSANDRA-17870 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17870 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > Attachments: fix_nodetool_rebuild.diff > > Time Spent: 1.5h > Remaining Estimate: 0h > > During expansion by Dc, when we issue nodetool/rebuild from new dc to rebuild > the data from other DCs. If src-dc is not passed explicitly, then C* tries to > rebuild the data from the same (new dc) dc. > We don’t exclude other nodes in the same DC. Only down sources and the local > node itself are excluded. > ``` > // We're _always_ filtering out a local node and down sources > addSourceFilter(new > RangeStreamer.FailureDetectorSourceFilter(failureDetector)); > addSourceFilter(new RangeStreamer.ExcludeLocalNodeFilter()); > ``` > We should fix nodetool/rebuild to exclude the local DC (from where we’re > executing the command) while issuing nodetool/rebuild without passing src dc > > Example: > in a 3 DC cluster, > ks1 has DC1, DC2 > ks2 has DC1, DC2, DC3 > ks3 has DC2 > now, we add a new DC [DC4] and configured it to all 3 keyspaces. > if we run rebuild with src DC as DC1, ks3 will fail as it does not have DC1. > Now, without src DC, the expectation is rebuild would auto pick up DCs for > each keyspace (let's say ks1: DC1, ks2: DC1, ks3: DC2) and would never fail > due to under-replicated keyspaces. > The issue with this approach (without src dc) is that, DC4 is getting picked > up during rebuild (as src), but DC4 does not have any data yet! > so, with the patch (ignore local dc flag), DC4 can be filtered out and let > the database pick up the right dc for each keyspace [from existing 3 DCs]. > -- this is what is the expectation after the patch. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17870) nodetool/rebuild: Add flag to exclude nodes from local datacenter
[ https://issues.apache.org/jira/browse/CASSANDRA-17870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17870: - Reviewers: Dinesh Joshi, Yifan Cai (was: Yifan Cai) > nodetool/rebuild: Add flag to exclude nodes from local datacenter > - > > Key: CASSANDRA-17870 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17870 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > Attachments: fix_nodetool_rebuild.diff > > Time Spent: 1h 20m > Remaining Estimate: 0h > > During expansion by Dc, when we issue nodetool/rebuild from new dc to rebuild > the data from other DCs. If src-dc is not passed explicitly, then C* tries to > rebuild the data from the same (new dc) dc. > We don’t exclude other nodes in the same DC. Only down sources and the local > node itself are excluded. > ``` > // We're _always_ filtering out a local node and down sources > addSourceFilter(new > RangeStreamer.FailureDetectorSourceFilter(failureDetector)); > addSourceFilter(new RangeStreamer.ExcludeLocalNodeFilter()); > ``` > We should fix nodetool/rebuild to exclude the local DC (from where we’re > executing the command) while issuing nodetool/rebuild without passing src dc > > Example: > in a 3 DC cluster, > ks1 has DC1, DC2 > ks2 has DC1, DC2, DC3 > ks3 has DC2 > now, we add a new DC [DC4] and configured it to all 3 keyspaces. > if we run rebuild with src DC as DC1, ks3 will fail as it does not have DC1. > Now, without src DC, the expectation is rebuild would auto pick up DCs for > each keyspace (let's say ks1: DC1, ks2: DC1, ks3: DC2) and would never fail > due to under-replicated keyspaces. > The issue with this approach (without src dc) is that, DC4 is getting picked > up during rebuild (as src), but DC4 does not have any data yet! > so, with the patch (ignore local dc flag), DC4 can be filtered out and let > the database pick up the right dc for each keyspace [from existing 3 DCs]. > -- this is what is the expectation after the patch. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630449#comment-17630449
]
Brandon Williams edited comment on CASSANDRA-17928 at 11/8/22 8:58 PM:
---
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/701/workflows/a1093b26-9c80-455a-871c-da9493642571],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
was (Author: brandon.williams):
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/9ed384b9-3cc3-412c-8d53-391d594f02a9],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> 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)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by
[jira] [Commented] (CASSANDRA-18021) Flaky org.apache.cassandra.distributed.test.ReprepareTestOldBehaviour#testReprepareMixedVersionWithoutReset
[
https://issues.apache.org/jira/browse/CASSANDRA-18021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630606#comment-17630606
]
Stefan Miklosovic commented on CASSANDRA-18021:
---
I hit it in 3.11 (as mentioned in description). Thanks for verifying for 4.1.
Not sure what the problem is with renaming. I will double check this upon
building CASSANDRA-17964 for 4.1 branch in Circle.
If not reproducible for 4.1, that is one problem less but I think it needs to
be still addressed for 3.11, even not so important right now.
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1540/workflows/56bf9387-0209-4510-8cc3-6ee24d74608f/jobs/6979
> Flaky
> org.apache.cassandra.distributed.test.ReprepareTestOldBehaviour#testReprepareMixedVersionWithoutReset
> ---
>
> Key: CASSANDRA-18021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18021
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
>
> {code:java}
> testReprepareMixedVersionWithoutReset
> com.datastax.driver.core.exceptions.InvalidQueryException: MD5 hash
> collision: query with the same MD5 hash was already prepared.
> Existing: ''
> at
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
> at
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> at
> com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:98)
> at
> org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest.testReprepareMixedVersionWithoutReset(ReprepareOldBehaviourTest.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: MD5
> hash collision: query with the same MD5 hash was already prepared.
> Existing: ''
> at
> com.datastax.driver.core.Responses$Error.asException(Responses.java:136)
> at
> com.datastax.driver.core.SessionManager$4.apply(SessionManager.java:220)
> at
> com.datastax.driver.core.SessionManager$4.apply(SessionManager.java:196)
> at
> com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:906)
> at com.google.common.util.concurrent.Futures$1$1.run(Futures.java:635)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
[jira] [Updated] (CASSANDRA-17768) Restore streaming_keep_alive_period functionality on the netty control streaming channel
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17768: --- Status: Ready to Commit (was: Review In Progress) > Restore streaming_keep_alive_period functionality on the netty control > streaming channel > > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-rc > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17768) Restore streaming_keep_alive_period functionality on the netty control streaming channel
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17768: --- Reviewers: Berenguer Blasi, Michael Semb Wever, Michael Semb Wever (was: Berenguer Blasi, Michael Semb Wever) Berenguer Blasi, Michael Semb Wever, Michael Semb Wever (was: Berenguer Blasi, Michael Semb Wever) Status: Review In Progress (was: Patch Available) > Restore streaming_keep_alive_period functionality on the netty control > streaming channel > > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-rc > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630565#comment-17630565 ] Derek Chen-Becker commented on CASSANDRA-17997: --- I think I'll defer the check on existing remotes just because that's more work for less impact > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17964: -- Status: Ready to Commit (was: Review In Progress) cool, sounds like we are good to move forward. [~stefan.miklosovic] if you plan to merge with them failing please create JIRAs first so they are not "unknown" errors for people; having a JIRA we can add to butler lets people not following know that their change may not have impacted as these tests are known failing > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17950: Authors: Derek Chen-Becker, Ekaterina Dimitrova (was: Derek Chen-Becker) > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeated jobs shouldn't appear on default config files
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18024: -- Summary: Circle repeated jobs shouldn't appear on default config files (was: Circle repeat jobs are always triggered even if not necessary) > Circle repeated jobs shouldn't appear on default config files > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1-beta2, 4.2 > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18024: -- Fix Version/s: 3.0.29 3.11.15 4.0.8 4.1-beta2 4.2 (was: 3.0.x) (was: 4.x) (was: 3.11.x) (was: 4.0.x) (was: 4.1.x) Since Version: 3.0.28 Source Control Link: https://github.com/apache/cassandra/commit/955231cacfc2732dd1fd4275049e224ab220d107 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1-beta2, 4.2 > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630552#comment-17630552 ] Andres de la Peña commented on CASSANDRA-18024: --- Committed to 3.0 as [955231cacfc2732dd1fd4275049e224ab220d107|https://github.com/apache/cassandra/commit/955231cacfc2732dd1fd4275049e224ab220d107] and merged to [3.11|https://github.com/apache/cassandra/commit/7b7762826e367b2a82ba1e99b12f8f19c583b920], [4.0|https://github.com/apache/cassandra/commit/cea850d67d5b726fe7ca9fef39c8578b46210155], [4.1|https://github.com/apache/cassandra/commit/6f431c13a6694173b12c62770b889ad09b9598b4] and [trunk|https://github.com/apache/cassandra/commit/af3eea7558e4da3976def20ac78070e79f8165f3]. Thanks for the reviews. > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18024: -- Status: Ready to Commit (was: Review In Progress) > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: CircleCI: Remove repeated jobs from default LOWRES, MIDRES and HIGHRES files
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.0 by this push: new 955231cacf CircleCI: Remove repeated jobs from default LOWRES, MIDRES and HIGHRES files 955231cacf is described below commit 955231cacfc2732dd1fd4275049e224ab220d107 Author: Andrés de la Peña AuthorDate: Tue Nov 8 13:27:49 2022 + CircleCI: Remove repeated jobs from default LOWRES, MIDRES and HIGHRES files patch by Andrés de la Peña; reviewed by Berenguer Blasi and Ekaterina Dimitrova for CASSANDRA-18024 --- .circleci/config.yml.HIGHRES | 81 - .circleci/config.yml.LOWRES | 81 - .circleci/config.yml.MIDRES | 81 - .circleci/generate.sh| 87 +--- 4 files changed, 50 insertions(+), 280 deletions(-) diff --git a/.circleci/config.yml.HIGHRES b/.circleci/config.yml.HIGHRES index 3ce70cd0bc..c5f23bd782 100644 --- a/.circleci/config.yml.HIGHRES +++ b/.circleci/config.yml.HIGHRES @@ -2390,48 +2390,24 @@ workflows: requires: - start_j8_unit_tests - build -- start_j8_unit_tests_repeat: -type: approval -- j8_unit_tests_repeat: -requires: -- start_j8_unit_tests_repeat -- build - start_j8_jvm_dtests: type: approval - j8_jvm_dtests: requires: - start_j8_jvm_dtests - build -- start_j8_jvm_dtests_repeat: -type: approval -- j8_jvm_dtests_repeat: -requires: -- start_j8_jvm_dtests_repeat -- build - start_utests_long: type: approval - utests_long: requires: - start_utests_long - build -- start_utests_long_repeat: -type: approval -- utests_long_repeat: -requires: -- start_utests_long_repeat -- build - start_utests_compression: type: approval - utests_compression: requires: - start_utests_compression - build -- start_utests_compression_repeat: -type: approval -- utests_compression_repeat: -requires: -- start_utests_compression_repeat -- build - start_j8_dtest_jars_build: type: approval - j8_dtest_jars_build: @@ -2444,54 +2420,24 @@ workflows: requires: - start_jvm_upgrade_dtests - j8_dtest_jars_build -- start_jvm_upgrade_dtests_repeat: -type: approval -- j8_jvm_upgrade_dtests_repeat: -requires: -- start_jvm_upgrade_dtests_repeat -- j8_dtest_jars_build - start_j8_dtests: type: approval - j8_dtests: requires: - start_j8_dtests - build -- start_j8_dtests_repeat: -type: approval -- j8_dtests_repeat: -requires: -- start_j8_dtests_repeat -- build - start_j8_dtests_vnode: type: approval - j8_dtests_vnode: requires: - start_j8_dtests_vnode - build -- start_j8_dtests_vnode_repeat: -type: approval -- j8_dtests_vnode_repeat: -requires: -- start_j8_dtests_vnode_repeat -- build - start_j8_upgrade_dtests: type: approval - j8_upgrade_dtests: requires: - start_j8_upgrade_dtests - build -- start_j8_upgrade_dtests_repeat: -type: approval -- j8_upgrade_dtests_repeat: -requires: -- start_j8_upgrade_dtests_repeat -- build -- start_j8_repeated_ant_test: -type: approval -- j8_repeated_ant_test: -requires: -- start_j8_repeated_ant_test -- build pre-commit_tests: jobs: - start_pre-commit_tests: @@ -2502,35 +2448,21 @@ workflows: - j8_unit_tests: requires: - build -- j8_unit_tests_repeat: -requires: -- build - j8_jvm_dtests: requires: - build -- j8_jvm_dtests_repeat: -requires: -- build - start_utests_long: type: approval - utests_long: requires: - start_utests_long - build -- utests_long_repeat: -requires: -- start_utests_long -- build - start_utests_compression: type: approval - utests_compression: requires: - start_utests_compression - build -- utests_compression_repeat: -requires: -- start_utests_compression -- build - start_jvm_upgrade_dtests: type: approval - j8_dtest_jars_build: @@ -2540,28 +2472,15 @@ workflows: - j8_jvm_upgrade_dtests: requires: - j8_dtest_jars_build -- j8_jvm_upgrade_dtests_repeat: -
[cassandra] branch cassandra-4.0 updated (7dbbe6907b -> cea850d67d)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 7dbbe6907b CircleCI: Fix j11_utests_fqltool executor new 955231cacf CircleCI: Remove repeated jobs from default LOWRES, MIDRES and HIGHRES files new 7b7762826e Merge branch 'cassandra-3.0' into cassandra-3.11 new cea850d67d Merge branch 'cassandra-3.11' into cassandra-4.0 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config.yml.HIGHRES | 315 --- .circleci/config.yml.LOWRES | 315 --- .circleci/config.yml.MIDRES | 315 --- .circleci/generate.sh| 113 +--- 4 files changed, 63 insertions(+), 995 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (f9b2cd6f3f -> 7b7762826e)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from f9b2cd6f3f Merge branch 'cassandra-3.0' into cassandra-3.11 new 955231cacf CircleCI: Remove repeated jobs from default LOWRES, MIDRES and HIGHRES files new 7b7762826e Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config.yml.HIGHRES | 104 --- .circleci/config.yml.LOWRES | 104 --- .circleci/config.yml.MIDRES | 104 --- .circleci/generate.sh| 95 ++- 4 files changed, 54 insertions(+), 353 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 6f431c13a6694173b12c62770b889ad09b9598b4 Merge: a805e32675 cea850d67d Author: Andrés de la Peña AuthorDate: Tue Nov 8 17:49:50 2022 + Merge branch 'cassandra-4.0' into cassandra-4.1 .circleci/config.yml.HIGHRES | 342 --- .circleci/config.yml.LOWRES | 342 --- .circleci/config.yml.MIDRES | 342 --- .circleci/generate.sh| 121 --- 4 files changed, 67 insertions(+), 1080 deletions(-) diff --cc .circleci/config.yml.HIGHRES index 2f411f18da,ea6ae1ead7..33445a7b95 --- a/.circleci/config.yml.HIGHRES +++ b/.circleci/config.yml.HIGHRES @@@ -6731,36 -8088,6 +6725,18 @@@ workflows requires: - start_j8_jvm_dtests - j8_build +- start_j8_jvm_dtests_vnode: +type: approval +- j8_jvm_dtests_vnode: +requires: +- start_j8_jvm_dtests_vnode +- j8_build - - start_j8_jvm_dtests_repeat: - type: approval - - j8_jvm_dtests_repeat: - requires: - - start_j8_jvm_dtests_repeat - - j8_build - - start_j8_jvm_dtests_vnode_repeat: - type: approval - - j8_jvm_dtests_vnode_repeat: - requires: - - start_j8_jvm_dtests_vnode_repeat - - j8_build +- start_j8_simulator_dtests: +type: approval +- j8_simulator_dtests: +requires: +- start_j8_simulator_dtests +- j8_build - - start_j8_simulator_dtests_repeat: - type: approval - - j8_simulator_dtests_repeat: - requires: - - start_j8_simulator_dtests_repeat - - j8_build - start_j8_cqlshlib_tests: type: approval - j8_cqlshlib_tests: @@@ -7059,27 -8276,9 +6909,15 @@@ - j8_unit_tests: requires: - j8_build - - j8_unit_tests_repeat: - requires: - - j8_build +- j8_simulator_dtests: +requires: +- j8_build - - j8_simulator_dtests_repeat: - requires: - - j8_build - j8_jvm_dtests: requires: - j8_build - - j8_jvm_dtests_repeat: - requires: - - j8_build +- j8_jvm_dtests_vnode: +requires: +- j8_build - - j8_jvm_dtests_vnode_repeat: - requires: - - j8_build - j8_cqlshlib_tests: requires: - j8_build @@@ -7225,23 -8365,13 +7004,13 @@@ - j11_dtests_vnode: requires: - j8_build - - j11_dtests_vnode_repeat: - requires: - - j8_build -- start_upgrade_tests: +- start_upgrade_dtests: type: approval - j8_upgrade_dtests: requires: - j8_build -- start_upgrade_tests -- j8_cqlsh-dtests-py2-with-vnodes: +- start_upgrade_dtests - - j8_upgrade_dtests_repeat: - requires: - - j8_build - - start_upgrade_dtests +- j8_cqlsh_dtests_py3: requires: - j8_build - j8_cqlsh_dtests_py3_vnode: @@@ -7290,24 -8426,6 +7053,12 @@@ requires: - start_j11_jvm_dtests - j11_build +- start_j11_jvm_dtests_vnode: +type: approval +- j11_jvm_dtests_vnode: +requires: +- start_j11_jvm_dtests_vnode +- j11_build - - start_j11_jvm_dtests_repeat: - type: approval - - j11_jvm_dtests_repeat: - requires: - - start_j11_jvm_dtests_repeat - - j11_build - - start_j11_jvm_dtests_vnode_repeat: - type: approval - - j11_jvm_dtests_vnode_repeat: - requires: - - start_j11_jvm_dtests_vnode_repeat - - j11_build - start_j11_cqlshlib_tests: type: approval - j11_cqlshlib_tests: @@@ -7447,19 -8519,10 +7144,10 @@@ - j11_jvm_dtests: requires: - j11_build - - j11_jvm_dtests_repeat: - requires: - - j11_build -- j11_cqlshlib_tests: +- j11_jvm_dtests_vnode: requires: - j11_build - - j11_jvm_dtests_vnode_repeat: - requires: - - j11_build -- j11_jvm_dtests: +- j11_cqlshlib_tests: requires: - j11_build - j11_cqlshlib_tests: @@@ -7471,13 -8534,7 +7159,7 @@@ - j11_dtests_vnode: requires: - j11_build - - j11_dtests_vnode_repeat: - requires: - - j11_build -- j11_cqlsh-dtests-py2-with-vnodes: +- j11_cqlsh_dtests_py3: requires: - j11_build - j11_cqlsh_dtests_py3_vnode: diff --cc .circleci/config.yml.LOWRES index 33923d8e69,ca564102a1..64d2e8f9a9 --- a/.circleci/config.yml.LOWRES +++ b/.circleci/config.yml.LOWRES @@@ -6731,36 -8088,6 +6725,18 @@@
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit cea850d67d5b726fe7ca9fef39c8578b46210155 Merge: 7dbbe6907b 7b7762826e Author: Andrés de la Peña AuthorDate: Tue Nov 8 17:49:06 2022 + Merge branch 'cassandra-3.11' into cassandra-4.0 .circleci/config.yml.HIGHRES | 315 --- .circleci/config.yml.LOWRES | 315 --- .circleci/config.yml.MIDRES | 315 --- .circleci/generate.sh| 113 +--- 4 files changed, 63 insertions(+), 995 deletions(-) diff --cc .circleci/config.yml.HIGHRES index e027af8dd6,5c55e714c8..ea6ae1ead7 --- a/.circleci/config.yml.HIGHRES +++ b/.circleci/config.yml.HIGHRES @@@ -8081,187 -2979,37 +8081,97 @@@ workflows - j8_unit_tests: requires: - start_j8_unit_tests -- build +- j8_build - - start_j8_unit_tests_repeat: - type: approval - - j8_unit_tests_repeat: - requires: - - start_j8_unit_tests_repeat - - j8_build - start_j8_jvm_dtests: type: approval - j8_jvm_dtests: requires: - start_j8_jvm_dtests -- build -- start_utests_long: +- j8_build - - start_j8_jvm_dtests_repeat: - type: approval - - j8_jvm_dtests_repeat: - requires: - - start_j8_jvm_dtests_repeat - - j8_build +- start_j8_cqlshlib_tests: type: approval -- utests_long: +- j8_cqlshlib_tests: requires: -- start_utests_long -- build -- start_utests_cdc: +- start_j8_cqlshlib_tests +- j8_build +- start_j11_unit_tests: type: approval -- utests_cdc: +- j11_unit_tests: requires: -- start_utests_cdc -- build -- start_utests_compression: +- start_j11_unit_tests +- j8_build - - start_j11_unit_tests_repeat: - type: approval - - j11_unit_tests_repeat: - requires: - - start_j11_unit_tests_repeat - - j8_build +- start_j8_utests_long: type: approval -- utests_compression: +- j8_utests_long: requires: -- start_utests_compression -- build -- start_utests_stress: +- start_j8_utests_long +- j8_build +- start_j11_utests_long: type: approval -- utests_stress: +- j11_utests_long: requires: -- start_utests_stress -- build +- start_j11_utests_long +- j8_build - - start_j8_utests_long_repeat: - type: approval - - j8_utests_long_repeat: - requires: - - start_j8_utests_long_repeat - - j8_build - - start_j11_utests_long_repeat: - type: approval - - j11_utests_long_repeat: - requires: - - start_j11_utests_long_repeat - - j8_build +- start_j8_utests_cdc: +type: approval +- j8_utests_cdc: +requires: +- start_j8_utests_cdc +- j8_build +- start_j11_utests_cdc: +type: approval +- j11_utests_cdc: +requires: +- start_j11_utests_cdc +- j8_build - - start_j8_utests_cdc_repeat: - type: approval - - j8_utests_cdc_repeat: - requires: - - start_j8_utests_cdc_repeat - - j8_build - - start_j11_utests_cdc_repeat: - type: approval - - j11_utests_cdc_repeat: - requires: - - start_j11_utests_cdc_repeat - - j8_build +- start_j8_utests_compression: +type: approval +- j8_utests_compression: +requires: +- start_j8_utests_compression +- j8_build +- start_j11_utests_compression: +type: approval +- j11_utests_compression: +requires: +- start_j11_utests_compression +- j8_build - - start_j8_utests_compression_repeat: - type: approval - - j8_utests_compression_repeat: - requires: - - start_j8_utests_compression_repeat - - j8_build - - start_j11_utests_compression_repeat: - type: approval - - j11_utests_compression_repeat: - requires: - - start_j11_utests_compression_repeat - - j8_build +- start_j8_utests_stress: +type: approval +- j8_utests_stress: +requires: +- start_j8_utests_stress +- j8_build +- start_j11_utests_stress: +type: approval +- j11_utests_stress: +requires: +- start_j11_utests_stress +- j8_build - - start_j8_utests_stress_repeat: - type: approval - - j8_utests_stress_repeat: - requires: - - start_j8_utests_stress_repeat - -
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit af3eea7558e4da3976def20ac78070e79f8165f3 Merge: 9490f9667d 6f431c13a6 Author: Andrés de la Peña AuthorDate: Tue Nov 8 17:50:32 2022 + Merge branch 'cassandra-4.1' into trunk .circleci/config.yml.HIGHRES | 372 --- .circleci/config.yml.LOWRES | 372 --- .circleci/config.yml.MIDRES | 372 --- .circleci/generate.sh| 125 --- 4 files changed, 69 insertions(+), 1172 deletions(-) diff --cc .circleci/config.yml.HIGHRES index b620263dc7,33445a7b95..56d16623a8 --- a/.circleci/config.yml.HIGHRES +++ b/.circleci/config.yml.HIGHRES @@@ -7255,42 -6785,6 +7201,18 @@@ workflows requires: - start_j11_utests_compression - j8_build - - start_j8_utests_compression_repeat: - type: approval - - j8_utests_compression_repeat: - requires: - - start_j8_utests_compression_repeat - - j8_build - - start_j11_utests_compression_repeat: - type: approval - - j11_utests_compression_repeat: - requires: - - start_j11_utests_compression_repeat - - j8_build +- start_j8_utests_trie: +type: approval +- j8_utests_trie: +requires: +- start_j8_utests_trie +- j8_build +- start_j11_utests_trie: +type: approval +- j11_utests_trie: +requires: +- start_j11_utests_trie +- j8_build - - start_j8_utests_trie_repeat: - type: approval - - j8_utests_trie_repeat: - requires: - - start_j8_utests_trie_repeat - - j8_build - - start_j11_utests_trie_repeat: - type: approval - - j11_utests_trie_repeat: - requires: - - start_j11_utests_trie_repeat - - j8_build - start_j8_utests_stress: type: approval - j8_utests_stress: @@@ -7575,32 -6954,6 +7382,16 @@@ requires: - start_utests_compression - j8_build - - j8_utests_compression_repeat: - requires: - - start_utests_compression - - j8_build - - j11_utests_compression_repeat: - requires: - - start_utests_compression - - j8_build +- start_utests_trie: +type: approval +- j8_utests_trie: +requires: +- start_utests_trie +- j8_build +- j11_utests_trie: +requires: +- start_utests_trie +- j8_build - - j8_utests_trie_repeat: - requires: - - start_utests_trie - - j8_build - - j11_utests_trie_repeat: - requires: - - start_utests_trie - - j8_build - start_utests_stress: type: approval - j8_utests_stress: @@@ -7832,24 -7113,6 +7551,12 @@@ requires: - start_j11_utests_compression - j11_build - - start_j11_utests_compression_repeat: - type: approval - - j11_utests_compression_repeat: - requires: - - start_j11_utests_compression_repeat - - j11_build +- start_j11_utests_trie: +type: approval +- j11_utests_trie: +requires: +- start_j11_utests_trie +- j11_build - - start_j11_utests_trie_repeat: - type: approval - - j11_utests_trie_repeat: - requires: - - start_j11_utests_trie_repeat - - j11_build - start_j11_utests_stress: type: approval - j11_utests_stress: @@@ -7985,20 -7189,6 +7633,12 @@@ requires: - start_utests_compression - j11_build - - j11_utests_compression_repeat: - requires: - - start_utests_compression - - j11_build +- start_utests_trie: +type: approval +- j11_utests_trie: +requires: +- start_utests_trie +- j11_build - - j11_utests_trie_repeat: - requires: - - start_utests_trie - - j11_build - start_utests_stress: type: approval - j11_utests_stress: diff --cc .circleci/config.yml.LOWRES index ef01153a21,64d2e8f9a9..40f3188660 --- a/.circleci/config.yml.LOWRES +++ b/.circleci/config.yml.LOWRES @@@ -7255,42 -6785,6 +7201,18 @@@ workflows requires: - start_j11_utests_compression - j8_build - - start_j8_utests_compression_repeat: - type: approval - - j8_utests_compression_repeat: - requires: - - start_j8_utests_compression_repeat - - j8_build - - start_j11_utests_compression_repeat: - type: approval - - j11_utests_compression_repeat: - requires: - - start_j11_utests_compression_repeat - - j8_build +- start_j8_utests_trie: +
[cassandra] branch trunk updated (9490f9667d -> af3eea7558)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 9490f9667d Merge branch 'cassandra-4.1' into trunk new 955231cacf CircleCI: Remove repeated jobs from default LOWRES, MIDRES and HIGHRES files new 7b7762826e Merge branch 'cassandra-3.0' into cassandra-3.11 new cea850d67d Merge branch 'cassandra-3.11' into cassandra-4.0 new 6f431c13a6 Merge branch 'cassandra-4.0' into cassandra-4.1 new af3eea7558 Merge branch 'cassandra-4.1' into trunk The 5 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config.yml.HIGHRES | 372 --- .circleci/config.yml.LOWRES | 372 --- .circleci/config.yml.MIDRES | 372 --- .circleci/generate.sh| 125 --- 4 files changed, 69 insertions(+), 1172 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 7b7762826e367b2a82ba1e99b12f8f19c583b920 Merge: f9b2cd6f3f 955231cacf Author: Andrés de la Peña AuthorDate: Tue Nov 8 17:48:29 2022 + Merge branch 'cassandra-3.0' into cassandra-3.11 .circleci/config.yml.HIGHRES | 104 --- .circleci/config.yml.LOWRES | 104 --- .circleci/config.yml.MIDRES | 104 --- .circleci/generate.sh| 95 ++- 4 files changed, 54 insertions(+), 353 deletions(-) diff --cc .circleci/config.yml.HIGHRES index 2f1e95a979,c5f23bd782..5c55e714c8 --- a/.circleci/config.yml.HIGHRES +++ b/.circleci/config.yml.HIGHRES @@@ -3004,48 -2402,12 +2992,24 @@@ workflows requires: - start_utests_long - build - - start_utests_long_repeat: - type: approval - - utests_long_repeat: - requires: - - start_utests_long_repeat - - build +- start_utests_cdc: +type: approval +- utests_cdc: +requires: +- start_utests_cdc +- build - - start_utests_cdc_repeat: - type: approval - - utests_cdc_repeat: - requires: - - start_utests_cdc_repeat - - build - start_utests_compression: type: approval - utests_compression: requires: - start_utests_compression - build - - start_utests_compression_repeat: - type: approval - - utests_compression_repeat: - requires: - - start_utests_compression_repeat - - build +- start_utests_stress: +type: approval +- utests_stress: +requires: +- start_utests_stress +- build - - start_utests_stress_repeat: - type: approval - - utests_stress_repeat: - requires: - - start_utests_stress_repeat - - build - start_j8_dtest_jars_build: type: approval - j8_dtest_jars_build: @@@ -3082,30 -2432,12 +3034,12 @@@ requires: - start_j8_dtests_vnode - build - - start_j8_dtests_vnode_repeat: - type: approval - - j8_dtests_vnode_repeat: - requires: - - start_j8_dtests_vnode_repeat - - build -- start_j8_upgrade_dtests: +- start_upgrade_dtests: type: approval - j8_upgrade_dtests: requires: -- start_j8_upgrade_dtests +- start_upgrade_dtests - build - - start_j8_upgrade_dtests_repeat: - type: approval - - j8_upgrade_dtests_repeat: - requires: - - start_j8_upgrade_dtests_repeat - - build - - start_j8_repeated_ant_test: - type: approval - - j8_repeated_ant_test: - requires: - - start_j8_repeated_ant_test - - build pre-commit_tests: jobs: - start_pre-commit_tests: @@@ -3131,40 -2457,12 +3059,24 @@@ requires: - start_utests_long - build - - utests_long_repeat: - requires: - - start_utests_long - - build +- start_utests_cdc: +type: approval +- utests_cdc: +requires: +- start_utests_cdc +- build - - utests_cdc_repeat: - requires: - - start_utests_cdc - - build - start_utests_compression: type: approval - utests_compression: requires: - start_utests_compression - build - - utests_compression_repeat: - requires: - - start_utests_compression - - build +- start_utests_stress: +type: approval +- utests_stress: +requires: +- start_utests_stress +- build - - utests_stress_repeat: - requires: - - start_utests_stress - - build - start_jvm_upgrade_dtests: type: approval - j8_dtest_jars_build: @@@ -3183,22 -2478,9 +3092,9 @@@ - j8_dtests_vnode: requires: - build - - j8_dtests_vnode_repeat: - requires: - - build -- start_upgrade_dtests: +- start_upgrade_tests: type: approval - j8_upgrade_dtests: requires: -- start_upgrade_dtests +- start_upgrade_tests - build - - j8_upgrade_dtests_repeat: - requires: - - start_upgrade_tests - - build - - j8_repeated_ant_test: - requires: - - build diff --cc .circleci/config.yml.LOWRES index dbfc0855dd,1141a9c923..30046af3ca --- a/.circleci/config.yml.LOWRES +++ b/.circleci/config.yml.LOWRES @@@ -3004,48 -2402,12 +2992,24 @@@ workflows requires: - start_utests_long - build -
[cassandra] branch cassandra-4.1 updated (a805e32675 -> 6f431c13a6)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from a805e32675 Move Schema.FORCE_LOAD_KEYSPACES and Schema.FORCE_LOAD_KEYSPACES_PROP to CassandraRelevantProps new 955231cacf CircleCI: Remove repeated jobs from default LOWRES, MIDRES and HIGHRES files new 7b7762826e Merge branch 'cassandra-3.0' into cassandra-3.11 new cea850d67d Merge branch 'cassandra-3.11' into cassandra-4.0 new 6f431c13a6 Merge branch 'cassandra-4.0' into cassandra-4.1 The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config.yml.HIGHRES | 342 --- .circleci/config.yml.LOWRES | 342 --- .circleci/config.yml.MIDRES | 342 --- .circleci/generate.sh| 121 --- 4 files changed, 67 insertions(+), 1080 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630449#comment-17630449
]
Brandon Williams edited comment on CASSANDRA-17928 at 11/8/22 5:53 PM:
---
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/9ed384b9-3cc3-412c-8d53-391d594f02a9],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f]|
was (Author: brandon.williams):
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f/jobs/7608]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/9ed384b9-3cc3-412c-8d53-391d594f02a9],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/28d800ad-9f19-4853-a8d8-88c2c20dbb6e/jobs/7522]
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> 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)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[cassandra-website] branch asf-staging updated (19b2a4fce -> aed729056)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 19b2a4fce generate docs for a67d0561 new aed729056 generate docs for a67d0561 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (19b2a4fce) \ N -- N -- N refs/heads/asf-staging (aed729056) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630449#comment-17630449
]
Brandon Williams edited comment on CASSANDRA-17928 at 11/8/22 5:43 PM:
---
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/97f32020-fc41-45ce-b8d4-a0e4cdfed84d],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/696/workflows/0b4f6404-3cb0-41ef-878b-0def1b845d2f/jobs/7608]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/9ed384b9-3cc3-412c-8d53-391d594f02a9],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/28d800ad-9f19-4853-a8d8-88c2c20dbb6e/jobs/7522]
was (Author: brandon.williams):
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/d94b6900-d568-4f14-a36d-5477eb98aafe],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/d2f2ee3b-5364-45fc-b77e-b29075c94930],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/c1c1c480-7659-4dda-8a24-719975151344]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/9ed384b9-3cc3-412c-8d53-391d594f02a9],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/28d800ad-9f19-4853-a8d8-88c2c20dbb6e/jobs/7522]
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> 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)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To
[jira] [Commented] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630539#comment-17630539
]
Andres de la Peña commented on CASSANDRA-17928:
---
The workaround looks good, +1 if it survives the run.
Nit: {{initThread}} can be a local variable now that is not used in {{setUp}}
anymore.
Tip: For trunk or any other additional run, if you rebase the branches you can
benefit from CASSANDRA-18000 to get faster repeated runs.
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> 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)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630527#comment-17630527
]
Andres de la Peña commented on CASSANDRA-18024:
---
Thanks for checking on this.
{quote}
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}
Fixed. Actually the links on the table were correct, but I forgot to push the
{{18024-3.0}}, etc. patch branches. The CI runs point to separate branches
named {{18024-3.0-test-low}}, {{18024-3.0-test-multiplexer}}, etc. that are
forked from the patch branches.
{quote}
CASSANDRA-18012 - I believe this is the ticket we can move this topic
discussion to. So far paid and free is what was agreed (instead of MIDRES,
HIGHRES, LOWRES)
{quote}
Yep, we can follow the discussion there. So far it's looking like the days of
the multiple default config files are numbered.
> Circle repeat jobs are always triggered even if not necessary
> -
>
> Key: CASSANDRA-18024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18024
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> It seems that when pushing a PR, the auto multiplexing of new tests triggers
> all multiplexing jobs, even if there are no tests present for that job.
> That is wasteful as it means spinning up many nodes etc for nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18021) Flaky org.apache.cassandra.distributed.test.ReprepareTestOldBehaviour#testReprepareMixedVersionWithoutReset
[
https://issues.apache.org/jira/browse/CASSANDRA-18021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630521#comment-17630521
]
Brandon Williams commented on CASSANDRA-18021:
--
This [doesn't occur on
4.1|https://app.circleci.com/pipelines/github/driftx/cassandra/695/workflows/c9cc5828-a5ad-4730-ae8a-28a7c369ba2a/jobs/7601/tests],
but there was a problem copying the results:
{noformat}
mv: cannot move
'build/test/logs//org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest'
to
'/tmp/results/repeated_utests/logs/passes/1/org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest':
File exists
Exited with code exit status 1
{noformat}
I'm not sure what's going on there, but the test does pass so I don't think we
need to block rc.
> Flaky
> org.apache.cassandra.distributed.test.ReprepareTestOldBehaviour#testReprepareMixedVersionWithoutReset
> ---
>
> Key: CASSANDRA-18021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18021
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1-rc
>
>
> {code:java}
> testReprepareMixedVersionWithoutReset
> com.datastax.driver.core.exceptions.InvalidQueryException: MD5 hash
> collision: query with the same MD5 hash was already prepared.
> Existing: ''
> at
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
> at
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> at
> com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:98)
> at
> org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest.testReprepareMixedVersionWithoutReset(ReprepareOldBehaviourTest.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: MD5
> hash collision: query with the same MD5 hash was already prepared.
> Existing: ''
> at
> com.datastax.driver.core.Responses$Error.asException(Responses.java:136)
> at
> com.datastax.driver.core.SessionManager$4.apply(SessionManager.java:220)
> at
> com.datastax.driver.core.SessionManager$4.apply(SessionManager.java:196)
> at
> com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:906)
> at com.google.common.util.concurrent.Futures$1$1.run(Futures.java:635)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
>
[jira] [Updated] (CASSANDRA-18021) Flaky org.apache.cassandra.distributed.test.ReprepareTestOldBehaviour#testReprepareMixedVersionWithoutReset
[
https://issues.apache.org/jira/browse/CASSANDRA-18021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18021:
-
Fix Version/s: 3.11.x
(was: 4.1-rc)
> Flaky
> org.apache.cassandra.distributed.test.ReprepareTestOldBehaviour#testReprepareMixedVersionWithoutReset
> ---
>
> Key: CASSANDRA-18021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18021
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
>
> {code:java}
> testReprepareMixedVersionWithoutReset
> com.datastax.driver.core.exceptions.InvalidQueryException: MD5 hash
> collision: query with the same MD5 hash was already prepared.
> Existing: ''
> at
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
> at
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> at
> com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:98)
> at
> org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest.testReprepareMixedVersionWithoutReset(ReprepareOldBehaviourTest.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: MD5
> hash collision: query with the same MD5 hash was already prepared.
> Existing: ''
> at
> com.datastax.driver.core.Responses$Error.asException(Responses.java:136)
> at
> com.datastax.driver.core.SessionManager$4.apply(SessionManager.java:220)
> at
> com.datastax.driver.core.SessionManager$4.apply(SessionManager.java:196)
> at
> com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:906)
> at com.google.common.util.concurrent.Futures$1$1.run(Futures.java:635)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> this throws:
> {code}
> lbp.setPrimary(firstContact);
> final PreparedStatement select = session.prepare(withKeyspace("SELECT * FROM
> %s.tbl")); /// THIS
> session.execute(select.bind());
> {code}
> I observed this in 3.11.
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/1540/workflows/56bf9387-0209-4510-8cc3-6ee24d74608f/jobs/6979
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630514#comment-17630514
]
Ekaterina Dimitrova commented on CASSANDRA-17950:
-
{quote}I'm afraid formatting has rendered this ilegible, is it "-" and "_",
right? I'll be fine doing that in a separate ticket.
{quote}
Ops, you are right, that's what it had to be.
{quote}Also, you'll hate me for this, but can we rename the
{{j8_cqlsh_dtests_offheap_py3}} jobs to {{{}j8_cqlsh_dtests_py3-offheap{}}}, so
it's consistent with {{{}j8_cqlsh_dtests_py3_vnode{}}}, where we have first the
Python version and then the config option? I'll be fine doing that in the
followup ticket for homogenizing names.
{quote}
No, no hate :D I changed them three times last night... naming is hard. hehe I
think what you suggested makes sense and it changes the new names so it doesn't
add noise. I will do that now before the patches.
{quote}Looks good to me, I think we can update the patches and run the other
resource configs.
{quote}
Thanks. Let's commit CASSANDRA-18024 and I will do them and add test runs.
Thank you for the quick review.
> Enable dtest-offheap in CircleCI
>
>
> Key: CASSANDRA-17950
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17950
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/dtest/python
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630510#comment-17630510
]
Ekaterina Dimitrova commented on CASSANDRA-18024:
-
{quote}I think I wouldn't be against removing them, and maybe provide only the
default {{config.yml}} that uses lowres for newcomers.
{quote}
CASSANDRA-18012 - I believe this is the ticket we can move this topic
discussion to. So far paid and free is what was agreed (instead of MIDRES,
HIGHRES, LOWRES)
> Circle repeat jobs are always triggered even if not necessary
> -
>
> Key: CASSANDRA-18024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18024
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> It seems that when pushing a PR, the auto multiplexing of new tests triggers
> all multiplexing jobs, even if there are no tests present for that job.
> That is wasteful as it means spinning up many nodes etc for nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18024: Authors: Andres de la Peña (was: Andres de la Peña, Ekaterina Dimitrova) > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630509#comment-17630509 ] Ekaterina Dimitrova commented on CASSANDRA-18024: - Just got a +1 offline from [~bereng] and leave the warning he suggested for a follow up ticket. Thanks > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630509#comment-17630509 ] Ekaterina Dimitrova edited comment on CASSANDRA-18024 at 11/8/22 4:22 PM: -- Just got a +1 offline from [~bereng]. We can leave the warning he suggested for a follow up ticket. Thanks was (Author: e.dimitrova): Just got a +1 offline from [~bereng] and leave the warning he suggested for a follow up ticket. Thanks > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18024: Reviewers: Berenguer Blasi, Ekaterina Dimitrova, Ekaterina Dimitrova (was: Berenguer Blasi) Berenguer Blasi, Ekaterina Dimitrova, Ekaterina Dimitrova (was: Berenguer Blasi, Ekaterina Dimitrova) Status: Review In Progress (was: Patch Available) > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18024: Authors: Andres de la Peña, Ekaterina Dimitrova (was: Andres de la Peña) > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18024: Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 4.x > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-18024: --- Assignee: Andres de la Peña (was: Ekaterina Dimitrova) > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-18024: --- Assignee: Ekaterina Dimitrova > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Ekaterina Dimitrova >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18024: Test and Documentation Plan: Patches and CI for all branches: ||Patch||Default LOWRES||Default MIDRES||Default HIGHRES||MIDRES multiplexer|| |[3.0 |https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:18024-3.0]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.0-test-low]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.0-test-mid]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.0-test-high]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.0-test-multiplexer]| |[3.11 |https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:18024-3.11]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.11-test-low]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.11-test-mid]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.11-test-high]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.11-test-multiplexer]| |[4.0 |https://github.com/apache/cassandra/compare/cassandra-4.0...adelapena:18024-4.0]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.0-test-low]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.0-test-mid]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.0-test-high]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.0-test-multiplexer]| |[4.1 |https://github.com/apache/cassandra/compare/cassandra-4.1...adelapena:18024-4.1]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.1-test-low]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.1-test-mid]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.1-test-high]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.1-test-multiplexer]| |[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:18024-trunk]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-low]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-mid]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-high]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-multiplexer]| Status: Patch Available (was: In Progress) > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18024: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: CI Discovered By: User Report Severity: Low Status: Open (was: Triage Needed) > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630494#comment-17630494 ] Andres de la Peña commented on CASSANDRA-17997: --- Thanks for the patch. The PR adds the -b option, but not the trickier check on the list of existing remotes. Are we going to do the latter here? I have left a few suggestions on the PR. > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630490#comment-17630490
]
Ekaterina Dimitrova edited comment on CASSANDRA-18024 at 11/8/22 3:38 PM:
--
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
I'd definitively do/discuss that in a separate ticket.
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI already went a long road compared to
where we were last year .
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine. (assuming I did not see
other custom changes in generate.sh in the other branches)
was (Author: e.dimitrova):
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
I'd definitively do/discuss that in a separate ticket.
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI already went a long road compared to
where we were
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630490#comment-17630490
]
Ekaterina Dimitrova edited comment on CASSANDRA-18024 at 11/8/22 3:38 PM:
--
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
I'd definitively do/discuss that in a separate ticket.
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI already went a long road compared to
where we were last year .
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine. (assuming I did not see
other custom changes in the other branches)
was (Author: e.dimitrova):
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
{quote}{quote} I'd definitively do/discuss that in a separate ticket.
{quote}{quote}
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI already went a long road compared to
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630490#comment-17630490
]
Ekaterina Dimitrova edited comment on CASSANDRA-18024 at 11/8/22 3:37 PM:
--
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
{quote}{quote} I'd definitively do/discuss that in a separate ticket.
{quote}{quote}
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI already went a long road compared to
where we were last year .
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine.
was (Author: e.dimitrova):
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
{quote}bq. I'd definitively do/discuss that in a separate ticket.
{quote}
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630490#comment-17630490
]
Ekaterina Dimitrova edited comment on CASSANDRA-18024 at 11/8/22 3:36 PM:
--
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
{quote}bq. I'd definitively do/discuss that in a separate ticket.
{quote}
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine.
was (Author: e.dimitrova):
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
I'd definitively do/discuss that in a separate ticket.
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I verified
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630490#comment-17630490
]
Ekaterina Dimitrova edited comment on CASSANDRA-18024 at 11/8/22 3:35 PM:
--
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update them for future
reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
I'd definitively do/discuss that in a separate ticket.
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine.
was (Author: e.dimitrova):
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
found them from CircleCI easily but you might want to update them for future
reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
{quote}{quote} I'd definitively do/discuss that in a separate ticket.
{quote}{quote}
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630490#comment-17630490
]
Ekaterina Dimitrova edited comment on CASSANDRA-18024 at 11/8/22 3:35 PM:
--
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
I'd definitively do/discuss that in a separate ticket.
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine.
was (Author: e.dimitrova):
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update them for future
reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
I'd definitively do/discuss that in a separate ticket.
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630490#comment-17630490
]
Ekaterina Dimitrova edited comment on CASSANDRA-18024 at 11/8/22 3:34 PM:
--
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
found them from CircleCI easily but you might want to update them for future
reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
{quote}{quote} I'd definitively do/discuss that in a separate ticket.
{quote}{quote}
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine.
was (Author: e.dimitrova):
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES. If someone wants to take advantage of those - they should
use generate.sh as described in the readme. Sounds neat and non-controversial
to me. Post-processing those 3 files instead of using the script sounds
terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
found them from CircleCI easily but you might want to update them for future
reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
{quote}bq. I'd definitively do/discuss that in a separate ticket.
{quote}
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630490#comment-17630490
]
Ekaterina Dimitrova commented on CASSANDRA-18024:
-
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES. If someone wants to take advantage of those - they should
use generate.sh as described in the readme. Sounds neat and non-controversial
to me. Post-processing those 3 files instead of using the script sounds
terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
found them from CircleCI easily but you might want to update them for future
reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
{quote}bq. I'd definitively do/discuss that in a separate ticket.
{quote}
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine.
> Circle repeat jobs are always triggered even if not necessary
> -
>
> Key: CASSANDRA-18024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18024
> Project: Cassandra
> Issue Type: Bug
>Reporter: Berenguer Blasi
>Priority: Normal
>
> It seems that when pushing a PR, the auto multiplexing of new tests triggers
> all multiplexing jobs, even if there are no tests present for that job.
> That is wasteful as it means spinning up many nodes etc for nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18025: - Bug Category: Parent values: Correctness(12982)Level 1 values: Transient Incorrect Response(12987) Complexity: Low Hanging Fruit Discovered By: User Report Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 4.2 Severity: Normal Status: Open (was: Triage Needed) > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
Israel Fruchter created CASSANDRA-18025: --- Summary: cassandra-stress: not all contact point are passed down to driver Key: CASSANDRA-18025 URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 Project: Cassandra Issue Type: Bug Components: Tool/stress Reporter: Israel Fruchter Seem like c-s is randomly selecting a node from the nodes passed down to it in the command line, and use that node as contact point to the driver. When using c-s together with other management operations (for example expending/shrinking the cluster), we can get into situation some of the nodes mentioned in the command line aren't reachable/available, and c-s instead of applying the best practice of having multiple contact points, pass down only one that can be unavailable and fail completely without trying any of the other nodes mentioned in the command line we just fixed that in our fork of cassandra-stress: [https://github.com/scylladb/scylla-tools-java/pull/314] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629799#comment-17629799 ] Stefan Miklosovic edited comment on CASSANDRA-17964 at 11/8/22 3:12 PM: I will be updating this comment as new branches and builds will be added. Important notes for 3.0 - I have updated reflections library to 0.10.2 (same as is in trunk). The reason for that was that when the scanning is happening in our Ant task, the version which is present in 3.0 currently (0.9.something) prints big debug log of reflection library which is unnecessary and it just pollutes the overall build logs. Moving to 0.10.2 is very simple, basically a drop-in replacement. 0.10.2 does not write out this log. 3.0 PR [https://github.com/apache/cassandra/pull/1981/files] Circle 3.0 [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1539/workflows/d18c175f-ecdc-47e8-b5e8-d2ea8b679dcb] Jenkins 3.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2063/] Circle 3.0 fails for me on dtests massively, I have never got a clean 3.0 build in Circle like ... _ever_. For that reason, as repeats are covered in circle, I built it in Jenkins too 3.11 PR [https://github.com/apache/cassandra/pull/1982] Jenkins [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2064/] Circle [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1540/workflows/56bf9387-0209-4510-8cc3-6ee24d74608f] 3.11 starts to fail on this: https://issues.apache.org/jira/browse/CASSANDRA-18021 4.0 branch https://github.com/instaclustr/cassandra/tree/CASSANDRA-17964-4.0-ant 4.0 jenkins https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2065/ 4.1 branch https://github.com/apache/cassandra/pull/1988 4.1 jenkins https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2068/ was (Author: smiklosovic): I will be updating this comment as new branches and builds will be added. Important notes for 3.0 - I have updated reflections library to 0.10.2 (same as is in trunk). The reason for that was that when the scanning is happening in our Ant task, the version which is present in 3.0 currently (0.9.something) prints big debug log of reflection library which is unnecessary and it just pollutes the overall build logs. Moving to 0.10.2 is very simple, basically a drop-in replacement. 0.10.2 does not write out this log. 3.0 PR [https://github.com/apache/cassandra/pull/1981/files] Circle 3.0 [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1539/workflows/d18c175f-ecdc-47e8-b5e8-d2ea8b679dcb] Jenkins 3.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2063/] Circle 3.0 fails for me on dtests massively, I have never got a clean 3.0 build in Circle like ... _ever_. For that reason, as repeats are covered in circle, I built it in Jenkins too 3.11 PR [https://github.com/apache/cassandra/pull/1982] Jenkins [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2064/] Circle [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1540/workflows/56bf9387-0209-4510-8cc3-6ee24d74608f] 3.11 starts to fail on this: https://issues.apache.org/jira/browse/CASSANDRA-18021 4.0 branch https://github.com/instaclustr/cassandra/tree/CASSANDRA-17964-4.0-ant 4.0 jenkins https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2065/ > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629799#comment-17629799 ] Stefan Miklosovic edited comment on CASSANDRA-17964 at 11/8/22 2:49 PM: I will be updating this comment as new branches and builds will be added. Important notes for 3.0 - I have updated reflections library to 0.10.2 (same as is in trunk). The reason for that was that when the scanning is happening in our Ant task, the version which is present in 3.0 currently (0.9.something) prints big debug log of reflection library which is unnecessary and it just pollutes the overall build logs. Moving to 0.10.2 is very simple, basically a drop-in replacement. 0.10.2 does not write out this log. 3.0 PR [https://github.com/apache/cassandra/pull/1981/files] Circle 3.0 [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1539/workflows/d18c175f-ecdc-47e8-b5e8-d2ea8b679dcb] Jenkins 3.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2063/] Circle 3.0 fails for me on dtests massively, I have never got a clean 3.0 build in Circle like ... _ever_. For that reason, as repeats are covered in circle, I built it in Jenkins too 3.11 PR [https://github.com/apache/cassandra/pull/1982] Jenkins [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2064/] Circle [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1540/workflows/56bf9387-0209-4510-8cc3-6ee24d74608f] 3.11 starts to fail on this: https://issues.apache.org/jira/browse/CASSANDRA-18021 4.0 branch https://github.com/instaclustr/cassandra/tree/CASSANDRA-17964-4.0-ant 4.0 jenkins https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2065/ was (Author: smiklosovic): I will be updating this comment as new branches and builds will be added. Important notes for 3.0 - I have updated reflections library to 0.10.2 (same as is in trunk). The reason for that was that when the scanning is happening in our Ant task, the version which is present in 3.0 currently (0.9.something) prints big debug log of reflection library which is unnecessary and it just pollutes the overall build logs. Moving to 0.10.2 is very simple, basically a drop-in replacement. 0.10.2 does not write out this log. 3.0 PR [https://github.com/apache/cassandra/pull/1981/files] Circle 3.0 [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1539/workflows/d18c175f-ecdc-47e8-b5e8-d2ea8b679dcb] Jenkins 3.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2063/] Circle 3.0 fails for me on dtests massively, I have never got a clean 3.0 build in Circle like ... _ever_. For that reason, as repeats are covered in circle, I built it in Jenkins too 3.11 PR [https://github.com/apache/cassandra/pull/1982] Jenkins [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2064/] Circle [https://app.circleci.com/pipelines/github/instaclustr/cassandra/1540/workflows/56bf9387-0209-4510-8cc3-6ee24d74608f] 3.11 starts to fail on this: https://issues.apache.org/jira/browse/CASSANDRA-18021 > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (12181e551 -> 19b2a4fce)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 12181e551 generate docs for a67d0561 new 19b2a4fce generate docs for a67d0561 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (12181e551) \ N -- N -- N refs/heads/asf-staging (19b2a4fce) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630471#comment-17630471
]
Andres de la Peña commented on CASSANDRA-17950:
---
Looks good to me, I think we can update the patches and run the other resource
configs.
{quote}I saw some inconsistencies in the names having both "{-}" and "{-}" in
the names and I decided to fix this In a different commit or even maybe in a
follow up ticket as otherwise things become extra noisy and super hard for
review.
{quote}
I'm afraid formatting has rendered this ilegible, is it "-" and "_", right?
I'll be fine doing that in a separate ticket.
Also, you'll hate me for this, but can we rename the
{{j8_cqlsh_dtests_offheap_py3}} jobs to {{{}j8_cqlsh_dtests_py3-offheap{}}}, so
it's consistent with {{{}j8_cqlsh_dtests_py3_vnode{}}}, where we have first the
Python version and then the config option? I'll be fine doing that in the
followup ticket for homogenizing names.
> Enable dtest-offheap in CircleCI
>
>
> Key: CASSANDRA-17950
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17950
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/dtest/python
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17915) Confusing error message when using ? with functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630453#comment-17630453
]
Brandon Williams commented on CASSANDRA-17915:
--
[~NateAdere] can you rebase this so the circle config is its own commit, and
squash the others into one?
> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
> which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can
> be matched by following signatures: system."castAsFloat" : (bigint) -> float,
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) ->
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" :
> (tinyint) -> float, system."castAsFloat" : (varint) -> float,
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint)
> -> float): use type casts to disambiguate
> {code}
> What we have to do is
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST
> to work in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630449#comment-17630449
]
Brandon Williams commented on CASSANDRA-17928:
--
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/d94b6900-d568-4f14-a36d-5477eb98aafe],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/d2f2ee3b-5364-45fc-b77e-b29075c94930],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/c1c1c480-7659-4dda-8a24-719975151344]|
|[4.1||https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/9ed384b9-3cc3-412c-8d53-391d594f02a9],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/28d800ad-9f19-4853-a8d8-88c2c20dbb6e/jobs/7522]
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> 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)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630449#comment-17630449
]
Brandon Williams edited comment on CASSANDRA-17928 at 11/8/22 2:26 PM:
---
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/d94b6900-d568-4f14-a36d-5477eb98aafe],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/d2f2ee3b-5364-45fc-b77e-b29075c94930],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/c1c1c480-7659-4dda-8a24-719975151344]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/9ed384b9-3cc3-412c-8d53-391d594f02a9],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/28d800ad-9f19-4853-a8d8-88c2c20dbb6e/jobs/7522]
was (Author: brandon.williams):
I ported this to 4.0 as well. CI is still running.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/d94b6900-d568-4f14-a36d-5477eb98aafe],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/d2f2ee3b-5364-45fc-b77e-b29075c94930],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/693/workflows/c1c1c480-7659-4dda-8a24-719975151344]|
|[4.1||https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/9ed384b9-3cc3-412c-8d53-391d594f02a9],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/7029bce2-ed30-4b93-831e-1efd831fc00f],
[30k|https://app.circleci.com/pipelines/github/driftx/cassandra/692/workflows/28d800ad-9f19-4853-a8d8-88c2c20dbb6e/jobs/7522]
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> 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)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe,
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630437#comment-17630437
]
Andres de la Peña commented on CASSANDRA-18024:
---
Thanks for the quick review. I have posted CI for the rest of the branches.
[~e.dimitrova] do you want to take a look? We should coordinate in which order
we merge to reduce rebase pains. This one is quite simple, I'd say.
{quote}wdyt about adding a job to configs that would fail with a message saying
'Caution: manually copying the file will skip auto multiplexing runs bla bla
bla? Please use generate.sh instead.'. Generate.sh could remove it. That would
protect us from the wall of green that didn't actually multiplex anything and
the other problems
{quote}
At the moment using those files is considered legitimate IMO, otherwise we
wouldn't have them. I think we shouldn't fail CI just to print a message that
the user might already be aware of. Not sure about how else we could print a
warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
Another question is whether we want to provide the default files with different
resource configs at all, or just make using the script mandatory. I think I
wouldn't be against removing them, and maybe provide only the default
{{config.yml}} that uses lowres for newcomers.
{quote}I can do that in another ticket if you're too far down the rabbit hole
with this one and don't want to redo the gazillion branches/files
{quote}
I'd definitively do/discuss that in a separate ticket.
> Circle repeat jobs are always triggered even if not necessary
> -
>
> Key: CASSANDRA-18024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18024
> Project: Cassandra
> Issue Type: Bug
>Reporter: Berenguer Blasi
>Priority: Normal
>
> It seems that when pushing a PR, the auto multiplexing of new tests triggers
> all multiplexing jobs, even if there are no tests present for that job.
> That is wasteful as it means spinning up many nodes etc for nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18013) Splitter sometimes creates different number of splits than requested
[
https://issues.apache.org/jira/browse/CASSANDRA-18013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630273#comment-17630273
]
Jacek Lewandowski edited comment on CASSANDRA-18013 at 11/8/22 1:54 PM:
||PR||j8||j11||
|[trunk|https://github.com/apache/cassandra/pull/1985]||
|[4.1|https://github.com/apache/cassandra/pull/1986]|[j8
(?)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/fa3cd055-763a-4db6-9106-c1ae3691cd02]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/306/workflows/2ec96e61-5593-4802-9ff1-33dd6a0bd562]|
|[4.0|https://github.com/apache/cassandra/pull/1987]|[j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]|
|[3.11|https://github.com/apache/cassandra/pull/1968]|[(/) - same failures as
on base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]||
was (Author: jlewandowski):
||PR||j8||j11||
|[trunk|https://github.com/apache/cassandra/pull/1985]||
|[4.1|https://github.com/apache/cassandra/pull/1986]||
|[4.0|https://github.com/apache/cassandra/pull/1987]|[j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]|
|[3.11|https://github.com/apache/cassandra/pull/1968]|[(/) - same failures as
on base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]||
> Splitter sometimes creates different number of splits than requested
>
>
> Key: CASSANDRA-18013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18013
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.11.x, 4.1, 4.2, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Splitter}} in some cases may produce one split more than requested. When it
> happens, it fails with assertion error when assertions are enabled.
> Test to reproduce the issue:
> {code:java}
> Splitter splitter = getSplitter(Murmur3Partitioner.instance);
> long lt = 0;
> long rt = 31;
> Range range = new
> Range<>(getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(lt)),
>
> getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(rt)));
> for (int i = 1; i <= (rt - lt); i++)
> {
> List splits = splitter.splitOwnedRanges(i,
> Arrays.asList(new Splitter.WeightedRange(1.0d, range)), false);
> logger.info("{} splits of {} are: {}", i, range, splits);
> Assertions.assertThat(splits).hasSize(i);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630421#comment-17630421 ] Andres de la Peña commented on CASSANDRA-18024: --- Patches and CI for all branches: ||Patch||Default LOWRES||Default MIDRES||Default HIGHRES||MIDRES multiplexer|| |[3.0 |https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:18024-3.0] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.0-test-low] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.0-test-mid] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.0-test-high] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.0-test-multiplexer]| |[3.11 |https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:18024-3.11]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.11-test-low] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.11-test-mid] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.11-test-high] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-3.11-test-multiplexer]| |[4.0 |https://github.com/apache/cassandra/compare/cassandra-4.0...adelapena:18024-4.0] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.0-test-low] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.0-test-mid] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.0-test-high] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.0-test-multiplexer]| |[4.1 |https://github.com/apache/cassandra/compare/cassandra-4.1...adelapena:18024-4.1] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.1-test-low] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.1-test-mid] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.1-test-high] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-4.1-test-multiplexer]| |[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:18024-trunk] |[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-low]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-mid]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-high]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-multiplexer]| > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug >Reporter: Berenguer Blasi >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18021) Flaky org.apache.cassandra.distributed.test.ReprepareTestOldBehaviour#testReprepareMixedVersionWithoutReset
[
https://issues.apache.org/jira/browse/CASSANDRA-18021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-18021:
--
Fix Version/s: 4.1-rc
> Flaky
> org.apache.cassandra.distributed.test.ReprepareTestOldBehaviour#testReprepareMixedVersionWithoutReset
> ---
>
> Key: CASSANDRA-18021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18021
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1-rc
>
>
> {code:java}
> testReprepareMixedVersionWithoutReset
> com.datastax.driver.core.exceptions.InvalidQueryException: MD5 hash
> collision: query with the same MD5 hash was already prepared.
> Existing: ''
> at
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
> at
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> at
> com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:98)
> at
> org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest.testReprepareMixedVersionWithoutReset(ReprepareOldBehaviourTest.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: MD5
> hash collision: query with the same MD5 hash was already prepared.
> Existing: ''
> at
> com.datastax.driver.core.Responses$Error.asException(Responses.java:136)
> at
> com.datastax.driver.core.SessionManager$4.apply(SessionManager.java:220)
> at
> com.datastax.driver.core.SessionManager$4.apply(SessionManager.java:196)
> at
> com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:906)
> at com.google.common.util.concurrent.Futures$1$1.run(Futures.java:635)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> this throws:
> {code}
> lbp.setPrimary(firstContact);
> final PreparedStatement select = session.prepare(withKeyspace("SELECT * FROM
> %s.tbl")); /// THIS
> session.execute(select.bind());
> {code}
> I observed this in 3.11.
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/1540/workflows/56bf9387-0209-4510-8cc3-6ee24d74608f/jobs/6979
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630415#comment-17630415 ] Berenguer Blasi commented on CASSANDRA-18024: - As far as removal of repeated jobs from the files goes the approach lgtm. I would still make default files fail with some message for extra safety. I can do that in another ticket if you're too far down the rabbit hole with this one and don't want to redo the gazillion branches/files. > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug >Reporter: Berenguer Blasi >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18013) Splitter sometimes creates different number of splits than requested
[
https://issues.apache.org/jira/browse/CASSANDRA-18013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630273#comment-17630273
]
Jacek Lewandowski edited comment on CASSANDRA-18013 at 11/8/22 1:16 PM:
||PR||j8||j11||
|[trunk|https://github.com/apache/cassandra/pull/1985]||
|[4.1|https://github.com/apache/cassandra/pull/1986]||
|[4.0|https://github.com/apache/cassandra/pull/1987]|[j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]|[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]|
|[3.11|https://github.com/apache/cassandra/pull/1968]|[(/) - same failures as
on base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]||
was (Author: jlewandowski):
[trunk|https://github.com/apache/cassandra/pull/1985]
[4.1|https://github.com/apache/cassandra/pull/1986]
[4.0|https://github.com/apache/cassandra/pull/1987] [j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]
[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]
[3.11|https://github.com/apache/cassandra/pull/1968] [(/) - same failures as on
base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]
> Splitter sometimes creates different number of splits than requested
>
>
> Key: CASSANDRA-18013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18013
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.11.x, 4.1, 4.2, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Splitter}} in some cases may produce one split more than requested. When it
> happens, it fails with assertion error when assertions are enabled.
> Test to reproduce the issue:
> {code:java}
> Splitter splitter = getSplitter(Murmur3Partitioner.instance);
> long lt = 0;
> long rt = 31;
> Range range = new
> Range<>(getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(lt)),
>
> getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(rt)));
> for (int i = 1; i <= (rt - lt); i++)
> {
> List splits = splitter.splitOwnedRanges(i,
> Arrays.asList(new Splitter.WeightedRange(1.0d, range)), false);
> logger.info("{} splits of {} are: {}", i, range, splits);
> Assertions.assertThat(splits).hasSize(i);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17997: -- Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18013) Splitter sometimes creates different number of splits than requested
[
https://issues.apache.org/jira/browse/CASSANDRA-18013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630273#comment-17630273
]
Jacek Lewandowski edited comment on CASSANDRA-18013 at 11/8/22 1:14 PM:
[trunk|https://github.com/apache/cassandra/pull/1985]
[4.1|https://github.com/apache/cassandra/pull/1986]
[4.0|https://github.com/apache/cassandra/pull/1987] [j8 (/) - the failed sets
were rerun without
errors|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/42ea925e-54cd-494e-957c-288fd8a45baa]
[j11
(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/305/workflows/ec7d5189-43e0-4eee-bdb1-68088223fb43]
[3.11|https://github.com/apache/cassandra/pull/1968] [(/) - same failures as on
base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]
was (Author: jlewandowski):
[trunk|https://github.com/apache/cassandra/pull/1985]
[4.1|https://github.com/apache/cassandra/pull/1986]
[4.0|https://github.com/apache/cassandra/pull/1987]
[3.11|https://github.com/apache/cassandra/pull/1968] [(/) - same failures as on
base
branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/304/workflows/e9462c50-dac7-43ca-af0f-c089f76c5455]
> Splitter sometimes creates different number of splits than requested
>
>
> Key: CASSANDRA-18013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18013
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.11.x, 4.1, 4.2, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Splitter}} in some cases may produce one split more than requested. When it
> happens, it fails with assertion error when assertions are enabled.
> Test to reproduce the issue:
> {code:java}
> Splitter splitter = getSplitter(Murmur3Partitioner.instance);
> long lt = 0;
> long rt = 31;
> Range range = new
> Range<>(getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(lt)),
>
> getWrappedToken(Murmur3Partitioner.instance, BigInteger.valueOf(rt)));
> for (int i = 1; i <= (rt - lt); i++)
> {
> List splits = splitter.splitOwnedRanges(i,
> Arrays.asList(new Splitter.WeightedRange(1.0d, range)), false);
> logger.info("{} splits of {} are: {}", i, range, splits);
> Assertions.assertThat(splits).hasSize(i);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17997: -- Reviewers: Andres de la Peña > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630405#comment-17630405 ] Andres de la Peña commented on CASSANDRA-18024: --- ||CI||Default LOWRES||Default MIDRES||Default HIGHRES||MIDRES multiplexer|| |[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:18024-trunk]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-low]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-mid]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-high]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-multiplexer]| > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug >Reporter: Berenguer Blasi >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630405#comment-17630405 ] Andres de la Peña edited comment on CASSANDRA-18024 at 11/8/22 1:06 PM: ||Patch||Default LOWRES||Default MIDRES||Default HIGHRES||MIDRES multiplexer|| |[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:18024-trunk]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-low]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-mid]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-high]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-multiplexer]| was (Author: adelapena): ||CI||Default LOWRES||Default MIDRES||Default HIGHRES||MIDRES multiplexer|| |[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:18024-trunk]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-low]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-mid]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-high]|[link|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=18024-trunk-test-multiplexer]| > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug >Reporter: Berenguer Blasi >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17878) Harden parsing of boolean values in CQL in PropertyDefinitions
[
https://issues.apache.org/jira/browse/CASSANDRA-17878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-17878:
--
Fix Version/s: 4.0.x
4.1.x
> Harden parsing of boolean values in CQL in PropertyDefinitions
> --
>
> Key: CASSANDRA-17878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17878
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There is currently this in PropertyDefinitions class as a pattern we use for
> testing a boolean value in cqlsh
> {code}
> private static final Pattern PATTERN_POSITIVE =
> Pattern.compile("(1|true|yes)");
> {code}
> This might be source of mistakes and typos. For example, if a user does, for
> example:
> {code}
> ALTER TABLE ks.tb WITH cdc = tru;
> {code}
> If he does not notice it, he thinks that cdc is true, but it is not.
> More to it, currently, everything which is not "1", "true", or "yes" is
> evaluated as false. We should harden this in such a way that both logical
> true and false would be parsed only on well defined values and every other
> value would be rejected and a query would fail.
> EDIT: I have checked how it behaves in cqlsh and there seems to be validation
> of this already like this:
> {code}
> cqlsh> ALTER TABLE abc.def WITH cdc = tru;
> SyntaxException: line 1:31 no viable alternative at input 'tru' (ALTER TABLE
> abc.def WITH [cdc] =...)
> {code}
> It seems that cqlsh already knows this should be a boolean and rejects such
> query.
> Nevertheless, it is still reasonable to harden this on the code level when a
> query is executed in Java, programmatically (e.g. as part of tests or
> similar). The patch also includes optimizations to not return Boolean but
> boolean on related methods (other primitives are covered as well).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17768) Restore streaming_keep_alive_period functionality on the netty control streaming channel
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630403#comment-17630403 ] Berenguer Blasi commented on CASSANDRA-17768: - So the auto multiplexing didn't run bc of CASSANDRA-18024. I got a patch from Mick's branch and I am running circle ci again [here|https://app.circleci.com/pipelines/github/bereng/cassandra/803/workflows/c55e6efa-7afc-41e4-a9e4-9fec3bce0d42] for my [branch|https://github.com/bereng/cassandra/pull/new/CASSANDRA-17768-4.1] > Restore streaming_keep_alive_period functionality on the netty control > streaming channel > > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-rc > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17878) Harden parsing of boolean values in CQL in PropertyDefinitions
[
https://issues.apache.org/jira/browse/CASSANDRA-17878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630401#comment-17630401
]
Aleksey Yeschenko commented on CASSANDRA-17878:
---
Patch looks good to me. Pushed another one on top with some further cleanup and
deduplication while we are at it anyway:
https://github.com/iamaleksey/cassandra/commits/17878-4.0
> Harden parsing of boolean values in CQL in PropertyDefinitions
> --
>
> Key: CASSANDRA-17878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17878
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There is currently this in PropertyDefinitions class as a pattern we use for
> testing a boolean value in cqlsh
> {code}
> private static final Pattern PATTERN_POSITIVE =
> Pattern.compile("(1|true|yes)");
> {code}
> This might be source of mistakes and typos. For example, if a user does, for
> example:
> {code}
> ALTER TABLE ks.tb WITH cdc = tru;
> {code}
> If he does not notice it, he thinks that cdc is true, but it is not.
> More to it, currently, everything which is not "1", "true", or "yes" is
> evaluated as false. We should harden this in such a way that both logical
> true and false would be parsed only on well defined values and every other
> value would be rejected and a query would fail.
> EDIT: I have checked how it behaves in cqlsh and there seems to be validation
> of this already like this:
> {code}
> cqlsh> ALTER TABLE abc.def WITH cdc = tru;
> SyntaxException: line 1:31 no viable alternative at input 'tru' (ALTER TABLE
> abc.def WITH [cdc] =...)
> {code}
> It seems that cqlsh already knows this should be a boolean and rejects such
> query.
> Nevertheless, it is still reasonable to harden this on the code level when a
> query is executed in Java, programmatically (e.g. as part of tests or
> similar). The patch also includes optimizations to not return Boolean but
> boolean on related methods (other primitives are covered as well).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17878) Harden parsing of boolean values in CQL in PropertyDefinitions
[
https://issues.apache.org/jira/browse/CASSANDRA-17878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-17878:
--
Status: Changes Suggested (was: Review In Progress)
> Harden parsing of boolean values in CQL in PropertyDefinitions
> --
>
> Key: CASSANDRA-17878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17878
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There is currently this in PropertyDefinitions class as a pattern we use for
> testing a boolean value in cqlsh
> {code}
> private static final Pattern PATTERN_POSITIVE =
> Pattern.compile("(1|true|yes)");
> {code}
> This might be source of mistakes and typos. For example, if a user does, for
> example:
> {code}
> ALTER TABLE ks.tb WITH cdc = tru;
> {code}
> If he does not notice it, he thinks that cdc is true, but it is not.
> More to it, currently, everything which is not "1", "true", or "yes" is
> evaluated as false. We should harden this in such a way that both logical
> true and false would be parsed only on well defined values and every other
> value would be rejected and a query would fail.
> EDIT: I have checked how it behaves in cqlsh and there seems to be validation
> of this already like this:
> {code}
> cqlsh> ALTER TABLE abc.def WITH cdc = tru;
> SyntaxException: line 1:31 no viable alternative at input 'tru' (ALTER TABLE
> abc.def WITH [cdc] =...)
> {code}
> It seems that cqlsh already knows this should be a boolean and rejects such
> query.
> Nevertheless, it is still reasonable to harden this on the code level when a
> query is executed in Java, programmatically (e.g. as part of tests or
> similar). The patch also includes optimizations to not return Boolean but
> boolean on related methods (other primitives are covered as well).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15215) VIntCoding should read and write more efficiently
[ https://issues.apache.org/jira/browse/CASSANDRA-15215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630398#comment-17630398 ] Alex Sorokoumov commented on CASSANDRA-15215: - Bump. I think it is important to include the fix into the 4.1-rc. > VIntCoding should read and write more efficiently > - > > Key: CASSANDRA-15215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15215 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Local/SSTable >Reporter: Benedict Elliott Smith >Assignee: Alex Sorokoumov >Priority: Normal > Fix For: 4.1-alpha1, 4.1 > > Attachments: testWriteRandomLongDOP_final.png, > writeUnsignedVInt_megamorphic_BB.png, writeUnsignedVInt_megamorphic_DOP.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Most vints occupy significantly fewer than 8 bytes, and most buffers have >= > 8 bytes spare, in which case we can construct the relevant bytes in a > register and memcpy them to the correct position. Since we read and write a > lot of vints, this waste is probably measurable, particularly during > compaction and flush, and can probably be considered a performance bug. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630395#comment-17630395 ] Berenguer Blasi edited comment on CASSANDRA-18024 at 11/8/22 12:47 PM: --- [~adelapena] wdyt about adding a job to configs that would fail with a message saying 'Caution: manually copying the file will skip auto multiplexing runs bla bla bla? Please use generate.sh instead.'. Generate.sh could remove it. That would protect us from the wall of green that didn't actually multiplex anything and the other problems was (Author: bereng): [~adelapena] wdyt about adding a job to configs that would fail with a message saying 'Caution: manually copying the file will skip about multiplexing runs bla bla bla? Please use generate.sh instead.'. Generate.sh could remove it. That would protect us from the wall of green that didn't actually multiplex anything and the other problems > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug >Reporter: Berenguer Blasi >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630395#comment-17630395 ] Berenguer Blasi commented on CASSANDRA-18024: - [~adelapena] wdyt about adding a job to configs that would fail with a message saying 'Caution: manually copying the file will skip about multiplexing runs bla bla bla. Please use generate.sh instead.'. Generate.sh could remove it. That would protect us from the wall of green that didn't actually multiplex anything and the other problems > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug >Reporter: Berenguer Blasi >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18024) Circle repeat jobs are always triggered even if not necessary
[ https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18024: Reviewers: Berenguer Blasi > Circle repeat jobs are always triggered even if not necessary > - > > Key: CASSANDRA-18024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18024 > Project: Cassandra > Issue Type: Bug >Reporter: Berenguer Blasi >Priority: Normal > > It seems that when pushing a PR, the auto multiplexing of new tests triggers > all multiplexing jobs, even if there are no tests present for that job. > That is wasteful as it means spinning up many nodes etc for nothing. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
