[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&focusedCommentId=17124520#comment-17124520
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/3/20, 2:21 AM:
--
Thanks [~mck] and [~snazy], it worked.
pip3 install was provided with --upgrade option in the circleci config file.
Final clean of the code tomorrow morning.
was (Author: e.dimitrova):
Thanks [~mck] and [~snazy], that helped, pip3 install was provided with
--upgrade in the circleci config file.
Almost done, have to clean the code tomorrow morning.
> 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] [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&focusedCommentId=17124520#comment-17124520
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
Thanks [~mck] and [~snazy], that helped, pip3 install was provided with
--upgrade in the circleci config file.
Almost done, have to clean the code tomorrow morning.
> 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-15822) DOC - Improve C* configuration docs
[ https://issues.apache.org/jira/browse/CASSANDRA-15822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15822: --- Test and Documentation Plan: Doc build & review Status: Patch Available (was: Open) > 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 > > 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] [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 ] Jon Haddad updated CASSANDRA-15822: --- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > 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 > > 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-15822) DOC - Improve C* configuration docs
[ https://issues.apache.org/jira/browse/CASSANDRA-15822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124465#comment-17124465 ] Lorina Poland commented on CASSANDRA-15822: --- PR for review: [https://github.com/apache/cassandra/pull/613] > 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 > > 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] [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:
---
Fix Version/s: 3.11.x
> 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: 5h
> 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] [Created] (CASSANDRA-15847) High Local read latency for few tables
Ananda Babu Velupala created CASSANDRA-15847: Summary: High Local read latency for few tables Key: CASSANDRA-15847 URL: https://issues.apache.org/jira/browse/CASSANDRA-15847 Project: Cassandra Issue Type: Improvement Components: Tool/sstable Reporter: Ananda Babu Velupala Hi Team, I am seeing high Local read latency for 3 tables in node(its 5 node cluster) and keyspace has total 16 sstables and hitting 10 sstables for read from that table, can you please suggest any path forward to fix read latency. Appreciate your help.. Thanks Cassandra version : 3.11.3 SSTable Hitratio: == k2view_usp/service_network_element_relation histograms Percentile SSTables Write Latency Read Latency Partition Size Cell Count (micros) (micros) (bytes) 50% 3.00 0.00 219.34 179 10 75% 7.00 0.00 315.85 179 10 95% 10.00 0.00 454.83 179 10 98% 10.00 0.00 545.79 215 10 99% 10.00 0.00 545.79 310 20 Min 0.00 0.00 51.01 43 0 Max 10.00 0.00 545.79 89970660 8409007 TABLE STATS: == Table: service_network_element_relation_mirTable: service_network_element_relation_mir SSTable count: 3 Space used (live): 283698097 Space used (total): 283698097 Space used by snapshots (total): 0 Off heap memory used (total): 5335824 SSTable Compression Ratio: 0.39563345719027554 Number of partitions (estimate): 2194136 Memtable cell count: 0 Memtable data size: 0 Memtable off heap memory used: 0 Memtable switch count: 0 Local read count: 0 Local read latency: NaN ms Local write count: 0 Local write latency: NaN ms Pending flushes: 0 Percent repaired: 100.0 Bloom filter false positives: 0 Bloom filter false ratio: 0.0 Bloom filter space used: 4567016 Bloom filter off heap memory used: 4566992 Index summary off heap memory used: 705208 Compression metadata off heap memory used: 63624 Compacted partition minimum bytes: 104 Compacted partition maximum bytes: 310 Compacted partition mean bytes: 154 Average live cells per slice (last five minutes): NaN Maximum live cells per slice (last five minutes): 0 Average tombstones per slice (last five minutes): NaN Maximum tombstones per slice (last five minutes): 0 Dropped Mutations: 0 Table: service_network_element_relationTable: service_network_element_relation SSTable count: 11 Space used (live): 8067239427 Space used (total): 8067239427 Space used by snapshots (total): 0 Off heap memory used (total): 143032693 SSTable Compression Ratio: 0.21558247949161227 Number of partitions (estimate): 29357598 Memtable cell count: 2714 Memtable data size: 691617 Memtable off heap memory used: 0 Memtable switch count: 9 Local read count: 6369399 Local read latency: 0.311 ms Local write count: 161229 Local write latency: NaN ms Pending flushes: 0 Percent repaired: 99.91 Bloom filter false positives: 1508 Bloom filter false ratio: 0.00012 Bloom filter space used: 113071680 Bloom filter off heap memory used: 113071592 Index summary off heap memory used: 27244541 Compression metadata off heap memory used: 2716560 Compacted partition minimum bytes: 43 Compacted partition maximum bytes: 89970660 Compacted partition mean bytes: 265 Average live cells per slice (last five minutes): 1.1779891304347827 Maximum live cells per slice (last five minutes): 103 Average tombstones per slice (last five minutes): 1.0 Maximum tombstones per slice (last five minutes): 1 Dropped Mutations: 0 Table: service_relationTable: service_relation SSTable count: 7 Space used (live): 281354042 Space used (total): 281354042 Space used by snapshots (total): 35695068 Off heap memory used (total): 6423276 SSTable Compression Ratio: 0.17685515178431085 Number of partitions (estimate): 1719400 Memtable cell count: 1150 Memtable data size: 67482 Memtable off heap memory used: 0 Memtable switch count: 3 Local read count: 5506327 Local read latency: 0.182 ms Local write count: 5237 Local write latency: 0.084 ms Pending flushes: 0 Percent repaired: 55.48 Bloom filter false positives: 17 Bloom filter false ratio: 0.0 Bloom filter space used: 5549664 Bloom filter off heap memory used: 5549608 Index summary off heap memory used: 737348 Compression metadata off heap memory used: 136320 Compacted partition minimum bytes: 87 Compacted partition maximum bytes: 4055269 Compacted partition mean bytes: 351 Average live cells per slice (last five minutes): 1.5556 Maximum live cells per slice (last five minutes): 3 Average tombstones per slice (last five minutes): 1.0 Maximum tombstones per slice (last five minutes): 1 Dropped Mutations: 0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14113) AssertionError while trying to upgrade 2.2.11 -> 3.11.1
[
https://issues.apache.org/jira/browse/CASSANDRA-14113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell reassigned CASSANDRA-14113:
-
Assignee: David Capwell
> AssertionError while trying to upgrade 2.2.11 -> 3.11.1
> ---
>
> Key: CASSANDRA-14113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14113
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
> Environment: Tables have been created in 2.2.11 using thrift and have
> supercolumns
>Reporter: Guillaume Herail
>Assignee: David Capwell
>Priority: Normal
> Labels: supercolumns
> Attachments: data.tar.gz
>
>
> We're trying to upgrade a test cluster from Cassandra 2.2.11 to Cassandra
> 3.11.1. The tables have been created using thrift and have supercolumns. When
> I try to run {{nodetool upgradesstables}} I get the following:
> {noformat}error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:42)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1242)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1185)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:498)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:472)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:306)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:188)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:140)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:122)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.utils.MergeIterator$TrivialOneToOne.computeNext(MergeIterator.java:484)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:499)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:359)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:75)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:26)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:233)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:196)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:428)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:315)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> We also tried to upgrade to 3.0.15 instead and had a different error:
> {noformat}
> ERROR 11:00:40 Exception in thread Thread[Compact
[jira] [Created] (CASSANDRA-15846) BusyPoolException with OperationTimedOutException
Yogesh Bidari created CASSANDRA-15846: - Summary: BusyPoolException with OperationTimedOutException Key: CASSANDRA-15846 URL: https://issues.apache.org/jira/browse/CASSANDRA-15846 Project: Cassandra Issue Type: Bug Reporter: Yogesh Bidari I am facing issue with my cassandra cluster, we are observing connection timeout errors with BusyPoolException. Logs: java.util.concurrent.ExecutionException: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: /x.x.x.x:9042 (com.datastax.driver.core.exceptions.OperationTimedOutException: [/x.x.x.x:9042] Timed out waiting for server response), cassandra/x.x.x.x:9042 (com.datastax.driver.core.exceptions.BusyPoolException: [cassandra/x.x.x.x:9042] Pool is busy (no available connection and the queue has reached its max size 0)))java.util.concurrent.ExecutionException: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: /x.x.x.x:9042 (com.datastax.driver.core.exceptions.OperationTimedOutException: [/x.x.x.x:9042] Timed out waiting for server response), cassandra/x.x.x.x:9042 (com.datastax.driver.core.exceptions.BusyPoolException: [cassandra/x.x.x.x:9042] Pool is busy (no available connection and the queue has reached its max size 0))) at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:552) at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:513) at akka.persistence.cassandra.package$ListenableFutureConverter$$anon$2.$anonfun$run$2(package.scala:50) at scala.util.Try$.apply(Try.scala:213) at akka.persistence.cassandra.package$ListenableFutureConverter$$anon$2.run(package.scala:50) at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:47) at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:47) at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source) at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source) at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: /x.x.x.x:9042 (com.datastax.driver.core.exceptions.OperationTimedOutException: [/x.x.x.x:9042] Timed out waiting for server response), cassandra/x.x.x.x:9042 (com.datastax.driver.core.exceptions.BusyPoolException: [cassandra/x.x.x.x:9042] Pool is busy (no available connection and the queue has reached its max size 0))) at com.datastax.driver.core.RequestHandler.reportNoMoreHosts(RequestHandler.java:283) at com.datastax.driver.core.RequestHandler.access$1200(RequestHandler.java:61) at com.datastax.driver.core.RequestHandler$SpeculativeExecution.findNextHostAndQuery(RequestHandler.java:375) at com.datastax.driver.core.RequestHandler$SpeculativeExecution$1.onFailure(RequestHandler.java:444) at com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1015) at com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30) at com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1137) at com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:707) at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.addListener(AbstractFuture.java:112) at com.google.common.util.concurrent.Futures.addCallback(Futures.java:996) at com.datastax.driver.core.GuavaCompatibility.addCallback(GuavaCompatibility.java:112) at com.datastax.driver.core.GuavaCompatibility.addCallback(GuavaCompatibility.java:100) at com.datastax.driver.core.RequestHandler$SpeculativeExecution.query(RequestHandler.java:400) at com.datastax.driver.core.RequestHandler$SpeculativeExecution.findNextHostAndQuery(RequestHandler.java:359) at com.datastax.driver.core.RequestHandler$SpeculativeExecution.retry(RequestHandler.java:557) at com.datastax.driver.core.RequestHandler$SpeculativeExecution.processRetryDecision(RequestHandler.java:539) at com.datastax.driver.core.RequestHandler$SpeculativeExecution.onTimeout(RequestHandler.java:981) at com.datastax.driver.core.Connection$ResponseHandler$1.run(Connection.java:1605) at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:680) at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:755) at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:483) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Unknown Source) -- This message was sent by Atlassian Jira (v8.3.
[jira] [Updated] (CASSANDRA-14811) RPC_READY flag handled inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-14811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rens Groothuijsen updated CASSANDRA-14811:
--
Impacts: None
Test and Documentation Plan: See PR
Status: Patch Available (was: Open)
> RPC_READY flag handled inconsistently
> -
>
> Key: CASSANDRA-14811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14811
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tibor Repasi
>Assignee: Rens Groothuijsen
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With version 3.0.17 we experience an inconsistent handling of the RPC_READY
> flag. We identified 3 scenarios with an unexpected behaviour.
> # Using {{nodetool disablebinary}} on a node in normal operation
> ** Observed behaviour:
> *** (/) the CQL listener is closed and Netty shut down
> *** (x) gossipinfo still contain the {{RPC_READY}} *true* advertisement.
> ** Expected behaviour: gossip announcement of the {{RPC_READY}} flag should
> switch to *false.* This is what we observe with version 2.2.13
> # Starting up a node with JVM option
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is not started to listen for CQL clients
> *** (/) logging {{cassandra[1765]: INFO 13:58:46 Not starting native
> transport as requested. Use JMX (StorageService->startNativeTransport()) or
> nodetool (enablebinary) to start it}}
> *** (?) the gossipinfo does not contain the {{RPC_READY}} flag at all,
> however, this is also observed on 2.2.13.
> # Issuing {{nodetool enablebinary}} command on a node started with
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is started up and open the CQL port for listening
> *** (x) the {{RPC_READY}} flag is not announced for this node any more,
> causing clients to not consider this node up and not trying to connect.
> ** Expected behaviour: gossip flag {{RPC_READY}} should be added to announce
> *true*, as observed with version 2.2.13.
>
--
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-14811) RPC_READY flag handled inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-14811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rens Groothuijsen reassigned CASSANDRA-14811:
-
Assignee: Rens Groothuijsen
> RPC_READY flag handled inconsistently
> -
>
> Key: CASSANDRA-14811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14811
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tibor Repasi
>Assignee: Rens Groothuijsen
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With version 3.0.17 we experience an inconsistent handling of the RPC_READY
> flag. We identified 3 scenarios with an unexpected behaviour.
> # Using {{nodetool disablebinary}} on a node in normal operation
> ** Observed behaviour:
> *** (/) the CQL listener is closed and Netty shut down
> *** (x) gossipinfo still contain the {{RPC_READY}} *true* advertisement.
> ** Expected behaviour: gossip announcement of the {{RPC_READY}} flag should
> switch to *false.* This is what we observe with version 2.2.13
> # Starting up a node with JVM option
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is not started to listen for CQL clients
> *** (/) logging {{cassandra[1765]: INFO 13:58:46 Not starting native
> transport as requested. Use JMX (StorageService->startNativeTransport()) or
> nodetool (enablebinary) to start it}}
> *** (?) the gossipinfo does not contain the {{RPC_READY}} flag at all,
> however, this is also observed on 2.2.13.
> # Issuing {{nodetool enablebinary}} command on a node started with
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is started up and open the CQL port for listening
> *** (x) the {{RPC_READY}} flag is not announced for this node any more,
> causing clients to not consider this node up and not trying to connect.
> ** Expected behaviour: gossip flag {{RPC_READY}} should be added to announce
> *true*, as observed with version 2.2.13.
>
--
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-15843) Include DROPPED_COLUMNS in schema digest computation.
[ https://issues.apache.org/jira/browse/CASSANDRA-15843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-15843: -- Fix Version/s: (was: 4.0-alpha) 4.0-alpha5 Source Control Link: [c230ec9ed07b9077ce8422bce8db4e94d5b644cb|https://github.com/apache/cassandra/commit/c230ec9ed07b9077ce8422bce8db4e94d5b644cb] Resolution: Fixed Status: Resolved (was: Ready to Commit) Cheers, committed as [c230ec9ed07b9077ce8422bce8db4e94d5b644cb|https://github.com/apache/cassandra/commit/c230ec9ed07b9077ce8422bce8db4e94d5b644cb] to trunk. > Include DROPPED_COLUMNS in schema digest computation. > - > > Key: CASSANDRA-15843 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15843 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.0-alpha5 > > > CASSANDRA-11050 introduced dropped columns but excluded it from schema digest > computations, with a comment to include the table in the next major release - > 4.0. > Change SchemaKeyspace to include DROPPED_COLUMNS in the schema digest > computation. -- 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: Include DROPPED_COLUMNS in schema digest computation.
This is an automated email from the ASF dual-hosted git repository.
aleksey 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 c230ec9 Include DROPPED_COLUMNS in schema digest computation.
c230ec9 is described below
commit c230ec9ed07b9077ce8422bce8db4e94d5b644cb
Author: Jon Meredith
AuthorDate: Mon Jun 1 11:52:50 2020 -0600
Include DROPPED_COLUMNS in schema digest computation.
CASSANDRA-11050 introduced dropped columns but excluded it from schema
digest computations, with
a comment to include the table in the next major release - 4.0.
The patch now includes DROPPED_COLUMNS in the schema digest computation.
Patch by Jon Meredith; reviewed by Aleksey Yeschenko for CASSANDRA-15843
---
CHANGES.txt | 1 +
src/java/org/apache/cassandra/schema/SchemaKeyspace.java | 5 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 3a58b05..09635e8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-alpha5
+ * Include DROPPED_COLUMNS in schema digest computation (CASSANDRA-15843)
* Fix Cassandra restart from rpm install (CASSANDRA-15830)
* Improve handling of 2i initialization failures (CASSANDRA-13606)
* Add completion_ratio column to sstable_tasks virtual table (CASANDRA-15759)
diff --git a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
index 76bda0f..a10156c 100644
--- a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
+++ b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
@@ -355,11 +355,6 @@ public final class SchemaKeyspace
Digest digest = Digest.forSchema();
for (String table : ALL)
{
-// Due to CASSANDRA-11050 we want to exclude DROPPED_COLUMNS for
schema digest computation. We can and
-// should remove that in the next major release (so C* 4.0).
-if (table.equals(DROPPED_COLUMNS))
-continue;
-
ReadCommand cmd = getReadCommandForTableSchema(table);
try (ReadExecutionController executionController =
cmd.executionController();
PartitionIterator schema =
cmd.executeInternal(executionController))
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124057#comment-17124057
]
Adam Holmberg commented on CASSANDRA-15663:
---
Sounds good. The next driver is only a couple weeks out. We'll ping here when
it lands. (/cc [~aboudreault]).
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x, 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-15663:
--
Fix Version/s: (was: 4.0-alpha)
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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) dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124027#comment-17124027
]
ZhaoYang commented on CASSANDRA-15845:
--
> sending MV mutations on MV creation before schema agreement and before MV
> build task:
kind of a known issue. When a node receives schema propagation, it starts view
building asynchronously, where other nodes may not receive schema propagation
yet.
> dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
> ---
>
> 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
>
>
> 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-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
]
ZhaoYang updated CASSANDRA-15752:
-
Source Control Link: trunk:
https://github.com/apache/cassandra/pull/606
Test and Documentation Plan:
Added unit tests.
Circle Ci:
https://app.circleci.com/pipelines/github/jasonstack/cassandra/153/workflows/39d0da06-96dc-4795-aa39-e4f428ba8ea7
[Trunk Patch|https://github.com/apache/cassandra/pull/606] /
[CI|https://app.circleci.com/pipelines/github/jasonstack/cassandra/153/workflows/39d0da06-96dc-4795-aa39-e4f428ba8ea7]:
* count vnode ranges instead of merged ranges against concurrency factor during
range read
* cap max concurrency factor as ten times the number of cores to avoid large
number of concurrent remote ranges in large vnode cluster.
> 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.x
>
>
> 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-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
]
ZhaoYang updated CASSANDRA-15752:
-
Status: Patch Available (was: In Progress)
> 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-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
]
ZhaoYang updated CASSANDRA-15752:
-
Bug Category: Parent values: Degradation(12984)Level 1 values: Performance
Bug/Regression(12997)
Complexity: Normal
Discovered By: Code Inspection
Fix Version/s: (was: 4.x)
4.0-rc
Severity: Normal
Status: Open (was: Triage Needed)
> 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] [Commented] (CASSANDRA-15845) dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123946#comment-17123946
]
Berenguer Blasi commented on CASSANDRA-15845:
-
Hard to repro but seems sometimes we are sending MV mutations on MV creation
before schema agreement and before MV build task:
{noformat}
DEBUG [OptionalTasks:1] 2020-06-02 17:31:36,119 CassandraDaemon.java:389 -
Completed submission of build tasks for any materialized views defined at
startup
INFO [MigrationStage:1] 2020-06-02 17:31:46,145 ColumnFamilyStore.java:849 -
Enqueuing flush of columns: 1.488KiB (0%) on-heap, 0.000KiB (0%) off-heap
INFO [Messaging-EventLoop-3-9] 2020-06-02 17:31:46,159 NoSpamLogger.java:91 -
127.0.0.1:7000->127.0.0.2:7000-SMALL_MESSAGES-3d6869c3 incompatible schema
encountered while deserializing a message
org.apache.cassandra.exceptions.UnknownTableException: Couldn't find table with
id 2afc69c0-a4e6-11ea-a44e-7941109e8480. If a table was just created, this is
likely due to the schemanot being fully propagated. Please wait for schema
agreement on table creation.
at
org.apache.cassandra.schema.Schema.getExistingTableMetadata(Schema.java:456)
at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize(PartitionUpdate.java:638)
at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:380)
at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:398)
at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:362)
at
org.apache.cassandra.net.Message$Serializer.deserializePost40(Message.java:770)
at
org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:630)
at
org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
at
org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
at
org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
at
org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
at
org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
at org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
at
org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
at
org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1408)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930)
at
io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792)
at
io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:424)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:326)
at
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
.
.
.
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)
ERROR [MutationStage-1] 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)
ERROR [MutationStage-2] 2020-06-02 17:31:46,415 Keyspace.java:621 - Attempting
to mutate non-existant table 2afc69c0-a4e6-11ea-a44e-7941109e8480 (ks.t_by_v)
ERROR [MutationStage-4] 2020-06-02 17:31:46,415 Keyspace.java:621 - Attempting
to mutate non-existant table 2afc69c0-a4e6-11ea-a44e-7941109e8480 (ks.t_by_v)
ERROR [MutationStage-1] 2020-06-02 17:31:46,415 Keyspace.java:621 - Attempting
to mutate non-existant table 2afc69c0-a4e6-11ea-a44e-7941109e8480 (ks.t_by_v)
.
.
.
INFO [MigrationStage:1] 2020-06-02 17:31:46,417 ColumnFamilyStore.java:398 -
Initiali
[jira] [Comment Edited] (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&focusedCommentId=17123524#comment-17123524
]
Michael Semb Wever edited comment on CASSANDRA-15838 at 6/2/20, 3:11 PM:
-
Things to keep in mind when testing
- compatibility with branches: cassandra-2.2, cassandra-3.0, cassandra-3.11,
trunk, and patches on any of these,
- testing failures work (eg patches in `debian/patches/` that don't apply)
- concurrent builds (eg with docker tags and labels)
- jdk8 and jdk11 (jdk11 on redhat isn't yet complete)
- the release process (ie release_prepare.sh)
- deb/rpm packages from tags versus branches and SHAs (these are handled
differently in the {{build-*s.sh}} scripts)
was (Author: michaelsembwever):
Things to keep in mind when testing
- compatibility with branches: cassandra-2.2, cassandra-3.0, cassandra-3.11,
trunk, and patches on any of these,
- testing failures work (eg patches in `debian/patches/` that don't apply)
- concurrent builds (eg with docker tags and labels)
- jdk8 and jdk11 (jdk11 on redhat isn't yet complete)
- the release process (ie release_prepare.sh)
> 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-14712) Add fqltool and auditlogviewer to rpm and deb packages
[ https://issues.apache.org/jira/browse/CASSANDRA-14712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123853#comment-17123853 ] Stefan Podkowinski commented on CASSANDRA-14712: The ticket was created quite a while ago, thanks for confirming that most of the described issues have been solved by now! > Add fqltool and auditlogviewer to rpm and deb packages > -- > > Key: CASSANDRA-14712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14712 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Stefan Podkowinski >Assignee: Stefan Miklosovic >Priority: Normal > Labels: Java11, pull-request-available > Fix For: 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently it's not possible to build any native packages (.deb/.rpm) for > trunk. > cassandra-builds - docker/*-image.docker > * Add Java11 to debian+centos build image > * (packaged ant scripts won't work with Java 11 on centos, so we may have to > install ant from tarballs) > cassandra-builds - docker/build-*.sh > * set JAVA8_HOME to Java8 > * set JAVA_HOME to Java11 (4.0) or Java8 (<4.0) > cassandra - redhat/cassandra.spec > * Check if patches still apply after CASSANDRA-14707 > * Add fqltool as %files > We may also have to change the version handling in build.xml or build-*.sh, > depending how we plan to release packages during beta, or if we plan to do so > at all before GA. -- 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-14712) Add fqltool and auditlogviewer to rpm and deb packages
[ https://issues.apache.org/jira/browse/CASSANDRA-14712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-14712: --- Summary: Add fqltool and auditlogviewer to rpm and deb packages (was: Cassandra 4.0 packaging support) > Add fqltool and auditlogviewer to rpm and deb packages > -- > > Key: CASSANDRA-14712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14712 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Stefan Podkowinski >Assignee: Stefan Miklosovic >Priority: Normal > Labels: Java11, pull-request-available > Fix For: 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently it's not possible to build any native packages (.deb/.rpm) for > trunk. > cassandra-builds - docker/*-image.docker > * Add Java11 to debian+centos build image > * (packaged ant scripts won't work with Java 11 on centos, so we may have to > install ant from tarballs) > cassandra-builds - docker/build-*.sh > * set JAVA8_HOME to Java8 > * set JAVA_HOME to Java11 (4.0) or Java8 (<4.0) > cassandra - redhat/cassandra.spec > * Check if patches still apply after CASSANDRA-14707 > * Add fqltool as %files > We may also have to change the version handling in build.xml or build-*.sh, > depending how we plan to release packages during beta, or if we plan to do so > at all before GA. -- 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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123794#comment-17123794
]
Michael Semb Wever commented on CASSANDRA-15234:
[~e.dimitrova], looks like you'll need the fix [~snazy] added
[here|https://github.com/apache/cassandra-builds/commit/bf6bc98085330172f323c27b21810ac0eb0cc732].
> 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
[cassandra-builds] branch master updated: Allow different pip-source-install repos in requirements.txt (#23)
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-builds.git The following commit(s) were added to refs/heads/master by this push: new bf6bc98 Allow different pip-source-install repos in requirements.txt (#23) bf6bc98 is described below commit bf6bc98085330172f323c27b21810ac0eb0cc732 Author: Robert Stupp AuthorDate: Tue Jun 2 15:28:08 2020 +0200 Allow different pip-source-install repos in requirements.txt (#23) --- .gitignore | 2 ++ build-scripts/cassandra-dtest-pytest.sh | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 5b88705..1348a5d 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,4 @@ dist/cassandra* .idea +*.iml + diff --git a/build-scripts/cassandra-dtest-pytest.sh b/build-scripts/cassandra-dtest-pytest.sh index c70ed5a..ef89780 100755 --- a/build-scripts/cassandra-dtest-pytest.sh +++ b/build-scripts/cassandra-dtest-pytest.sh @@ -52,7 +52,7 @@ fi set -e # enable immediate exit if venv setup fails virtualenv --python=python3 venv source venv/bin/activate -pip3 install -r cassandra-dtest/requirements.txt +pip3 install --exists-action w -r cassandra-dtest/requirements.txt pip3 freeze - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=17123593#comment-17123593
]
Robert Stupp edited comment on CASSANDRA-15835 at 6/2/20, 1:27 PM:
---
PRs:
* ccm/cassandra-test: https://github.com/riptano/ccm/pull/713
* ccm/master: https://github.com/riptano/ccm/pull/714
* dtest/master: https://github.com/apache/cassandra-dtest/pull/71
* cassandra/trunk: https://github.com/apache/cassandra/pull/611
* cassandra-builds/master: https://github.com/apache/cassandra-builds/pull/22
The above PRs fix a couple of issues w/ dtests:
* Fix/re-enable upgrade-dtests broken by CASSANDRA-14420 + CASSANDRA-14421
* Fix building C* using Java 11 during upgrade-dtests
* Use the correct Java version when starting C* and related processes
* Don't let check_logs_for_errors() fail, if there's no log file
* Always create a node*-startup-stdout/stderr.log (which helps a lot to
investigate why nodes don't start)
* Add `--exists-option w` for dtests requiements.txt installation
[~eduard.tudenhoefner] can you review?
was (Author: snazy):
PRs:
* ccm/cassandra-test: https://github.com/riptano/ccm/pull/713
* ccm/master: https://github.com/riptano/ccm/pull/714
* dtest/master: https://github.com/apache/cassandra-dtest/pull/71
* cassandra/trunk: https://github.com/apache/cassandra/pull/611
* cassandra-builds/master: https://github.com/apache/cassandra-builds/pull/22
The above PRs fix a couple of issues w/ dtests:
* Fix/re-enable upgrade-dtests broken by CASSANDRA-14420 + CASSANDRA-14421
* Fix building C* using Java 11 during upgrade-dtests
* Use the correct Java version when starting C* and related processes
* Don't let check_logs_for_errors() fail, if there's no log file
* Always create a node*-startup-stdout/stderr.log (which helps a lot to
investigate why nodes don't start)
[~eduard.tudenhoefner] can you review?
> 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: 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] [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&focusedCommentId=17123750#comment-17123750
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
Thanks [~mck], I will do the testing locally then and attach the logs here.
> 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-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
]
Michael Semb Wever updated CASSANDRA-15835:
---
Component/s: CI
> 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: 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-14712) Cassandra 4.0 packaging support
[ https://issues.apache.org/jira/browse/CASSANDRA-14712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14712: --- Reviewers: Michael Semb Wever > Cassandra 4.0 packaging support > --- > > Key: CASSANDRA-14712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14712 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Stefan Podkowinski >Assignee: Stefan Miklosovic >Priority: Normal > Labels: Java11, pull-request-available > Fix For: 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently it's not possible to build any native packages (.deb/.rpm) for > trunk. > cassandra-builds - docker/*-image.docker > * Add Java11 to debian+centos build image > * (packaged ant scripts won't work with Java 11 on centos, so we may have to > install ant from tarballs) > cassandra-builds - docker/build-*.sh > * set JAVA8_HOME to Java8 > * set JAVA_HOME to Java11 (4.0) or Java8 (<4.0) > cassandra - redhat/cassandra.spec > * Check if patches still apply after CASSANDRA-14707 > * Add fqltool as %files > We may also have to change the version handling in build.xml or build-*.sh, > depending how we plan to release packages during beta, or if we plan to do so > at all before GA. -- 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:
-
Reviewers: Eduard Tudenhoefner
> 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: Test/dtest
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 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-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:
-
Test and Documentation Plan: Internal Circle-CI runs
Status: Patch Available (was: In Progress)
> 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: Test/dtest
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 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] [Comment Edited] (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:comment-tabpanel&focusedCommentId=17123593#comment-17123593
]
Robert Stupp edited comment on CASSANDRA-15835 at 6/2/20, 10:44 AM:
PRs:
* ccm/cassandra-test: https://github.com/riptano/ccm/pull/713
* ccm/master: https://github.com/riptano/ccm/pull/714
* dtest/master: https://github.com/apache/cassandra-dtest/pull/71
* cassandra/trunk: https://github.com/apache/cassandra/pull/611
* cassandra-builds/master: https://github.com/apache/cassandra-builds/pull/22
The above PRs fix a couple of issues w/ dtests:
* Fix/re-enable upgrade-dtests broken by CASSANDRA-14420 + CASSANDRA-14421
* Fix building C* using Java 11 during upgrade-dtests
* Use the correct Java version when starting C* and related processes
* Don't let check_logs_for_errors() fail, if there's no log file
* Always create a node*-startup-stdout/stderr.log (which helps a lot to
investigate why nodes don't start)
[~eduard.tudenhoefner] can you review?
was (Author: snazy):
PRs:
* ccm/cassandra-test: https://github.com/riptano/ccm/pull/713
* ccm/master: https://github.com/riptano/ccm/pull/714
* dtest/master: https://github.com/apache/cassandra-dtest/pull/71
* cassandra/trunk: https://github.com/apache/cassandra/pull/611
The above PRs fix a couple of issues w/ dtests:
* Fix/re-enable upgrade-dtests broken by CASSANDRA-14420 + CASSANDRA-14421
* Fix building C* using Java 11 during upgrade-dtests
* Use the correct Java version when starting C* and related processes
* Don't let check_logs_for_errors() fail, if there's no log file
* Always create a node*-startup-stdout/stderr.log (which helps a lot to
investigate why nodes don't start)
[~eduard.tudenhoefner] can you review?
> 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: Test/dtest
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 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] [Commented] (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:comment-tabpanel&focusedCommentId=17123612#comment-17123612
]
Robert Stupp commented on CASSANDRA-15835:
--
[~jmckenzie] not worth to block any release on this one. The CI runs with the
above changes look almost good.
> 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: Test/dtest
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> 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] [Comment Edited] (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:comment-tabpanel&focusedCommentId=17123593#comment-17123593
]
Robert Stupp edited comment on CASSANDRA-15835 at 6/2/20, 10:33 AM:
PRs:
* ccm/cassandra-test: https://github.com/riptano/ccm/pull/713
* ccm/master: https://github.com/riptano/ccm/pull/714
* dtest/master: https://github.com/apache/cassandra-dtest/pull/71
* cassandra/trunk: https://github.com/apache/cassandra/pull/611
The above PRs fix a couple of issues w/ dtests:
* Fix/re-enable upgrade-dtests broken by CASSANDRA-14420 + CASSANDRA-14421
* Fix building C* using Java 11 during upgrade-dtests
* Use the correct Java version when starting C* and related processes
* Don't let check_logs_for_errors() fail, if there's no log file
* Always create a node*-startup-stdout/stderr.log (which helps a lot to
investigate why nodes don't start)
[~eduard.tudenhoefner] can you review?
was (Author: snazy):
PRs:
* ccm/cassandra-test: https://github.com/riptano/ccm/pull/713
* ccm/master: https://github.com/riptano/ccm/pull/714
* dtest/master: https://github.com/apache/cassandra-dtest/pull/71
The above PRs fix a couple of issues w/ dtests:
* Fix/re-enable upgrade-dtests broken by CASSANDRA-14420 + CASSANDRA-14421
* Fix building C* using Java 11 during upgrade-dtests
* Use the correct Java version when starting C* and related processes
* Don't let check_logs_for_errors() fail, if there's no log file
* Always create a node*-startup-stdout/stderr.log (which helps a lot to
investigate why nodes don't start)
[~eduard.tudenhoefner] can you review?
> 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: Test/dtest
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> 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] [Commented] (CASSANDRA-14712) Cassandra 4.0 packaging support
[
https://issues.apache.org/jira/browse/CASSANDRA-14712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123608#comment-17123608
]
Michael Semb Wever commented on CASSANDRA-14712:
Looping back on this ticket, as I'm working on CASSANDRA-15838.
bq. Currently it's not possible to build any native packages (.deb/.rpm) for
trunk.
Much of the description of this ticket does not appear up to date. deb/rpm
packages can indeed be built off trunk, as both CASSANDRA-15838 and all the
4.0-alpha* releases demonstrate.
bq. I am still not completely sure whats the deal with Java 8 / Java 11 combo…
The need to defined {{JAVA8_HOME}} no longer exists. In CASSANDRA-15838 it
becomes more evident how to build the artefacts with either jdk8 or jdk11. We
want nightlies of both, but releases will remain only jdk8 generated (for now).
While CASSANDRA-15838 will fix deb/rpm jdk11 generation, it will get plugged
into the ASF CI (Jenkins) via CASSANDRA-15809
bq. Debian Jesse was in my case so old…
The `jessie-image.docker` is no longer required. You can see in CASSANDRA-15838
"cassandra-deb-packaging.sh" that it now uses `buster-image.docker`.
h4. Ticket Status?
My understanding is that #9 is no longer required. And that this ticket can
solely cover what is provided in #307, which looks good to me. If this is the
case, could you update the ticket summary accordingly [~stefan.miklosovic]?
while i'll test #307 a bit more and commit if all is well.
> Cassandra 4.0 packaging support
> ---
>
> Key: CASSANDRA-14712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14712
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: Java11, pull-request-available
> Fix For: 4.x
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently it's not possible to build any native packages (.deb/.rpm) for
> trunk.
> cassandra-builds - docker/*-image.docker
> * Add Java11 to debian+centos build image
> * (packaged ant scripts won't work with Java 11 on centos, so we may have to
> install ant from tarballs)
> cassandra-builds - docker/build-*.sh
> * set JAVA8_HOME to Java8
> * set JAVA_HOME to Java11 (4.0) or Java8 (<4.0)
> cassandra - redhat/cassandra.spec
> * Check if patches still apply after CASSANDRA-14707
> * Add fqltool as %files
> We may also have to change the version handling in build.xml or build-*.sh,
> depending how we plan to release packages during beta, or if we plan to do so
> at all before GA.
--
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-15835) Upgrade-dtests on trunk not working in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123593#comment-17123593
]
Robert Stupp commented on CASSANDRA-15835:
--
PRs:
* ccm/cassandra-test: https://github.com/riptano/ccm/pull/713
* ccm/master: https://github.com/riptano/ccm/pull/714
* dtest/master: https://github.com/apache/cassandra-dtest/pull/71
The above PRs fix a couple of issues w/ dtests:
* Fix/re-enable upgrade-dtests broken by CASSANDRA-14420 + CASSANDRA-14421
* Fix building C* using Java 11 during upgrade-dtests
* Use the correct Java version when starting C* and related processes
* Don't let check_logs_for_errors() fail, if there's no log file
* Always create a node*-startup-stdout/stderr.log (which helps a lot to
investigate why nodes don't start)
[~eduard.tudenhoefner] can you review?
> 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: Test/dtest
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> ~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] [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&focusedCommentId=17123580#comment-17123580
]
Michael Semb Wever commented on CASSANDRA-15234:
bq. Michael Semb Wever, is there a way this to be done in Jenkins?
Currently the CCM repository is not a parameter to the Cassandra-devbranch
pipeline.
So I can only recommend the same approach, by updating the repo url in the
cassandra-dtests/requirements.txt and starting the devbranch pipeline off
against your patched dtest repo.
> 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-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&focusedCommentId=17123524#comment-17123524 ] Michael Semb Wever edited comment on CASSANDRA-15838 at 6/2/20, 8:51 AM: - Things to keep in mind when testing - compatibility with branches: cassandra-2.2, cassandra-3.0, cassandra-3.11, trunk, and patches on any of these, - testing failures work (eg patches in `debian/patches/` that don't apply) - concurrent builds (eg with docker tags and labels) - jdk8 and jdk11 (jdk11 on redhat isn't yet complete) - the release process (ie release_prepare.sh) was (Author: michaelsembwever): Things to keep in mind when testing - compatibility with branches: cassandra-2.2, cassandra-3.0, cassandra-3.11, trunk, and patches on any of these, - testing failures work (eg patches in `debian/patches/` that don't apply) - concurrent builds (eg with docker tags and labels) - jdk8 and jdk11 (jdk11 on redhat isn't yet complete) > 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-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&focusedCommentId=17123524#comment-17123524 ] Michael Semb Wever commented on CASSANDRA-15838: Things to keep in mind when testing - compatibility with branches: cassandra-2.2, cassandra-3.0, cassandra-3.11, trunk, and patches on any of these, - testing failures work (eg patches in `debian/patches/` that don't apply) - concurrent builds (eg with docker tags and labels) - jdk8 and jdk11 (jdk11 on redhat isn't yet complete) > 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-15845) dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15845:
Description:
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}
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/]
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
> dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
> ---
>
> Key: CASSANDRA-15845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15845
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Berenguer Blasi
>Priority: Normal
>
> 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 w
[jira] [Assigned] (CASSANDRA-15845) dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-15845:
---
Assignee: Berenguer Blasi
> dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
> ---
>
> 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
>
>
> 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) dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
[
https://issues.apache.org/jira/browse/CASSANDRA-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15845:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
> ---
>
> Key: CASSANDRA-15845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15845
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> 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] [Created] (CASSANDRA-15845) dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
Berenguer Blasi created CASSANDRA-15845:
---
Summary:
dtest-novnode.materialized_views_test.TestMaterializedViews.test_populate_mv_after_insert_wide_rows
Key: CASSANDRA-15845
URL: https://issues.apache.org/jira/browse/CASSANDRA-15845
Project: Cassandra
Issue Type: Bug
Components: Test/dtest
Reporter: Berenguer Blasi
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/]
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
--
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-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123449#comment-17123449
]
Aleksandr Sorokoumov commented on CASSANDRA-15663:
--
[~jmckenzie] CASSANDRA-14825 solves the issue for 4.0. The ticket is still
valid for 3.11. To fix it in 3.11, we need to update python driver to the
latest version that already has
[607ff52|https://github.com/datastax/python-driver/commit/607ff52c7521f179fc944df4dfc9ddb075fbb30d].
A side effect of doing that right now is that the new driver depends on
external library that we'll need to bring as well - {{geomet}}. We discussed
this with [~aboudreault] and he suggested to make dependency on that library
optional in the next release.
I suggest to remove {{fix version 4.0-alpha}} as the issue there will be fixed
without any changes in this ticket. As for 3.11, I'd keep the ticket opened
until the next driver version. WDYT?
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x, 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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
