[jira] [Commented] (CASSANDRA-16525) Gossip STATUS can be either missing during upgrade or stale after upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-16525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305584#comment-17305584
]
Yifan Cai commented on CASSANDRA-16525:
---
Thank you for the quick fix!
+1
Here is the cause of the test regression.
[c591978f4|https://github.com/apache/cassandra/commit/c591978f4d265e42d0132418005ba63a99278c75]
changed the cluster version checker in the gossiper to only start when the
Gossiper is started. The failed test was not configured to start gossiper (no
Feature.GOSSIP), so the checker always returns false. The checker updates every
60 seconds, so increasing the attempts from 30 to 90 makes sense.
> Gossip STATUS can be either missing during upgrade or stale after upgrade
> -
>
> Key: CASSANDRA-16525
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16525
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta5, 4.0
>
> Attachments:
> Demonstrate-a-scenario-that-a-node-may-hold-the-stale-status.patch
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> In 4.0, new application states are added in Gossip and the corresponding old
> ones are deprecated, e.g. {{STATUS}} and the successor {{STATUS_WITH_PORT}}.
> There are 2 issues discovered by the jvm (upgrade) dtest. First, the
> {{STATUS}} field of a peer in the lower version (e.g. 3.0) node can be
> missing. Second, it is possible the {{STATUS}} coexist with the new state
> {{STATUS_WITH_PORT}} in the 4.0 nodes after cluster is fully upgraded and the
> {{STATUS}} field can becomes stale as the 4.0 node filters out when applying
> new state.
> The first issue can happen in this scenario. During upgrade, node1 and node2
> are in v4, and node3 is still in v3. If node3 only gets the gossip info
> regarding node2 from node1, the {{STATUS}} field of node2 will be missing in
> node3's local state, which is unexpected. There could be many reasons that
> node3 does not exchange gossip with node2 directly, e.g. network issue
> between node2 and node3, or node2 simply does not select node3 when
> initiating the gossip round. Gossip should be resilient to it. I have a [jvm
> upgrade
> dtest|https://github.com/yifan-c/cassandra/blob/CASSANDRA-16525/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeGossipTest.java#L81]
> to demonstrate the unexpected behavior.
> The cause of the second issue is more subtle. Heartbeat update happens as
> part of the Gossip task and outside of the GossipStage. When node2 just
> update its local application state and received a {{SYN}} from node1, node 2
> just replies its gossip state without updating the heartbeat version. When
> node1 receives it, it first filters out the legacy {{STATUS}} field, and only
> saves the new one. So far so good. However, node2 soon updates its heart
> beat, and node1 realizes that its local version is less than the remove
> (node2) version in the next gossip round. So node2 sends {{STATUS}} along to
> node1. Because it does not come together with the new field, node1 does not
> filter it out when receiving. Boo! Node1 now has the {{STATUS}} field from
> node2. Such field can become stale and diverge with its successor in a live
> cluster. The jvm upgrade test
> [testStatusFieldShouldExistInOldVersionNodes|https://github.com/yifan-c/cassandra/blob/CASSANDRA-16525/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeGossipTest.java#L47]
> can fairly easy to reproduce it when the entire cluster is upgraded. And
> there is another jvm dtest (with source changes to help make deterministic
> result, see the attached
> Demonstrate-a-scenario-that-a-node-may-hold-the-stale-status.patch) that
> demonstrates the {{STATUS}} can be replicated to the peer and become stale.
> The fix is to
> 1) retain the legacy fields if the cluster is still in mixed mode
> 2) remove the legacy field when cluster is fully upgraded
--
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-16525) Gossip STATUS can be either missing during upgrade or stale after upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-16525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305569#comment-17305569
]
Michael Semb Wever commented on CASSANDRA-16525:
This broke
[MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck|https://ci-cassandra.apache.org/job/Cassandra-trunk/348/].
It had failed in the above [CI
runs|https://ci-cassandra.apache.org/job/Cassandra-devbranch/498/] as well.
Proposed
[patch|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk/16525_test-fix]
to fix, and CI
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-jvm-dtest-upgrade/314/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-jvm-dtest-upgrade/314/]
> Gossip STATUS can be either missing during upgrade or stale after upgrade
> -
>
> Key: CASSANDRA-16525
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16525
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta5, 4.0
>
> Attachments:
> Demonstrate-a-scenario-that-a-node-may-hold-the-stale-status.patch
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> In 4.0, new application states are added in Gossip and the corresponding old
> ones are deprecated, e.g. {{STATUS}} and the successor {{STATUS_WITH_PORT}}.
> There are 2 issues discovered by the jvm (upgrade) dtest. First, the
> {{STATUS}} field of a peer in the lower version (e.g. 3.0) node can be
> missing. Second, it is possible the {{STATUS}} coexist with the new state
> {{STATUS_WITH_PORT}} in the 4.0 nodes after cluster is fully upgraded and the
> {{STATUS}} field can becomes stale as the 4.0 node filters out when applying
> new state.
> The first issue can happen in this scenario. During upgrade, node1 and node2
> are in v4, and node3 is still in v3. If node3 only gets the gossip info
> regarding node2 from node1, the {{STATUS}} field of node2 will be missing in
> node3's local state, which is unexpected. There could be many reasons that
> node3 does not exchange gossip with node2 directly, e.g. network issue
> between node2 and node3, or node2 simply does not select node3 when
> initiating the gossip round. Gossip should be resilient to it. I have a [jvm
> upgrade
> dtest|https://github.com/yifan-c/cassandra/blob/CASSANDRA-16525/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeGossipTest.java#L81]
> to demonstrate the unexpected behavior.
> The cause of the second issue is more subtle. Heartbeat update happens as
> part of the Gossip task and outside of the GossipStage. When node2 just
> update its local application state and received a {{SYN}} from node1, node 2
> just replies its gossip state without updating the heartbeat version. When
> node1 receives it, it first filters out the legacy {{STATUS}} field, and only
> saves the new one. So far so good. However, node2 soon updates its heart
> beat, and node1 realizes that its local version is less than the remove
> (node2) version in the next gossip round. So node2 sends {{STATUS}} along to
> node1. Because it does not come together with the new field, node1 does not
> filter it out when receiving. Boo! Node1 now has the {{STATUS}} field from
> node2. Such field can become stale and diverge with its successor in a live
> cluster. The jvm upgrade test
> [testStatusFieldShouldExistInOldVersionNodes|https://github.com/yifan-c/cassandra/blob/CASSANDRA-16525/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeGossipTest.java#L47]
> can fairly easy to reproduce it when the entire cluster is upgraded. And
> there is another jvm dtest (with source changes to help make deterministic
> result, see the attached
> Demonstrate-a-scenario-that-a-node-may-hold-the-stale-status.patch) that
> demonstrates the {{STATUS}} can be replicated to the peer and become stale.
> The fix is to
> 1) retain the legacy fields if the cluster is still in mixed mode
> 2) remove the legacy field when cluster is fully upgraded
--
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-16451) Add ability to ttl snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305524#comment-17305524
]
Abuli Palagashvili commented on CASSANDRA-16451:
[~paulo] I have played a bit with CCM and manually-made snapshots.As I
understand right now, after snapshot creation it is not managed by
cassandra.Also, each snapshot has it's own manifest.json file with metadata.So,
we can write expiration timestamp to each such file and make cassandra
regularly scanning folders with keyspaces/column families and
detecting/removing outdated snapshots.Correct me if I'm wrong, please.
> Add ability to ttl snapshots
>
>
> Key: CASSANDRA-16451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16451
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Priority: Normal
> Labels: gsoc2021, mentor
>
> It should be possible to add a TTL to snapshots, after which it automatically
> cleans itself up.
> This will be useful together with the {{auto_snapshot}} option, where you
> want to keep an emergency snapshot in case of accidental drop or truncation
> but automatically remove it after a specified period when it's no longer
> useful. So in addition to allowing a user to specify a snapshot ttl on
> {{nodetool snapshot}} we should have a {{auto_snapshot_ttl}} option that
> allows a user to set a ttl for automatic snaphots on drop/truncate.
--
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-16423) Grammatically updated the tech docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16423: - Change Category: Semantic Complexity: Low Hanging Fruit Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Grammatically updated the tech docs > --- > > Key: CASSANDRA-16423 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16423 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Shachar Almagor >Priority: Low > > small grammaticall update to the tech docs. > > https://github.com/shachar-almagor/cassandra/tree/my-contribution -- 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-16423) Grammatically updated the tech docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-16423: - Authors: Shachar Almagor Test and Documentation Plan: N/A; doc update. Status: Patch Available (was: In Progress) [https://github.com/shachar-almagor/cassandra/tree/my-contribution] > Grammatically updated the tech docs > --- > > Key: CASSANDRA-16423 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16423 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Shachar Almagor >Priority: Low > > small grammaticall update to the tech docs. > > https://github.com/shachar-almagor/cassandra/tree/my-contribution -- 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-16423) Grammatically updated the tech docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305522#comment-17305522 ] C. Scott Andreas commented on CASSANDRA-16423: -- Thanks for this patch; the changes look good to me. Moving to Patch Available. > Grammatically updated the tech docs > --- > > Key: CASSANDRA-16423 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16423 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Shachar Almagor >Priority: Normal > > small grammaticall update to the tech docs. > > https://github.com/shachar-almagor/cassandra/tree/my-contribution -- 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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305518#comment-17305518 ] C. Scott Andreas commented on CASSANDRA-16262: -- Thanks [~ifesdjeen]. Do you have a sense of what specific scope we should cover under this ticket, and/or what a definition of done might look like? > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-15585) 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation
[ https://issues.apache.org/jira/browse/CASSANDRA-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305517#comment-17305517 ] C. Scott Andreas commented on CASSANDRA-15585: -- [~blerer] Based on what's described above, I don't think there's anything left here that should be considered blocking scope for 4.0. Harry coverage and use has expanded quite a bit; many of the new tests added to C* utilize random input and assert based on properties; cassandra-diff has been widely used by contributors to compare 3.0 and 4.0 clusters, etc. If there's anything further, we should track it under a more specific follow-up ticket – but I don't see such tickets as blocking in scope, either. I'll mark this resolved. > 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation > - > > Key: CASSANDRA-15585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15585 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Josh McKenzie >Priority: Normal > Fix For: 4.0-rc > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Jordan West* > This area refers to contributions to test frameworks/tooling (e.g., dtests, > QuickTheories, CASSANDRA-14821), and automation enabling those tools to be > applied at scale (e.g., replay testing via Spark-based replay of captured FQL > logs). -- 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-15585) 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation
[ https://issues.apache.org/jira/browse/CASSANDRA-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15585: - Resolution: Done Status: Resolved (was: Open) > 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation > - > > Key: CASSANDRA-15585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15585 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Josh McKenzie >Priority: Normal > Fix For: 4.0-rc > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Jordan West* > This area refers to contributions to test frameworks/tooling (e.g., dtests, > QuickTheories, CASSANDRA-14821), and automation enabling those tools to be > applied at scale (e.g., replay testing via Spark-based replay of captured FQL > logs). -- 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=17305516#comment-17305516 ] C. Scott Andreas commented on CASSANDRA-16245: -- This is great! [~adejanovski] I see that the last PR mentioned above has been merged. Is there anything left on this ticket? > 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-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=17305492#comment-17305492
]
Brandon Williams commented on CASSANDRA-16528:
--
You can delete all the nonexistent files you like:
https://github.com/apache/cassandra/tree/trunk/lib
If you mean build/lib, you can delete the entire build directory after building.
> 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] [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=17305490#comment-17305490
]
LHX commented on CASSANDRA-16528:
-
If these are not actually used by cassandra, would it be ok to delete the
associated .jar files from the lib directory on a machine running cassandra?
[~brandon.williams]
> 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] [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=17305402#comment-17305402 ] Michael Semb Wever commented on CASSANDRA-16476: +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
