[jira] [Commented] (CASSANDRA-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716926#comment-17716926 ] Tatu Saloranta commented on CASSANDRA-16855: [~smiklosovic] not at all, would appreciate it a lot! > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18340) Bump snakeyaml from 1.26 to 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711562#comment-17711562 ] Tatu Saloranta commented on CASSANDRA-18340: At very least why not go to 1.33? While it is true that last few versions have mostly been about small things & CVEs (... which may be big if (and only if) usage is applicable). But API compatibility has been good. And if using 1.33 without calling any deprecated methods, 2.0 should actually be swappable by users (there are a few deprecated methods removed from SnakeYAML 2.x). > Bump snakeyaml from 1.26 to 2.0 > --- > > Key: CASSANDRA-18340 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18340 > Project: Cassandra > Issue Type: New Feature >Reporter: Bipin Prasad >Assignee: Bipin Prasad >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 > To see the CVEs, goto > [https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.1.0] > and seach for [org.yaml|https://mvnrepository.com/artifact/org.yaml] » > [snakeyaml|https://mvnrepository.com/artifact/org.yaml/snakeyaml] under > compile dependencies.Vulnerabilites are listed thusly: > > Direct vulnerabilities: > [CVE-2022-41854|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41854] > [CVE-2022-38752|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38752] > [CVE-2022-38751|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38751] > [View 4 more ...|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] > Vulnerabilities from dependencies: > [CVE-2022-22971|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22971] > [CVE-2022-22970|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22970] > [CVE-2022-22968|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22968] > . -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529666#comment-17529666 ] Tatu Saloranta commented on CASSANDRA-17556: I am late to the party but I really don't think there is a big change for significant performance degradation; beyond likelihood that any upgrade could have it. But I understand that since there was one last time – highly unusual case fwtw – there is desire to be doubly sure there is due diligence before upgrade. > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.13, 4.1, 4.0.4 > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523889#comment-17523889 ] Tatu Saloranta commented on CASSANDRA-17556: Performance changes (or at least negatives ones) are rather rare so that issue was an outlier. Although I can see how this specific type of change could seem suspicious to be sure. But I do not think fix here should have any measurable performance impact; and since for 2.12.6.1 it is literally the only change beyond 2.12.6, that should be particularly safe. I wouldn't expect 2.12 -> 2.13 have meaningful performance difference either, but there are more changes that being a minor version bump. Put another way: I am not aware of any performance degradation between 2.12(.6) and 2.13(.2), nor expect there to be anything. But it is not possible to prove something does not exist, in general. > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523820#comment-17523820 ] Tatu Saloranta edited comment on CASSANDRA-17556 at 4/18/22 6:05 PM: - Yeah this would be covered by either tiny bump to 2.12.6.1 of jackson-databind, or, with 2.13.2.1 (or 2.13.2.2) of jackson-databind. I don't think Cassandra would actually be exposed by this CVE (unless I misremember limited usage there is for Jackson databind), but I know that sec scan tools have no concept of actual applicability to tell it "no, it is actually not a problem" so it tends to be easier to Just Upgrade That Dep to silence bogus warnings. I do check both of handles but it doesn't hurt using both so that's fine too :) was (Author: cowtowncoder): Yeah this would be covered by either tiny bump to 2.12.6.1 of jackson-databind, or, with 2.13.2.1 (or 2.13.2.2) of jackson-databind. I don't think Cassandra would actually be exposed by this CVE (unless I misremember limited usage there is for Jackson databind), but I know that sec scan tools have no concept of actual applicability to tell it "no, it is actually not a problem" so it tends to be easier to Just Upgrade That Dep to silence bogus warnings. > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523820#comment-17523820 ] Tatu Saloranta commented on CASSANDRA-17556: Yeah this would be covered by either tiny bump to 2.12.6.1 of jackson-databind, or, with 2.13.2.1 (or 2.13.2.2) of jackson-databind. I don't think Cassandra would actually be exposed by this CVE (unless I misremember limited usage there is for Jackson databind), but I know that sec scan tools have no concept of actual applicability to tell it "no, it is actually not a problem" so it tends to be easier to Just Upgrade That Dep to silence bogus warnings. > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507838#comment-17507838 ] Tatu Saloranta commented on CASSANDRA-16855: Sorry [~smiklosovic] I dropped the ball here; no progress. Would need to get back and see what work was still needed, if I can reuse changes from PR. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17401) Race condition in QueryProcessor causes just prepared statement not to be in the prepared statements cache
[ https://issues.apache.org/jira/browse/CASSANDRA-17401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17496917#comment-17496917 ] Tatu Saloranta commented on CASSANDRA-17401: It seems to me that returning `null` – if that is to be expected – definitely needs to be well documented. It would also seem quite awkward for caller to essentially have to retry the operation, theoretically multiple times (more than 2 threads). Or perhaps I have misunderstood something. > Race condition in QueryProcessor causes just prepared statement not to be in > the prepared statements cache > -- > > Key: CASSANDRA-17401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17401 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Senic >Priority: Normal > > The changes in the > [QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638] > method that were introduced in versions *4.0.2* and *3.11.12* can cause a > race condition between two threads trying to concurrently prepare the same > statement. This race condition can cause removing of a prepared statement > from the cache, after one of the threads has received the result of the > prepare and eventually uses MD5Digest to call > [QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215]. > The race condition looks like this: > * Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false > * Thread1 executes eviction of hashes > * Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false > * Thread1 prepares the statement and caches it > * Thread1 returns the result of the prepare > * Thread2 executes eviction of hashes > * Thread1 tries to execute the prepared statement with the received > MD5Digest, but statement is not in the cache as it was evicted by Thread2 > I tried to reproduce this by using a Java driver, but hitting this case from > a client side is highly unlikely and I can not simulate the needed race > condition. However, we can easily reproduce this in Stargate (details > [here|https://github.com/stargate/stargate/pull/1647]), as it's closer to > QueryProcessor. > Reproducing this in a unit test is fairly easy. I am happy to showcase this > if needed. > Note that the issue can occur only when safeToReturnCached is resolved as > false. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tatu Saloranta reassigned CASSANDRA-15453:
--
Assignee: (was: Tatu Saloranta)
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tatu Saloranta reassigned CASSANDRA-15453:
--
Assignee: Tatu Saloranta
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Assignee: Tatu Saloranta
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428357#comment-17428357
]
Tatu Saloranta edited comment on CASSANDRA-15453 at 10/13/21, 6:37 PM:
---
Also created second PR:
[https://github.com/apache/cassandra/pull/1266]
which upgrades Guava to 25.1-jre. One change I am unsure about is to
`cassandra-driver-core`: upgrade to (at least) 3.2.0 is a must wrt Guava, but
there are some issues with protocol handling that I hope will not complicate
actual operation, but that required a small (? ) change to test code.
All local tests (ant test) pass with these changes as well (first had fails
before upgrading Airline dependency) so would need to get full integration
tests done next.
was (Author: cowtowncoder):
Also created second PR:
[https://github.com/apache/cassandra/pull/1266]
which upgrades Guava to 25.1-jre. One change I am unsure about is to
`cassandra-driver-core`: upgrade to (at least) 3.2.0 is a must wrt Guava, but
there are some issues with protocol handling that I hope will not complicate
actual operation, but that required a small (? ) change to test code.
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428357#comment-17428357
]
Tatu Saloranta commented on CASSANDRA-15453:
Also created second PR:
[https://github.com/apache/cassandra/pull/1266]
which upgrades Guava to 25.1-jre. One change I am unsure about is to
`cassandra-driver-core`: upgrade to (at least) 3.2.0 is a must wrt Guava, but
there are some issues with protocol handling that I hope will not complicate
actual operation, but that required a small (? ) change to test code.
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427804#comment-17427804
]
Tatu Saloranta edited comment on CASSANDRA-15453 at 10/12/21, 7:11 PM:
---
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
Passes local test suite (ant clean test) without failures.
And matching PR:
https://github.com/apache/cassandra/pull/1265
was (Author: cowtowncoder):
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
Passes local test suite (ant clean test) without failures.
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427876#comment-17427876
]
Tatu Saloranta commented on CASSANDRA-15453:
Thank you [~slachiewicz]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427804#comment-17427804
]
Tatu Saloranta edited comment on CASSANDRA-15453 at 10/12/21, 7:05 PM:
---
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
Passes local test suite (ant clean test) without failures.
was (Author: cowtowncoder):
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tatu Saloranta updated CASSANDRA-15453:
---
Attachment: cass-3.11-guava-19.0.patch
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427804#comment-17427804
]
Tatu Saloranta commented on CASSANDRA-15453:
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427795#comment-17427795
]
Tatu Saloranta edited comment on CASSANDRA-15453 at 10/12/21, 5:09 PM:
---
Diff for patch to use Guava 20.0: - removed -
EDIT: unfortunately as I noted on CASSANDRA-15248 there is a test dependency
that croaks with Guava 20.0 (wrt something called `FutureFallback`), which
needs to be tackled separately. Since it's a test failure, not runtime, likely
would not affect users but I can't just break tests obviously.
So I will attach a patch for just going to 19.0 first, with fixes for
`CharMatcher.DIGIT` and `Futures.transform()`.
was (Author: cowtowncoder):
Diff for patch to use Guava 20.0: [^cass-3.11-diff.txt]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413438#comment-17413438 ] Tatu Saloranta edited comment on CASSANDRA-15248 at 10/12/21, 5:03 PM: --- Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureFallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureFallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). Looks like "cassandra-driver-core" 3.2.0 does resolve these, see – [https://datastax-oss.atlassian.net/browse/JAVA-1328] – but whether using that version otherwise works seems unsure. Based on version it'd make sense it did but... EDIT2: To replace `CharMatcher.DIGIT` (removed from guava 26?) one could use `CharMatcher.digit()` added in 19.0. So even that relatively small improvement would require small bump to Guava version. was (Author: cowtowncoder): Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureCallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureCallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). Looks like "cassandra-driver-core" 3.2.0 does resolve these, see – [https://datastax-oss.atlassian.net/browse/JAVA-1328] – but using that version otherwise works seems unsure. Based on version it'd make sense it did but... EDIT2: To replace `CharMatcher.DIGIT` (removed from guava 26?) one could use `CharMatcher.digit()` added in 19.0. So even that relatively small improvement would require small bump to Guava version. > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- 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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tatu Saloranta updated CASSANDRA-15453:
---
Attachment: cass-3.11-diff.txt
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427795#comment-17427795
]
Tatu Saloranta commented on CASSANDRA-15453:
Diff for patch to use Guava 20.0: [^cass-3.11-diff.txt]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427793#comment-17427793
]
Tatu Saloranta commented on CASSANDRA-15453:
Playing with this a bit more, it looks like upgrade to 20.0 is relatively easy
as well. In addition to `CharMatcher.DIGIT`, we have 2 other mechanical safe
changes:
# Futures.transform() -> Futures.transformAsync() (added in 19.0, old removed
from a later version)
# HostAndPort.getHostText() -> Futures.getHost() (added in 20.0, old removed
from 22.0)--
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427778#comment-17427778
]
Tatu Saloranta commented on CASSANDRA-15453:
It looks like the replacement for `CharMatcher.DIGIT` (removed from 26),
`CharMatcher.digit()` was added in Guava 19. So the very minimum possibly
useful thing would be a minimal upgrade for Cassandra 3.11 to:
# Upgrade Guava dep from 18.0 to 19.0
# Replace `CharMatcher.DIGIT` with `CharMatcher.digit()`
This alone will not solve other Guava upgrade issues (see CASSANDRA-15248 for
details) but might help untangle the problem.
If this sounds useful, I can provide a PR.
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413438#comment-17413438 ] Tatu Saloranta edited comment on CASSANDRA-15248 at 10/12/21, 3:53 PM: --- Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureCallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureCallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). Looks like "cassandra-driver-core" 3.2.0 does resolve these, see – [https://datastax-oss.atlassian.net/browse/JAVA-1328] – but using that version otherwise works seems unsure. Based on version it'd make sense it did but... EDIT2: To replace `CharMatcher.DIGIT` (removed from guava 26?) one could use `CharMatcher.digit()` added in 19.0. So even that relatively small improvement would require small bump to Guava version. was (Author: cowtowncoder): Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureFallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureFallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). Looks like "cassandra-driver-core" 3.2.0 does resolve these, see – [https://datastax-oss.atlassian.net/browse/JAVA-1328] – but using that version otherwise works seems unsure. Based on version it'd make sense it did but... > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- 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-15416) CVE-2017-7525 ( jackson-databind is vulnerable to Remote Code Execution) on version 3.11.4
[ https://issues.apache.org/jira/browse/CASSANDRA-15416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17420832#comment-17420832 ] Tatu Saloranta commented on CASSANDRA-15416: This falls under general polymorphic deserialization, explained here: [https://cowtowncoder.medium.com/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062] and as far as I know, Cassandra does not use polymorphic deserialization anywhere (either with `@JsonTypeInfo` annotation on `Object`-valued property or by enabling "Default Typing"). Note that `BeanDeserializerFactory` itself is used indirectly when deserializing regular Java POJOs/Beans and is not called directly by app code (that is, looking for references to it won't tell much about usage). Having said that, the issue is resolved for 2.10 so CASSANDRA-16851 should resolve this for 3.11 and 4.x. > CVE-2017-7525 ( jackson-databind is vulnerable to Remote Code Execution) on > version 3.11.4 > -- > > Key: CASSANDRA-15416 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15416 > Project: Cassandra > Issue Type: Bug >Reporter: Abhishek Singh >Priority: Normal > > *Description :* > *Severity :* CVE CVSS 2.0: 7.5Sonatype CVSS 3: 8.5 > *Weakness :* CVE CWE: 502 > *Source :* National Vulnerability Database > *Categories :* Data > *Description from CVE :* A deserialization flaw was discovered in the > jackson-databind, versions before 2.6.7.1, 2.7.9.1 and 2.8.9, which could > allow an unauthenticated user to perform code execution by sending the > maliciously crafted input to the readValue method of the ObjectMapper. > *Explanation :* jackson-databind is vulnerable to Remote Code Execution > [RCE]. The createBeanDeserializer[] function in the BeanDeserializerFactory > class allows untrusted Java objects to be deserialized. A remote attacker can > exploit this by uploading a malicious serialized object that will result in > RCE if the application attempts to deserialize it. > NOTE: This vulnerability is also tracked by the Apache Struts team as S2-055. > *Detection :* The application is vulnerable by using this component, when > default typing is enabled. > Note: Spring Security has provided their own fix for this vulnerability > [CVE-2017-4995]. If this component is being used as part of Spring Security, > then you are not vulnerable if you are running Spring Security 4.2.3.RELEASE > or greater for 4.x or Spring Security 5.0.0.M2 or greater for 5.x. > *Recommendation :* : As of version 2.10.0, Jackson now provides a safe > default typing solution that fully mitigates this vulnerability. > Reference: > [https://medium.com/@cowtowncoder/jackson-2-10-features-cd880674d8a2] > In order to mitigate this vulnerability, we recommend upgrading to at least > version 2.10.0 and changing any usages of enableDefaultTyping[] to > activateDefaultTyping[]. > Alternatively, if upgrading is not a viable option, this vulnerability can be > mitigated by disabling default typing. Instead, you will need to implement > your own: > It is also possible to customize global defaulting, using > ObjectMapper.setDefaultTyping[...] – you just have to implement your own > TypeResolverBuilder [which is not very difficult]; and by doing so, can > actually configure all aspects of type information. Builder itself is just a > short-cut for building actual handlers. > Reference: > [https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization] > Examples of implementing your own typing can be found by looking at this > Stack Overflow article. > *Root Cause :* > apache-cassandra-3.11.4-bin.tar.gzorg/codehaus/jackson/map/deser/BeanDeserializerFactory.class > : [0.9.8, ] > *Advisories :* Project: > [https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-7525] > *CVSS Details :* CVE CVSS 2.0: 7.5CVSS Vector: AV:N/AC:L/Au:N/C:P/I:P/A:P > *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"] > *CVE :* CVE-2017-7525 > *URL :* [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7525] > *Remediation :* This component does not have any non-vulnerable Version. > Please contact the vendor to get this vulnerability fixed. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418194#comment-17418194 ] Tatu Saloranta commented on CASSANDRA-16851: My pleasure! > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 4h > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416967#comment-17416967 ] Tatu Saloranta commented on CASSANDRA-16851: Pop the champagne! Thank you again [~e.dimitrova] for getting this through; should eliminate possibility of those "busy work cve updates for jackson 2.9" popping up ever again. Plus I think there's some incremental performance work for JsonNode handling too in 2.10 and 2.11 if I remember correctly. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416230#comment-17416230 ] Tatu Saloranta commented on CASSANDRA-16851: Sounds good to me: wish I had something to contribute wrt failures but I agree that none of the failures sound related (with limited understanding of C* internals I have). Jackson usage I have seen is quite basic and seems unlikely to have regressions, functionally or wrt performance. Thank you [~e.dimitrova] for all your work on this! > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413438#comment-17413438 ] Tatu Saloranta edited comment on CASSANDRA-15248 at 9/11/21, 12:01 AM: --- Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureFallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureFallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). Looks like "cassandra-driver-core" 3.2.0 does resolve these, see – [https://datastax-oss.atlassian.net/browse/JAVA-1328] – but using that version otherwise works seems unsure. Based on version it'd make sense it did but... was (Author: cowtowncoder): Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureFallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureFallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- 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-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413438#comment-17413438 ] Tatu Saloranta edited comment on CASSANDRA-15248 at 9/10/21, 11:29 PM: --- Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureFallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureFallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). was (Author: cowtowncoder): Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureFallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- 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-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413438#comment-17413438 ] Tatu Saloranta commented on CASSANDRA-15248: Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureFallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- 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-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413418#comment-17413418 ] Tatu Saloranta commented on CASSANDRA-15248: Aside from actual upgrade, would it be possible to increase compatibility first by – for example – replacing use of `CharMatcher.DIGIT` (which is one problem) with something that is available on later versions? Many OSS libraries work hard to try to work with wide(r) range of Guava versions, being that Guava compatibility is a rather hard problem due to its ubiquity – and I 100% agree that it is often not easy or safe to "just upgrade to the latest Guava", at least if the current dep is to version below 23.0. This comment is in particular wrt pre-4.0 Cassandra. (for those interested, I wrote a bit about Guava compatibility wrt Jackson Guava datatype module here: [https://cowtowncoder.medium.com/jackson-guava-compatibility-b0b61ac59b28] ) where I have tried to avoid this module being the bottleneck wrt compatibility. > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- 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-16901) Optimize heavily-used `String.format()`-with-constant formatter use cases
[
https://issues.apache.org/jira/browse/CASSANDRA-16901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412150#comment-17412150
]
Tatu Saloranta commented on CASSANDRA-16901:
No, I don't have cluster benchmarks unfortunately. I doubt effect would be big
enough to show on latencies; might be visible on heap dumps wrt garbage
(assuming `QualifiedName.to[CQL]String()` is heavily used, maybe it isn't).
My thinking is more along the lines of this being incremental improvement which
would not add complexity (a simple helper method). But I agree that ideally it
would show some measurable improvement.
> Optimize heavily-used `String.format()`-with-constant formatter use cases
> -
>
> Key: CASSANDRA-16901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16901
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tatu Saloranta
>Priority: Normal
>
> For background, I did some benchmarking to compare performance of two simple
> ways to concatenate 2 Strings with a separator (used in f.ex
> `QualifiedName.java` for "keyspace:name" concatenation):
> # String.format("%s.%s", keyspace, name);
> # new StringBuilder().append(keyspace).append('.').append(name).toString()
> Difference is somewhat significant (for me, factor of 40x), as per:
> https://cowtowncoder.medium.com/measuring-performance-of-java-string-format-or-lack-thereof-2e1c6a13362c
> and so it seems worthwhile replacing at least some of usage from Cassandra.
> With a quick look it seems that classes like:
> * QualifiedName.java, FieldSelector.java, Selectable.java (in cql3)
> could benefit from this. And the second implementation can be packaged as a
> simple utility method (concatenateStringsWithChar?) so that code should be as
> readable as before.
> I can provide a patch, or if anyone else wants to have a go, feel free to.
>
>
>
--
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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411470#comment-17411470 ] Tatu Saloranta commented on CASSANDRA-16851: [~e.dimitrova] gotcha wrt 3.0; since it is Jackson 1.x, this would not apply (and adding Jackson 2.x would do no good; it wouldn't be used). I did not realize upgrade happened after 3.0; 3.11 and later use Jackson 2.x. As to `BufferRecyclers.getJsonStringEncoder()`: it has bit of an "interesting" history, and was not meant for use by code outside Jackson. During Jackson 2.9 there was an attempt for safe recycling of underlying buffers of encoder, which lead to complicated handling via `BufferRecyclers`. This was removed in 2.10, along with making encoder stateless, but without considering compatibility aspects (i.e. removing accessor method). I added old method back in 2.12.5 to address this. With Jackson 2.13 (when it gets released), the recommended way is to just call `JsonStringEncoder.getInstance()`; there is no buffer recycling (underlying buffer is calculated to be about optimal size). With 2.12.x this method is safe to use as well. But for 2.12 I added method `BufferRecyclers.getJsonEncoder()` (and related) back for compatibility reasons, but marked "deprecated" so that there would not be additional use. It is not meant to indicate imminent removal (methods won't be removed before 3.0). So I think going via `BufferRecyclers` makes sense now and maybe move "back" to `JsonStringEncoder.getInstance()` when Cassandra upgrades to Jackson 2.13 or later 2.x? Does above make sense? (the whole thing being a mess, but that aside :) ) > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409595#comment-17409595 ] Tatu Saloranta commented on CASSANDRA-16855: One possibility, too, would be for me to split changes into 2 (or if need be, more) PRs, starting with safest ones (adding missing test). This would make sense if someone with a better idea of hotspots/-paths could suggest split. More important change(s) should then be merged with a jmh test (or tests), or validated with load/stress-test for overall change (likely none measurable at high level). > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408444#comment-17408444 ] Tatu Saloranta commented on CASSANDRA-16854: Thank you [~mck]! > Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency > > > Key: CASSANDRA-16854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16854 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.11.12, 4.1, 4.0.2 > > Attachments: CASSANDRA-16854.patch > > > build.xml has a dependency for an old hadoop-core version (1.0.3). This is > likely needed for some Hadoop compatibility code under > `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its > dependencies are very old; in particular it depends on "jackson-mapper-asl" > 1.0.1 (from 2009!). > An earlier issue CASSANDRA-15867 referenced this dependency as well (but did > not actually remove it for some reason, which marked as resolved). > Although `hadoop-core` dependency is marked as "provided" (and should then > not be included in distributed version) it seems best to avoid downloading it > during build to "build/lib/jars". This can be done by adding 2 exclusions for > "hadoop-core" and "hadoop-minicluster" dependencies in build.xml. > I will provide a patch. > I also tried updating "hadoop-core" to the latest public version (1.2.1), > which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the > build due to some other version incompatibility (asm, possibly). If anyone > wants to tackle that issue it could be a good follow-up task; "hadoop-core" > itself has been moved to "hadoop-client" it seems (and there's > "hadoop-commons" too... confusing). > -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407645#comment-17407645 ] Tatu Saloranta commented on CASSANDRA-16851: Ok good, this makes sense. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407621#comment-17407621 ] Tatu Saloranta commented on CASSANDRA-16851: Looks like above test summary says: "[Test Result|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/testReport/] (7 failures / -1)". Not 100% sure if it means that there is one less failure from baseline (recent runs), or something else. Failed tests: !https://ci-cassandra.apache.org/static/c0f8b409/images/16x16/document_add.png! [org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageUpgradeTest|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/testReport/org.apache.cassandra.distributed.upgrade/CompactStorageUpgradeTest/compactStorageUpgradeTest/] 6.9 sec [1|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/] !https://ci-cassandra.apache.org/static/c0f8b409/images/16x16/document_add.png! [org.apache.cassandra.distributed.test.OptimiseStreamsRepairTest.randomTest|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/testReport/org.apache.cassandra.distributed.test/OptimiseStreamsRepairTest/randomTest/] 37 sec [1|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/] !https://ci-cassandra.apache.org/static/c0f8b409/images/16x16/document_add.png! [org.apache.cassandra.metrics.TableMetricsTest.testLoggedPartitionsPerBatch-compression|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/testReport/org.apache.cassandra.metrics/TableMetricsTest/testLoggedPartitionsPerBatch_compression/] 3.1 sec [1|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/] !https://ci-cassandra.apache.org/static/c0f8b409/images/16x16/document_add.png! [org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageHiddenColumnTest|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/testReport/org.apache.cassandra.distributed.upgrade/CompactStorageUpgradeTest/compactStorageHiddenColumnTest/] 1 min 13 sec [2|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1081/] !https://ci-cassandra.apache.org/static/c0f8b409/images/16x16/document_add.png! [org.apache.cassandra.distributed.upgrade.MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/testReport/org.apache.cassandra.distributed.upgrade/MixedModeReadTest/mixedModeReadColumnSubsetDigestCheck/] 26 sec [4|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1079/] !https://ci-cassandra.apache.org/static/c0f8b409/images/16x16/document_add.png! [org.apache.cassandra.distributed.upgrade.MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/testReport/org.apache.cassandra.distributed.upgrade/MixedModeReadTest/mixedModeReadColumnSubsetDigestCheck_2/] 25 sec [4|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1079/] !https://ci-cassandra.apache.org/static/c0f8b409/images/16x16/document_add.png! [org.apache.cassandra.distributed.upgrade.MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1082/testReport/org.apache.cassandra.distributed.upgrade/MixedModeReadTest/mixedModeReadColumnSubsetDigestCheck_3/] 29 sec [4|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1079/] > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16901) Optimize heavily-used `String.format()`-with-constant formatter use cases
Tatu Saloranta created CASSANDRA-16901:
--
Summary: Optimize heavily-used `String.format()`-with-constant
formatter use cases
Key: CASSANDRA-16901
URL: https://issues.apache.org/jira/browse/CASSANDRA-16901
Project: Cassandra
Issue Type: Improvement
Reporter: Tatu Saloranta
For background, I did some benchmarking to compare performance of two simple
ways to concatenate 2 Strings with a separator (used in f.ex
`QualifiedName.java` for "keyspace:name" concatenation):
# String.format("%s.%s", keyspace, name);
# new StringBuilder().append(keyspace).append('.').append(name).toString()
Difference is somewhat significant (for me, factor of 40x), as per:
https://cowtowncoder.medium.com/measuring-performance-of-java-string-format-or-lack-thereof-2e1c6a13362c
and so it seems worthwhile replacing at least some of usage from Cassandra.
With a quick look it seems that classes like:
* QualifiedName.java, FieldSelector.java, Selectable.java (in cql3)
could benefit from this. And the second implementation can be packaged as a
simple utility method (concatenateStringsWithChar?) so that code should be as
readable as before.
I can provide a patch, or if anyone else wants to have a go, feel free to.
--
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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406859#comment-17406859 ] Tatu Saloranta commented on CASSANDRA-16851: [~mck] I ended up reverting code wrt JsonStringEncoder so now can use the old method (since it was reintroduced in 2.12.5, as it was technically API regression). I hope this makes patch easier to consider. A full CI test run would be needed still, although if that has been run before there is no functional change here. I did however notice that someone had added a Jackson module in the meantime to support Java 8 date/time types. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 3h > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406838#comment-17406838 ] Tatu Saloranta commented on CASSANDRA-16851: I ended up adding back the missing method in `BufferRecyclers` for Jackson 2.12, included again in 2.12.5. This simplifies patch; will update PR accordingly. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 2h 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403294#comment-17403294 ] Tatu Saloranta commented on CASSANDRA-16854: [~mck] I agree that it'd be great to somehow smoke-test/sanity-check for obvious breakage. I am not sure how to proceed with this, however; wonder if others might have some ideas? > Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency > > > Key: CASSANDRA-16854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16854 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: CASSANDRA-16854.patch > > > build.xml has a dependency for an old hadoop-core version (1.0.3). This is > likely needed for some Hadoop compatibility code under > `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its > dependencies are very old; in particular it depends on "jackson-mapper-asl" > 1.0.1 (from 2009!). > An earlier issue CASSANDRA-15867 referenced this dependency as well (but did > not actually remove it for some reason, which marked as resolved). > Although `hadoop-core` dependency is marked as "provided" (and should then > not be included in distributed version) it seems best to avoid downloading it > during build to "build/lib/jars". This can be done by adding 2 exclusions for > "hadoop-core" and "hadoop-minicluster" dependencies in build.xml. > I will provide a patch. > I also tried updating "hadoop-core" to the latest public version (1.2.1), > which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the > build due to some other version incompatibility (asm, possibly). If anyone > wants to tackle that issue it could be a good follow-up task; "hadoop-core" > itself has been moved to "hadoop-client" it seems (and there's > "hadoop-commons" too... confusing). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401388#comment-17401388 ] Tatu Saloranta commented on CASSANDRA-16855: One benchmark that seems quite relevant : [https://github.com/fabienrenaud/java-json-benchmark] It includes Jackson 2.10 as well as jsonsimple (in some places mentioned as "simplejson") – latter for just first 2 cases as it only supports non-POJO reading/writing (scalars, Lists, Maps) and not POJOs. Benchmark is based on jmh and seems quite solid; it is written by someone other than author of either of json libraries (may be author of dsl-json/jsoniter, not 100% sure; but someone familiar with the domain). :) Results suggest, fwtw, Jackson to be 2-3x faster at reading and 5x faster at writing of the stuff tested. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401386#comment-17401386 ] Tatu Saloranta commented on CASSANDRA-16855: I added that one unit tests to (try to) ensure that `StatsPrinter` behavior did not change (there was one special case wrt NaNs). Coverage for other aspects is probably more limited, at least direct tests. As to performance I would expect Jackson to at least be not-slower and likely faster (based on benchmarking I have done over the years) but would not expect differences to necessarily surface to higher level tests. JSON processing is probably not big enough part of cpu load for that. I can find links to external tests but not sure they would help with specific usage. But if it was easy enough, could probably add `jmh` based tests for one of aspects. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401298#comment-17401298 ] Tatu Saloranta commented on CASSANDRA-16851: Security aspect wrt CVE is probably a good one regarding move from 2.9 to even just 2.10 – practically all Jackson CVEs for past 2.5 years were for polymorphic deserialization and are not applicable to 2.10 or beyond. While these CVEs were already not applicable to Cassandra usage (as per [https://cowtowncoder.medium.com/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062),] vuln tracking tools are very simplistic and cannot really express something that is only applicable to specific usage scenarios, and will happily indicate Cassandra requiring update to latest Jackson 2.9 patch. Or, TL;DNR; moving out of 2.9 will stop any new jackson polymorphic deser CVEs. This would probably be nice for C* 3.x as well as 4.x. Choice of Jackson dependency to use can also be different between 3.x and 4.x, although with relatively simple usage it is probably simpler from support perspective to update both to Jackson 2.12. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta reassigned CASSANDRA-16855: -- Assignee: Tatu Saloranta (was: Tatu Saloranta) > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta reassigned CASSANDRA-16851: -- Assignee: Tatu Saloranta (was: Tatu Saloranta) > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta reassigned CASSANDRA-16854: -- Assignee: Tatu Saloranta (was: Tatu Saloranta) > Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency > > > Key: CASSANDRA-16854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16854 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: CASSANDRA-16854.patch > > > build.xml has a dependency for an old hadoop-core version (1.0.3). This is > likely needed for some Hadoop compatibility code under > `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its > dependencies are very old; in particular it depends on "jackson-mapper-asl" > 1.0.1 (from 2009!). > An earlier issue CASSANDRA-15867 referenced this dependency as well (but did > not actually remove it for some reason, which marked as resolved). > Although `hadoop-core` dependency is marked as "provided" (and should then > not be included in distributed version) it seems best to avoid downloading it > during build to "build/lib/jars". This can be done by adding 2 exclusions for > "hadoop-core" and "hadoop-minicluster" dependencies in build.xml. > I will provide a patch. > I also tried updating "hadoop-core" to the latest public version (1.2.1), > which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the > build due to some other version incompatibility (asm, possibly). If anyone > wants to tackle that issue it could be a good follow-up task; "hadoop-core" > itself has been moved to "hadoop-client" it seems (and there's > "hadoop-commons" too... confusing). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400689#comment-17400689 ] Tatu Saloranta edited comment on CASSANDRA-16855 at 8/18/21, 12:51 AM: --- [~brandon.williams] fixed the remaining usage (and noticed that I had to do `ant realclean` before seeing compilation issue locally). -Will try to restart circle-ci job but not sure if I have access: I can see it fine fwtw.- (note: just realized that this is not a shared circle-ci set up) was (Author: cowtowncoder): [~brandon.williams] fixed the remaining usage (and noticed that I had to do `ant realclean` before seeing compilation issue locally). Will try to restart circle-ci job but not sure if I have access: I can see it fine fwtw. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400689#comment-17400689 ] Tatu Saloranta commented on CASSANDRA-16855: [~brandon.williams] fixed the remaining usage (and noticed that I had to do `ant realclean` before seeing compilation issue locally). Will try to restart circle-ci job but not sure if I have access: I can see it fine fwtw. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400679#comment-17400679 ] Tatu Saloranta commented on CASSANDRA-16855: Oh. Somehow missed your comment [~brandon.williams] – will check, thanks! > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta updated CASSANDRA-16855: --- Status: Patch Available (was: In Progress) > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta updated CASSANDRA-16855: --- Labels: pull-request-available (was: ) > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.1, 5.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta updated CASSANDRA-16855: --- Fix Version/s: (was: 4.x) 5.x 4.1 > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 4.1, 5.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400117#comment-17400117 ] Tatu Saloranta commented on CASSANDRA-16855: Created PR [https://github.com/apache/cassandra/pull/1147] which contains all changes to remove `json-simple` dependency. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398992#comment-17398992 ] Tatu Saloranta commented on CASSANDRA-16855: Looks like testing of yaml/json output for StatsPrinter would be ... complicated. For some reason stats are internally converted to `HashMap` (and not `LinkedHashMap`) so ordering of entries will be arbitrary. Will probably need to settle for some sort of round-trip testing with a subset, compared to pretty-printed textual stats printing which checks for exact formatting. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
Tatu Saloranta created CASSANDRA-16855: -- Summary: Replace minor use of `json-simple` with Jackson Key: CASSANDRA-16855 URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 Project: Cassandra Issue Type: Improvement Components: Dependencies, Local/Other, Tool/nodetool Reporter: Tatu Saloranta Jackson library is used for most JSON reading/writing, but there are couple of places where older "json-simple" library is used, mostly for diagnostics output. Replacing those minor usages would allow removal of a dependency, one for which the last release was made in 2012. Places where json-simple is used are: * src/java/org/apache/cassandra/db/ColumnFamilyStore.java * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java * src/java/org/apache/cassandra/hints/HintsDescriptor.java * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java (and some matching usage in couple of test classes) I can take a stab at replacing these uses; it also looks like test coverage may be spotty for some (StatsPrinter json/yaml part has no tests for example). It is probably best to target this for "trunk" (4.1?). -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta reassigned CASSANDRA-16855: -- Assignee: Tatu Saloranta > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398974#comment-17398974 ] Tatu Saloranta commented on CASSANDRA-16854: Added proposed fix version of 4.1 and beyond: would likely be fine for 4.0 as well. Will let committers decide on if that makes sense. > Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency > > > Key: CASSANDRA-16854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16854 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 4.1, 5.x > > Attachments: CASSANDRA-16854.patch > > > build.xml has a dependency for an old hadoop-core version (1.0.3). This is > likely needed for some Hadoop compatibility code under > `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its > dependencies are very old; in particular it depends on "jackson-mapper-asl" > 1.0.1 (from 2009!). > An earlier issue CASSANDRA-15867 referenced this dependency as well (but did > not actually remove it for some reason, which marked as resolved). > Although `hadoop-core` dependency is marked as "provided" (and should then > not be included in distributed version) it seems best to avoid downloading it > during build to "build/lib/jars". This can be done by adding 2 exclusions for > "hadoop-core" and "hadoop-minicluster" dependencies in build.xml. > I will provide a patch. > I also tried updating "hadoop-core" to the latest public version (1.2.1), > which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the > build due to some other version incompatibility (asm, possibly). If anyone > wants to tackle that issue it could be a good follow-up task; "hadoop-core" > itself has been moved to "hadoop-client" it seems (and there's > "hadoop-commons" too... confusing). > -- 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-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta updated CASSANDRA-16854: --- Fix Version/s: (was: 4.0.x) (was: 3.11.x) (was: 4.x) 5.x 4.1 > Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency > > > Key: CASSANDRA-16854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16854 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 4.1, 5.x > > Attachments: CASSANDRA-16854.patch > > > build.xml has a dependency for an old hadoop-core version (1.0.3). This is > likely needed for some Hadoop compatibility code under > `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its > dependencies are very old; in particular it depends on "jackson-mapper-asl" > 1.0.1 (from 2009!). > An earlier issue CASSANDRA-15867 referenced this dependency as well (but did > not actually remove it for some reason, which marked as resolved). > Although `hadoop-core` dependency is marked as "provided" (and should then > not be included in distributed version) it seems best to avoid downloading it > during build to "build/lib/jars". This can be done by adding 2 exclusions for > "hadoop-core" and "hadoop-minicluster" dependencies in build.xml. > I will provide a patch. > I also tried updating "hadoop-core" to the latest public version (1.2.1), > which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the > build due to some other version incompatibility (asm, possibly). If anyone > wants to tackle that issue it could be a good follow-up task; "hadoop-core" > itself has been moved to "hadoop-client" it seems (and there's > "hadoop-commons" too... confusing). > -- 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-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta updated CASSANDRA-16854: --- Attachment: CASSANDRA-16854.patch > Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency > > > Key: CASSANDRA-16854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16854 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Attachments: CASSANDRA-16854.patch > > > build.xml has a dependency for an old hadoop-core version (1.0.3). This is > likely needed for some Hadoop compatibility code under > `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its > dependencies are very old; in particular it depends on "jackson-mapper-asl" > 1.0.1 (from 2009!). > An earlier issue CASSANDRA-15867 referenced this dependency as well (but did > not actually remove it for some reason, which marked as resolved). > Although `hadoop-core` dependency is marked as "provided" (and should then > not be included in distributed version) it seems best to avoid downloading it > during build to "build/lib/jars". This can be done by adding 2 exclusions for > "hadoop-core" and "hadoop-minicluster" dependencies in build.xml. > I will provide a patch. > I also tried updating "hadoop-core" to the latest public version (1.2.1), > which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the > build due to some other version incompatibility (asm, possibly). If anyone > wants to tackle that issue it could be a good follow-up task; "hadoop-core" > itself has been moved to "hadoop-client" it seems (and there's > "hadoop-commons" too... confusing). > -- 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-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398901#comment-17398901
]
Tatu Saloranta edited comment on CASSANDRA-16854 at 8/13/21, 8:17 PM:
--
Simple patch would be:
{code:java}
diff --git a/build.xml b/build.xml
index 41dffa12bc..c84e04c24d 100644
--- a/build.xml
+++ b/build.xml
@@ -539,10 +539,12 @@
+
+
{code}
(added as attachment as well)
was (Author: cowtowncoder):
Simple patch would be:
{code:java}
diff --git a/build.xml b/build.xml
index 41dffa12bc..c84e04c24d 100644
--- a/build.xml
+++ b/build.xml
@@ -539,10 +539,12 @@
+
+
{code}
> Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
>
>
> Key: CASSANDRA-16854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16854
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tatu Saloranta
>Assignee: Tatu Saloranta
>Priority: Normal
> Attachments: CASSANDRA-16854.patch
>
>
> build.xml has a dependency for an old hadoop-core version (1.0.3). This is
> likely needed for some Hadoop compatibility code under
> `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its
> dependencies are very old; in particular it depends on "jackson-mapper-asl"
> 1.0.1 (from 2009!).
> An earlier issue CASSANDRA-15867 referenced this dependency as well (but did
> not actually remove it for some reason, which marked as resolved).
> Although `hadoop-core` dependency is marked as "provided" (and should then
> not be included in distributed version) it seems best to avoid downloading it
> during build to "build/lib/jars". This can be done by adding 2 exclusions for
> "hadoop-core" and "hadoop-minicluster" dependencies in build.xml.
> I will provide a patch.
> I also tried updating "hadoop-core" to the latest public version (1.2.1),
> which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the
> build due to some other version incompatibility (asm, possibly). If anyone
> wants to tackle that issue it could be a good follow-up task; "hadoop-core"
> itself has been moved to "hadoop-client" it seems (and there's
> "hadoop-commons" too... confusing).
>
--
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-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398901#comment-17398901
]
Tatu Saloranta commented on CASSANDRA-16854:
Simple patch would be:
{code:java}
diff --git a/build.xml b/build.xml
index 41dffa12bc..c84e04c24d 100644
--- a/build.xml
+++ b/build.xml
@@ -539,10 +539,12 @@
+
+
{code}
> Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
>
>
> Key: CASSANDRA-16854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16854
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tatu Saloranta
>Assignee: Tatu Saloranta
>Priority: Normal
>
> build.xml has a dependency for an old hadoop-core version (1.0.3). This is
> likely needed for some Hadoop compatibility code under
> `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its
> dependencies are very old; in particular it depends on "jackson-mapper-asl"
> 1.0.1 (from 2009!).
> An earlier issue CASSANDRA-15867 referenced this dependency as well (but did
> not actually remove it for some reason, which marked as resolved).
> Although `hadoop-core` dependency is marked as "provided" (and should then
> not be included in distributed version) it seems best to avoid downloading it
> during build to "build/lib/jars". This can be done by adding 2 exclusions for
> "hadoop-core" and "hadoop-minicluster" dependencies in build.xml.
> I will provide a patch.
> I also tried updating "hadoop-core" to the latest public version (1.2.1),
> which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the
> build due to some other version incompatibility (asm, possibly). If anyone
> wants to tackle that issue it could be a good follow-up task; "hadoop-core"
> itself has been moved to "hadoop-client" it seems (and there's
> "hadoop-commons" too... confusing).
>
--
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-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
Tatu Saloranta created CASSANDRA-16854: -- Summary: Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency Key: CASSANDRA-16854 URL: https://issues.apache.org/jira/browse/CASSANDRA-16854 Project: Cassandra Issue Type: Improvement Components: Dependencies Reporter: Tatu Saloranta Assignee: Tatu Saloranta build.xml has a dependency for an old hadoop-core version (1.0.3). This is likely needed for some Hadoop compatibility code under `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its dependencies are very old; in particular it depends on "jackson-mapper-asl" 1.0.1 (from 2009!). An earlier issue CASSANDRA-15867 referenced this dependency as well (but did not actually remove it for some reason, which marked as resolved). Although `hadoop-core` dependency is marked as "provided" (and should then not be included in distributed version) it seems best to avoid downloading it during build to "build/lib/jars". This can be done by adding 2 exclusions for "hadoop-core" and "hadoop-minicluster" dependencies in build.xml. I will provide a patch. I also tried updating "hadoop-core" to the latest public version (1.2.1), which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the build due to some other version incompatibility (asm, possibly). If anyone wants to tackle that issue it could be a good follow-up task; "hadoop-core" itself has been moved to "hadoop-client" it seems (and there's "hadoop-commons" too... confusing). -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta updated CASSANDRA-16851: --- Summary: Update from Jackson 2.9 to 2.12 (was: Update from Jackson 2.9 to 2.10) > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5). > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta updated CASSANDRA-16851: --- Description: Given that Jackson 2.9 support has ended, it would be good to move at least to the next minor version (2.10, patch 2.10.5) or later – latest stable being 2.12.4. I can test to see if anything breaks, but looking at existing Jackson usage there shouldn't be many issues. Assuming upgrade is acceptable there's the question of which branches to apply it to; I will first test it against 4.0. was: Given that Jackson 2.9 support has ended, it would be good to move at least to the next minor version (2.10, patch 2.10.5). I can test to see if anything breaks, but looking at existing Jackson usage there shouldn't be many issues. Assuming upgrade is acceptable there's the question of which branches to apply it to; I will first test it against 4.0. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398836#comment-17398836 ] Tatu Saloranta commented on CASSANDRA-16851: As per discussions, changed to refer to Jackson 2.12(.4). > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.10
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398356#comment-17398356 ] Tatu Saloranta commented on CASSANDRA-16851: Hi [~e.dimitrova]! Thank you for updating the issue and suggestions. Will try to see how to use CI as plain ant test locally is taking quite long time. I'd be happy to move to the latest version as well but since this is my first contribution wanted to be cautious – no real blocker for that and I could target Jackson 2.12.4 instead of 2.10.5. > Update from Jackson 2.9 to 2.10 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5). > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.10
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398317#comment-17398317 ] Tatu Saloranta commented on CASSANDRA-16851: PR: [https://github.com/apache/cassandra/pull/1137] > Update from Jackson 2.9 to 2.10 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5). > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.10
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398298#comment-17398298 ] Tatu Saloranta commented on CASSANDRA-16851: Looks like there is need for one small change, for accessing `JsonStringEncoder` directly. > Update from Jackson 2.9 to 2.10 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5). > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.10
Tatu Saloranta created CASSANDRA-16851: -- Summary: Update from Jackson 2.9 to 2.10 Key: CASSANDRA-16851 URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 Project: Cassandra Issue Type: Improvement Components: Dependencies Reporter: Tatu Saloranta Assignee: Tatu Saloranta Given that Jackson 2.9 support has ended, it would be good to move at least to the next minor version (2.10, patch 2.10.5). I can test to see if anything breaks, but looking at existing Jackson usage there shouldn't be many issues. Assuming upgrade is acceptable there's the question of which branches to apply it to; I will first test it against 4.0. -- 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-1765) Compare serialization metrics between a few frameworks.
[ https://issues.apache.org/jira/browse/CASSANDRA-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038221#comment-13038221 ] Tatu Saloranta commented on CASSANDRA-1765: --- It sort of makes sense that differences might not be huge, with well-written codecs and test. One more thing that might be useful would be to add baseline of basic JSON-based serialization (with Jackson, data binding), to see how much use of binary formats helps. If tests are easy enough to modify, maybe I'll try to add that. Compare serialization metrics between a few frameworks. --- Key: CASSANDRA-1765 URL: https://issues.apache.org/jira/browse/CASSANDRA-1765 Project: Cassandra Issue Type: Task Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 beta 1 Attachments: 0001-CASSANDRA-1765-allocate-memory-for-binary-deserializ.patch, 0001-inserts-codes-for-properly-calling-full-GC-into-Mess.patch, MessageSerializationThriftTest.java, v1-0001-CASSANDRA-1765-create-reader-writer-once.txt, v1-0001-CASSANDRA-1765-don-t-ser-dser-schema-string.txt, v1-0001-IDL-and-RangeSliceCommand-alteration.txt, v1-0002-msgpack-dependencies.txt, v1-0003-serialization-tests.txt, v1-0004-jvm-warmup-and-other-improvements.-by-Muga-Nishizawa.txt, v2-0001-CASSANDRA-1765-create-reader-writer-once.txt, v2-0001-IDL-and-RangeSliceCommand-alteration.txt, v2-0002-msgpack-dependencies.txt, v2-0003-serialization-tests.txt, v2-0004-jvm-warmup-and-other-improvements.-by-Muga-Nishizawa.txt, v2-0005-don-t-bother-with-sending-schema-on-avro-tests.-patch-.txt, v2-0006-allocate-memory-more-efficently-for-msgpack.-patch-by-.txt Compare serialization performance of Cassandra (ICompactSerializer), Thrift, Avro and Messagepack. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-1765) Compare serialization metrics between a few frameworks.
[ https://issues.apache.org/jira/browse/CASSANDRA-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038221#comment-13038221 ] Tatu Saloranta edited comment on CASSANDRA-1765 at 5/23/11 9:14 PM: It sort of makes sense that differences might not be huge, with well-written codecs and test. One more thing that might be useful would be to add baseline of basic JSON-based serialization (with Jackson, data binding), to see how much use of binary formats helps. If tests are easy enough to modify, maybe I'll try to add that. But it looks like tests are not (yet?) part of trunk? was (Author: cowtowncoder): It sort of makes sense that differences might not be huge, with well-written codecs and test. One more thing that might be useful would be to add baseline of basic JSON-based serialization (with Jackson, data binding), to see how much use of binary formats helps. If tests are easy enough to modify, maybe I'll try to add that. Compare serialization metrics between a few frameworks. --- Key: CASSANDRA-1765 URL: https://issues.apache.org/jira/browse/CASSANDRA-1765 Project: Cassandra Issue Type: Task Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 beta 1 Attachments: 0001-CASSANDRA-1765-allocate-memory-for-binary-deserializ.patch, 0001-inserts-codes-for-properly-calling-full-GC-into-Mess.patch, MessageSerializationThriftTest.java, v1-0001-CASSANDRA-1765-create-reader-writer-once.txt, v1-0001-CASSANDRA-1765-don-t-ser-dser-schema-string.txt, v1-0001-IDL-and-RangeSliceCommand-alteration.txt, v1-0002-msgpack-dependencies.txt, v1-0003-serialization-tests.txt, v1-0004-jvm-warmup-and-other-improvements.-by-Muga-Nishizawa.txt, v2-0001-CASSANDRA-1765-create-reader-writer-once.txt, v2-0001-IDL-and-RangeSliceCommand-alteration.txt, v2-0002-msgpack-dependencies.txt, v2-0003-serialization-tests.txt, v2-0004-jvm-warmup-and-other-improvements.-by-Muga-Nishizawa.txt, v2-0005-don-t-bother-with-sending-schema-on-avro-tests.-patch-.txt, v2-0006-allocate-memory-more-efficently-for-msgpack.-patch-by-.txt Compare serialization performance of Cassandra (ICompactSerializer), Thrift, Avro and Messagepack. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1765) Compare serialization metrics between a few frameworks.
[ https://issues.apache.org/jira/browse/CASSANDRA-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12934684#action_12934684 ] Tatu Saloranta commented on CASSANDRA-1765: --- Did the test do proper JVM warmup (it looks like they might not)? There should always be enough time for JVM warm up, and specifically hot spot to have chance to inline commonly used code. Relatively short time (like 5 seconds) often works well enough. Compare serialization metrics between a few frameworks. --- Key: CASSANDRA-1765 URL: https://issues.apache.org/jira/browse/CASSANDRA-1765 Project: Cassandra Issue Type: Task Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 Attachments: v0-0001-IDL-and-RangeSliceCommand-alteration.txt, v0-0002-msgpack-dependencies.txt, v0-0003-serialization-tests.txt Compare serialization performance of Cassandra (ICompactSerializer), Thrift, Avro and Messagepack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
