[jira] [Commented] (CASSANDRA-16500) Missing validation in AbstractType.writeValue():
[
https://issues.apache.org/jira/browse/CASSANDRA-16500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306784#comment-17306784
]
Berenguer Blasi commented on CASSANDRA-16500:
-
LGTM
> Missing validation in AbstractType.writeValue():
>
>
> Key: CASSANDRA-16500
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16500
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Benjamin Lerer
>Assignee: Alexandre Dutra
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Some validation checks present in {{AbstractType.writeValue()}} in
> {{cassandra-3.11}} are not there in {{trunk}}.
> In 3.11 the checks used assertion. It would make sense to use
> {{IOExceptions}} instead as used in {{AbstractType.readValue()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16391) Migrate use of maven-ant-tasks to resolver-ant-tasks
[
https://issues.apache.org/jira/browse/CASSANDRA-16391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-16391:
-
Complexity: Low Hanging Fruit (was: Normal)
> Migrate use of maven-ant-tasks to resolver-ant-tasks
>
>
> Key: CASSANDRA-16391
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16391
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies
>Reporter: Michael Semb Wever
>Priority: High
> Labels: gsoc2021, lhf, mentor
>
> Cassandra resolves dependencies and generates maven pom files through the use
> of [maven-ant-tasks|http://maven.apache.org/ant-tasks/]. This is no longer a
> supported project.
> The recommended upgrade is to
> [resolver-ant-tasks|http://maven.apache.org/resolver-ant-tasks/]. It follows
> similar APIs so shouldn't be too impactful a change.
> The existing maven-ant-tasks has caused [some headaches
> already|https://issues.apache.org/jira/browse/CASSANDRA-16359] with internal
> super poms referencing insecure http:// central maven repository URLs that
> are no longer supported.
> We should also take the opportunity to
> - define the "test" scope (classpath) for those dependencies only used for
> tests (currently we are packaging test dependencies into the release binary
> artefact),
> - remove the jar files stored in the git repo under the "lib/" folder.
> These two above points have to happen in tandem, as the jar files under
> {{lib/}} are those that get bundled into the {{build/dist/lib/}} and hence
> the binary artefact. That is, all jar files under {{lib/}} are the project's
> "compile" scope, and all other dependencies defined in build.xml are either
> "provided" or "test" scope. These different scopes for dependencies are
> currently configured in different maven-ant-tasks poms. See
> https://github.com/apache/cassandra/commit/d43b9ce5092f8879a1a66afebab74d86e9e127fb#r45659668
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16528) Update Cassandra dependencies to fix security vulnerabilities
[
https://issues.apache.org/jira/browse/CASSANDRA-16528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306705#comment-17306705
]
LHX commented on CASSANDRA-16528:
-
So the entire build/lib directory is unused by cassandra or any of its
dependencies once the build is completed?
> Update Cassandra dependencies to fix security vulnerabilities
> -
>
> Key: CASSANDRA-16528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16528
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Dependencies
>Reporter: LHX
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> There are a couple of security vulnerabilities that show up in libraries that
> cassandra pulls in.
> # apache commons-collections v 3.2.1
> # apache commons-beanutils v 1.7.0
> For number one, there is a well-known security vulnerability in apache
> commons-collection 3.2.1 (see [https://www.kb.cert.org/vuls/id/576313] and
> https://issues.apache.org/jira/browse/COLLECTIONS-580). This is
> fixed/mitigated in commons-collections 3.2.2.
> All current versions of cassandra (including 4.0beta4) pull in
> commons-collections 3.2.1 via apache-rat 0.10. Is it possible to upgrade
> apache-rat to version 0.12 in order to pull in the latest version of
> commons-collections? See
> [https://github.com/apache/creadur-rat/commit/2380409fbcd02b418eceacfdc1e486bdbbca9632].
> I made the below change in 3.0.24 src and recompiled without errors.
> {code:java}
> // code placeholder
> diff --git a/cassandra/cassandra-3.0-src/build.xml
> b/cassandra/cassandra-3.0-src/build.xml
> index 73c9889d81..ed236443d4 100644
> --- a/cassandra/cassandra-3.0-src/build.xml
> +++ b/cassandra/cassandra-3.0-src/build.xml
> @@ -402,3 +402,3 @@
> version="0.9.12" />
> - version="0.10">
> + version="0.12">
>
> @@ -1605,3 +1605,3 @@
>
> - version="0.6" />
> + version="0.12" />
>
> {code}
>
> For number two, I was able to discern that beanutils is coming from
> hadoop-core which is version 1.0.3. I believe this also is quite out of date
> and could be upgraded.
> Could someone take a look and see if these version upgrades are possible?
> {{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11978) StreamReader fails to write sstable if CF directory is symlink
[ https://issues.apache.org/jira/browse/CASSANDRA-11978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk True reassigned CASSANDRA-11978: - Assignee: Kirk True > StreamReader fails to write sstable if CF directory is symlink > -- > > Key: CASSANDRA-11978 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11978 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Michael Frisch >Assignee: Kirk True >Priority: Normal > Labels: lhf > > I'm using Cassandra v2.2.6. If the CF is stored as a symlink in the keyspace > directory on disk then StreamReader.createWriter fails because > Descriptor.fromFilename is passed the actual path on disk instead of path > with the symlink. > Example: > /path/to/data/dir/Keyspace/CFName -> /path/to/data/dir/AnotherDisk/CFName > Descriptor.fromFilename is passed "/path/to/data/dir/AnotherDisk/CFName" > instead of "/path/to/data/dir/Keyspace/CFName", then it concludes that the > keyspace name is "AnotherDisk" which is erroneous. I've temporarily worked > around this by using cfs.keyspace.getName() to get the keyspace name and > cfs.name to get the CF name as those are correct. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16447) Expose StorageServiceMBean#getKeyspaceReplicationInfo from 4.0 to 3.11
[ https://issues.apache.org/jira/browse/CASSANDRA-16447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16447: --- Reviewers: Michael Semb Wever Status: Review In Progress (was: Patch Available) > Expose StorageServiceMBean#getKeyspaceReplicationInfo from 4.0 to 3.11 > -- > > Key: CASSANDRA-16447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16447 > Project: Cassandra > Issue Type: Improvement > Components: Observability/JMX >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.11.11 > > > As part of CASSANDRA-13853, there was a method introduced into > StorageServiceMBean via which an operator can retrieve information about a > particular keyspace. This method is very handy not only in the context of > 13853 and I am lacking that method in 3.11 as it was not ported there. I > would like to have that method in 3.11 too for observability purposes as well > as for the feature parity with 4.0. > https://github.com/apache/cassandra/pull/897 > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/505/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16447) Expose StorageServiceMBean#getKeyspaceReplicationInfo from 4.0 to 3.11
[ https://issues.apache.org/jira/browse/CASSANDRA-16447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16447: -- Test and Documentation Plan: manual invoking of that method Status: Patch Available (was: Open) > Expose StorageServiceMBean#getKeyspaceReplicationInfo from 4.0 to 3.11 > -- > > Key: CASSANDRA-16447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16447 > Project: Cassandra > Issue Type: Improvement > Components: Observability/JMX >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.11.11 > > > As part of CASSANDRA-13853, there was a method introduced into > StorageServiceMBean via which an operator can retrieve information about a > particular keyspace. This method is very handy not only in the context of > 13853 and I am lacking that method in 3.11 as it was not ported there. I > would like to have that method in 3.11 too for observability purposes as well > as for the feature parity with 4.0. > https://github.com/apache/cassandra/pull/897 > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/505/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16447) Expose StorageServiceMBean#getKeyspaceReplicationInfo from 4.0 to 3.11
[ https://issues.apache.org/jira/browse/CASSANDRA-16447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16447: -- Description: As part of CASSANDRA-13853, there was a method introduced into StorageServiceMBean via which an operator can retrieve information about a particular keyspace. This method is very handy not only in the context of 13853 and I am lacking that method in 3.11 as it was not ported there. I would like to have that method in 3.11 too for observability purposes as well as for the feature parity with 4.0. https://github.com/apache/cassandra/pull/897 https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/505/ was: As part of CASSANDRA-13853, there was a method introduced into StorageServiceMBean via which an operator can retrieve information about a particular keyspace. This method is very handy not only in the context of 13853 and I am lacking that method in 3.11 as it was not ported there. I would like to have that method in 3.11 too for observability purposes as well as for the feature parity with 4.0. https://github.com/apache/cassandra/pull/897 > Expose StorageServiceMBean#getKeyspaceReplicationInfo from 4.0 to 3.11 > -- > > Key: CASSANDRA-16447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16447 > Project: Cassandra > Issue Type: Improvement > Components: Observability/JMX >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.11.11 > > > As part of CASSANDRA-13853, there was a method introduced into > StorageServiceMBean via which an operator can retrieve information about a > particular keyspace. This method is very handy not only in the context of > 13853 and I am lacking that method in 3.11 as it was not ported there. I > would like to have that method in 3.11 too for observability purposes as well > as for the feature parity with 4.0. > https://github.com/apache/cassandra/pull/897 > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/505/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16526) BinLogTest is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306486#comment-17306486
]
Brandon Williams commented on CASSANDRA-16526:
--
Though CI only has the [one
failure|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/497/tests]
it doesn't really have enough history to see what's happened here. Hoping I
could bisect, I tried to find a good revision, but even the fix for the last
time it was flaky in CASSANDRA-15797 does not pass 100 iterations on either j11
or j8 on multiple machines with just a single test runner. It doesn't seem
like this could have been failing sporadically for this long and been lost in
the noise each time, but I don't have any other explanation at this point.
> BinLogTest is flaky
> ---
>
> Key: CASSANDRA-16526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16526
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Probably due to increasing the runners:
> {noformat}
> java.lang.RuntimeException: java.lang.IllegalStateException: Expected file to
> exist for cycle: 1616021848, file:
> /home/jenkins/jenkins-slave/workspace/Cassandra-devbranch-test-compression/jdk/jdk_11_latest/label/cassandra/tmp/foo17bar/20210317-225728T.cq4.
> minCycle: 1616021850, maxCycle: 1616021852
> Available files: [20210317-225730T.cq4, 20210317-225732T.cq4]
> at
> org.apache.cassandra.utils.binlog.BinLogTest.readBinLogRecords(BinLogTest.java:492)
> at
> org.apache.cassandra.utils.binlog.BinLogTest.lambda$testTrucationReleasesLogSpace$8(BinLogTest.java:444)
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:605)
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:595)
> at
> org.apache.cassandra.utils.binlog.BinLogTest.testTrucationReleasesLogSpace(BinLogTest.java:444)
> 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)
> Caused by: java.lang.IllegalStateException: Expected file to exist for cycle:
> 1616021848, file:
> /home/jenkins/jenkins-slave/workspace/Cassandra-devbranch-test-compression/jdk/jdk_11_latest/label/cassandra/tmp/foo17bar/20210317-225728T.cq4.
> minCycle: 1616021850, maxCycle: 1616021852
> Available files: [20210317-225730T.cq4, 20210317-225732T.cq4]
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.nextCycle(SingleChronicleQueue.java:1157)
> at
> net.openhft.chronicle.queue.impl.WireStorePool.nextCycle(WireStorePool.java:66)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.nextCycle(SingleChronicleQueue.java:507)
> at
> net.openhft.chronicle.queue.impl.single.StoreTailer.nextIndexWithNextAvailableCycle(StoreTailer.java:507)
> at
> net.openhft.chronicle.queue.impl.single.StoreTailer.endOfCycle(StoreTailer.java:323)
> at
> net.openhft.chronicle.queue.impl.single.StoreTailer.next0(StoreTailer.java:295)
> at
> net.openhft.chronicle.queue.impl.single.StoreTailer.readingDocument(StoreTailer.java:202)
> at
> net.openhft.chronicle.queue.impl.single.StoreTailer.readDocument(StoreTailer.java:108)
> at
> org.apache.cassandra.utils.binlog.BinLogTest.readBinLogRecords(BinLogTest.java:481)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13951) Release Java and Python drivers and re-enable build.xml driver dep
[
https://issues.apache.org/jira/browse/CASSANDRA-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-13951:
Fix Version/s: (was: 4.0-rc)
(was: 4.0)
4.0-beta5
Source Control Link:
https://github.com/apache/cassandra/commit/1371883db3d8bf7d7c54e0baaca89c6c2d2a5abe
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks, committed to trunk in {{1371883db3d8bf7d7c54e0baaca89c6c2d2a5abe}}.
> Release Java and Python drivers and re-enable build.xml driver dep
> --
>
> Key: CASSANDRA-13951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13951
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies
>Reporter: Alex Petrov
>Assignee: Sam Tunnicliffe
>Priority: Urgent
> Fix For: 4.0-beta5
>
>
> During [CASSANDRA-10786], driver changes were introduced that required a
> snapshot release of both drivers.
> When the stable driver version is published, we have to update the driver
> dependencies in {{lib}} and un-comment {{build.xml}} sections with
> {{java-driver}} information for correct publish of 4.0. This manipulation was
> required in order to account for the chicken-or-egg problem between Cassandra
> itself and the drivers.
> This absolutely has to be done before 4.0 & there should be no release
> without making sure right drivers are in place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13951) Release Java and Python drivers and re-enable build.xml driver dep
[
https://issues.apache.org/jira/browse/CASSANDRA-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-13951:
Status: Ready to Commit (was: Review In Progress)
> Release Java and Python drivers and re-enable build.xml driver dep
> --
>
> Key: CASSANDRA-13951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13951
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies
>Reporter: Alex Petrov
>Assignee: Sam Tunnicliffe
>Priority: Urgent
> Fix For: 4.0, 4.0-rc
>
>
> During [CASSANDRA-10786], driver changes were introduced that required a
> snapshot release of both drivers.
> When the stable driver version is published, we have to update the driver
> dependencies in {{lib}} and un-comment {{build.xml}} sections with
> {{java-driver}} information for correct publish of 4.0. This manipulation was
> required in order to account for the chicken-or-egg problem between Cassandra
> itself and the drivers.
> This absolutely has to be done before 4.0 & there should be no release
> without making sure right drivers are in place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13951) Release Java and Python drivers and re-enable build.xml driver dep
[
https://issues.apache.org/jira/browse/CASSANDRA-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-13951:
Status: Review In Progress (was: Patch Available)
> Release Java and Python drivers and re-enable build.xml driver dep
> --
>
> Key: CASSANDRA-13951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13951
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies
>Reporter: Alex Petrov
>Assignee: Sam Tunnicliffe
>Priority: Urgent
> Fix For: 4.0, 4.0-rc
>
>
> During [CASSANDRA-10786], driver changes were introduced that required a
> snapshot release of both drivers.
> When the stable driver version is published, we have to update the driver
> dependencies in {{lib}} and un-comment {{build.xml}} sections with
> {{java-driver}} information for correct publish of 4.0. This manipulation was
> required in order to account for the chicken-or-egg problem between Cassandra
> itself and the drivers.
> This absolutely has to be done before 4.0 & there should be no release
> without making sure right drivers are in place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Update bundled driver dependencies
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 1371883 Update bundled driver dependencies 1371883 is described below commit 1371883db3d8bf7d7c54e0baaca89c6c2d2a5abe Author: Sam Tunnicliffe AuthorDate: Wed Mar 17 15:07:34 2021 + Update bundled driver dependencies This commit updates that bundled java and python drivers to their latest released versions, 3.11.0 and 3.25.0 respectively. Patch by Sam Tunnicliffe and Adam Holmberg; reviewed by Brandon Williams for CASSANDRA-13951 Co-authored-by: Adam Holmberg --- CHANGES.txt| 1 + build.xml | 10 +- ...jar => cassandra-driver-core-3.11.0-shaded.jar} | Bin 2781089 -> 2782668 bytes ...p => cassandra-driver-internal-only-3.25.0.zip} | Bin 347058 -> 345177 bytes 4 files changed, 2 insertions(+), 9 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 6ed7b96..90eac99 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0-beta5 + * Update bundled java and python drivers to 3.11.0 and 3.25.0 respectively (CASSANDRA-13951) * Add io.netty.tryReflectionSetAccessible=true to j11 server options in order to enable netty to use Unsafe direct byte buffer construction (CASSANDRA-16493) * Make cassandra-stress -node support host:port notation (CASSANDRA-16529) * Better handle legacy gossip application states during (and after) upgrades (CASSANDRA-16525) diff --git a/build.xml b/build.xml index 111c267..17f0e96 100644 --- a/build.xml +++ b/build.xml @@ -649,15 +649,13 @@ - @@ -753,9 +751,7 @@ - @@ -786,9 +782,7 @@ - @@ -865,14 +859,12 @@ - diff --git a/lib/cassandra-driver-core-3.10.3-1af7382fe-shaded.jar b/lib/cassandra-driver-core-3.11.0-shaded.jar similarity index 80% rename from lib/cassandra-driver-core-3.10.3-1af7382fe-shaded.jar rename to lib/cassandra-driver-core-3.11.0-shaded.jar index adf439a..e85a7aa 100644 Binary files a/lib/cassandra-driver-core-3.10.3-1af7382fe-shaded.jar and b/lib/cassandra-driver-core-3.11.0-shaded.jar differ diff --git a/lib/cassandra-driver-internal-only-3.24.0-a04c5929.zip b/lib/cassandra-driver-internal-only-3.25.0.zip similarity index 86% rename from lib/cassandra-driver-internal-only-3.24.0-a04c5929.zip rename to lib/cassandra-driver-internal-only-3.25.0.zip index 03f7d09..ecfd6a9 100644 Binary files a/lib/cassandra-driver-internal-only-3.24.0-a04c5929.zip and b/lib/cassandra-driver-internal-only-3.25.0.zip differ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13951) Release Java and Python drivers and re-enable build.xml driver dep
[
https://issues.apache.org/jira/browse/CASSANDRA-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306406#comment-17306406
]
Brandon Williams commented on CASSANDRA-13951:
--
+1
> Release Java and Python drivers and re-enable build.xml driver dep
> --
>
> Key: CASSANDRA-13951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13951
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies
>Reporter: Alex Petrov
>Assignee: Sam Tunnicliffe
>Priority: Urgent
> Fix For: 4.0, 4.0-rc
>
>
> During [CASSANDRA-10786], driver changes were introduced that required a
> snapshot release of both drivers.
> When the stable driver version is published, we have to update the driver
> dependencies in {{lib}} and un-comment {{build.xml}} sections with
> {{java-driver}} information for correct publish of 4.0. This manipulation was
> required in order to account for the chicken-or-egg problem between Cassandra
> itself and the drivers.
> This absolutely has to be done before 4.0 & there should be no release
> without making sure right drivers are in place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13951) Release Java and Python drivers and re-enable build.xml driver dep
[
https://issues.apache.org/jira/browse/CASSANDRA-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-13951:
Authors: Adam Holmberg, Sam Tunnicliffe (was: Sam Tunnicliffe)
> Release Java and Python drivers and re-enable build.xml driver dep
> --
>
> Key: CASSANDRA-13951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13951
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies
>Reporter: Alex Petrov
>Assignee: Sam Tunnicliffe
>Priority: Urgent
> Fix For: 4.0, 4.0-rc
>
>
> During [CASSANDRA-10786], driver changes were introduced that required a
> snapshot release of both drivers.
> When the stable driver version is published, we have to update the driver
> dependencies in {{lib}} and un-comment {{build.xml}} sections with
> {{java-driver}} information for correct publish of 4.0. This manipulation was
> required in order to account for the chicken-or-egg problem between Cassandra
> itself and the drivers.
> This absolutely has to be done before 4.0 & there should be no release
> without making sure right drivers are in place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13951) Release Java and Python drivers and re-enable build.xml driver dep
[
https://issues.apache.org/jira/browse/CASSANDRA-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-13951:
Reviewers: Brandon Williams
> Release Java and Python drivers and re-enable build.xml driver dep
> --
>
> Key: CASSANDRA-13951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13951
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies
>Reporter: Alex Petrov
>Assignee: Sam Tunnicliffe
>Priority: Urgent
> Fix For: 4.0, 4.0-rc
>
>
> During [CASSANDRA-10786], driver changes were introduced that required a
> snapshot release of both drivers.
> When the stable driver version is published, we have to update the driver
> dependencies in {{lib}} and un-comment {{build.xml}} sections with
> {{java-driver}} information for correct publish of 4.0. This manipulation was
> required in order to account for the chicken-or-egg problem between Cassandra
> itself and the drivers.
> This absolutely has to be done before 4.0 & there should be no release
> without making sure right drivers are in place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15148) Add in-jvm dtest for Gossip to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15148:
Status: Ready to Commit (was: Review In Progress)
> Add in-jvm dtest for Gossip to trunk
>
>
> Key: CASSANDRA-15148
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15148
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
>Reporter: Sam Tunnicliffe
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> When merging CASSANDRA-15120 to trunk, the in-jvm dtest support for gossip
> and networking were ommitted as much of the work to support that is already
> done and due to land in CASSANDRA-15066. Once that patch is committed, we
> should add the {{GossipTest}} from CASSANDRA-15120 to trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15148) Add in-jvm dtest for Gossip to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306368#comment-17306368
]
Sam Tunnicliffe commented on CASSANDRA-15148:
-
Great, LGTM too, thanks!
> Add in-jvm dtest for Gossip to trunk
>
>
> Key: CASSANDRA-15148
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15148
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
>Reporter: Sam Tunnicliffe
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> When merging CASSANDRA-15120 to trunk, the in-jvm dtest support for gossip
> and networking were ommitted as much of the work to support that is already
> done and due to land in CASSANDRA-15066. Once that patch is committed, we
> should add the {{GossipTest}} from CASSANDRA-15120 to trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16497:
---
Fix Version/s: (was: 4.0-rc)
4.0
4.0-beta5
Since Version: 3.0.24
Source Control Link:
https://github.com/apache/cassandra/commit/86a3cfe2fa7d8dcf070fd8d3297cdabffe410934
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[86a3cfe2fa7d8dcf070fd8d3297cdabffe410934|https://github.com/apache/cassandra/commit/86a3cfe2fa7d8dcf070fd8d3297cdabffe410934].
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta5, 4.0
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16497:
---
Status: Ready to Commit (was: Review In Progress)
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Ignore LongSharedExecutorPoolTest until SEPThreadpool is re-evaluated post 4.0
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 86a3cfe Ignore LongSharedExecutorPoolTest until SEPThreadpool is
re-evaluated post 4.0
86a3cfe is described below
commit 86a3cfe2fa7d8dcf070fd8d3297cdabffe410934
Author: Mick Semb Wever
AuthorDate: Mon Mar 22 16:18:56 2021 +0100
Ignore LongSharedExecutorPoolTest until SEPThreadpool is re-evaluated post
4.0
patch by Mick Semb Wever; reviewed by Ekaterina Dimitrova for
CASSANDRA-16497
---
.../org/apache/cassandra/concurrent/LongSharedExecutorPoolTest.java| 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/test/burn/org/apache/cassandra/concurrent/LongSharedExecutorPoolTest.java
b/test/burn/org/apache/cassandra/concurrent/LongSharedExecutorPoolTest.java
index f6c5720..fd7920a 100644
--- a/test/burn/org/apache/cassandra/concurrent/LongSharedExecutorPoolTest.java
+++ b/test/burn/org/apache/cassandra/concurrent/LongSharedExecutorPoolTest.java
@@ -28,6 +28,7 @@ import java.util.concurrent.locks.LockSupport;
import com.google.common.util.concurrent.Uninterruptibles;
import org.apache.commons.math3.distribution.WeibullDistribution;
+import org.junit.Ignore;
import org.junit.Test;
public class LongSharedExecutorPoolTest
@@ -96,7 +97,7 @@ public class LongSharedExecutorPoolTest
}
}
-@Test
+@Test @Ignore // see CASSANDRA-16497. re-evaluate SEPThreadpools post 4.0
public void testPromptnessOfExecution() throws InterruptedException,
ExecutionException
{
testPromptnessOfExecution(TimeUnit.MINUTES.toNanos(2L), 0.5f);
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15148) Add in-jvm dtest for Gossip to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15148:
Reviewers: Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> Add in-jvm dtest for Gossip to trunk
>
>
> Key: CASSANDRA-15148
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15148
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
>Reporter: Sam Tunnicliffe
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> When merging CASSANDRA-15120 to trunk, the in-jvm dtest support for gossip
> and networking were ommitted as much of the work to support that is already
> done and due to land in CASSANDRA-15066. Once that patch is committed, we
> should add the {{GossipTest}} from CASSANDRA-15120 to trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15148) Add in-jvm dtest for Gossip to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15148:
Test and Documentation Plan: Current CI
Status: Patch Available (was: In Progress)
> Add in-jvm dtest for Gossip to trunk
>
>
> Key: CASSANDRA-15148
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15148
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
>Reporter: Sam Tunnicliffe
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> When merging CASSANDRA-15120 to trunk, the in-jvm dtest support for gossip
> and networking were ommitted as much of the work to support that is already
> done and due to land in CASSANDRA-15066. Once that patch is committed, we
> should add the {{GossipTest}} from CASSANDRA-15120 to trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15148) Add in-jvm dtest for Gossip to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306322#comment-17306322
]
Ekaterina Dimitrova commented on CASSANDRA-15148:
-
CI looks good; +1 from me :)
> Add in-jvm dtest for Gossip to trunk
>
>
> Key: CASSANDRA-15148
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15148
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
>Reporter: Sam Tunnicliffe
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> When merging CASSANDRA-15120 to trunk, the in-jvm dtest support for gossip
> and networking were ommitted as much of the work to support that is already
> done and due to land in CASSANDRA-15066. Once that patch is committed, we
> should add the {{GossipTest}} from CASSANDRA-15120 to trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15148) Add in-jvm dtest for Gossip to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305229#comment-17305229
]
Ekaterina Dimitrova edited comment on CASSANDRA-15148 at 3/22/21, 4:06 PM:
---
Actually, considering you debugged it while I was sleeping in my time zone, I
set you as an author as I believe that is fair. :) I wrapped it [here
|https://github.com/ekaterinadimitrova2/cassandra/commit/3db3e2a9a7cb0c7bc6c36654003c81b292c01613]
and marking myself as a reviewer. +1 on green CI from me :D LMK what you think.
{quote}{quote} I am planning to change it also in the other tests as part of
this ticket, not only for this test, WDYT?
{quote}{quote}
I decided to leave this out of the scope of this ticket as it seems there are
a lot of occurrences and not all of them should be directly changed; careful
revision should be done not only in the test framework but also in the actual
product source.
Pushing CircleCI run
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=15148]
was (Author: e.dimitrova):
Actually, considering you debugged it while I was sleeping in my time zone, I
set you as an author as I believe that is fair. :) I wrapped it [here
|https://github.com/ekaterinadimitrova2/cassandra/commit/3db3e2a9a7cb0c7bc6c36654003c81b292c01613]
and marking myself as a reviewer. +1 on green CI from me :D LMK what you think.
{quote}bq. I am planning to change it also in the other tests as part of this
ticket, not only for this test, WDYT?
{quote}
I decided to leave this out of the scope of this ticket as it seems there are a
lot of occurrences and not all of them should be directly changed; careful
revision should be done not only in the test framework but also in the actual
product source.
Pushing CircleCI run
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=15148]
> Add in-jvm dtest for Gossip to trunk
>
>
> Key: CASSANDRA-15148
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15148
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
>Reporter: Sam Tunnicliffe
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> When merging CASSANDRA-15120 to trunk, the in-jvm dtest support for gossip
> and networking were ommitted as much of the work to support that is already
> done and due to land in CASSANDRA-15066. Once that patch is committed, we
> should add the {{GossipTest}} from CASSANDRA-15120 to trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15148) Add in-jvm dtest for Gossip to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305229#comment-17305229
]
Ekaterina Dimitrova edited comment on CASSANDRA-15148 at 3/22/21, 4:06 PM:
---
Actually, considering you debugged it while I was sleeping in my time zone, I
set you as an author as I believe that is fair. :) I wrapped it [here
|https://github.com/ekaterinadimitrova2/cassandra/commit/3db3e2a9a7cb0c7bc6c36654003c81b292c01613]
and marking myself as a reviewer. +1 on green CI from me :D LMK what you think.
{quote}bq. I am planning to change it also in the other tests as part of this
ticket, not only for this test, WDYT?
{quote}
I decided to leave this out of the scope of this ticket as it seems there are a
lot of occurrences and not all of them should be directly changed; careful
revision should be done not only in the test framework but also in the actual
product source.
Pushing CircleCI run
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=15148]
was (Author: e.dimitrova):
Actually, considering you debugged it while I was sleeping in my time zone, I
set you as an author as I believe that is fair. :) I wrapped it [here
|https://github.com/ekaterinadimitrova2/cassandra/commit/3db3e2a9a7cb0c7bc6c36654003c81b292c01613]
and marking myself as a reviewer. +1 on green CI from me :D LMK what you think.
{quote}{quote}I am planning to change it also in the other tests as part of
this ticket, not only for this test, WDYT?
{quote}{quote}
I decided to leave this out of the scope of this ticket as it seems there are a
lot of occurrences and not all of them should be directly changed; careful
revision should be done not only in the test framework but also in the actual
product source.
Pushing CircleCI run
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=15148]
> Add in-jvm dtest for Gossip to trunk
>
>
> Key: CASSANDRA-15148
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15148
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
>Reporter: Sam Tunnicliffe
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> When merging CASSANDRA-15120 to trunk, the in-jvm dtest support for gossip
> and networking were ommitted as much of the work to support that is already
> done and due to land in CASSANDRA-15066. Once that patch is committed, we
> should add the {{GossipTest}} from CASSANDRA-15120 to trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16476) Update the Compact Storage related docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16476: Test and Documentation Plan: (was: [Patch |https://github.com/ekaterinadimitrova2/cassandra/commit/b8434017e4a7687381be11ddf54ecde0d1e4e3b3]) > Update the Compact Storage related docs > --- > > Key: CASSANDRA-16476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16476 > Project: Cassandra > Issue Type: Task > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-beta5, 4.0 > > > Compact Storage partial support was returned recently. > We need to elaborate in the docs on what does this mean to the users. > * Compact Storage support was returned, except for the supercolumn tables. > * This was done because during the big 4.0 beta testing changes of behavior > after DROP COMPACT STORAGE usage were revealed. > /CC [~ifesdjeen] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16476) Update the Compact Storage related docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16476: Fix Version/s: (was: 4.0-rc) 4.0 4.0-beta5 Source Control Link: https://github.com/apache/cassandra/commit/0a49d25078665da0ec30d9e69a036de163deb9c3 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Update the Compact Storage related docs > --- > > Key: CASSANDRA-16476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16476 > Project: Cassandra > Issue Type: Task > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-beta5, 4.0 > > > Compact Storage partial support was returned recently. > We need to elaborate in the docs on what does this mean to the users. > * Compact Storage support was returned, except for the supercolumn tables. > * This was done because during the big 4.0 beta testing changes of behavior > after DROP COMPACT STORAGE usage were revealed. > /CC [~ifesdjeen] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16476) Update the Compact Storage related docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16476: Status: Ready to Commit (was: Review In Progress) > Update the Compact Storage related docs > --- > > Key: CASSANDRA-16476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16476 > Project: Cassandra > Issue Type: Task > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-rc > > > Compact Storage partial support was returned recently. > We need to elaborate in the docs on what does this mean to the users. > * Compact Storage support was returned, except for the supercolumn tables. > * This was done because during the big 4.0 beta testing changes of behavior > after DROP COMPACT STORAGE usage were revealed. > /CC [~ifesdjeen] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16476) Update the Compact Storage related docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306321#comment-17306321 ] Ekaterina Dimitrova commented on CASSANDRA-16476: - The small nit was addressed on commit [here|https://github.com/apache/cassandra/commit/0a49d25078665da0ec30d9e69a036de163deb9c3] We agreed on Slack with [~Bereng] that the current state is good enough at this point until a native-speaker and professional writer like [~lor...@datastax.com] for example pick it up :) Thanks everyone for the input and the review > Update the Compact Storage related docs > --- > > Key: CASSANDRA-16476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16476 > Project: Cassandra > Issue Type: Task > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-rc > > > Compact Storage partial support was returned recently. > We need to elaborate in the docs on what does this mean to the users. > * Compact Storage support was returned, except for the supercolumn tables. > * This was done because during the big 4.0 beta testing changes of behavior > after DROP COMPACT STORAGE usage were revealed. > /CC [~ifesdjeen] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Update compact storage related docs Authored by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Berenguer Blasi for CASSANDRA-16476
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 0a49d25 Update compact storage related docs Authored by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Berenguer Blasi for CASSANDRA-16476 0a49d25 is described below commit 0a49d25078665da0ec30d9e69a036de163deb9c3 Author: Ekaterina Dimitrova AuthorDate: Fri Mar 5 23:33:00 2021 -0500 Update compact storage related docs Authored by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Berenguer Blasi for CASSANDRA-16476 --- doc/cql3/CQL.textile | 2 ++ doc/source/cql/ddl.rst | 26 ++ 2 files changed, 28 insertions(+) diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile index fafca14..f50b2ac 100644 --- a/doc/cql3/CQL.textile +++ b/doc/cql3/CQL.textile @@ -396,6 +396,7 @@ bc(syntax).. | ADD ( ( , )* ) | DROP | DROP ( ( , )* ) +| DROP COMPACT STORAGE | WITH ( AND )* p. __Sample:__ @@ -414,6 +415,7 @@ The @ALTER@ statement is used to manipulate table definitions. It allows for add The @@ is the table name optionally preceded by the keyspace name. The @@ defines the alteration to perform: * @ADD@: Adds a new column to the table. The @@ for the new column must not conflict with an existing column. Moreover, columns cannot be added to tables defined with the @COMPACT STORAGE@ option. * @DROP@: Removes a column from the table. Dropped columns will immediately become unavailable in the queries and will not be included in compacted sstables in the future. If a column is readded, queries won't return values written before the column was last dropped. It is assumed that timestamps represent actual time, so if this is not your case, you should NOT readd previously dropped columns. Columns can't be dropped from tables defined with the @COMPACT STORAGE@ option. +* @DROP COMPACT STORAGE@: Removes Thrift compatibility mode from the table. * @WITH@: Allows to update the options of the table. The "supported @@":#createTableOptions (and syntax) are the same as for the @CREATE TABLE@ statement except that @COMPACT STORAGE@ is not supported. Note that setting any @compaction@ sub-options has the effect of erasing all previous @compaction@ options, so you need to re-specify all the sub-options if you want to keep them. The same note applies to the set of @compression@ sub-options. h4. CQL type compatibility: diff --git a/doc/source/cql/ddl.rst b/doc/source/cql/ddl.rst index d0e92ec..2f442e9 100644 --- a/doc/source/cql/ddl.rst +++ b/doc/source/cql/ddl.rst @@ -453,6 +453,32 @@ A CQL table has a number of options that can be set at creation (and, for most o ` later). These options are specified after the ``WITH`` keyword and are described in the following sections. +.. _compact-tables: + + COMPACT STORAGE tables + `` + +.. warning:: It is strongly discouraged to create new tables with the ``COMPACT STORAGE`` option. Since Cassandra 3.0, +compact storage tables have the exact same layout internally than non compact ones (for the same schema obviously), +and declaring a table compact **only** creates artificial limitations on the table definition and usage. As of Cassandra +|version| ``COMPACT STORAGE`` cannot be removed. + +.. warning:: ``DROP COMPACT STORAGE`` is not recommended for production environments. There are still cases where a change of +behavior is observed. To name a few: (1) Hidden columns show up, which breaks ``SELECT *`` queries. +(2) ``DELETE v`` and ``UPDATE v WITH TTL`` would result into row removals in non-dense compact storage tables (CASSANDRA-16069) +(3) ``INSERT`` allows skipping clusterings, which are filled with nulls by default. + + A *compact storage* table is one defined with the ``COMPACT STORAGE`` option. This option is only maintained for backward + compatibility for definitions created before CQL version 3 and shouldn't be used for new tables. 4.0 supports partially + ``COMPACT STORAGE``. There is no support for super column family. Since Cassandra 3.0, compact storage tables have the exact + same layout internally than non compact ones (for the same schema obviously), and declaring a table with this option creates + limitations for the table which are largely arbitrary (and exists for historical reasons). Amongst those limitation: + + - a compact storage table cannot use collections nor static columns. + - if a compact storage table has at least one clustering column, then it must have *exactly* one column outside of the primary + key ones. This implies you cannot add or remove columns after creation in particular. + - a compact storage table is limited in the indexes it can create, and no materialized view
[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306304#comment-17306304
]
Ekaterina Dimitrova commented on CASSANDRA-16497:
-
+1 on the patch, assuming everything is alright with the CI run which is still
ongoing. Thanks
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16497:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306289#comment-17306289
]
Michael Semb Wever edited comment on CASSANDRA-16497 at 3/22/21, 3:30 PM:
--
Patch at
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk/16497
CI
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-test-burn/302//badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-test-burn/302//]
was (Author: michaelsembwever):
Patch at
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk/16497
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16497:
---
Test and Documentation Plan: CI
Status: Patch Available (was: In Progress)
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306289#comment-17306289
]
Michael Semb Wever commented on CASSANDRA-16497:
Patch at
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk/16497
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever reassigned CASSANDRA-16497:
--
Assignee: Michael Semb Wever (was: Benjamin Lerer)
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16500) Missing validation in AbstractType.writeValue():
[
https://issues.apache.org/jira/browse/CASSANDRA-16500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306257#comment-17306257
]
Andres de la Peña commented on CASSANDRA-16500:
---
Here goes a new CI round:
* [CircleCI j8
|https://app.circleci.com/pipelines/github/adelapena/cassandra/231/workflows/9a3abb64-968f-4159-afad-f6e71ed538b7]
* [CircleCI
j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/231/workflows/c2c86374-e720-4528-92f8-e0f1f1ad588a]
* [Jenkins
|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/504/pipeline]
> Missing validation in AbstractType.writeValue():
>
>
> Key: CASSANDRA-16500
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16500
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Benjamin Lerer
>Assignee: Alexandre Dutra
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Some validation checks present in {{AbstractType.writeValue()}} in
> {{cassandra-3.11}} are not there in {{trunk}}.
> In 3.11 the checks used assertion. It would make sense to use
> {{IOExceptions}} instead as used in {{AbstractType.readValue()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16476) Update the Compact Storage related docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16476: Reviewers: Berenguer Blasi, Michael Semb Wever (was: Alex Petrov, Berenguer Blasi, Michael Semb Wever) > Update the Compact Storage related docs > --- > > Key: CASSANDRA-16476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16476 > Project: Cassandra > Issue Type: Task > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-rc > > > Compact Storage partial support was returned recently. > We need to elaborate in the docs on what does this mean to the users. > * Compact Storage support was returned, except for the supercolumn tables. > * This was done because during the big 4.0 beta testing changes of behavior > after DROP COMPACT STORAGE usage were revealed. > /CC [~ifesdjeen] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16531) cqlsh can stuck randomly during a connect-timeout period in Kubernetes
[
https://issues.apache.org/jira/browse/CASSANDRA-16531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16531:
-
Bug Category: Parent values: Availability(12983)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 3.11.x
Severity: Normal
Status: Open (was: Triage Needed)
Thanks for the analysis. I'm not sure how much we can do from this end, as
this seems to be a problem rooted in the driver, have you opened a ticket
there? https://github.com/datastax/python-driver
> cqlsh can stuck randomly during a connect-timeout period in Kubernetes
> --
>
> Key: CASSANDRA-16531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16531
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 3.11.x
>
> Attachments: cqlsh_debug.txt, pystack-2868.txt
>
>
> Hello, we get the following issue for cqlsh in Kubernetes environment.
> When cqlsh is executed against a head-less Cassandra service (which is
> configured for Cassandra pods) - it can stuck randomly during a
> connect-timeout period.
> We reproduced the issue using the following command:
> {code:java}
> for i in {1..1000}; do cqlsh --debug --connect-timeout="600" -u cassandra -p
> cassandra cassandra.env-1-cassandra.svc 9042 -k keyspace1_test -e "select
> cql_version from system.local"; sleep 1; done
> {code}
> if a specific Cassandra node address or IP is provided instead of service DNS
> name - the issue is not reproduced.
> Additional observation - stuck is happening in cqlsh after printing a result
> of select, so the select query itself is executed normally.
> The following logic was added to cqlsh.py to print debug logs in Cassandra
> python driver:
> {code:java}
> import logging
> logging.basicConfig(filename='/tmp/cqlsh.log', level=logging.DEBUG, format =
> '%(asctime)s | %(levelname)-8s | %(threadName)s | %(module)s:%(name)s |
> %(lineno)04d | %(message)s')
> logging.info('=')
> {code}
> The log captured for the cqlsh invocation when the issue is reproduced:
> [^cqlsh_debug.txt]
> According the log - cassandra.env-1-cassandra.svc provided as a contact
> point to cqlsh is resolved immediately to 3 node IPs, before any discovery
> queries to Cassandra servers:
> {code:java}
> 2021-03-18 21:37:11,566 | DEBUG| MainThread | pool:cassandra.pool | 0139
> | Host 10.129.19.19 is now marked up
> 2021-03-18 21:37:11,566 | DEBUG| MainThread | pool:cassandra.pool | 0139
> | Host 10.129.205.119 is now marked up
> 2021-03-18 21:37:11,566 | DEBUG| MainThread | pool:cassandra.pool | 0139
> | Host 10.130.169.162 is now marked up
> {code}
> the correspondent logic in cassandra/cluster.py from Cassandra python driver:
> {code:java}
> self.contact_points_resolved = [endpoint[4][0] for a in self.contact_points
>for endpoint in
> socket.getaddrinfo(a, self.port, socket.AF_UNSPEC, socket.SOCK_STREAM)]
> {code}
> So, the driver resolves all IPs for the DNS name, like:
> {code:java}
> nslookup cassandra.env-1-cassandra
> Server: 172.30.0.10
> Address:172.30.0.10#53
> Name: cassandra.env-1-cassandra.svc.cluster.local
> Address: 10.129.205.119
> Name: cassandra.env-1-cassandra.svc.cluster.local
> Address: 10.129.38.98
> Name: cassandra.env-1-cassandra.svc.cluster.local
> Address: 10.130.169.162
> {code}
> After it the driver uses all of the IPs as contact points.
> Several threads are used to work with connections in the driver, Thread-1
> and Thread-2 are used to handle events related to connection state change and
> execute re-connects.
> Once cqlsh executed a query and got a result - it triggers a graceful
> shutdown of the driver instance.
> The shutdown logic is closing connections:
> {code:java}
> 2021-03-18 21:37:14,140 | DEBUG| Dummy-3 |
> asyncorereactor:cassandra.io.asyncorereactor | 0368 | Closing connection
> (139784430944720) to 10.129.205.119
> 2021-03-18 21:37:14,140 | DEBUG| Dummy-3 |
> asyncorereactor:cassandra.io.asyncorereactor | 0375 | Closed socket to
> 10.129.205.119
> {code}
> At this moment of time in parallel the logic related to host events handling
> decides to re-connect for a host sometimes (race condition):
> {code:java}
> 2021-03-18 21:37:14,145 | DEBUG| Thread-2 | cluster:cassandra.cluster |
> 2792 | [control connection] Attempting to reconnect
> 2021-03-18 21:37:14,145 | DEBUG| Thread-2 | cluster:cassandra.cluster |
> 2742 | [control connection] Opening new connection to 10.129.205.119
> {code}
> The thread starts to wait for connect timeout to initiate a re-connection.
>
[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306220#comment-17306220
]
Michael Semb Wever commented on CASSANDRA-16497:
+1 to removing it, and revisiting it post 4.0.
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16530) Fix flaky test_ttl_deletions
[ https://issues.apache.org/jira/browse/CASSANDRA-16530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16530: Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Ekaterina Dimitrova, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Fix flaky test_ttl_deletions > > > Key: CASSANDRA-16530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16530 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test in slow environments. See > [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/362/testReport/junit/dtest-novnode.paging_test/TestPagingWithDeletions/test_ttl_deletions/] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306186#comment-17306186
]
Benjamin Lerer commented on CASSANDRA-16497:
My understanding is that the goal of this test was to check the SEPThreadpool
throughput. As such it does not make a lot of sense to me to simply bump the
timeout or replace the assertion.
In my opinion, we should simply remove the test and plan for the next release
to introduce some proper automated performance testing that allow us to catch
performance regressions.
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16531) cqlsh can stuck randomly during a connect-timeout period in Kubernetes
[
https://issues.apache.org/jira/browse/CASSANDRA-16531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-16531:
Since Version: 3.11.5
> cqlsh can stuck randomly during a connect-timeout period in Kubernetes
> --
>
> Key: CASSANDRA-16531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16531
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Attachments: cqlsh_debug.txt, pystack-2868.txt
>
>
> Hello, we get the following issue for cqlsh in Kubernetes environment.
> When cqlsh is executed against a head-less Cassandra service (which is
> configured for Cassandra pods) - it can stuck randomly during a
> connect-timeout period.
> We reproduced the issue using the following command:
> {code:java}
> for i in {1..1000}; do cqlsh --debug --connect-timeout="600" -u cassandra -p
> cassandra cassandra.env-1-cassandra.svc 9042 -k keyspace1_test -e "select
> cql_version from system.local"; sleep 1; done
> {code}
> if a specific Cassandra node address or IP is provided instead of service DNS
> name - the issue is not reproduced.
> Additional observation - stuck is happening in cqlsh after printing a result
> of select, so the select query itself is executed normally.
> The following logic was added to cqlsh.py to print debug logs in Cassandra
> python driver:
> {code:java}
> import logging
> logging.basicConfig(filename='/tmp/cqlsh.log', level=logging.DEBUG, format =
> '%(asctime)s | %(levelname)-8s | %(threadName)s | %(module)s:%(name)s |
> %(lineno)04d | %(message)s')
> logging.info('=')
> {code}
> The log captured for the cqlsh invocation when the issue is reproduced:
> [^cqlsh_debug.txt]
> According the log - cassandra.env-1-cassandra.svc provided as a contact
> point to cqlsh is resolved immediately to 3 node IPs, before any discovery
> queries to Cassandra servers:
> {code:java}
> 2021-03-18 21:37:11,566 | DEBUG| MainThread | pool:cassandra.pool | 0139
> | Host 10.129.19.19 is now marked up
> 2021-03-18 21:37:11,566 | DEBUG| MainThread | pool:cassandra.pool | 0139
> | Host 10.129.205.119 is now marked up
> 2021-03-18 21:37:11,566 | DEBUG| MainThread | pool:cassandra.pool | 0139
> | Host 10.130.169.162 is now marked up
> {code}
> the correspondent logic in cassandra/cluster.py from Cassandra python driver:
> {code:java}
> self.contact_points_resolved = [endpoint[4][0] for a in self.contact_points
>for endpoint in
> socket.getaddrinfo(a, self.port, socket.AF_UNSPEC, socket.SOCK_STREAM)]
> {code}
> So, the driver resolves all IPs for the DNS name, like:
> {code:java}
> nslookup cassandra.env-1-cassandra
> Server: 172.30.0.10
> Address:172.30.0.10#53
> Name: cassandra.env-1-cassandra.svc.cluster.local
> Address: 10.129.205.119
> Name: cassandra.env-1-cassandra.svc.cluster.local
> Address: 10.129.38.98
> Name: cassandra.env-1-cassandra.svc.cluster.local
> Address: 10.130.169.162
> {code}
> After it the driver uses all of the IPs as contact points.
> Several threads are used to work with connections in the driver, Thread-1
> and Thread-2 are used to handle events related to connection state change and
> execute re-connects.
> Once cqlsh executed a query and got a result - it triggers a graceful
> shutdown of the driver instance.
> The shutdown logic is closing connections:
> {code:java}
> 2021-03-18 21:37:14,140 | DEBUG| Dummy-3 |
> asyncorereactor:cassandra.io.asyncorereactor | 0368 | Closing connection
> (139784430944720) to 10.129.205.119
> 2021-03-18 21:37:14,140 | DEBUG| Dummy-3 |
> asyncorereactor:cassandra.io.asyncorereactor | 0375 | Closed socket to
> 10.129.205.119
> {code}
> At this moment of time in parallel the logic related to host events handling
> decides to re-connect for a host sometimes (race condition):
> {code:java}
> 2021-03-18 21:37:14,145 | DEBUG| Thread-2 | cluster:cassandra.cluster |
> 2792 | [control connection] Attempting to reconnect
> 2021-03-18 21:37:14,145 | DEBUG| Thread-2 | cluster:cassandra.cluster |
> 2742 | [control connection] Opening new connection to 10.129.205.119
> {code}
> The thread starts to wait for connect timeout to initiate a re-connection.
> {code:java}
> 2021-03-18 21:37:14,194 | DEBUG| Dummy-3 | cluster:cassandra.cluster |
> 3245 | Shutting down Cluster Scheduler
> 2021-03-18 21:37:14,245 | DEBUG| Dummy-3 | cluster:cassandra.cluster |
> 2848 | Shutting down control connection
> <--- stuck is here -->
> 2021-03-18 21:47:14,146 | DEBUG| Thread-2 |
> connection:cassandra.connection | 0639 | Not sending options message for new
>
[jira] [Created] (CASSANDRA-16531) cqlsh can stuck randomly during a connect-timeout period in Kubernetes
Dmitry Konstantinov created CASSANDRA-16531:
---
Summary: cqlsh can stuck randomly during a connect-timeout period
in Kubernetes
Key: CASSANDRA-16531
URL: https://issues.apache.org/jira/browse/CASSANDRA-16531
Project: Cassandra
Issue Type: Bug
Components: Tool/cqlsh
Reporter: Dmitry Konstantinov
Attachments: cqlsh_debug.txt, pystack-2868.txt
Hello, we get the following issue for cqlsh in Kubernetes environment.
When cqlsh is executed against a head-less Cassandra service (which is
configured for Cassandra pods) - it can stuck randomly during a connect-timeout
period.
We reproduced the issue using the following command:
{code:java}
for i in {1..1000}; do cqlsh --debug --connect-timeout="600" -u cassandra -p
cassandra cassandra.env-1-cassandra.svc 9042 -k keyspace1_test -e "select
cql_version from system.local"; sleep 1; done
{code}
if a specific Cassandra node address or IP is provided instead of service DNS
name - the issue is not reproduced.
Additional observation - stuck is happening in cqlsh after printing a result
of select, so the select query itself is executed normally.
The following logic was added to cqlsh.py to print debug logs in Cassandra
python driver:
{code:java}
import logging
logging.basicConfig(filename='/tmp/cqlsh.log', level=logging.DEBUG, format =
'%(asctime)s | %(levelname)-8s | %(threadName)s | %(module)s:%(name)s |
%(lineno)04d | %(message)s')
logging.info('=')
{code}
The log captured for the cqlsh invocation when the issue is reproduced:
[^cqlsh_debug.txt]
According the log - cassandra.env-1-cassandra.svc provided as a contact point
to cqlsh is resolved immediately to 3 node IPs, before any discovery queries to
Cassandra servers:
{code:java}
2021-03-18 21:37:11,566 | DEBUG| MainThread | pool:cassandra.pool | 0139 |
Host 10.129.19.19 is now marked up
2021-03-18 21:37:11,566 | DEBUG| MainThread | pool:cassandra.pool | 0139 |
Host 10.129.205.119 is now marked up
2021-03-18 21:37:11,566 | DEBUG| MainThread | pool:cassandra.pool | 0139 |
Host 10.130.169.162 is now marked up
{code}
the correspondent logic in cassandra/cluster.py from Cassandra python driver:
{code:java}
self.contact_points_resolved = [endpoint[4][0] for a in self.contact_points
for endpoint in
socket.getaddrinfo(a, self.port, socket.AF_UNSPEC, socket.SOCK_STREAM)]
{code}
So, the driver resolves all IPs for the DNS name, like:
{code:java}
nslookup cassandra.env-1-cassandra
Server: 172.30.0.10
Address:172.30.0.10#53
Name: cassandra.env-1-cassandra.svc.cluster.local
Address: 10.129.205.119
Name: cassandra.env-1-cassandra.svc.cluster.local
Address: 10.129.38.98
Name: cassandra.env-1-cassandra.svc.cluster.local
Address: 10.130.169.162
{code}
After it the driver uses all of the IPs as contact points.
Several threads are used to work with connections in the driver, Thread-1 and
Thread-2 are used to handle events related to connection state change and
execute re-connects.
Once cqlsh executed a query and got a result - it triggers a graceful shutdown
of the driver instance.
The shutdown logic is closing connections:
{code:java}
2021-03-18 21:37:14,140 | DEBUG| Dummy-3 |
asyncorereactor:cassandra.io.asyncorereactor | 0368 | Closing connection
(139784430944720) to 10.129.205.119
2021-03-18 21:37:14,140 | DEBUG| Dummy-3 |
asyncorereactor:cassandra.io.asyncorereactor | 0375 | Closed socket to
10.129.205.119
{code}
At this moment of time in parallel the logic related to host events handling
decides to re-connect for a host sometimes (race condition):
{code:java}
2021-03-18 21:37:14,145 | DEBUG| Thread-2 | cluster:cassandra.cluster |
2792 | [control connection] Attempting to reconnect
2021-03-18 21:37:14,145 | DEBUG| Thread-2 | cluster:cassandra.cluster |
2742 | [control connection] Opening new connection to 10.129.205.119
{code}
The thread starts to wait for connect timeout to initiate a re-connection.
{code:java}
2021-03-18 21:37:14,194 | DEBUG| Dummy-3 | cluster:cassandra.cluster | 3245
| Shutting down Cluster Scheduler
2021-03-18 21:37:14,245 | DEBUG| Dummy-3 | cluster:cassandra.cluster | 2848
| Shutting down control connection
<--- stuck is here -->
2021-03-18 21:47:14,146 | DEBUG| Thread-2 | connection:cassandra.connection
| 0639 | Not sending options message for new connection(139784430946896) to
10.129.205.119 because compression is disabled and a cql version was not
specified
2021-03-18 21:47:14,147 | DEBUG| Thread-2 | connection:cassandra.connection
| 0712 | Sending StartupMessage on
2021-03-18 21:47:14,147 | DEBUG| Thread-2 | connection:cassandra.connection
| 0720 | Sent StartupMessage on
2021-03-18 21:47:14,147 | DEBUG| Thread-2 |
[jira] [Comment Edited] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306156#comment-17306156
]
Michael Semb Wever edited comment on CASSANDRA-16497 at 3/22/21, 12:23 PM:
---
[~benedict], this test failure is currently the biggest blocker we have to
4.0-rc1, as it is pretty much consistently failing in CI.
I can think of a few ways forward here, but am not sure which is best…
- bump the
[timeout|https://github.com/apache/cassandra/blob/trunk/test/burn/org/apache/cassandra/concurrent/LongSharedExecutorPoolTest.java#L209-L210]
from 100ms to 1s
- replace the
[assertion|https://github.com/apache/cassandra/blob/trunk/test/burn/org/apache/cassandra/concurrent/LongSharedExecutorPoolTest.java#L169]
with just a system.out line
- rewrite the test to jmh
- just remove the test
was (Author: michaelsembwever):
[~benedict], this test failure is currently the biggest blocker we have to
4.0-rc1, as it is pretty much consistently failing in CI.
I can think of a few ways forward here, but am not sure which is best…
- bump the timeout from 100ms to 1s
- replace the assertion with just a system.out line
- rewrite the test to jmh
- just remove the test
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306156#comment-17306156
]
Michael Semb Wever edited comment on CASSANDRA-16497 at 3/22/21, 12:20 PM:
---
[~benedict], this test failure is currently the biggest blocker we have to
4.0-rc1, as it is pretty much consistently failing in CI.
I can think of a few ways forward here, but am not sure which is best…
- bump the timeout from 100ms to 1s
- replace the assertion with just a system.out line
- rewrite the test to jmh
- just remove the test
was (Author: michaelsembwever):
[~benedict], this test failure is currently the biggest blocker we have to
4.0-rc1, as it is pretty much consistently failing in CI.
I can a few ways forward here, but am not sure which is best…
- bump the timeout from 100ms to 1s
- replace the assertion with just a system.out line
- rewrite the test to jmh
- just remove the test
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306156#comment-17306156
]
Michael Semb Wever commented on CASSANDRA-16497:
[~benedict], this test failure is currently the biggest blocker we have to
4.0-rc1, as it is pretty much consistently failing in CI.
I can a few ways forward here, but am not sure which is best…
- bump the timeout from 100ms to 1s
- replace the assertion with just a system.out line
- rewrite the test to jmh
- just remove the test
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16530) Fix flaky test_ttl_deletions
[ https://issues.apache.org/jira/browse/CASSANDRA-16530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306099#comment-17306099 ] Berenguer Blasi commented on CASSANDRA-16530: - The issue only reproduces on slow environments where fetching the results can miss some rows bc TTL has already kicked in. Increasing the TLL window fixes the issue. > Fix flaky test_ttl_deletions > > > Key: CASSANDRA-16530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16530 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test in slow environments. See > [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/362/testReport/junit/dtest-novnode.paging_test/TestPagingWithDeletions/test_ttl_deletions/] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16530) Fix flaky test_ttl_deletions
[ https://issues.apache.org/jira/browse/CASSANDRA-16530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16530: Test and Documentation Plan: Tested locally as repro'ing is only possible on slow enviroments Status: Patch Available (was: In Progress) > Fix flaky test_ttl_deletions > > > Key: CASSANDRA-16530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16530 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test in slow environments. See > [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/362/testReport/junit/dtest-novnode.paging_test/TestPagingWithDeletions/test_ttl_deletions/] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16530) Fix flaky test_ttl_deletions
[ https://issues.apache.org/jira/browse/CASSANDRA-16530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16530: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Test/unit Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > Fix flaky test_ttl_deletions > > > Key: CASSANDRA-16530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16530 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > > Flaky test in slow environments. See > [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/362/testReport/junit/dtest-novnode.paging_test/TestPagingWithDeletions/test_ttl_deletions/] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16530) Fix flaky test_ttl_deletions
[ https://issues.apache.org/jira/browse/CASSANDRA-16530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16530: Fix Version/s: 4.0-rc > Fix flaky test_ttl_deletions > > > Key: CASSANDRA-16530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16530 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > > Flaky test in slow environments. See > [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/362/testReport/junit/dtest-novnode.paging_test/TestPagingWithDeletions/test_ttl_deletions/] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16530) Fix flaky test_ttl_deletions
Berenguer Blasi created CASSANDRA-16530: --- Summary: Fix flaky test_ttl_deletions Key: CASSANDRA-16530 URL: https://issues.apache.org/jira/browse/CASSANDRA-16530 Project: Cassandra Issue Type: Bug Reporter: Berenguer Blasi Assignee: Berenguer Blasi Flaky test in slow environments. See [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/362/testReport/junit/dtest-novnode.paging_test/TestPagingWithDeletions/test_ttl_deletions/] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15892) JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianluca Righetto updated CASSANDRA-15892: -- Attachment: CASSANDRA-15892-07babf3c-node2-deadlock-thread-dump.txt > JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild > > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-rc > > Attachments: CASSANDRA-15892-07babf3c-node2-deadlock-thread-dump.txt > > Time Spent: 0.5h > Remaining Estimate: 0h > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15892) JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianluca Righetto updated CASSANDRA-15892: -- Test and Documentation Plan: Reproduction steps added to the comments. Patches available: https://github.com/grighetto/cassandra/pull/3 https://github.com/apache/cassandra-dtest/pull/130 was:Impossible to repro Status: Patch Available (was: In Progress) > JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild > > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 0.5h > Remaining Estimate: 0h > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15892) JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305936#comment-17305936 ] Gianluca Righetto commented on CASSANDRA-15892: --- [~e.dimitrova] Would you be able to try the reproduction steps I shared above and review the patch? > JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild > > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 0.5h > Remaining Estimate: 0h > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15892) JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305935#comment-17305935 ] Gianluca Righetto commented on CASSANDRA-15892: --- I did some more investigation recently and got to the bottom of this issue and this is actually a runtime problem, not simply a flaky test. I have a patch available, but I'll try to break it down below in a way that makes it easier to understand what's going on: *Dtest*: - The dtest is designed to initially write data to only 2 nodes, then a third node is started and _nodetool rebuild_ is invoked, so the sstables start to be streamed to node 3. - The goal of the test is to make sure the rebuild process is able to continue later, in case the first attempt fails for whatever reason. - To simulate a failure, byteman is used on node 3 to throw an exception (only once) when it receives a message from node 2. - That will make node 2 receive a Stream Failed message back. If that message is processed and the event-loop thread tries to close the network channel while the writer thread is Parked waiting for the stream to complete, there will be a deadlock. - The second time _nodetool rebuild_ command is invoked by the dtest, node 2 will be in deadlock already, so the test will remain on-hold indefinitely (eventually time out on Jenkins). *Reproduction steps*: In your IDE, set a couple of breakpoints at the following lines, then attach the debugger to the process of node 2 and make sure the first method below (_StreamSession#closeSession_) is executed before the line of the second breakpoint. [https://github.com/apache/cassandra/blob/4d49308a3fbc354850126a5ec128b11a3aca4007/src/java/org/apache/cassandra/streaming/StreamSession.java#L485] [https://github.com/apache/cassandra/blob/4d49308a3fbc354850126a5ec128b11a3aca4007/src/java/org/apache/cassandra/net/AsyncStreamingOutputPlus.java#L91] *Patch*: The patch simply handles the channel's _closeFuture_ callback asynchronously, that allows for the channel to be fully closed and then the [error handler|https://github.com/apache/cassandra/blob/4d49308a3fbc354850126a5ec128b11a3aca4007/src/java/org/apache/cassandra/net/AsyncChannelOutputPlus.java#L100] in _AsyncChannelOutputPlus_ is executed to clean things up and Unpark the thread, so no deadlock occurs. C* patch: [https://github.com/grighetto/cassandra/pull/3] Dtest patch: [https://github.com/apache/cassandra-dtest/pull/130] (remove @flaky annotation and add ignore-log pattern) *CircleCI Results*: JVM 11 Dtests: [https://app.circleci.com/pipelines/github/grighetto/cassandra/32/workflows/77ef945f-8cf9-4c8b-84c6-13bc48078275/jobs/198] JVM 8 Dtests: [https://app.circleci.com/pipelines/github/grighetto/cassandra/32/workflows/dfc132e9-e4c4-4ea5-bc8e-d56e73679bcf/jobs/189] > JAVA 8/11: test_resumable_rebuild - rebuild_test.TestRebuild > > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 0.5h > Remaining Estimate: 0h > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16245) Implement repair quality test scenarios
[ https://issues.apache.org/jira/browse/CASSANDRA-16245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305923#comment-17305923 ] Alexander Dejanovski commented on CASSANDRA-16245: -- Thanks [~cscotta]! We're done with this ticket. There was some instability in the CI runs lately due to CASSANDRA-16478 which was fixed with CASSANDRA-16480 and it seems like it's passing nicely since then. > Implement repair quality test scenarios > --- > > Key: CASSANDRA-16245 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16245 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alexander Dejanovski >Assignee: Radovan Zvoncek >Priority: Normal > Fix For: 4.0-rc > > > Implement the following test scenarios in a new test suite for repair > integration testing with significant load: > Generate/restore a workload of ~100GB per node. Medusa should be considered > to create the initial backup which could then be restored from an S3 bucket > to speed up node population. > Data should on purpose require repair and be generated accordingly. > Perform repairs for a 3 nodes cluster with 4 cores each and 16GB-32GB RAM > (m5d.xlarge instances would be the most cost efficient type). > Repaired keyspaces will use RF=3 or RF=2 in some cases (the latter is for > subranges with different sets of replicas). > ||Mode||Version||Settings||Checks|| > |Full repair|trunk|Sequential + All token ranges|"No anticompaction > (repairedAt==0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range"| > |Full repair|trunk|Parallel + Primary range|"No anticompaction (repairedAt==0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range"| > |Full repair|trunk|Force terminate repair shortly after it was > triggered|Repair threads must be cleaned up| > |Subrange repair|trunk|Sequential + single token range|"No anticompaction > (repairedAt==0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range"| > |Subrange repair|trunk|Parallel + 10 token ranges which have the same > replicas|"No anticompaction (repairedAt == 0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range > A single repair session will handle all subranges at once"| > |Subrange repair|trunk|Parallel + 10 token ranges which have different > replicas|"No anticompaction (repairedAt==0) > Out of sync ranges > 0 > Subsequent run must show no out of sync range > More than one repair session is triggered to process all subranges"| > |Incremental repair|trunk|"Parallel (mandatory) > No compaction during repair"|"Anticompaction status (repairedAt != 0) on all > SSTables > No pending repair on SSTables after completion (could require to wait a bit > as this will happen asynchronously) > Out of sync ranges > 0 + Subsequent run must show no out of sync range"| > |Incremental repair|trunk|"Parallel (mandatory) > Major compaction triggered during repair"|"Anticompaction status (repairedAt > != 0) on all SSTables > No pending repair on SSTables after completion (could require to wait a bit > as this will happen asynchronously) > Out of sync ranges > 0 + Subsequent run must show no out of sync range"| > |Incremental repair|trunk|Force terminate repair shortly after it was > triggered.|Repair threads must be cleaned up| -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16476) Update the Compact Storage related docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305906#comment-17305906 ] Berenguer Blasi commented on CASSANDRA-16476: - I left just small comment. The only issue I have is that it reads weird in my head where there seems to be 'duplication' or 'repetition' between the first and second halves. But if that's just me then +1. > Update the Compact Storage related docs > --- > > Key: CASSANDRA-16476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16476 > Project: Cassandra > Issue Type: Task > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0-rc > > > Compact Storage partial support was returned recently. > We need to elaborate in the docs on what does this mean to the users. > * Compact Storage support was returned, except for the supercolumn tables. > * This was done because during the big 4.0 beta testing changes of behavior > after DROP COMPACT STORAGE usage were revealed. > /CC [~ifesdjeen] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16500) Missing validation in AbstractType.writeValue():
[
https://issues.apache.org/jira/browse/CASSANDRA-16500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305899#comment-17305899
]
Berenguer Blasi commented on CASSANDRA-16500:
-
I'd say +1 and that they are not related bc most are timeouts which probably
relate to CASSANDRA-16493. But:
-
dtest-upgrade.upgrade_tests.compatibility_flag_test.TestCompatibilityFlag.test__compatibility_flag_off_3014
-
org.apache.cassandra.distributed.test.NetstatsRepairStreamingTest.testWithCompressionDisabled
annoy me. If you're OCD like me I'd rebase now that was merged and run an extra
CI.
> Missing validation in AbstractType.writeValue():
>
>
> Key: CASSANDRA-16500
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16500
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Benjamin Lerer
>Assignee: Alexandre Dutra
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Some validation checks present in {{AbstractType.writeValue()}} in
> {{cassandra-3.11}} are not there in {{trunk}}.
> In 3.11 the checks used assertion. It would make sense to use
> {{IOExceptions}} instead as used in {{AbstractType.readValue()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
