[jira] [Commented] (CASSANDRA-18177) Support AbstractCompositeType with toJSONString method
[ https://issues.apache.org/jira/browse/CASSANDRA-18177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693838#comment-17693838 ] Yong Jiang commented on CASSANDRA-18177: Hi, [~maxwellguo], thank you for your comments! I think the change in this feature still need to combine with your change in CASSANDRA-17698. I tested on my host, without the implementation from CASSANDRA-17698, the index table will need toJsonString method for PartitionerDefinedOrder, not AbstractCompositeType. It is [this line|https://github.com/apache/cassandra/pull/2004/files#diff-a7e8323c9332e6c0d12b0ef92709fa241342fc505a4bdf144b146e9f22cb9adaR750:~:text=.addClusteringColumn(%22partition_key%22%2C%20indexTableMokePkType)%3B] in your changes that will assign the AbstractCompositeType type. So if I start my code based on trunk, there will be no straghtforward way for me to test it until the changes will be merged with yours. That's why I think it is better to have this feature implemented on top of CASSANDRA-17698. > Support AbstractCompositeType with toJSONString method > -- > > Key: CASSANDRA-18177 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18177 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: maxwellguo >Assignee: Yong Jiang >Priority: Normal > Fix For: 4.x > > > As we know AbstractCompositeType do not support toJSONString method , but > some times > we do need this. > See the discusstion of > [CASSANDRA-17698|https://issues.apache.org/jira/browse/CASSANDRA-17698]. -- 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-18249) Docker image for releases
[ https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693800#comment-17693800 ] Berenguer Blasi commented on CASSANDRA-18249: - createrepo_c is the way to go imo bc of the python dependency. It is neither available in Ubuntu 20 #justfyi. If this has to become a big problem maybe it's better to leave it. There is a later Ubuntu LTS release version 22 that has been available for some time now, it should be stable and have everything needed for anybody using Ubuntu. > Docker image for releases > - > > Key: CASSANDRA-18249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18249 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Brandon Williams >Priority: Normal > > The release process is currently driven bu this > [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] > mainly. > Some of the requirements are a Debian based distro and a number of packages. > As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have > createrepo available i.e. > To avoid such problems, add repeatability, have a controlled env where > releases are cut, enable more people to cut them, etc [~mck] suggested > creating a docker image to that purpose probably based off > [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18177) Support AbstractCompositeType with toJSONString method
[ https://issues.apache.org/jira/browse/CASSANDRA-18177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693762#comment-17693762 ] maxwellguo edited comment on CASSANDRA-18177 at 2/27/23 2:45 AM: - hi [~yongjiang], I left some comments . Besides,I think you should start your code based on trunk , for this feature (or CASSANDRA-18177) have little relation with CASSANDRA-17698 ,so I think it may be better to start your code based on trunk. For toJSONString method of AbstractCompositeType does not work only for CASSANDRA-17698, but all cases that need toJSONString method of AbstractCompositeType(or DynamicCompositeType/CompositeType) was (Author: maxwellguo): Some comments was left. Besides,I think you should start your code based on trunk , for this feature (or CASSANDRA-18177) have little relation with CASSANDRA-17698 ,so I think it may be better to start your code based on trunk. For toJSONString method of AbstractCompositeType does not work only for CASSANDRA-17698, but all cases that need toJSONString method of AbstractCompositeType(or DynamicCompositeType/CompositeType) > Support AbstractCompositeType with toJSONString method > -- > > Key: CASSANDRA-18177 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18177 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: maxwellguo >Assignee: Yong Jiang >Priority: Normal > Fix For: 4.x > > > As we know AbstractCompositeType do not support toJSONString method , but > some times > we do need this. > See the discusstion of > [CASSANDRA-17698|https://issues.apache.org/jira/browse/CASSANDRA-17698]. -- 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-18177) Support AbstractCompositeType with toJSONString method
[ https://issues.apache.org/jira/browse/CASSANDRA-18177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693762#comment-17693762 ] maxwellguo commented on CASSANDRA-18177: Some comments was left. Besides,I think you should start your code based on trunk , for this feature (or CASSANDRA-18177) have little relation with CASSANDRA-17698 ,so I think it may be better to start your code based on trunk. For toJSONString method of AbstractCompositeType does not work only for CASSANDRA-17698, but all cases that need toJSONString method of AbstractCompositeType(or DynamicCompositeType/CompositeType) > Support AbstractCompositeType with toJSONString method > -- > > Key: CASSANDRA-18177 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18177 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: maxwellguo >Assignee: Yong Jiang >Priority: Normal > Fix For: 4.x > > > As we know AbstractCompositeType do not support toJSONString method , but > some times > we do need this. > See the discusstion of > [CASSANDRA-17698|https://issues.apache.org/jira/browse/CASSANDRA-17698]. -- 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-18177) Support AbstractCompositeType with toJSONString method
[
https://issues.apache.org/jira/browse/CASSANDRA-18177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693740#comment-17693740
]
Yong Jiang commented on CASSANDRA-18177:
Hi, [~maxwellguo], I have implemented the toJsonString method for
AbstractCompositeType per your instruction. Since your change is planned for
5.0 release and not in current trunk yet, so I created new branch
CASSANDRA-18177-4.1 and merged the fixes from your branch CASSANDRA-17698-4.1.
So here is commited change for parsing index table for composite partition key.
Please help review and let me know your comments. If everything looks good, I
will go ahead make the changes for branches 3.0, 3.11, 4.0 and trunck as well
to match your changes.
[changes for 4.1
|https://github.com/yongj/cassandra/commit/042f13a5cc6aa1782c1a68afeb4ab4b940ed7a7e?diff=unified]
I have also tried to created and parse an example table and below is the output
for your reference:
{code:java}
yongjiang@local:~/Documents/Code/test/cassandra$ ./bin/cqlsh
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.1.0 | Cassandra 4.1.1-SNAPSHOT | CQL spec 3.4.6 | Native protocol v5]
Use HELP for help.
cqlsh> CREATE KEYSPACE k WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> CREATE TABLE k.t ( k1 int, k2 int, v int, primary key ((k1, k2)));
cqlsh> CREATE INDEX IF NOT EXISTS ON k.t(v);
cqlsh> INSERT INTO k.t (k1, k2, v ) VALUES (1, 2, 3);
cqlsh> exit;
yongjiang@local:~/Documents/Code/test/cassandra$ ./bin/nodetool flush
yongjiang@local:~/Documents/Code/test/cassandra$ ./tools/bin/sstabledump
./data/data/k/t-bc9f5370b63a11ed9fb76fcfbbea78bb/.t_v_idx/nb-1-big-Data.db
[
{
"table kind" : "INDEX",
"partition" : {
"key" : [ "3" ],
"position" : 0
},
"rows" : [
{
"type" : "row",
"position" : 18,
"clustering" : [ "1", "2" ],
"liveness_info" : { "tstamp" : "2023-02-27T01:05:04.595860Z" },
"cells" : [ ]
}
]
}
] {code}
> Support AbstractCompositeType with toJSONString method
> --
>
> Key: CASSANDRA-18177
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18177
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/SSTable
>Reporter: maxwellguo
>Assignee: Yong Jiang
>Priority: Normal
> Fix For: 4.x
>
>
> As we know AbstractCompositeType do not support toJSONString method , but
> some times
> we do need this.
> See the discusstion of
> [CASSANDRA-17698|https://issues.apache.org/jira/browse/CASSANDRA-17698].
--
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-17971) Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-17971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693712#comment-17693712 ] Ekaterina Dimitrova commented on CASSANDRA-17971: - I suggest we leave this one the patch as-is and have the simulator upgraded to be able to handle 17 in its own separate ticket. Same way it was done in additional ticket for simulator Java 11 support before. So ASM adds support for Java 17 in 9.1 and we need the Opcodes.ASM9. I do not see anything about removal of 8 support or so so I do not think it can affect it. Regarding the bump of an ASM version I looked [here|https://asm.ow2.io/versions.html] and I do not see anything that can affect us. [~blerer] is working in the same code area now, maybe he can also confirm if he is seeing something we might be missing? I think I am personally +1 on green CI after rebase on the current patch. Thank you > Opcodes.ASM7 to be updated when JDK17 support is added for Cassandra > > > Key: CASSANDRA-17971 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17971 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Feature/UDF >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.x > > > In CASSANDRA-17873 we updated the ASM opcode inconsistencies for JDK11, we > need to revise it again before we switch fro jdk8&11 to jdk11&17 -- 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-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[
https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693679#comment-17693679
]
Paulo Motta commented on CASSANDRA-17561:
-
{quote}Why do we want to know what ranges that snapshot covers? What is the use
case?
{quote}
This would be additional metadata to enrich the snapshot manifest, just to
indicate that particular snapshot covers a subset of ranges (and not all ranges
as standard snapshots). While this could be useful if this functionality was
available to external users, I don't think this is a big deal for
internal/ephemeral snapshots since they're removed anyway after repair
completes.
{quote}btw isnt it true that as soon as there is some topology change and nodes
are not responsible for so and so ranges anymore, that information in snapshot
is pretty much useless, no?
{quote}
The metadata could be useful to easily identify that a snapshot is no longer
"valid" when a node's changes ranges. I think this would be a nice to have but
shouldn't block this ticket. Perhaps we can reconsider if we decide to expose
the "partial" snapshot functionality to external users.
> Diagnostic snapshot service should only snapshot mismatching ranges on
> preview repair mismatch
> --
>
> Key: CASSANDRA-17561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17561
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> We currently snapshot all sstables in a table when a preview repair mismatch
> occurs, we should only snapshot the sstables containing the mismatching ranges
--
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-18271) Centralize all snapshot operations to SnapshotManager
[
https://issues.apache.org/jira/browse/CASSANDRA-18271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693677#comment-17693677
]
Paulo Motta commented on CASSANDRA-18271:
-
I was planning to do this on CASSANDRA-18111, but this work got a bit delayed.
If you're interested I can rebase my branch and post an initial patch for
review/discussion.
> Centralize all snapshot operations to SnapshotManager
> -
>
> Key: CASSANDRA-18271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18271
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> Currently, there is a lot of places where snapshotting logic is in place,
> scattered across the codebase. We should centralize snapshotting logic under
> SnapshotManager so every place in the code interacts only with that. This
> should remove whole class of possible synchronization problems. Merely
> looking into the code, all these methods are potentially unsafe.
> {code:java}
> public Map listSnapshots()
> protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
> Set snapshotDirs) {
> protected static SnapshotManifest maybeLoadManifest(String keyspace, String
> table, String tag, Set snapshotDirs)
> public List listEphemeralSnapshots()
> private List listAllSnapshots()
> protected Map> listSnapshotDirsByTag()
> public boolean snapshotExists(String snapshotName)
> public static void clearSnapshot(String snapshotName, List
> tableDirectories, RateLimiter snapshotRateLimiter)
> public static void removeSnapshotDirectory(RateLimiter snapshotRateLimiter,
> File snapshotDir)
> public long trueSnapshotsSize()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15619) Counter tables should use a 4KB chunk length by default
[ https://issues.apache.org/jira/browse/CASSANDRA-15619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swen Fuhrmann reassigned CASSANDRA-15619: - Assignee: (was: Swen Fuhrmann) > Counter tables should use a 4KB chunk length by default > --- > > Key: CASSANDRA-15619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15619 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Counters >Reporter: Jon Haddad >Priority: Normal > > One of the issues I found when using counters is throughput gets > significantly limited due to the default chunk length. When tuning from 64 > to 4, I saw a massive improvement in both throughput and latency. > Our default chunk length is 16, which is fine for general purpose tables, but > since tables with counters are special purpose we should give users this > optimization automatically. -- 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-18285) Add JDK 11 upgrade tests for 4.1+
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693646#comment-17693646 ] Michael Semb Wever commented on CASSANDRA-18285: If this is true, that in non-trunk branches there are forward upgrade paths and a different jdk (i.e. 11) needs to be selected, then this applies to cassandra-4.0 branch as well. ci-cassandra.a.o (before 18133) does not do such jdk selection in-tree, so no ticket is needed for that work. > Add JDK 11 upgrade tests for 4.1+ > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1.x, 4.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- 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
