[jira] [Created] (CASSANDRA-15856) Security vulnerabilities with dependency jars of Cassandra 3.11.6
Kshitiz Saxena created CASSANDRA-15856: -- Summary: Security vulnerabilities with dependency jars of Cassandra 3.11.6 Key: CASSANDRA-15856 URL: https://issues.apache.org/jira/browse/CASSANDRA-15856 Project: Cassandra Issue Type: Task Reporter: Kshitiz Saxena The latest release of Cassandra 3.11.6 has few dependency jars which have some security vulnerabilities. Apache Thrift (org.apache.thrift:libthrift:0.9.2) has below mentioned security vulnerabilities reported |+[https://nvd.nist.gov/vuln/detail/CVE-2016-5397]+| |+[https://nvd.nist.gov/vuln/detail/CVE-2018-1320]+| |+[https://nvd.nist.gov/vuln/detail/CVE-2019-0205]+| Netty Project (io.netty:netty-all:4.0.44.Final) has below mentioned security vulnerabilities reported |+[https://nvd.nist.gov/vuln/detail/CVE-2019-16869]+| |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20444]+| |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20445]+| Is there a plan to upgrade these jars in any upcoming release? -- 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-8272) 2ndary indexes can return stale data
[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-8272:
---
Status: Ready to Commit (was: Review In Progress)
> 2ndary indexes can return stale data
>
>
> Key: CASSANDRA-8272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8272
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Sylvain Lebresne
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> When replica return 2ndary index results, it's possible for a single replica
> to return a stale result and that result will be sent back to the user,
> potentially failing the CL contract.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v text);
> CREATE INDEX ON test(v);
> INSERT INTO test(k, v) VALUES (0, 'foo');
> {noformat}
> with every replica up to date. Now, suppose that the following queries are
> done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v = 'bar' WHERE k = 0;
> SELECT * FROM test WHERE v = 'foo';
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before
> having applied the insert, then the now stale result will be returned (since
> C will return it and A or B will return nothing).
> A potential solution would be that when we read a tombstone in the index (and
> provided we make the index inherit the gcGrace of it's parent CF), instead of
> skipping that tombstone, we'd insert in the result a corresponding range
> tombstone.
--
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-15700) Performance regression on internode messaging
[
https://issues.apache.org/jira/browse/CASSANDRA-15700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126005#comment-17126005
]
Aleksey Yeschenko commented on CASSANDRA-15700:
---
Thanks for your patience overall. Just have a few nits now.
1. Can you change {{maybeUpdateEarliestExpiryTime()}} to have the same
structure as {{maybeUpdateNextExpirationDeadline()}}?
2. In {{add()}}, use the return value of {{maybeUpdateExpiryTime()}} instead of
loading the current value (should be equivalent)?
3. Fix up whitespace in the last commit
4. Check {{Remover}} logic? In particular I don't think {{earliestExpiresAt =
Long.MAX_VALUE;}} belongs there anymore.
And, so long as you don't mind omitting the {{id()}} commit, we can push.
> Performance regression on internode messaging
> -
>
> Key: CASSANDRA-15700
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15700
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Attachments: Oss40patchedvsOss311.png, Oss40vsOss311.png, oss40.gc,
> oss40_nogc.tar.xz, oss40_system.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Me and [~jasonstack] have been investigating a performance regression
> affecting 4.0 during a 3 nodes, RF 3 write throughput test with a timeseries
> like workload, as shown in this plot, where blue is 3.11 and orange is 4.0:
> !Oss40vsOss311.png|width=389,height=214!
> It's been a bit of a long investigation, but two clues ended up standing out:
> 1) An abnormal number of expired messages on 4.0 (as shown in the attached
> system log), while 3.11 has almost none.
> 2) An abnormal GC activity (as shown in the attached gc log).
> Turns out the two are related, as the [on expired
> callback|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundConnection.java#L462]
> creates a huge amount of strings in the {{id()}} call. The next question is
> what causes all those message expirations; we thoroughly reviewed the
> internode messaging code and the only issue we could find so far is related
> to the "batch pruning" calls
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L81]
> and
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L188]:
> it _seems_ too much time is spent on those, causing the event loop to fall
> behind in processing the rest of the messages, which will end up being
> expired. This is supported by the analysis of the collapsed stacks (after
> fixing the GC issue):
> {noformat}
> (tprint (top-aggregated-calls oss40nogc "EventLoopDelivery:doRun" 5))
> org/apache/cassandra/net/OutboundConnection$EventLoopDelivery:doRun 3456
> org/apache/cassandra/net/OutboundMessageQueue:access$600 1621
> org/apache/cassandra/net/PrunableArrayQueue:prune 1621
> org/apache/cassandra/net/OutboundMessageQueue$WithLock:close 1621
> org/apache/cassandra/net/OutboundMessageQueue:pruneInternalQueueWithLock 1620
> {noformat}
> Those are the top 5 sampled calls from {{EventLoopDelivery#doRun()}} which
> spends half of its time pruning. But only a tiny portion of such pruning time
> is spent actually expiring:
> {noformat}
> (tprint (top-aggregated-calls oss40nogc
> "OutboundMessageQueue:pruneInternalQueueWithLock" 5))
> org/apache/cassandra/net/OutboundMessageQueue:pruneInternalQueueWithLock 1900
> org/apache/cassandra/net/PrunableArrayQueue:prune 1894
> org/apache/cassandra/net/OutboundMessageQueue$1Pruner:onPruned 147
> org/apache/cassandra/net/OutboundConnection$$Lambda$444/740904487:accept 147
> org/apache/cassandra/net/OutboundConnection:onExpired 147
> {noformat}
> And indeed, the {{PrunableArrayQueue:prune()}} self time is dominant:
> {noformat}
> (tprint (top-self-calls oss40nogc "PrunableArrayQueue:prune" 5))
> org/apache/cassandra/net/PrunableArrayQueue:prune 1718
> org/apache/cassandra/net/OutboundConnection:releaseCapacity 27
> java/util/concurrent/ConcurrentHashMap:replaceNode 19
> java/util/concurrent/ConcurrentLinkedQueue:offer 16
> java/util/concurrent/LinkedBlockingQueue:offer 15
> {noformat}
> That said, before proceeding with a PR to fix those issues, I'd like to
> understand: what's the reason to prune so often, rather than just when
> polling the message during delivery? If there's a reason I'm missing, let's
> talk about how to optimize pruning, otherwise let's get rid of that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Updated] (CASSANDRA-15838) Add deb and rpm packaging to artifacts test script
[ https://issues.apache.org/jira/browse/CASSANDRA-15838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15838: --- Status: Ready to Commit (was: Review In Progress) > Add deb and rpm packaging to artifacts test script > -- > > Key: CASSANDRA-15838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15838 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-beta > > Attachments: Screenshot 2020-06-01 at 12.29.21.png, Screenshot > 2020-06-01 at 23.24.39.png > > > Currently we have no way of testing debian or rpm packaging. This is a > problem, it hurts when cutting releases as well as afterwards (like > CASSANDRA-15830). > This ticket is to add testing of debian or rpm packaging into the artifacts > test script. > This will also provide "nightly" build artifacts for the deb and rpm packages. -- 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-15838) Add deb and rpm packaging to artifacts test script
[ https://issues.apache.org/jira/browse/CASSANDRA-15838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15838: --- Fix Version/s: (was: 4.0-beta) 4.0-alpha5 4.0 Source Control Link: https://github.com/apache/cassandra-builds/commit/55a2d2676ff5820fa638511734e45a8908ce5ca2 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [55a2d2676ff5820fa638511734e45a8908ce5ca2 |https://github.com/apache/cassandra-builds/commit/55a2d2676ff5820fa638511734e45a8908ce5ca2] Thanks for the review [~stefan.miklosovic]! > Add deb and rpm packaging to artifacts test script > -- > > Key: CASSANDRA-15838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15838 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0, 4.0-alpha5 > > Attachments: Screenshot 2020-06-01 at 12.29.21.png, Screenshot > 2020-06-01 at 23.24.39.png > > > Currently we have no way of testing debian or rpm packaging. This is a > problem, it hurts when cutting releases as well as afterwards (like > CASSANDRA-15830). > This ticket is to add testing of debian or rpm packaging into the artifacts > test script. > This will also provide "nightly" build artifacts for the deb and rpm packages. -- 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-15778) CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
[
https://issues.apache.org/jira/browse/CASSANDRA-15778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126122#comment-17126122
]
Alex Petrov commented on CASSANDRA-15778:
-
[~dcapwell] thank you for the detailed explanation. I've taken your suggestion
in.
[~sumanth.pasupuleti] thank you for checking this on the cluster and your
feedback on the patch! I've added the test you have suggested. As regards
keyspace/cf key/value pairs, I did think about this. I think if you have
written to even a single cf, it makes sense to force {{BytesType}} for all cfs,
in particular - to avoid folks forgetting about previous writes. We can open up
a ticket with a follow-up/improvement, but I do not feel this is a necessary
condition for the fix.
> CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
> -
>
> Key: CASSANDRA-15778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/SSTable
>Reporter: Sumanth Pasupuleti
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 3.0.x
>
>
> Below is the exception with stack trace. This issue is consistently
> reproduce-able.
> {code:java}
> ERROR [SharedPool-Worker-1] 2020-05-01 14:57:57,661
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,main]ERROR [SharedPool-Worker-1] 2020-05-01
> 14:57:57,661 AbstractLocalAwareExecutorService.java:169 - Uncaught exception
> on thread
> Thread[SharedPool-Worker-1,5,main]org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /mnt/data/cassandra/data// at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:349)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:220)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:33)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:187)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:180)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:176)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:341)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
>
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126135#comment-17126135
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
*UPDATE:*
- the unit test is a flakey test. The configuration is properly loaded so it is
not caused by this patch.
- small issue with Auth_test.py was fixed.
- the rest of the failing unit tests are related to current failures we already
see on trunk. Some of them are already fixed in the newer commits. Rebase and
run new CI now to confirm the latest status.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126135#comment-17126135
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/4/20, 6:36 PM:
--
*UPDATE:*
- the failing unit test is a flakey test. The configuration is properly loaded
so it is not caused by this patch.
- small issue with Auth_test.py was fixed.
- the rest of the failing unit tests are related to current failures we already
see on trunk. Some of them are already fixed in the newer commits. Rebase and
run new CI now to confirm the latest status.
was (Author: e.dimitrova):
*UPDATE:*
- the unit test is a flakey test. The configuration is properly loaded so it is
not caused by this patch.
- small issue with Auth_test.py was fixed.
- the rest of the failing unit tests are related to current failures we already
see on trunk. Some of them are already fixed in the newer commits. Rebase and
run new CI now to confirm the latest status.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126135#comment-17126135
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/4/20, 6:54 PM:
--
*UPDATE:*
- the failing unit test is a flakey test. The configuration is properly loaded
so it is not caused by this patch.
- small issue with Auth_test.py was fixed.
- the rest of the failing DTests are related to current failures we already see
on trunk. Some of them are already fixed in the newer commits. Rebase and run
new CI now to confirm the latest status.
was (Author: e.dimitrova):
*UPDATE:*
- the failing unit test is a flakey test. The configuration is properly loaded
so it is not caused by this patch.
- small issue with Auth_test.py was fixed.
- the rest of the failing unit tests are related to current failures we already
see on trunk. Some of them are already fixed in the newer commits. Rebase and
run new CI now to confirm the latest status.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15857) Frozen RawTuple is not annotated with frozen in the toString method
[
https://issues.apache.org/jira/browse/CASSANDRA-15857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-15857:
--
Bug Category: Parent values: Correctness(12982)Level 1 values:
Unrecoverable Corruption / Loss(13161)
Complexity: Normal
Discovered By: Code Inspection
Severity: Normal
Status: Open (was: Triage Needed)
> Frozen RawTuple is not annotated with frozen in the toString method
> ---
>
> Key: CASSANDRA-15857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15857
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> All raw types (e.g. RawCollection, RawUT) that supports freezing wraps the
> type name with 'frozen<>' in the toString method, except RawTuple.
> Therefore, the RawTuple::toString output misses the frozen wrapper.
> Tuple is always frozen. However since CASSANDRA-15035, it throws when the
> inner tuple is not explicitly wrapped with frozen within a collection.
> The method, CQL3Type.Raw::toString, is referenced at multiple places in the
> source. For example, referenced in CreateTypeStatement.Raw and involved in
> CQLSSTableWriter. Another example is that it is called to produce the
> SchemaChange at several AlterSchemaStatement implementations.
> A test can prove that missing the frozen wrapper causes exception when
> building CQLSSTableWriter for user types defined like below. Note that the
> inner tuple is wrapped with frozen in the initial CQL statement.
> {code:java}
> CREATE TYPE ks.fooType ( f list>> )
> {code}
> {code:java}
> org.apache.cassandra.exceptions.InvalidRequestException: Non-frozen tuples
> are not allowed inside collections: list>
> at
> org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.throwNestedNonFrozenError(CQL3Type.java:710)
> at
> org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.prepare(CQL3Type.java:669)
> at
> org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.prepareInternal(CQL3Type.java:661)
> at
> org.apache.cassandra.schema.Types$RawBuilder$RawUDT.lambda$prepare$1(Types.java:341)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at
> org.apache.cassandra.schema.Types$RawBuilder$RawUDT.prepare(Types.java:342)
> at org.apache.cassandra.schema.Types$RawBuilder.build(Types.java:291)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.createTypes(CQLSSTableWriter.java:551)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.build(CQLSSTableWriter.java:527)
> {code}
--
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-15857) Frozen RawTuple is not annotated with frozen in the toString method
Yifan Cai created CASSANDRA-15857:
-
Summary: Frozen RawTuple is not annotated with frozen in the
toString method
Key: CASSANDRA-15857
URL: https://issues.apache.org/jira/browse/CASSANDRA-15857
Project: Cassandra
Issue Type: Bug
Components: Legacy/CQL
Reporter: Yifan Cai
Assignee: Yifan Cai
All raw types (e.g. RawCollection, RawUT) that supports freezing wraps the type
name with 'frozen<>' in the toString method, except RawTuple.
Therefore, the RawTuple::toString output misses the frozen wrapper.
Tuple is always frozen. However since CASSANDRA-15035, it throws when the inner
tuple is not explicitly wrapped with frozen within a collection.
The method, CQL3Type.Raw::toString, is referenced at multiple places in the
source. For example, referenced in CreateTypeStatement.Raw and involved in
CQLSSTableWriter. Another example is that it is called to produce the
SchemaChange at several AlterSchemaStatement implementations.
A test can prove that missing the frozen wrapper causes exception when building
CQLSSTableWriter for user types defined like below. Note that the inner tuple
is wrapped with frozen in the initial CQL statement.
{code:java}
CREATE TYPE ks.fooType ( f list>> )
{code}
{code:java}
org.apache.cassandra.exceptions.InvalidRequestException: Non-frozen tuples are
not allowed inside collections: list>
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.throwNestedNonFrozenError(CQL3Type.java:710)
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.prepare(CQL3Type.java:669)
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.prepareInternal(CQL3Type.java:661)
at
org.apache.cassandra.schema.Types$RawBuilder$RawUDT.lambda$prepare$1(Types.java:341)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at
org.apache.cassandra.schema.Types$RawBuilder$RawUDT.prepare(Types.java:342)
at org.apache.cassandra.schema.Types$RawBuilder.build(Types.java:291)
at
org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.createTypes(CQLSSTableWriter.java:551)
at
org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.build(CQLSSTableWriter.java:527)
{code}
--
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-15778) CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
[
https://issues.apache.org/jira/browse/CASSANDRA-15778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15778:
Since Version: 3.0 alpha 1
Source Control Link:
https://github.com/apache/cassandra/commit/c4064dd80e427aec7c04e8e2e1e4630d6c8087b6
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
> -
>
> Key: CASSANDRA-15778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/SSTable
>Reporter: Sumanth Pasupuleti
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 3.0.x
>
>
> Below is the exception with stack trace. This issue is consistently
> reproduce-able.
> {code:java}
> ERROR [SharedPool-Worker-1] 2020-05-01 14:57:57,661
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,main]ERROR [SharedPool-Worker-1] 2020-05-01
> 14:57:57,661 AbstractLocalAwareExecutorService.java:169 - Uncaught exception
> on thread
> Thread[SharedPool-Worker-1,5,main]org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /mnt/data/cassandra/data// at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:349)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:220)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:33)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:187)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:180)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:176)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:341)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_231] at
>
[jira] [Updated] (CASSANDRA-15778) CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
[
https://issues.apache.org/jira/browse/CASSANDRA-15778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15778:
Reviewers: David Capwell, Sylvain Lebresne, Alex Petrov (was: Alex Petrov,
David Capwell, Sylvain Lebresne)
David Capwell, Sylvain Lebresne, Alex Petrov (was: David
Capwell, Sylvain Lebresne)
Status: Review In Progress (was: Patch Available)
> CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
> -
>
> Key: CASSANDRA-15778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/SSTable
>Reporter: Sumanth Pasupuleti
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 3.0.x
>
>
> Below is the exception with stack trace. This issue is consistently
> reproduce-able.
> {code:java}
> ERROR [SharedPool-Worker-1] 2020-05-01 14:57:57,661
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,main]ERROR [SharedPool-Worker-1] 2020-05-01
> 14:57:57,661 AbstractLocalAwareExecutorService.java:169 - Uncaught exception
> on thread
> Thread[SharedPool-Worker-1,5,main]org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /mnt/data/cassandra/data// at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:349)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:220)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:33)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:187)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:180)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:176)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:341)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_231] at
>
[jira] [Updated] (CASSANDRA-15778) CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
[
https://issues.apache.org/jira/browse/CASSANDRA-15778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15778:
Status: Ready to Commit (was: Review In Progress)
> CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
> -
>
> Key: CASSANDRA-15778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/SSTable
>Reporter: Sumanth Pasupuleti
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 3.0.x
>
>
> Below is the exception with stack trace. This issue is consistently
> reproduce-able.
> {code:java}
> ERROR [SharedPool-Worker-1] 2020-05-01 14:57:57,661
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,main]ERROR [SharedPool-Worker-1] 2020-05-01
> 14:57:57,661 AbstractLocalAwareExecutorService.java:169 - Uncaught exception
> on thread
> Thread[SharedPool-Worker-1,5,main]org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /mnt/data/cassandra/data// at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:349)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:220)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:33)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:187)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:180)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:176)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:341)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_231] at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
>
[jira] [Commented] (CASSANDRA-15778) CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
[
https://issues.apache.org/jira/browse/CASSANDRA-15778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126130#comment-17126130
]
Alex Petrov commented on CASSANDRA-15778:
-
Thank you all for review and comments. Committed to 3.0 with
[c4064dd80e427aec7c04e8e2e1e4630d6c8087b6|https://github.com/apache/cassandra/commit/c4064dd80e427aec7c04e8e2e1e4630d6c8087b6],
and merged up to
[3.11|https://github.com/apache/cassandra/commit/056c9eff4b0311d9bde526e0bc9f39e5fad21e39].
Merge to trunk was done with {{-s ours}}.
> CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
> -
>
> Key: CASSANDRA-15778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/SSTable
>Reporter: Sumanth Pasupuleti
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 3.0.x
>
>
> Below is the exception with stack trace. This issue is consistently
> reproduce-able.
> {code:java}
> ERROR [SharedPool-Worker-1] 2020-05-01 14:57:57,661
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,main]ERROR [SharedPool-Worker-1] 2020-05-01
> 14:57:57,661 AbstractLocalAwareExecutorService.java:169 - Uncaught exception
> on thread
> Thread[SharedPool-Worker-1,5,main]org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /mnt/data/cassandra/data// at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:349)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:220)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:33)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:294)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:187)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:180)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:176)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:341)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
>
[cassandra] branch cassandra-3.0 updated: Allow recovery from the cases when CQL-created compact sense tables have bytes in EmptyType columns.
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new c4064dd Allow recovery from the cases when CQL-created compact sense
tables have bytes in EmptyType columns.
c4064dd is described below
commit c4064dd80e427aec7c04e8e2e1e4630d6c8087b6
Author: Alex Petrov
AuthorDate: Mon May 18 16:53:08 2020 +0200
Allow recovery from the cases when CQL-created compact sense tables have
bytes in EmptyType columns.
Patch by Alex Petrov; reviewed by Sylvain Lebresne for CASSANDRA-15778.
---
.../org/apache/cassandra/config/CFMetaData.java| 21
.../cql3/statements/AlterTableStatement.java | 23 -
.../apache/cassandra/db/marshal/AbstractType.java | 12 +--
.../cassandra/schema/LegacySchemaMigrator.java | 9 +++--
.../cassandra/serializers/EmptySerializer.java | 6 +++-
..._dense_table_with_bytes-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
...cql_created_dense_table_with_bytes-ka-1-Data.db | Bin 0 -> 56 bytes
...created_dense_table_with_bytes-ka-1-Digest.sha1 | 1 +
...l_created_dense_table_with_bytes-ka-1-Filter.db | Bin 0 -> 16 bytes
...ql_created_dense_table_with_bytes-ka-1-Index.db | Bin 0 -> 19 bytes
...eated_dense_table_with_bytes-ka-1-Statistics.db | Bin 0 -> 4450 bytes
..._created_dense_table_with_bytes-ka-1-Summary.db | Bin 0 -> 95 bytes
...cql_created_dense_table_with_bytes-ka-1-TOC.txt | 8 +
...ed_dense_table_with_int-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
...a_cql_created_dense_table_with_int-ka-1-Data.db | Bin 0 -> 49 bytes
...l_created_dense_table_with_int-ka-1-Digest.sha1 | 1 +
...cql_created_dense_table_with_int-ka-1-Filter.db | Bin 0 -> 16 bytes
..._cql_created_dense_table_with_int-ka-1-Index.db | Bin 0 -> 19 bytes
...created_dense_table_with_int-ka-1-Statistics.db | Bin 0 -> 4450 bytes
...ql_created_dense_table_with_int-ka-1-Summary.db | Bin 0 -> 95 bytes
...a_cql_created_dense_table_with_int-ka-1-TOC.txt | 8 +
.../cql3/validation/operations/AlterTest.java | 22
test/unit/org/apache/cassandra/db/ScrubTest.java | 3 +-
.../apache/cassandra/db/marshal/EmptyTypeTest.java | 2 +-
.../cassandra/io/sstable/LegacySSTableTest.java| 37 +
25 files changed, 144 insertions(+), 9 deletions(-)
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 68e06be..19f744e 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -615,6 +615,27 @@ public final class CFMetaData
this);
}
+public CFMetaData copyWithNewCompactValueType(AbstractType type)
+{
+assert isDense && compactValueColumn.type instanceof EmptyType &&
partitionColumns.size() == 1;
+return copyOpts(new CFMetaData(ksName,
+ cfName,
+ cfId,
+ isSuper,
+ isCounter,
+ isDense,
+ isCompound,
+ isView,
+ copy(partitionKeyColumns),
+ copy(clusteringColumns),
+
PartitionColumns.of(compactValueColumn.withNewType(type)),
+ partitioner,
+ superCfKeyColumn,
+ superCfValueColumn),
+this);
+}
+
+
private static List copy(List l)
{
List copied = new ArrayList<>(l.size());
diff --git
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 5bff24e..193c24c 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -30,6 +30,8 @@ import org.apache.cassandra.cql3.ColumnIdentifier;
import org.apache.cassandra.db.ColumnFamilyStore;
import org.apache.cassandra.db.Keyspace;
import org.apache.cassandra.db.marshal.AbstractType;
+import org.apache.cassandra.db.marshal.BytesType;
+import org.apache.cassandra.db.marshal.EmptyType;
import org.apache.cassandra.db.view.View;
import org.apache.cassandra.exceptions.*;
import org.apache.cassandra.schema.IndexMetadata;
@@ -109,7 +111,26 @@ public class AlterTableStatement extends
SchemaAlteringStatement
switch (oType)
{
case ALTER:
-throw new InvalidRequestException("Altering of types is not
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 056c9eff4b0311d9bde526e0bc9f39e5fad21e39
Merge: ebfd052 c4064dd
Author: Alex Petrov
AuthorDate: Thu Jun 4 20:17:31 2020 +0200
Merge branch 'cassandra-3.0' into cassandra-3.11
.../org/apache/cassandra/config/CFMetaData.java| 21
.../cql3/statements/AlterTableStatement.java | 30 -
.../apache/cassandra/db/marshal/AbstractType.java | 12 +--
.../cassandra/schema/LegacySchemaMigrator.java | 9 +++--
.../cassandra/serializers/EmptySerializer.java | 6 +++-
..._dense_table_with_bytes-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
...cql_created_dense_table_with_bytes-ka-1-Data.db | Bin 0 -> 56 bytes
...created_dense_table_with_bytes-ka-1-Digest.sha1 | 1 +
...l_created_dense_table_with_bytes-ka-1-Filter.db | Bin 0 -> 16 bytes
...ql_created_dense_table_with_bytes-ka-1-Index.db | Bin 0 -> 19 bytes
...eated_dense_table_with_bytes-ka-1-Statistics.db | Bin 0 -> 4450 bytes
..._created_dense_table_with_bytes-ka-1-Summary.db | Bin 0 -> 95 bytes
...cql_created_dense_table_with_bytes-ka-1-TOC.txt | 8 +
...ed_dense_table_with_int-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
...a_cql_created_dense_table_with_int-ka-1-Data.db | Bin 0 -> 49 bytes
...l_created_dense_table_with_int-ka-1-Digest.sha1 | 1 +
...cql_created_dense_table_with_int-ka-1-Filter.db | Bin 0 -> 16 bytes
..._cql_created_dense_table_with_int-ka-1-Index.db | Bin 0 -> 19 bytes
...created_dense_table_with_int-ka-1-Statistics.db | Bin 0 -> 4450 bytes
...ql_created_dense_table_with_int-ka-1-Summary.db | Bin 0 -> 95 bytes
...a_cql_created_dense_table_with_int-ka-1-TOC.txt | 8 +
.../cql3/validation/operations/AlterTest.java | 22
test/unit/org/apache/cassandra/db/ScrubTest.java | 3 +-
.../apache/cassandra/db/marshal/EmptyTypeTest.java | 2 +-
.../cassandra/io/sstable/LegacySSTableTest.java| 37 +
25 files changed, 151 insertions(+), 9 deletions(-)
diff --cc src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 5017fe3,193c24c..3e0674a
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@@ -97,8 -111,28 +99,34 @@@ public class AlterTableStatement extend
switch (oType)
{
case ALTER:
- throw new InvalidRequestException("Altering of types is not
allowed");
-// We do not support altering of types and only allow this to
for people who have already one
-// through the upgrade of 2.x CQL-created SSTables with
Thrift writes, affected by CASSANDRA-15778.
-if (meta.isDense()
-&& meta.compactValueColumn().equals(def)
-&& meta.compactValueColumn().type instanceof EmptyType
-&& validator != null)
++cfm = null;
++for (AlterTableStatementColumn colData : colNameList)
+ {
-if (validator.getType() instanceof BytesType)
++columnName = colData.getColumnName().getIdentifier(meta);
++def = meta.getColumnDefinition(columnName);
++dataType = colData.getColumnType();
++validator = dataType.prepare(keyspace());
++
++// We do not support altering of types and only allow
this to for people who have already one
++// through the upgrade of 2.x CQL-created SSTables with
Thrift writes, affected by CASSANDRA-15778.
++if (meta.isDense()
++&& meta.compactValueColumn().equals(def)
++&& meta.compactValueColumn().type instanceof EmptyType
++&& validator != null)
+ {
-cfm =
meta.copyWithNewCompactValueType(validator.getType());
-break;
++if (validator.getType() instanceof BytesType)
++cfm =
meta.copyWithNewCompactValueType(validator.getType());
++else
++throw new
InvalidRequestException(String.format("Compact value type can only be changed
to BytesType, but %s was given.",
++
validator.getType()));
+ }
-
-throw new InvalidRequestException(String.format("Compact
value type can only be changed to BytesType, but %s was given.",
-
validator.getType()));
+ }
-else
-{
++
++if (cfm == null)
[cassandra] branch cassandra-3.11 updated (ebfd052 -> 056c9ef)
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a change to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from ebfd052 Merge commit 'c8a2834606d683ba9945e9cc11bdb4207ce269d1' into
cassandra-3.11
new c4064dd Allow recovery from the cases when CQL-created compact sense
tables have bytes in EmptyType columns.
new 056c9ef Merge branch 'cassandra-3.0' into cassandra-3.11
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../org/apache/cassandra/config/CFMetaData.java| 21
.../cql3/statements/AlterTableStatement.java | 30 -
.../apache/cassandra/db/marshal/AbstractType.java | 12 +--
.../cassandra/schema/LegacySchemaMigrator.java | 9 +++--
.../cassandra/serializers/EmptySerializer.java | 6 +++-
..._dense_table_with_bytes-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
...cql_created_dense_table_with_bytes-ka-1-Data.db | Bin 0 -> 56 bytes
...created_dense_table_with_bytes-ka-1-Digest.sha1 | 1 +
...l_created_dense_table_with_bytes-ka-1-Filter.db | Bin 0 -> 16 bytes
...ql_created_dense_table_with_bytes-ka-1-Index.db | Bin 0 -> 19 bytes
...ated_dense_table_with_bytes-ka-1-Statistics.db} | Bin 4452 -> 4450 bytes
..._created_dense_table_with_bytes-ka-1-Summary.db | Bin 0 -> 95 bytes
...ql_created_dense_table_with_bytes-ka-1-TOC.txt} | 8 ++---
...ed_dense_table_with_int-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
...a_cql_created_dense_table_with_int-ka-1-Data.db | Bin 0 -> 49 bytes
...l_created_dense_table_with_int-ka-1-Digest.sha1 | 1 +
...cql_created_dense_table_with_int-ka-1-Filter.db | Bin 0 -> 16 bytes
..._cql_created_dense_table_with_int-ka-1-Index.db | Bin 0 -> 19 bytes
...reated_dense_table_with_int-ka-1-Statistics.db} | Bin 4452 -> 4450 bytes
...ql_created_dense_table_with_int-ka-1-Summary.db | Bin 0 -> 95 bytes
..._cql_created_dense_table_with_int-ka-1-TOC.txt} | 8 ++---
.../cql3/validation/operations/AlterTest.java | 22
test/unit/org/apache/cassandra/db/ScrubTest.java | 3 +-
.../apache/cassandra/db/marshal/EmptyTypeTest.java | 2 +-
.../cassandra/io/sstable/LegacySSTableTest.java| 37 +
25 files changed, 143 insertions(+), 17 deletions(-)
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_bytes/legacy_tables-legacy_ka_cql_created_dense_table_with_bytes-ka-1-CompressionInfo.db
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_bytes/legacy_tables-legacy_ka_cql_created_dense_table_with_bytes-ka-1-Data.db
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_bytes/legacy_tables-legacy_ka_cql_created_dense_table_with_bytes-ka-1-Digest.sha1
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_bytes/legacy_tables-legacy_ka_cql_created_dense_table_with_bytes-ka-1-Filter.db
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_bytes/legacy_tables-legacy_ka_cql_created_dense_table_with_bytes-ka-1-Index.db
copy
test/data/legacy-sstables/ka/legacy_tables/{legacy_ka_with_illegal_cell_names/legacy_tables-legacy_ka_with_illegal_cell_names-ka-2-Statistics.db
=>
legacy_ka_cql_created_dense_table_with_bytes/legacy_tables-legacy_ka_cql_created_dense_table_with_bytes-ka-1-Statistics.db}
(95%)
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_bytes/legacy_tables-legacy_ka_cql_created_dense_table_with_bytes-ka-1-Summary.db
copy test/data/{bloom-filter/ka/foo/foo-atable-ka-1-TOC.txt =>
legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_bytes/legacy_tables-legacy_ka_cql_created_dense_table_with_bytes-ka-1-TOC.txt}
(100%)
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_int/legacy_tables-legacy_ka_cql_created_dense_table_with_int-ka-1-CompressionInfo.db
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_int/legacy_tables-legacy_ka_cql_created_dense_table_with_int-ka-1-Data.db
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_int/legacy_tables-legacy_ka_cql_created_dense_table_with_int-ka-1-Digest.sha1
create mode 100644
test/data/legacy-sstables/ka/legacy_tables/legacy_ka_cql_created_dense_table_with_int/legacy_tables-legacy_ka_cql_created_dense_table_with_int-ka-1-Filter.db
create mode 100644
[cassandra] branch trunk updated (d6552ce -> da8fe7a)
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d6552ce Use Docker image for dtests in CircleCI w/ JAVA8_HOME environment variable & Allow different pip-source-install repos in requirements.txt new c4064dd Allow recovery from the cases when CQL-created compact sense tables have bytes in EmptyType columns. new 056c9ef Merge branch 'cassandra-3.0' into cassandra-3.11 new da8fe7a Merge branch 'cassandra-3.11' into trunk The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit da8fe7a2c23ad2ff1ea2168cccf90c8ef082957e Merge: d6552ce 056c9ef Author: Alex Petrov AuthorDate: Thu Jun 4 20:17:45 2020 +0200 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126344#comment-17126344
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 3:35 AM:
--
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk|] ] [ [JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
was (Author: e.dimitrova):
[ trunk ] [ DTests ] [ CCM ] [ JAVA8 ] [ JAVA11 ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
Last update: after rebase and a few nits on my end, we have only 1 DTest and 1
Unit test failing in JAVA11. Unrelated known failures.
added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
"line.separator" getter added
[ [trunk|] ] [ JAVA8 CI ] [ JAVA11 CI ]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15234:
Test and Documentation Plan:
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk|] ] [ [JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
Status: Patch Available (was: In Progress)
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126344#comment-17126344
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 3:36 AM:
--
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [
[JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
was (Author: e.dimitrova):
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk|] ] [ [JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are
[jira] [Updated] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15234:
Attachment: CASSANDRA-15234-3-DTests-JAVA8.txt
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15234:
Test and Documentation Plan:
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [
[JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
was:
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk|] ] [ [JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we
[jira] [Updated] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15234:
Test and Documentation Plan:
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [
[JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE:* Before commit return to the default config.yml and requirements.txt
files
was:
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [
[JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126344#comment-17126344
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
[ trunk ] [ DTests ] [ CCM ] [ JAVA8 ] [ JAVA11 ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
Last update: after rebase and a few nits on my end, we have only 1 DTest and 1
Unit test failing in JAVA11. Unrelated known failures.
added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
"line.separator" getter added
[ [trunk|] ] [ JAVA8 CI ] [ JAVA11 CI ]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126344#comment-17126344
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 3:37 AM:
--
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [
[JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE:* Before commit return to the default config.yml and requirements.txt
files
was (Author: e.dimitrova):
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase
] ] [ [DTests |
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ]
[ [JAVA8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
] [ [JAVA11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
] ]
Attached to the ticket is the log of the successful runs of the few failing
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as
it didn't make sense to me to rerun the whole suite of tests.
*Last update:* after rebase and a few nits on my end, we have only 1 DTest and
1 Unit test failing in JAVA11. Unrelated known failures.
- added additional note on the possible units to be used as suffixes in both
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
- "line.separator" getter added
[ [trunk
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [
[JAVA8 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
] [ [JAVA11 CI
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt
files
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds
[jira] [Updated] (CASSANDRA-15792) test_speculative_data_request - read_repair_test.TestSpeculativeReadRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-15792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15792: Reviewers: Berenguer Blasi > test_speculative_data_request - read_repair_test.TestSpeculativeReadRepair > -- > > Key: CASSANDRA-15792 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15792 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-beta > > > Failing on the latest trunk here: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/127/workflows/dfba669d-4a5c-4553-b6a2-85647d0d8d2b/jobs/668/tests > Failing once in 30 times as per Jenkins: > https://jenkins-cm4.apache.org/job/Cassandra-trunk-dtest/69/testReport/dtest.read_repair_test/TestSpeculativeReadRepair/test_speculative_data_request/ -- 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-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126389#comment-17126389 ] Berenguer Blasi commented on CASSANDRA-15855: - [~adelapena] thx for the run that is very kind of you. You made me think the test should run for <4.0 were the implementation for MVs is different. So I amended my commit to instead of skipping always, running it up to 3X and xfail for 4.0. This is much better imo.wdyt? > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- 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-15845) MV schema version update race
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15845:
Description:
test_populate_mv_after_insert_wide_rows fails with
{quote}
ERROR [MutationStage-2] 2020-06-02 17:31:46,414 Keyspace.java:621 - Attempting
to mutate non-existant table 2afc69c0-a4e6-11ea-a44e-7941109e8480 (ks.t_by_v)
{quote}
was:
See failure
[here|https://ci-cassandra.apache.org/job/Cassandra-trunk/155/testReport/dtest-novnode.materialized_views_test/TestMaterializedViews/test_populate_mv_after_insert_wide_rows_2/]
{quote}Error Message
assert 160 == 0 + where 160 = Row(count=160).count
Stacktrace
self =
def test_populate_mv_after_insert_wide_rows(self):
"""Test that a view is OK when created with existing data with wide
rows"""
session = self.prepare(consistency_level=ConsistencyLevel.QUORUM)
session.execute("CREATE TABLE t (id int, v int, PRIMARY KEY (id, v))")
for i in range(5):
for j in range(1):
session.execute("INSERT INTO t (id, v) VALUES ({},
{})".format(i, j))
session.execute(("CREATE MATERIALIZED VIEW t_by_v AS SELECT * FROM t
WHERE v IS NOT NULL "
"AND id IS NOT NULL PRIMARY KEY (v, id)"))
logger.debug("wait for view to build")
self._wait_for_view("ks", "t_by_v")
logger.debug("wait that all batchlogs are replayed")
> self._replay_batchlogs()
materialized_views_test.py:350:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
def _replay_batchlogs(self):
for node in self.cluster.nodelist():
if node.is_running():
logger.debug("Replaying batchlog on node {}".format(node.name))
node.nodetool("replaybatchlog")
# CASSANDRA-13069 - Ensure replayed mutations are removed from
the batchlog
node_session = self.patient_exclusive_cql_connection(node)
result = list(node_session.execute("SELECT count(*) FROM
system.batches;"))
> assert result[0].count == 0
E assert 160 == 0
E+ where 160 = Row(count=160).count
materialized_views_test.py:171: AssertionError{quote}
> MV schema version update race
> -
>
> Key: CASSANDRA-15845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15845
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views, Test/dtest
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> test_populate_mv_after_insert_wide_rows fails with
> {quote}
> ERROR [MutationStage-2] 2020-06-02 17:31:46,414 Keyspace.java:621 -
> Attempting to mutate non-existant table 2afc69c0-a4e6-11ea-a44e-7941109e8480
> (ks.t_by_v)
> {quote}
--
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-15838) Add deb and rpm packaging to artifacts test script
[ https://issues.apache.org/jira/browse/CASSANDRA-15838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125901#comment-17125901 ] Stefan Miklosovic commented on CASSANDRA-15838: --- Tested and worked as expected. +1 for merging > Add deb and rpm packaging to artifacts test script > -- > > Key: CASSANDRA-15838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15838 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-beta > > Attachments: Screenshot 2020-06-01 at 12.29.21.png, Screenshot > 2020-06-01 at 23.24.39.png > > > Currently we have no way of testing debian or rpm packaging. This is a > problem, it hurts when cutting releases as well as afterwards (like > CASSANDRA-15830). > This ticket is to add testing of debian or rpm packaging into the artifacts > test script. > This will also provide "nightly" build artifacts for the deb and rpm packages. -- 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-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15855: Fix Version/s: 4.0-beta > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- 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] [Issue Comment Deleted] (CASSANDRA-15838) Add deb and rpm packaging to artifacts test script
[ https://issues.apache.org/jira/browse/CASSANDRA-15838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15838: -- Comment: was deleted (was: Tested and worked as expected. +1 for merging) > Add deb and rpm packaging to artifacts test script > -- > > Key: CASSANDRA-15838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15838 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-beta > > Attachments: Screenshot 2020-06-01 at 12.29.21.png, Screenshot > 2020-06-01 at 23.24.39.png > > > Currently we have no way of testing debian or rpm packaging. This is a > problem, it hurts when cutting releases as well as afterwards (like > CASSANDRA-15830). > This ticket is to add testing of debian or rpm packaging into the artifacts > test script. > This will also provide "nightly" build artifacts for the deb and rpm packages. -- 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-15838) Add deb and rpm packaging to artifacts test script
[ https://issues.apache.org/jira/browse/CASSANDRA-15838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15838: -- Reviewers: Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Stefan Miklosovic, Stefan Miklosovic Status: Review In Progress (was: Patch Available) Tested and works as described. +1 for mering. > Add deb and rpm packaging to artifacts test script > -- > > Key: CASSANDRA-15838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15838 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-beta > > Attachments: Screenshot 2020-06-01 at 12.29.21.png, Screenshot > 2020-06-01 at 23.24.39.png > > > Currently we have no way of testing debian or rpm packaging. This is a > problem, it hurts when cutting releases as well as afterwards (like > CASSANDRA-15830). > This ticket is to add testing of debian or rpm packaging into the artifacts > test script. > This will also provide "nightly" build artifacts for the deb and rpm packages. -- 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-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125938#comment-17125938 ] Andres de la Peña commented on CASSANDRA-15855: --- [~Bereng] [here|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/145/] you have a run of dtests for trunk and your dtest branch. I'd say we don't need to run them for 3.0 or 3.11, given that it's just ignoring a test and AFAIK we don't have a way to run specific dtests. > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: Add deb and rpm packaging to cassandra-artifacts.sh test script
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new 55a2d26 Add deb and rpm packaging to cassandra-artifacts.sh test
script
55a2d26 is described below
commit 55a2d2676ff5820fa638511734e45a8908ce5ca2
Author: Mick Semb Wever
AuthorDate: Tue Jun 2 18:23:44 2020 +0200
Add deb and rpm packaging to cassandra-artifacts.sh test script
- extend the build-scripts/cassandra-*-packaging.sh scripts to build on
SHAs (as well as tags and branches),
- add support for building deb/rpm packages with jdk11,
- add support for running the the build-scripts/cassandra-*-packaging.sh
scripts concurrently,
- include calling the cassandra-*-packaging.sh scripts from the
cassandra-artifacts.sh scripts,
- get prepare_release.sh script to re-use the cassandra-*-packaging.sh
scripts,
- have jenkins artifact jobs save the deb and rpm packages, so they are
available as "nightlies" (along with the tar.gz files)
patch by Mick Semb Wever; reviewed by Stefan Miklosovic for CASSANDRA-15830
---
build-scripts/cassandra-artifacts.sh | 24
build-scripts/cassandra-deb-packaging.sh | 48 ++-
build-scripts/cassandra-rpm-packaging.sh | 49 ++--
cassandra-release/prepare_release.sh | 31 ++-
docker/build-debs.sh | 63 +++
docker/build-rpms.sh | 50 +---
docker/centos7-image.docker | 1 -
jenkins-dsl/cassandra_job_dsl_seed.groovy | 42 ++---
8 files changed, 209 insertions(+), 99 deletions(-)
diff --git a/build-scripts/cassandra-artifacts.sh
b/build-scripts/cassandra-artifacts.sh
index 7cdda72..5dae24e 100755
--- a/build-scripts/cassandra-artifacts.sh
+++ b/build-scripts/cassandra-artifacts.sh
@@ -6,6 +6,19 @@
#
+# variables, with defaults
+[ "x${cassandra_builds_dir}" != "x" ] ||
cassandra_builds_dir="cassandra-builds"
+
+# pre-conditions
+command -v ant >/dev/null 2>&1 || { echo >&2 "ant needs to be installed"; exit
1; }
+command -v pip >/dev/null 2>&1 || { echo >&2 "pip needs to be installed"; exit
1; }
+command -v virtualenv >/dev/null 2>&1 || { echo >&2 "virtualenv needs to be
installed"; exit 1; }
+command -v docker >/dev/null 2>&1 || { echo >&2 "docker needs to be
installed"; exit 1; }
+(docker info >/dev/null 2>&1) || { echo >&2 "docker needs to running"; exit 1;
}
+[ -f "build.xml" ] || { echo >&2 "build.xml must exist"; exit 1; }
+[ -d "${cassandra_builds_dir}" ] || { echo >&2 "cassandra-builds directory
must exist"; exit 1; }
+
+
# Sphinx is needed for the gen-doc target
virtualenv venv
source venv/bin/activate
@@ -27,6 +40,17 @@ for x in $(seq 1 3); do
# Run eclipse-warnings if build was successful
ant eclipse-warnings
RETURN="$?"
+if [ "${RETURN}" -eq "0" ]; then
+set -e
+# build debian and rpm packages
+head_commit=`git log --pretty=oneline -1 | cut -d " " -f 1`
+declare -x cassandra_builds_dir="${cassandra_builds_dir}"
+declare -x CASSANDRA_GIT_URL="`git remote get-url origin`"
+# debian
+deb_dir="`pwd`/build"
${cassandra_builds_dir}/build-scripts/cassandra-deb-packaging.sh ${head_commit}
+# rpm
+rpm_dir="`pwd`/build"
${cassandra_builds_dir}/build-scripts/cassandra-rpm-packaging.sh ${head_commit}
+fi
break
fi
done
diff --git a/build-scripts/cassandra-deb-packaging.sh
b/build-scripts/cassandra-deb-packaging.sh
index 4466ced..8b71697 100755
--- a/build-scripts/cassandra-deb-packaging.sh
+++ b/build-scripts/cassandra-deb-packaging.sh
@@ -1,16 +1,44 @@
#!/bin/bash -xe
+#
+# Builds (inside docker) the rpm packages for the provided git sha
+#
+# Called from build-scripts/cassandra-artifacts.sh or
cassandra-release/prepare_release.sh
-CASSANDRA_BUILDS_DIR="${WORKSPACE}/cassandra-builds"
-CASSANDRA_GIT_URL=$1
-CASSANDRA_BRANCH=$2
+if [ "$#" -lt 1 ]; then
+ echo "$0 "
+ echo "if Java version is not set, it is set to 8 by default, choose from 8
or 11"
+ exit 1
+fi
-# Create build images containing the build tool-chain, Java and an Apache
Cassandra git working directory
-docker build --build-arg CASSANDRA_GIT_URL=$CASSANDRA_GIT_URL -f
${CASSANDRA_BUILDS_DIR}/docker/jessie-image.docker
${CASSANDRA_BUILDS_DIR}/docker/
+sha=$1
+java_version=$2
+
+# required arguments
+[ "x${sha}" != "x" ] || { echo >&2 "Missing argument "; exit
1; }
+
+# variables, with defaults
+[ "x${deb_dir}" != "x" ] || deb_dir="."
+[ "x${cassandra_builds_dir}" != "x" ] || cassandra_builds_dir="."
+[ "x${CASSANDRA_GIT_URL}" != "x" ] ||
[jira] [Updated] (CASSANDRA-15848) Fully purged static row causes NPE in repaired data tracking
[
https://issues.apache.org/jira/browse/CASSANDRA-15848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15848:
Status: Changes Suggested (was: Review In Progress)
I think we should check if {{purged.isEmpty()}} instead of {{row.isEmpty()}}
> Fully purged static row causes NPE in repaired data tracking
>
>
> Key: CASSANDRA-15848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15848
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> During repaired data tracking, if the result of applying the purge function
> to a static row is null, an exception is thrown from RepairedDataInfo. This
> will cause a read exception from the replica and could lead to unavailable
> results if hit on multiple replicas. A workaround is to disable repaired data
> tracking.
--
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-15848) Fully purged static row causes NPE in repaired data tracking
[ https://issues.apache.org/jira/browse/CASSANDRA-15848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15848: Reviewers: Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson) Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson) Status: Review In Progress (was: Patch Available) > Fully purged static row causes NPE in repaired data tracking > > > Key: CASSANDRA-15848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15848 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-alpha > > > During repaired data tracking, if the result of applying the purge function > to a static row is null, an exception is thrown from RepairedDataInfo. This > will cause a read exception from the replica and could lead to unavailable > results if hit on multiple replicas. A workaround is to disable repaired data > tracking. -- 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-15845) MV schema version update race
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-15845:
---
Assignee: (was: Berenguer Blasi)
> MV schema version update race
> -
>
> Key: CASSANDRA-15845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15845
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views, Test/dtest
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/155/testReport/dtest-novnode.materialized_views_test/TestMaterializedViews/test_populate_mv_after_insert_wide_rows_2/]
> {quote}Error Message
> assert 160 == 0 + where 160 = Row(count=160).count
> Stacktrace
> self = 0x7fcb232b5760>
> def test_populate_mv_after_insert_wide_rows(self):
> """Test that a view is OK when created with existing data with wide
> rows"""
> session = self.prepare(consistency_level=ConsistencyLevel.QUORUM)
>
> session.execute("CREATE TABLE t (id int, v int, PRIMARY KEY (id, v))")
>
> for i in range(5):
> for j in range(1):
> session.execute("INSERT INTO t (id, v) VALUES ({},
> {})".format(i, j))
>
> session.execute(("CREATE MATERIALIZED VIEW t_by_v AS SELECT * FROM t
> WHERE v IS NOT NULL "
> "AND id IS NOT NULL PRIMARY KEY (v, id)"))
>
> logger.debug("wait for view to build")
> self._wait_for_view("ks", "t_by_v")
>
> logger.debug("wait that all batchlogs are replayed")
> > self._replay_batchlogs()
> materialized_views_test.py:350:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = 0x7fcb232b5760>
> def _replay_batchlogs(self):
> for node in self.cluster.nodelist():
> if node.is_running():
> logger.debug("Replaying batchlog on node
> {}".format(node.name))
> node.nodetool("replaybatchlog")
> # CASSANDRA-13069 - Ensure replayed mutations are removed
> from the batchlog
> node_session = self.patient_exclusive_cql_connection(node)
> result = list(node_session.execute("SELECT count(*) FROM
> system.batches;"))
> > assert result[0].count == 0
> E assert 160 == 0
> E+ where 160 = Row(count=160).count
> materialized_views_test.py:171: AssertionError{quote}
--
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-14612) Please add OWASP Dependency Check to the build (pom.xml)
[
https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125760#comment-17125760
]
Michael Semb Wever edited comment on CASSANDRA-14612 at 6/4/20, 9:50 AM:
-
+1 to starting with…
- adding into build.xml the ant {{dependency-check}},
- call it from the {{cassandra-artifacts.sh}}
[script|https://github.com/apache/cassandra-builds/blob/master/build-scripts/cassandra-artifacts.sh],
alongside the call to eclipse-warnings,
Then we can deal with checking past releases later on, as currently there's no
such post-release checks (AFAIK).
was (Author: michaelsembwever):
+1 to starting with…
- adding into build.xml the ant {{dependency-check}},
- call it from the {{cassandra-artifacts.sh}}
[script|https://github.com/apache/cassandra-builds/blob/master/build-scripts/cassandra-artifacts.sh,
alongside the call to eclipse-warnings,
Then we can deal with checking past releases later on, as currently there's no
such post-release checks (AFAIK).
> Please add OWASP Dependency Check to the build (pom.xml)
>
>
> Key: CASSANDRA-14612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14612
> Project: Cassandra
> Issue Type: New Feature
> Components: Build
> Environment: All development, build, test, environments.
>Reporter: Albert Baker
>Priority: Normal
> Labels: build, easyfix, security
> Fix For: 3.11.x, 4.x
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an
> outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to
> perform a lookup for each dependant .jar to list any/all known
> vulnerabilities for each jar. This step is needed because a manual MITRE CVE
> lookup/check on the main component does not include checking for
> vulnerabilities in components or in dependant libraries.
> OWASP Dependency check :
> https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most
> Java build/make types (ant, maven, ivy, gradle).
> Also, add the appropriate command to the nightly build to generate a report
> of all known vulnerabilities in any/all third party libraries/dependencies
> that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false
> clean aggregate
> Generating this report nightly/weekly will help inform the project's
> development team if any dependant libraries have a reported known
> vulnerailities. Project teams that keep up with removing vulnerabilities on a
> weekly basis will help protect businesses that rely on these open source
> componets.
--
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-14612) Please add OWASP Dependency Check to the build (pom.xml)
[
https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125760#comment-17125760
]
Michael Semb Wever edited comment on CASSANDRA-14612 at 6/4/20, 9:50 AM:
-
+1 to starting with…
- adding into build.xml the ant {{dependency-check}},
- call it from the {{cassandra-artifacts.sh}}
[script|https://github.com/apache/cassandra-builds/blob/master/build-scripts/cassandra-artifacts.sh],
alongside the call to eclipse-warnings, (i'm not sure how we "report" issues
though… do we really want to fail the build?)
Then we can deal with checking past releases later on, as currently there's no
such post-release checks (AFAIK).
was (Author: michaelsembwever):
+1 to starting with…
- adding into build.xml the ant {{dependency-check}},
- call it from the {{cassandra-artifacts.sh}}
[script|https://github.com/apache/cassandra-builds/blob/master/build-scripts/cassandra-artifacts.sh],
alongside the call to eclipse-warnings,
Then we can deal with checking past releases later on, as currently there's no
such post-release checks (AFAIK).
> Please add OWASP Dependency Check to the build (pom.xml)
>
>
> Key: CASSANDRA-14612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14612
> Project: Cassandra
> Issue Type: New Feature
> Components: Build
> Environment: All development, build, test, environments.
>Reporter: Albert Baker
>Priority: Normal
> Labels: build, easyfix, security
> Fix For: 3.11.x, 4.x
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an
> outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to
> perform a lookup for each dependant .jar to list any/all known
> vulnerabilities for each jar. This step is needed because a manual MITRE CVE
> lookup/check on the main component does not include checking for
> vulnerabilities in components or in dependant libraries.
> OWASP Dependency check :
> https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most
> Java build/make types (ant, maven, ivy, gradle).
> Also, add the appropriate command to the nightly build to generate a report
> of all known vulnerabilities in any/all third party libraries/dependencies
> that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false
> clean aggregate
> Generating this report nightly/weekly will help inform the project's
> development team if any dependant libraries have a reported known
> vulnerailities. Project teams that keep up with removing vulnerabilities on a
> weekly basis will help protect businesses that rely on these open source
> componets.
--
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-15845) MV schema version update race
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125755#comment-17125755
]
Berenguer Blasi commented on CASSANDRA-15845:
-
After speaking with [~jasonstack] we agreed this race condition is in the
nature of the beast. It won't accommodate a quick and easy fix so better move
it off 4.0 to be picked up later at a better time. Meanwhile a skip for the
flaky failing test will be added.
> MV schema version update race
> -
>
> Key: CASSANDRA-15845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15845
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views, Test/dtest
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/155/testReport/dtest-novnode.materialized_views_test/TestMaterializedViews/test_populate_mv_after_insert_wide_rows_2/]
> {quote}Error Message
> assert 160 == 0 + where 160 = Row(count=160).count
> Stacktrace
> self = 0x7fcb232b5760>
> def test_populate_mv_after_insert_wide_rows(self):
> """Test that a view is OK when created with existing data with wide
> rows"""
> session = self.prepare(consistency_level=ConsistencyLevel.QUORUM)
>
> session.execute("CREATE TABLE t (id int, v int, PRIMARY KEY (id, v))")
>
> for i in range(5):
> for j in range(1):
> session.execute("INSERT INTO t (id, v) VALUES ({},
> {})".format(i, j))
>
> session.execute(("CREATE MATERIALIZED VIEW t_by_v AS SELECT * FROM t
> WHERE v IS NOT NULL "
> "AND id IS NOT NULL PRIMARY KEY (v, id)"))
>
> logger.debug("wait for view to build")
> self._wait_for_view("ks", "t_by_v")
>
> logger.debug("wait that all batchlogs are replayed")
> > self._replay_batchlogs()
> materialized_views_test.py:350:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = 0x7fcb232b5760>
> def _replay_batchlogs(self):
> for node in self.cluster.nodelist():
> if node.is_running():
> logger.debug("Replaying batchlog on node
> {}".format(node.name))
> node.nodetool("replaybatchlog")
> # CASSANDRA-13069 - Ensure replayed mutations are removed
> from the batchlog
> node_session = self.patient_exclusive_cql_connection(node)
> result = list(node_session.execute("SELECT count(*) FROM
> system.batches;"))
> > assert result[0].count == 0
> E assert 160 == 0
> E+ where 160 = Row(count=160).count
> materialized_views_test.py:171: AssertionError{quote}
--
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-15822) DOC - Improve C* configuration docs
[ https://issues.apache.org/jira/browse/CASSANDRA-15822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15822: --- Source Control Link: https://github.com/apache/cassandra/commit/57a63f8551448d10d39f67d138842e0c81414526 (was: https://issues.apache.org/jira/browse/CASSANDRA-15822) > DOC - Improve C* configuration docs > --- > > Key: CASSANDRA-15822 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15822 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 4.0-alpha5 > > > Two sections, Getting started > Configuring and Configuration, could use > improvement. > Adding information about some of the other config files besides > cassandra.yaml is one key goal. > > At the risk of contaminating one ticket with another project, I started > creating a separate glossary file, so that key terms in configuration can be > linked to a glossary that describes terms. -- 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-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
Berenguer Blasi created CASSANDRA-15855: --- Summary: Mark test_populate_mv_after_insert_wide_rows as flaky Key: CASSANDRA-15855 URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 Project: Cassandra Issue Type: Bug Components: Test/dtest Reporter: Berenguer Blasi See CASSANDRA-15845. This test can still fail in a flaky way so we better mark it as such to avoid confusion and dup investigation efforts on failing tests -- 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-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-15855: --- Assignee: Berenguer Blasi > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- 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-15752) Range read concurrency factor didn't consider range merger
[
https://issues.apache.org/jira/browse/CASSANDRA-15752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-15752:
--
Reviewers: Andres de la Peña
> Range read concurrency factor didn't consider range merger
> --
>
> Key: CASSANDRA-15752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> During range read, coordinator computes concurrency factor which is the
> number of vnode ranges to contact in parallel for the next batch.
> But in {{RangeCommandIterator}}, vnode ranges are merged by {{RangeMerger}}
> if vnode ranges share enough replicas to satisfy consistency level. eg. vnode
> range [a,b) has replica n1,n2,n3 and vnode range [b,c) has replica n2,n3,n4,
> so they can be merged as range [a,c) with replica n2, n3 for Quorum.
> Currently it counts number of merged ranges towards concurrency factor.
> Coordinator may fetch more ranges than needed.
>
> Another issue is that when executing range read on table with very small
> amount of data, concurrency factor can be bumped to {{size of total vnode
> ranges}}, eg. 10k, depending on the num of vnodes and cluster size. As a
> result, coordinator will send large number of concurrent range requests,
> potentially slowing down the cluster.. We should cap the max concurrency
> factor..
--
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-15845) MV schema version update race
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15845:
Summary: MV schema version update race (was:
test_populate_mv_after_insert_wide_rows schema version update race)
> MV schema version update race
> -
>
> Key: CASSANDRA-15845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15845
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/155/testReport/dtest-novnode.materialized_views_test/TestMaterializedViews/test_populate_mv_after_insert_wide_rows_2/]
> {quote}Error Message
> assert 160 == 0 + where 160 = Row(count=160).count
> Stacktrace
> self = 0x7fcb232b5760>
> def test_populate_mv_after_insert_wide_rows(self):
> """Test that a view is OK when created with existing data with wide
> rows"""
> session = self.prepare(consistency_level=ConsistencyLevel.QUORUM)
>
> session.execute("CREATE TABLE t (id int, v int, PRIMARY KEY (id, v))")
>
> for i in range(5):
> for j in range(1):
> session.execute("INSERT INTO t (id, v) VALUES ({},
> {})".format(i, j))
>
> session.execute(("CREATE MATERIALIZED VIEW t_by_v AS SELECT * FROM t
> WHERE v IS NOT NULL "
> "AND id IS NOT NULL PRIMARY KEY (v, id)"))
>
> logger.debug("wait for view to build")
> self._wait_for_view("ks", "t_by_v")
>
> logger.debug("wait that all batchlogs are replayed")
> > self._replay_batchlogs()
> materialized_views_test.py:350:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = 0x7fcb232b5760>
> def _replay_batchlogs(self):
> for node in self.cluster.nodelist():
> if node.is_running():
> logger.debug("Replaying batchlog on node
> {}".format(node.name))
> node.nodetool("replaybatchlog")
> # CASSANDRA-13069 - Ensure replayed mutations are removed
> from the batchlog
> node_session = self.patient_exclusive_cql_connection(node)
> result = list(node_session.execute("SELECT count(*) FROM
> system.batches;"))
> > assert result[0].count == 0
> E assert 160 == 0
> E+ where 160 = Row(count=160).count
> materialized_views_test.py:171: AssertionError{quote}
--
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-15845) MV schema version update race
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15845:
Component/s: Feature/Materialized Views
> MV schema version update race
> -
>
> Key: CASSANDRA-15845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15845
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views, Test/dtest
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/155/testReport/dtest-novnode.materialized_views_test/TestMaterializedViews/test_populate_mv_after_insert_wide_rows_2/]
> {quote}Error Message
> assert 160 == 0 + where 160 = Row(count=160).count
> Stacktrace
> self = 0x7fcb232b5760>
> def test_populate_mv_after_insert_wide_rows(self):
> """Test that a view is OK when created with existing data with wide
> rows"""
> session = self.prepare(consistency_level=ConsistencyLevel.QUORUM)
>
> session.execute("CREATE TABLE t (id int, v int, PRIMARY KEY (id, v))")
>
> for i in range(5):
> for j in range(1):
> session.execute("INSERT INTO t (id, v) VALUES ({},
> {})".format(i, j))
>
> session.execute(("CREATE MATERIALIZED VIEW t_by_v AS SELECT * FROM t
> WHERE v IS NOT NULL "
> "AND id IS NOT NULL PRIMARY KEY (v, id)"))
>
> logger.debug("wait for view to build")
> self._wait_for_view("ks", "t_by_v")
>
> logger.debug("wait that all batchlogs are replayed")
> > self._replay_batchlogs()
> materialized_views_test.py:350:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = 0x7fcb232b5760>
> def _replay_batchlogs(self):
> for node in self.cluster.nodelist():
> if node.is_running():
> logger.debug("Replaying batchlog on node
> {}".format(node.name))
> node.nodetool("replaybatchlog")
> # CASSANDRA-13069 - Ensure replayed mutations are removed
> from the batchlog
> node_session = self.patient_exclusive_cql_connection(node)
> result = list(node_session.execute("SELECT count(*) FROM
> system.batches;"))
> > assert result[0].count == 0
> E assert 160 == 0
> E+ where 160 = Row(count=160).count
> materialized_views_test.py:171: AssertionError{quote}
--
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-15845) MV schema version update race
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15845:
Fix Version/s: (was: 4.0-beta)
4.x
> MV schema version update race
> -
>
> Key: CASSANDRA-15845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15845
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views, Test/dtest
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/155/testReport/dtest-novnode.materialized_views_test/TestMaterializedViews/test_populate_mv_after_insert_wide_rows_2/]
> {quote}Error Message
> assert 160 == 0 + where 160 = Row(count=160).count
> Stacktrace
> self = 0x7fcb232b5760>
> def test_populate_mv_after_insert_wide_rows(self):
> """Test that a view is OK when created with existing data with wide
> rows"""
> session = self.prepare(consistency_level=ConsistencyLevel.QUORUM)
>
> session.execute("CREATE TABLE t (id int, v int, PRIMARY KEY (id, v))")
>
> for i in range(5):
> for j in range(1):
> session.execute("INSERT INTO t (id, v) VALUES ({},
> {})".format(i, j))
>
> session.execute(("CREATE MATERIALIZED VIEW t_by_v AS SELECT * FROM t
> WHERE v IS NOT NULL "
> "AND id IS NOT NULL PRIMARY KEY (v, id)"))
>
> logger.debug("wait for view to build")
> self._wait_for_view("ks", "t_by_v")
>
> logger.debug("wait that all batchlogs are replayed")
> > self._replay_batchlogs()
> materialized_views_test.py:350:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = 0x7fcb232b5760>
> def _replay_batchlogs(self):
> for node in self.cluster.nodelist():
> if node.is_running():
> logger.debug("Replaying batchlog on node
> {}".format(node.name))
> node.nodetool("replaybatchlog")
> # CASSANDRA-13069 - Ensure replayed mutations are removed
> from the batchlog
> node_session = self.patient_exclusive_cql_connection(node)
> result = list(node_session.execute("SELECT count(*) FROM
> system.batches;"))
> > assert result[0].count == 0
> E assert 160 == 0
> E+ where 160 = Row(count=160).count
> materialized_views_test.py:171: AssertionError{quote}
--
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-14612) Please add OWASP Dependency Check to the build (pom.xml)
[
https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125760#comment-17125760
]
Michael Semb Wever commented on CASSANDRA-14612:
+1 to starting with…
- adding into build.xml the ant {{dependency-check}},
- call it from the {{cassandra-artifacts.sh}}
[script|https://github.com/apache/cassandra-builds/blob/master/build-scripts/cassandra-artifacts.sh,
alongside the call to eclipse-warnings,
Then we can deal with checking past releases later on, as currently there's no
such post-release checks (AFAIK).
> Please add OWASP Dependency Check to the build (pom.xml)
>
>
> Key: CASSANDRA-14612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14612
> Project: Cassandra
> Issue Type: New Feature
> Components: Build
> Environment: All development, build, test, environments.
>Reporter: Albert Baker
>Priority: Normal
> Labels: build, easyfix, security
> Fix For: 3.11.x, 4.x
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an
> outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to
> perform a lookup for each dependant .jar to list any/all known
> vulnerabilities for each jar. This step is needed because a manual MITRE CVE
> lookup/check on the main component does not include checking for
> vulnerabilities in components or in dependant libraries.
> OWASP Dependency check :
> https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most
> Java build/make types (ant, maven, ivy, gradle).
> Also, add the appropriate command to the nightly build to generate a report
> of all known vulnerabilities in any/all third party libraries/dependencies
> that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false
> clean aggregate
> Generating this report nightly/weekly will help inform the project's
> development team if any dependant libraries have a reported known
> vulnerailities. Project teams that keep up with removing vulnerabilities on a
> weekly basis will help protect businesses that rely on these open source
> componets.
--
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-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15855: Bug Category: Parent values: Correctness(12982)Level 1 values: Transient Incorrect Response(12987) Complexity: Normal Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- 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-15822) DOC - Improve C* configuration docs
[ https://issues.apache.org/jira/browse/CASSANDRA-15822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125765#comment-17125765 ] Michael Semb Wever commented on CASSANDRA-15822: CD'd to https://cassandra.staged.apache.org > DOC - Improve C* configuration docs > --- > > Key: CASSANDRA-15822 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15822 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 4.0-alpha5 > > > Two sections, Getting started > Configuring and Configuration, could use > improvement. > Adding information about some of the other config files besides > cassandra.yaml is one key goal. > > At the risk of contaminating one ticket with another project, I started > creating a separate glossary file, so that key terms in configuration can be > linked to a glossary that describes terms. -- 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-13606) Improve handling of 2i initialization failures
[
https://issues.apache.org/jira/browse/CASSANDRA-13606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125857#comment-17125857
]
ZhaoYang commented on CASSANDRA-13606:
--
bq. I'm not sure about what making the index not available for writes should
mean...
Not sure why index needs to skip writes when its build failed...if no index
uses `LoadType read/no_op`, having `writableIndex` is giving extra overhead..
Perhaps we should unify both {{`queryableIndex`}} and {{`writableIndex`}} into
{{`indexStatus`}}, aka. "Map".
> Improve handling of 2i initialization failures
> --
>
> Key: CASSANDRA-13606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13606
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Sergio Bossa
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-alpha5
>
> Time Spent: 8h 40m
> Remaining Estimate: 0h
>
> CASSANDRA-10130 fixes the 2i build management, but initialization failures
> are still not properly handled, most notably because:
> * Initialization failures make the index non-queryable, but it can still be
> written to.
> * Initialization failures can be recovered via full rebuilds.
> Both points above are probably suboptimal because the initialization logic
> could be more complex than just an index build, hence it shouldn't be made
> recoverable via a simple rebuild, and could cause the index to be fully
> unavailable not just for reads, but for writes as well.
> So, we should better handle initialization failures by:
> * Allowing the index implementation to specify if unavailable for reads,
> writes, or both.
> * Providing a proper method to recover, distinct from index rebuilds.
--
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-14612) Please add OWASP Dependency Check to the build (pom.xml)
[ https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125807#comment-17125807 ] Stefan Miklosovic commented on CASSANDRA-14612: --- I have implemented required ant tasks and download of all bits here (1), it downloads whole thing when not present and it scans build/dist/libs instead of "libs" as the word on the street is that libs dir will be nuked from git ... however, when scanning build/dist/libs instead of libs, there seems to be more false positives and some affected jars are not part of Cassandra distribution as some libs are just part of e.g. ant build itself. It would be indeed nice to see this in action, especially in times when [~mck] is working on better pipeline in terms of package building etc ... (1) [https://github.com/smiklosovic/cassandra/tree/CASSANDRA-14612] > Please add OWASP Dependency Check to the build (pom.xml) > > > Key: CASSANDRA-14612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14612 > Project: Cassandra > Issue Type: New Feature > Components: Build > Environment: All development, build, test, environments. >Reporter: Albert Baker >Priority: Normal > Labels: build, easyfix, security > Fix For: 3.11.x, 4.x > > Original Estimate: 1h > Remaining Estimate: 1h > > Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an > outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to > perform a lookup for each dependant .jar to list any/all known > vulnerabilities for each jar. This step is needed because a manual MITRE CVE > lookup/check on the main component does not include checking for > vulnerabilities in components or in dependant libraries. > OWASP Dependency check : > https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most > Java build/make types (ant, maven, ivy, gradle). > Also, add the appropriate command to the nightly build to generate a report > of all known vulnerabilities in any/all third party libraries/dependencies > that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false > clean aggregate > Generating this report nightly/weekly will help inform the project's > development team if any dependant libraries have a reported known > vulnerailities. Project teams that keep up with removing vulnerabilities on a > weekly basis will help protect businesses that rely on these open source > componets. -- 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-15841) Fix flaky junit.framework.TestSuite.org.apache.cassandra.io.sstable.CQLSSTableWriterTest-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-15841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15841: --- Reviewers: Benjamin Lerer > Fix flaky > junit.framework.TestSuite.org.apache.cassandra.io.sstable.CQLSSTableWriterTest-cdc > > > Key: CASSANDRA-15841 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15841 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Failing for the past [29 > buils|https://ci-cassandra.apache.org/job/Cassandra-trunk/154/testReport/junit.framework/TestSuite/org_apache_cassandra_io_sstable_CQLSSTableWriterTest_cdc/] > java.lang.NullPointerException > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC$CDCSizeTracker.shutdown(CommitLogSegmentManagerCDC.java:312) > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:89) > at > org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:413) > at > org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:467) > at > org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:785) > at > org.apache.cassandra.io.sstable.CQLSSTableWriterTest.setup(CQLSSTableWriterTest.java:62) -- 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-15848) Fully purged static row causes NPE in repaired data tracking
[ https://issues.apache.org/jira/browse/CASSANDRA-15848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125672#comment-17125672 ] Marcus Eriksson edited comment on CASSANDRA-15848 at 6/4/20, 8:17 AM: -- +1 was (Author: krummas): +1 if tests look good > Fully purged static row causes NPE in repaired data tracking > > > Key: CASSANDRA-15848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15848 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-alpha > > > During repaired data tracking, if the result of applying the purge function > to a static row is null, an exception is thrown from RepairedDataInfo. This > will cause a read exception from the replica and could lead to unavailable > results if hit on multiple replicas. A workaround is to disable repaired data > tracking. -- 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-15853) @since missing/wrong for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33
[ https://issues.apache.org/jira/browse/CASSANDRA-15853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-15853: - Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear Impact(13164) Complexity: Low Hanging Fruit Discovered By: Unit Test Reviewers: Eduard Tudenhoefner Severity: Low Status: Open (was: Triage Needed) > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 > - > > Key: CASSANDRA-15853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15853 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Normal > > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 -- 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-15835) Upgrade-dtests on trunk not working in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-15835:
-
Status: Ready to Commit (was: Review In Progress)
+1'd on the linked PRs
> Upgrade-dtests on trunk not working in CircleCI
> ---
>
> Key: CASSANDRA-15835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15835
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> ~3600 Upgrade-dtests are failing in CircleCI for trunk due to the missing
> {{JAVA8_HOME}} environment variable.
> Patching the Docker image is rather simple by creating a new image:
> {code}
> FROM nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200406
> ENV JAVA8_HOME=/usr/lib/jvm/java-8-openjdk-amd64
> {code}
> Pushed the above to Docker hub as
> [snazy/cassandra-testing-ubuntu1910-java11-w-dependencies:202005261540|https://hub.docker.com/layers/snazy/cassandra-testing-ubuntu1910-java11-w-dependencies/202005261540/images/sha256-ac8a713be58694f095c491921e006c2d1a7823a3c23299e477198e2c93a6bbd7?context=explore]
> The size of the whole Docker image is a little concerning though (1.85G
> compressed), but that's out of the scope of this ticket.
> I'll prepare a patch soon-ish.
--
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-15851) Add bytebuddy support for in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-15851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15851: Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > Add bytebuddy support for in-jvm dtests > --- > > Key: CASSANDRA-15851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15851 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > Old python dtests support byteman, but that is quite horrible to work with, > [bytebuddy|https://bytebuddy.net/#/] is much better, so we should add support > for that in the in-jvm dtests. -- 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-15842) Fix flaky org.apache.cassandra.schema.SchemaTest.testTransKsMigration-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-15842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15842: --- Reviewers: Benjamin Lerer > Fix flaky org.apache.cassandra.schema.SchemaTest.testTransKsMigration-cdc > - > > Key: CASSANDRA-15842 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15842 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Failing for the past [28 > builds|https://ci-cassandra.apache.org/job/Cassandra-trunk/153/testReport/org.apache.cassandra.schema/SchemaTest/testTransKsMigration_cdc/] > java.lang.NullPointerException > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC$CDCSizeTracker.shutdown(CommitLogSegmentManagerCDC.java:312) > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:89) > at > org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:413) > at > org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:467) > at > org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:785) > at > org.apache.cassandra.schema.SchemaTest.testTransKsMigration(SchemaTest.java:46) -- 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-15853) @since missing/wrong for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33
Robert Stupp created CASSANDRA-15853: Summary: @since missing/wrong for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 Key: CASSANDRA-15853 URL: https://issues.apache.org/jira/browse/CASSANDRA-15853 Project: Cassandra Issue Type: Bug Components: Test/dtest Reporter: Robert Stupp Assignee: Robert Stupp @since missing/wrong for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch master updated: Fix `@since` for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22 + test_upgrade_to_30
This is an automated email from the ASF dual-hosted git repository.
snazy pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/master by this push:
new ca00939 Fix `@since` for
upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22 +
test_upgrade_to_30
ca00939 is described below
commit ca009392d1697ef5a42e87a62930fe9274a3c2fe
Author: Robert Stupp
AuthorDate: Thu Jun 4 10:21:27 2020 +0200
Fix `@since` for
upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22 +
test_upgrade_to_30
Patch by Robert Stupp; reviewed by Eduard Tudenhöfner for CASSANDRA-15853
---
upgrade_internal_auth_test.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/upgrade_internal_auth_test.py b/upgrade_internal_auth_test.py
index d0425b1..b86c00e 100644
--- a/upgrade_internal_auth_test.py
+++ b/upgrade_internal_auth_test.py
@@ -36,10 +36,11 @@ class TestAuthUpgrade(Tester):
r'Can\'t send migration request: node.*is down',
)
+@since('2.2', max_version='2.2.X')
def test_upgrade_to_22(self):
self.do_upgrade_with_internal_auth("github:apache/cassandra-2.2")
-@since('3.0')
+@since('3.0', max_version='3.0.X')
@pytest.mark.no_offheap_memtables
def test_upgrade_to_30(self):
self.do_upgrade_with_internal_auth("github:apache/cassandra-3.0")
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15853) @since missing/wrong for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33
[ https://issues.apache.org/jira/browse/CASSANDRA-15853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-15853: - Status: Ready to Commit (was: Review In Progress) > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 > - > > Key: CASSANDRA-15853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15853 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Normal > > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 -- 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-15853) @since missing/wrong for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33
[ https://issues.apache.org/jira/browse/CASSANDRA-15853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-15853: - Fix Version/s: 4.0-beta 3.11.7 3.0.21 Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra-dtest/commit/ca009392d1697ef5a42e87a62930fe9274a3c2fe Resolution: Fixed Status: Resolved (was: Ready to Commit) > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 > - > > Key: CASSANDRA-15853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15853 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Normal > Fix For: 3.0.21, 3.11.7, 4.0-beta > > > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch master updated (ca00939 -> d08296b)
This is an automated email from the ASF dual-hosted git repository. snazy pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git. from ca00939 Fix `@since` for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22 + test_upgrade_to_30 new 01753e8 CASSANDRA-15835: use correct Java version for upgrade-tests new 94b1b4b CASSANDRA-15835: re-enable running upgrade-dtests for developer-CI runs against a local C* clone new 6a7f721 CASSANDRA-15835: don't let check_logs_for_errors() fail, if there's no log file new 76e87f9 CASSANDRA-15835: also copy the new ccm node startup-stdout/stderr.log files new d08296b Merge pull request #71 from snazy/15835-fix-upgrade-dtests The 5202 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: conftest.py | 55 +++ upgrade_tests/upgrade_base.py | 38 --- upgrade_tests/upgrade_manifest.py | 8 +++--- 3 files changed, 61 insertions(+), 40 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15835) Upgrade-dtests on trunk not working in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-15835:
-
Since Version: 4.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/d6552ce3a42d3394277e8156959c9409bb302d81
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[d6552ce3a42d3394277e8156959c9409bb302d81|https://github.com/apache/cassandra/commit/d6552ce3a42d3394277e8156959c9409bb302d81]
to [trunk|https://github.com/apache/cassandra/tree/trunk].
Merged PRs:
https://github.com/riptano/ccm/pull/713
https://github.com/riptano/ccm/pull/714
https://github.com/apache/cassandra-dtest/pull/71
https://github.com/apache/cassandra-builds/pull/22
> Upgrade-dtests on trunk not working in CircleCI
> ---
>
> Key: CASSANDRA-15835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15835
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> ~3600 Upgrade-dtests are failing in CircleCI for trunk due to the missing
> {{JAVA8_HOME}} environment variable.
> Patching the Docker image is rather simple by creating a new image:
> {code}
> FROM nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200406
> ENV JAVA8_HOME=/usr/lib/jvm/java-8-openjdk-amd64
> {code}
> Pushed the above to Docker hub as
> [snazy/cassandra-testing-ubuntu1910-java11-w-dependencies:202005261540|https://hub.docker.com/layers/snazy/cassandra-testing-ubuntu1910-java11-w-dependencies/202005261540/images/sha256-ac8a713be58694f095c491921e006c2d1a7823a3c23299e477198e2c93a6bbd7?context=explore]
> The size of the whole Docker image is a little concerning though (1.85G
> compressed), but that's out of the scope of this ticket.
> I'll prepare a patch soon-ish.
--
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-15854) Truncation should fail any ongoing preview repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15854: Bug Category: Parent values: Correctness(12982)Level 1 values: Transient Incorrect Response(12987) Complexity: Low Hanging Fruit Component/s: Consistency/Repair Discovered By: Code Inspection Fix Version/s: 4.0-beta Severity: Low Status: Open (was: Triage Needed) > Truncation should fail any ongoing preview repairs > -- > > Key: CASSANDRA-15854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15854 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > Truncation may race with preview repairs, validating different data on > different nodes, we should abort any ongoing preview repairs if we get a > truncation request -- 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-15854) Truncation should fail any ongoing preview repairs
Marcus Eriksson created CASSANDRA-15854: --- Summary: Truncation should fail any ongoing preview repairs Key: CASSANDRA-15854 URL: https://issues.apache.org/jira/browse/CASSANDRA-15854 Project: Cassandra Issue Type: Bug Reporter: Marcus Eriksson Assignee: Marcus Eriksson Truncation may race with preview repairs, validating different data on different nodes, we should abort any ongoing preview repairs if we get a truncation request -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (442a3aa -> 06ef521)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard 442a3aa generate docs for 1ad5e747
new 06ef521 generate docs for 1ad5e747
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (442a3aa)
\
N -- N -- N refs/heads/asf-staging (06ef521)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
content/doc/3.11.7/objects.inv | Bin 8167 -> 8123 bytes
content/doc/3.11.7/searchindex.js | 2 +-
content/doc/3.11.7/tools/nodetool/bootstrap.html | 5 +-
.../3.11.7/tools/nodetool/enablefullquerylog.html | 7 +-
content/doc/3.11.7/tools/nodetool/getreplicas.html | 261 --
.../doc/3.11.7/tools/nodetool/handoffwindow.html | 251 --
content/doc/3.11.7/tools/nodetool/nodetool.html| 7 +-
content/doc/3.11/objects.inv | Bin 8167 -> 8123 bytes
content/doc/3.11/searchindex.js| 2 +-
content/doc/3.11/tools/nodetool/bootstrap.html | 5 +-
.../3.11/tools/nodetool/enablefullquerylog.html| 7 +-
content/doc/3.11/tools/nodetool/getreplicas.html | 261 --
content/doc/3.11/tools/nodetool/handoffwindow.html | 251 --
content/doc/3.11/tools/nodetool/nodetool.html | 7 +-
.../{index.html => cass_cl_archive_file.html} | 65 +++-
.../4.0-alpha5/configuration/cass_env_sh_file.html | 376 +
.../{index.html => cass_jvm_options_file.html} | 36 +-
.../configuration/cass_logback_xml_file.html | 373
.../cass_rackdc_file.html} | 134
.../{index.html => cass_topo_file.html}| 71 +++-
...sandra_config_file.html => cass_yaml_file.html} | 34 +-
.../configuration/cassandra_config_file.html | 200 +--
content/doc/4.0-alpha5/configuration/index.html| 20 +-
content/doc/4.0-alpha5/development/ci.html | 5 +
.../4.0-alpha5/getting_started/configuring.html| 61 ++--
.../{configuration/index.html => glossary.html}| 116 ---
content/doc/4.0-alpha5/new/auditlogging.html | 22 +-
.../doc/4.0-alpha5/new/transientreplication.html | 4 +-
content/doc/4.0-alpha5/objects.inv | Bin 9472 -> 9641 bytes
content/doc/4.0-alpha5/operating/index.html| 4 +-
content/doc/4.0-alpha5/searchindex.js | 2 +-
.../doc/4.0-alpha5/tools/nodetool/bootstrap.html | 5 +-
.../tools/nodetool/enablefullquerylog.html | 7 +-
.../doc/4.0-alpha5/tools/nodetool/getreplicas.html | 263 --
.../4.0-alpha5/tools/nodetool/handoffwindow.html | 253 --
.../doc/4.0-alpha5/tools/nodetool/nodetool.html| 7 +-
.../{index.html => cass_cl_archive_file.html} | 65 +++-
.../doc/latest/configuration/cass_env_sh_file.html | 376 +
.../{index.html => cass_jvm_options_file.html} | 36 +-
.../configuration/cass_logback_xml_file.html | 373
.../cass_rackdc_file.html} | 134
.../{index.html => cass_topo_file.html}| 71 +++-
...sandra_config_file.html => cass_yaml_file.html} | 34 +-
.../configuration/cassandra_config_file.html | 200 +--
content/doc/latest/configuration/index.html| 20 +-
content/doc/latest/development/ci.html | 5 +
.../doc/latest/getting_started/configuring.html| 61 ++--
.../{configuration/index.html => glossary.html}| 116 ---
content/doc/latest/new/auditlogging.html | 22 +-
content/doc/latest/new/transientreplication.html | 4 +-
content/doc/latest/objects.inv | Bin 9472 -> 9641 bytes
content/doc/latest/operating/index.html| 4 +-
content/doc/latest/searchindex.js | 2 +-
content/doc/latest/tools/nodetool/bootstrap.html | 5 +-
.../latest/tools/nodetool/enablefullquerylog.html | 7 +-
content/doc/latest/tools/nodetool/getreplicas.html | 263 --
.../doc/latest/tools/nodetool/handoffwindow.html | 253 --
[jira] [Created] (CASSANDRA-15851) Add bytebuddy support for in-jvm dtests
Marcus Eriksson created CASSANDRA-15851: --- Summary: Add bytebuddy support for in-jvm dtests Key: CASSANDRA-15851 URL: https://issues.apache.org/jira/browse/CASSANDRA-15851 Project: Cassandra Issue Type: Improvement Components: Test/dtest Reporter: Marcus Eriksson Assignee: Marcus Eriksson Old python dtests support byteman, but that is quite horrible to work with, [bytebuddy|https://bytebuddy.net/#/] is much better, so we should add support for that in the in-jvm dtests. -- 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-15852) Handle errors in StreamSession#prepare
Marcus Eriksson created CASSANDRA-15852:
---
Summary: Handle errors in StreamSession#prepare
Key: CASSANDRA-15852
URL: https://issues.apache.org/jira/browse/CASSANDRA-15852
Project: Cassandra
Issue Type: Bug
Components: Consistency/Streaming
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
Since CASSANDRA-12229 we don't handle errors in {{StreamSession#prepare}} -
this makes a stream initiator hang forever if an error is thrown.
--
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-15848) Fully purged static row causes NPE in repaired data tracking
[ https://issues.apache.org/jira/browse/CASSANDRA-15848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125670#comment-17125670 ] Sam Tunnicliffe commented on CASSANDRA-15848: - Sorry, you're absolutely right, so I've pushed that change. It looks like Circle has stopped even limited access to job info unless authenticated, but I'll update the CI status when the jobs are finished. > Fully purged static row causes NPE in repaired data tracking > > > Key: CASSANDRA-15848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15848 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-alpha > > > During repaired data tracking, if the result of applying the purge function > to a static row is null, an exception is thrown from RepairedDataInfo. This > will cause a read exception from the replica and could lead to unavailable > results if hit on multiple replicas. A workaround is to disable repaired data > tracking. -- 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-15848) Fully purged static row causes NPE in repaired data tracking
[ https://issues.apache.org/jira/browse/CASSANDRA-15848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15848: Status: Ready to Commit (was: Changes Suggested) +1 if tests look good > Fully purged static row causes NPE in repaired data tracking > > > Key: CASSANDRA-15848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15848 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-alpha > > > During repaired data tracking, if the result of applying the purge function > to a static row is null, an exception is thrown from RepairedDataInfo. This > will cause a read exception from the replica and could lead to unavailable > results if hit on multiple replicas. A workaround is to disable repaired data > tracking. -- 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-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125675#comment-17125675
]
Sam Tunnicliffe commented on CASSANDRA-15299:
-
Thanks, but there isn't really. [~omichallat]'s driver work has been really
helpful in validating the approach and the server side changes are getting
pretty close to being ready for review. Hopefully that can get started next
week.
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-alpha
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
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-15853) @since missing/wrong for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33
[ https://issues.apache.org/jira/browse/CASSANDRA-15853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-15853: - Reviewers: Eduard Tudenhoefner, Robert Stupp (was: Eduard Tudenhoefner) Status: Review In Progress (was: Patch Available) +1'd on the PR > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 > - > > Key: CASSANDRA-15853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15853 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Normal > > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 -- 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-15853) @since missing/wrong for upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33
[ https://issues.apache.org/jira/browse/CASSANDRA-15853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-15853: - Test and Documentation Plan: - Status: Patch Available (was: In Progress) PR: https://github.com/apache/cassandra-dtest/pull/73 > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 > - > > Key: CASSANDRA-15853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15853 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Normal > > @since missing/wrong for > upgrade_internal_auth_test.TestAuthUpgrade.test_upgrade_to_22/33 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Use Docker image for dtests in CircleCI w/ JAVA8_HOME environment variable & Allow different pip-source-install repos in requirements.txt
This is an automated email from the ASF dual-hosted git repository. snazy pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new d6552ce Use Docker image for dtests in CircleCI w/ JAVA8_HOME environment variable & Allow different pip-source-install repos in requirements.txt d6552ce is described below commit d6552ce3a42d3394277e8156959c9409bb302d81 Author: Robert Stupp AuthorDate: Tue May 26 15:40:43 2020 +0200 Use Docker image for dtests in CircleCI w/ JAVA8_HOME environment variable & Allow different pip-source-install repos in requirements.txt Related changes in cassandra-dtests + ccm fix more issues w/ upgraded-dtests Patch by Robert Stupp; reviewed by Eduard Tudenhöfner for CASSANDRA-15835 --- .circleci/config-2_1.yml | 6 +-- .circleci/config.yml | 92 ++-- .circleci/config.yml.HIGHRES | 92 ++-- .circleci/config.yml.LOWRES | 92 ++-- 4 files changed, 141 insertions(+), 141 deletions(-) diff --git a/.circleci/config-2_1.yml b/.circleci/config-2_1.yml index d711975..ab62124 100644 --- a/.circleci/config-2_1.yml +++ b/.circleci/config-2_1.yml @@ -277,7 +277,7 @@ executors: type: string default: medium docker: - - image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200406 + - image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200603 resource_class: << parameters.exec_resource_class >> working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -292,7 +292,7 @@ executors: type: string default: medium docker: -- image: nastra/cassandra-testing-ubuntu1910-java11:20200406 +- image: nastra/cassandra-testing-ubuntu1910-java11:20200603 resource_class: << parameters.exec_resource_class >> working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -914,7 +914,7 @@ commands: # rebuild the docker image! (it automatically pulls the latest requirements.txt on build) source ~/env<>/bin/activate export PATH=$JAVA_HOME/bin:$PATH - pip3 install --upgrade -r ~/cassandra-dtest/requirements.txt + pip3 install --exists-action w --upgrade -r ~/cassandra-dtest/requirements.txt pip3 uninstall -y cqlsh pip3 freeze diff --git a/.circleci/config.yml b/.circleci/config.yml index 7f6c93b..ffcb107 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -2,7 +2,7 @@ version: 2 jobs: j8_jvm_upgrade_dtests: docker: -- image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200406 +- image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200603 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -93,7 +93,7 @@ jobs: - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64 j8_cqlsh-dtests-py2-with-vnodes: docker: -- image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200406 +- image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200603 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -114,7 +114,7 @@ jobs: # rebuild the docker image! (it automatically pulls the latest requirements.txt on build) source ~/env3.6/bin/activate export PATH=$JAVA_HOME/bin:$PATH - pip3 install --upgrade -r ~/cassandra-dtest/requirements.txt + pip3 install --exists-action w --upgrade -r ~/cassandra-dtest/requirements.txt pip3 uninstall -y cqlsh pip3 freeze - run: @@ -170,7 +170,7 @@ jobs: - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64 j11_unit_tests: docker: -- image: nastra/cassandra-testing-ubuntu1910-java11:20200406 +- image: nastra/cassandra-testing-ubuntu1910-java11:20200603 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -262,7 +262,7 @@ jobs: - CASSANDRA_USE_JDK11: true j8_cqlsh-dtests-py38-no-vnodes: docker: -- image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200406 +- image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200603 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -283,7 +283,7 @@ jobs: # rebuild the docker image! (it automatically pulls the latest requirements.txt on build) source ~/env3.8/bin/activate export PATH=$JAVA_HOME/bin:$PATH - pip3 install --upgrade -r ~/cassandra-dtest/requirements.txt + pip3 install --exists-action w --upgrade -r ~/cassandra-dtest/requirements.txt pip3 uninstall -y cqlsh pip3 freeze - run: @@ -339,7 +339,7 @@ jobs: - JDK_HOME:
[jira] [Commented] (CASSANDRA-15852) Handle errors in StreamSession#prepare
[
https://issues.apache.org/jira/browse/CASSANDRA-15852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125702#comment-17125702
]
Marcus Eriksson commented on CASSANDRA-15852:
-
need CASSANDRA-15851 to test this
> Handle errors in StreamSession#prepare
> --
>
> Key: CASSANDRA-15852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15852
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> Since CASSANDRA-12229 we don't handle errors in {{StreamSession#prepare}} -
> this makes a stream initiator hang forever if an error is thrown.
--
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-15852) Handle errors in StreamSession#prepare
[
https://issues.apache.org/jira/browse/CASSANDRA-15852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15852:
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Complexity: Normal
Discovered By: Code Inspection
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> Handle errors in StreamSession#prepare
> --
>
> Key: CASSANDRA-15852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15852
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Since CASSANDRA-12229 we don't handle errors in {{StreamSession#prepare}} -
> this makes a stream initiator hang forever if an error is thrown.
--
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-13606) Improve handling of 2i initialization failures
[
https://issues.apache.org/jira/browse/CASSANDRA-13606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125876#comment-17125876
]
Andres de la Peña commented on CASSANDRA-13606:
---
bq. Not sure why index needs to skip writes when its build failed...if no index
uses `LoadType read/no_op`, having `writableIndex` is giving extra overhead..
[~jasonstack] those writes will be replayed during rebuild, so it seems
pointless to process them twice. None current implementation make use of this,
but we might change that in a followup ticket, as an improvement. There's also
the idea of making the entire write fail, but it seems that that would have
more serious implications for availability, especially if the coordinator is
not aware of index availability.
bq. Perhaps we should unify both {{queryableIndex}} and {{writableIndex}} into
{{indexStatus}}, aka. {{Map}}.
Sounds like a good idea.
> Improve handling of 2i initialization failures
> --
>
> Key: CASSANDRA-13606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13606
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Sergio Bossa
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-alpha5
>
> Time Spent: 8h 40m
> Remaining Estimate: 0h
>
> CASSANDRA-10130 fixes the 2i build management, but initialization failures
> are still not properly handled, most notably because:
> * Initialization failures make the index non-queryable, but it can still be
> written to.
> * Initialization failures can be recovered via full rebuilds.
> Both points above are probably suboptimal because the initialization logic
> could be more complex than just an index build, hence it shouldn't be made
> recoverable via a simple rebuild, and could cause the index to be fully
> unavailable not just for reads, but for writes as well.
> So, we should better handle initialization failures by:
> * Allowing the index implementation to specify if unavailable for reads,
> writes, or both.
> * Providing a proper method to recover, distinct from index rebuilds.
--
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-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15855: Test and Documentation Plan: See PR Status: Patch Available (was: In Progress) > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- 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-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125883#comment-17125883 ] Berenguer Blasi commented on CASSANDRA-15855: - [~jasonstack] maybe you want to review/commit this one as you've been involved in it. I did run the dtest locally, is it enough? or is there a way to run dtests against CI without a C* branch commit to trigger them > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- 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-14571) Fix race condition in MV build/propagate when there is existing data in the base table
[
https://issues.apache.org/jira/browse/CASSANDRA-14571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125887#comment-17125887
]
Berenguer Blasi commented on CASSANDRA-14571:
-
Looking at 4.0 test failures this one was failing again. There is still a
window for schema agreement to happen but the view not be available yet in some
nodes. Marking the flaky test in CASSANDRA-15855 and CASSANDRA-15845 to address
that root cause eventually. #justfyi
> Fix race condition in MV build/propagate when there is existing data in the
> base table
> --
>
> Key: CASSANDRA-14571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14571
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.0, 4.0-alpha1
>
>
> CASSANDRA-13426 exposed a race in MV initialisation and building, which now
> breaks, consistently,
> {{materialized_views_test.py::TestMaterializedViews::test_populate_mv_after_insert_wide_rows}}.
> CASSANDRA-14168 is also directly related.
--
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
