[jira] [Created] (CASSANDRA-15868) Update Netty version to 4.1.50 because there are security issues in 4.1.37
Stefan Miklosovic created CASSANDRA-15868: - Summary: Update Netty version to 4.1.50 because there are security issues in 4.1.37 Key: CASSANDRA-15868 URL: https://issues.apache.org/jira/browse/CASSANDRA-15868 Project: Cassandra Issue Type: Task Components: Dependencies Reporter: Stefan Miklosovic Attachments: dependency-check-report.html Please see attached HTML report from OWASP dependency check. -- 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-15867) Update Jackson version to 2.9.10.1 because there are security issues in 2.9.5
Stefan Miklosovic created CASSANDRA-15867: - Summary: Update Jackson version to 2.9.10.1 because there are security issues in 2.9.5 Key: CASSANDRA-15867 URL: https://issues.apache.org/jira/browse/CASSANDRA-15867 Project: Cassandra Issue Type: Task Components: Dependencies Reporter: Stefan Miklosovic Attachments: dependency-check-report.html Please see attached HTML report from OWASP dependency check for current 4.0-alpha5 trunk branch. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-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: (was: 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
>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[CompactionExecutor:1,1,main]
>
[jira] [Commented] (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:comment-tabpanel=17130027#comment-17130027
]
David Capwell commented on CASSANDRA-14113:
---
When I comment out the metadata.isCQLTable() check here
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/LegacyLayout.java#L1434,
I am able to read the data.
The issue was that the partition key was written again as a normal column, in
2.1 this was dropped but in 3.0 we only drop if the table is a pure CQL table,
which this table is not.
> 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
>
[jira] [Commented] (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:comment-tabpanel=17130011#comment-17130011
]
David Capwell commented on CASSANDRA-14113:
---
I started looking into this since I hit the same exception but the problem I
hit was that a frozen collection was written in a multi-cell column; will file
a different JIRA for that.
I downloaded the data and replicated the exception
{code}
select * from "TDF_DATA";
{code}
Schema
{code}
CREATE TABLE "WafercloudData"."TDF_DATA" (
key blob,
column1 blob,
column2 blob,
"" map,
value blob,
PRIMARY KEY (key, column1, column2)
) WITH COMPACT STORAGE
{code}
This produced the following in 3.0
{code}
Caused by: java.lang.IllegalStateException: [ColumnDefinition{name=key,
type=org.apache.cassandra.db.marshal.BytesType, kind=PARTITION_KEY,
position=0}, ColumnDefinition{name=, type=org.apache.cassandra.db.ma
rshal.MapType(org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.BytesType),
kind=REGULAR, position=-1}] is not a subset of []
at
org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:545) ~[]
at
org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:477) ~[]
at
org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:188)
~[]
at
org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:118)
~[]
at
org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:106)
~[]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
~[]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
~[]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
~[]
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:325)
~[]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:186)
~[]
{code}
The subset isn't empty but its actually the column with the empty name; the
exception is rejecting the column "key" since it was only expected non rowKey
columns.
Now, this happens after the following steps
1) read the lb using LegacyLayout
2) migrate the data to modern Unfiltered
3) serialize the partition to send over the wire - this is where the exception
is happening.
> 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)
>
[jira] [Commented] (CASSANDRA-14888) Several mbeans are not unregistered when dropping a keyspace and table
[ https://issues.apache.org/jira/browse/CASSANDRA-14888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129976#comment-17129976 ] Alex Deparvu commented on CASSANDRA-14888: -- thanks [~maedhroz] for the review. I have rebased & updated the patch. [0] the only changes still missing are the tests for ViewWriteMetrics, which I will add soon. please take a look and let me know if it looks good so far. [0] https://github.com/apache/cassandra/compare/trunk...stillalex:CASSANDRA-14888 > Several mbeans are not unregistered when dropping a keyspace and table > -- > > Key: CASSANDRA-14888 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14888 > Project: Cassandra > Issue Type: Bug > Components: Observability/Metrics >Reporter: Ariel Weisberg >Assignee: Alex Deparvu >Priority: Urgent > Labels: patch-available > Fix For: 4.0-beta > > Attachments: CASSANDRA-14888.patch > > > CasCommit, CasPrepare, CasPropose, ReadRepairRequests, > ShortReadProtectionRequests, AntiCompactionTime, BytesValidated, > PartitionsValidated, RepairPrepareTime, RepairSyncTime, > RepairedDataInconsistencies, ViewLockAcquireTime, ViewReadTime, > WriteFailedIdealCL > Basically for 3 years people haven't known what they are doing because the > entire thing is kind of obscure. Fix it and also add a dtest that detects if > any mbeans are left behind after dropping a table and keyspace. -- 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-15833) Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657
[
https://issues.apache.org/jira/browse/CASSANDRA-15833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129895#comment-17129895
]
Jordan West edited comment on CASSANDRA-15833 at 6/10/20, 12:28 AM:
[~jlewandowski] I have begun the review. One thing I am trying to think about
is how we can fix the issue without tying {{ColumnFilter.Builder}} to
{{Gossiper.instance}}. On the other hand, while testing your patch I noticed
that {{Gossiper#haveMajorVersion3Nodes}} can return {{false}} when it is indeed
{{true}}. I am still digging into it. I will continue more tomorrow.
EDIT: Testing a bit more, this fixes the case where 4.0 is the coordinator.
However, when a 3.0.x node is the coordinator the deserialized {{ColumnFilter}}
on the 4.0 still has the queried columns set.
was (Author: jrwest):
[~jlewandowski] I have begun the review. One thing I am trying to think about
is how we can fix the issue without tying {{ColumnFilter.Builder}} to
{{Gossiper.instance}}. On the other hand, while testing your patch I noticed
that {{Gossiper#haveMajorVersion3Nodes}} can return {{false}} when it is indeed
{{true}}. I am still digging into it. I will continue more tomorrow.
> Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657
>
>
> Key: CASSANDRA-15833
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15833
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
> Attachments: CASSANDRA-15833-3.11.patch, CASSANDRA-15833-4.0.patch
>
>
> CASSANDRA-10657 introduced changes in how the ColumnFilter is interpreted.
> This results in digest mismatch when querying incomplete set of columns from
> a table with consistency that requires reaching instances running pre
> CASSANDRA-10657 from nodes that include CASSANDRA-10657 (it was introduced in
> Cassandra 3.4).
> The fix is to bring back the previous behaviour until there are no instances
> running pre CASSANDRA-10657 version.
--
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-15833) Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657
[
https://issues.apache.org/jira/browse/CASSANDRA-15833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129895#comment-17129895
]
Jordan West commented on CASSANDRA-15833:
-
[~jlewandowski] I have begun the review. One thing I am trying to think about
is how we can fix the issue without tying {{ColumnFilter.Builder}} to
{{Gossiper.instance}}. On the other hand, while testing your patch I noticed
that {{Gossiper#haveMajorVersion3Nodes}} can return {{false}} when it is indeed
{{true}}. I am still digging into it. I will continue more tomorrow.
> Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657
>
>
> Key: CASSANDRA-15833
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15833
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
> Attachments: CASSANDRA-15833-3.11.patch, CASSANDRA-15833-4.0.patch
>
>
> CASSANDRA-10657 introduced changes in how the ColumnFilter is interpreted.
> This results in digest mismatch when querying incomplete set of columns from
> a table with consistency that requires reaching instances running pre
> CASSANDRA-10657 from nodes that include CASSANDRA-10657 (it was introduced in
> Cassandra 3.4).
> The fix is to bring back the previous behaviour until there are no instances
> running pre CASSANDRA-10657 version.
--
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-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-14848:
-
Status: Patch Available (was: Ready to Commit)
Apologies, I can't work out how to close this. I'll work out how and take care
of it.
> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Urgent
> Labels: security
> Fix For: 4.0-beta
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0
> node only connects to 3.11.3 seed node, there are no connection established
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> {noformat}
>
> I have built 4.0 with wire tracing activated and in my config the
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but
> quickly switch to the ssl_storage_port, but when connecting to the non-seed
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT:
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT:
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT:
> /10.216.193.243:12700{noformat}
>
> When I had the dbug log activated and started the 4.0 node I can see that it
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG
> o.a.c.n.a.OutboundMessagingConnection:314 maybeUpdateConnectionId changing
> connectionId to 10.216.193.246:12701 (GOSSIP), with a different port for
[jira] [Updated] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-14848:
-
Status: Ready to Commit (was: Review In Progress)
Fix merged in CASSANDRA-15727.
> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Urgent
> Labels: security
> Fix For: 4.0-beta
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0
> node only connects to 3.11.3 seed node, there are no connection established
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> {noformat}
>
> I have built 4.0 with wire tracing activated and in my config the
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but
> quickly switch to the ssl_storage_port, but when connecting to the non-seed
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT:
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT:
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT:
> /10.216.193.243:12700{noformat}
>
> When I had the dbug log activated and started the 4.0 node I can see that it
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG
> o.a.c.n.a.OutboundMessagingConnection:314 maybeUpdateConnectionId changing
> connectionId to 10.216.193.246:12701 (GOSSIP), with a different port for
> secure communication, because peer version is 11
>
[jira] [Updated] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-14848:
-
Reviewers: Jon Meredith, Jon Meredith (was: Jon Meredith)
Jon Meredith, Jon Meredith
Status: Review In Progress (was: Patch Available)
Don't know how to close without going through all the steps...
> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Urgent
> Labels: security
> Fix For: 4.0-beta
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0
> node only connects to 3.11.3 seed node, there are no connection established
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> {noformat}
>
> I have built 4.0 with wire tracing activated and in my config the
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but
> quickly switch to the ssl_storage_port, but when connecting to the non-seed
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT:
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT:
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT:
> /10.216.193.243:12700{noformat}
>
> When I had the dbug log activated and started the 4.0 node I can see that it
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG
> o.a.c.n.a.OutboundMessagingConnection:314 maybeUpdateConnectionId
[jira] [Updated] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-14848:
-
Test and Documentation Plan: Fixed by CASSANDRA-15727.
Status: Patch Available (was: In Progress)
> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Urgent
> Labels: security
> Fix For: 4.0-beta
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0
> node only connects to 3.11.3 seed node, there are no connection established
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> {noformat}
>
> I have built 4.0 with wire tracing activated and in my config the
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but
> quickly switch to the ssl_storage_port, but when connecting to the non-seed
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT:
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT:
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT:
> /10.216.193.243:12700{noformat}
>
> When I had the dbug log activated and started the 4.0 node I can see that it
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG
> o.a.c.n.a.OutboundMessagingConnection:314 maybeUpdateConnectionId changing
> connectionId to 10.216.193.246:12701 (GOSSIP), with a different port for
> secure
[jira] [Commented] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129873#comment-17129873
]
Jon Meredith commented on CASSANDRA-14848:
--
I'm glad it's fixed for you. Sorry I missed your original patch when working
on the fix, I didn't even think to look for it as I thought it was due to the
internode message refactor.
Closing this ticket.
> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Urgent
> Labels: security
> Fix For: 4.0-beta
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0
> node only connects to 3.11.3 seed node, there are no connection established
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> {noformat}
>
> I have built 4.0 with wire tracing activated and in my config the
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but
> quickly switch to the ssl_storage_port, but when connecting to the non-seed
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT:
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT:
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT:
> /10.216.193.243:12700{noformat}
>
> When I had the dbug log activated and started the 4.0 node I can see that it
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG
> o.a.c.n.a.OutboundMessagingConnection:314
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129847#comment-17129847 ] Jon Meredith commented on CASSANDRA-14825: -- How's this going? Is anybody actively working on it as we near completion of all the alpha tickets? > Expose table schema for drivers > --- > > Key: CASSANDRA-14825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14825 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Chris Lohfink >Assignee: Robert Stupp >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the drivers recreate the CQL for the tables by putting together the > system table values. This is very difficult to keep up to date and buggy > enough that its only even supported in Java and Python drivers. Cassandra > already has some limited output available for snapshots that we could provide > in a virtual table or new query that the drivers can fetch. This can greatly > reduce the complexity of drivers while also reducing bugs like > CASSANDRA-14822 as the underlying schema and properties change. -- 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-13994) Remove COMPACT STORAGE internals before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129840#comment-17129840
]
C. Scott Andreas commented on CASSANDRA-13994:
--
Echoing that, yes; removing protocol V3 at this point would delay the ability
of many to upgrade to Cassandra 4.0 and reduce the amount of prerelease testing
that can be performed due to use of older driver versions.
> Remove COMPACT STORAGE internals before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15677:
-
Status: Open (was: Resolved)
I'm not sure how circle got around this, but it broke jenkins:
https://ci-cassandra.apache.org/job/Cassandra-trunk-artifacts/164/console
Looks like maybe we don't have that test api commit you mentioned earlier in
the ticket?
I've reverted this for now temporarily.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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: Revert "Make sure topology events are sent to clients when using a single network interface"
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams 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 66cd032 Revert "Make sure topology events are sent to clients when
using a single network interface"
66cd032 is described below
commit 66cd0324c447495ae3b40e58ca792e6fe305133e
Author: Brandon Williams
AuthorDate: Tue Jun 9 15:54:02 2020 -0500
Revert "Make sure topology events are sent to clients when using a single
network interface"
This reverts commit 595a4528dc54bc75076acf1b17f62ce9996f863c.
---
CHANGES.txt| 1 -
build.xml | 3 --
src/java/org/apache/cassandra/transport/Event.java | 4 +-
.../org/apache/cassandra/transport/Server.java | 4 +-
.../distributed/test/NodeDecommissionTest.java | 57 --
5 files changed, 4 insertions(+), 65 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 0c4203b..3b0ab6f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,4 @@
4.0-alpha5
- * Fix missing topology events when running multiple nodes on the same network
interface (CASSANDRA-15677)
* Create config.yml.MIDRES (CASSANDRA-15712)
* Fix handling of fully purged static rows in repaired data tracking
(CASSANDRA-15848)
* Prevent validation request submission from blocking ANTI_ENTROPY stage
(CASSANDRA-15812)
diff --git a/build.xml b/build.xml
index f329017..a53aafc 100644
--- a/build.xml
+++ b/build.xml
@@ -633,7 +633,6 @@
-
@@ -719,7 +718,6 @@
this that the new assertj's `assertj-parent-pom` depends on. -->
-
@@ -739,7 +737,6 @@
-
http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-package org.apache.cassandra.distributed.test;
-
-import java.util.concurrent.TimeUnit;
-
-import org.junit.Assert;
-import org.junit.Test;
-
-import com.datastax.driver.core.Session;
-import org.apache.cassandra.distributed.Cluster;
-
-import static org.apache.cassandra.distributed.api.Feature.GOSSIP;
-import static org.apache.cassandra.distributed.api.Feature.NATIVE_PROTOCOL;
-import static org.apache.cassandra.distributed.api.Feature.NETWORK;
-import static
org.apache.cassandra.distributed.impl.INodeProvisionStrategy.Strategy.OneNetworkInterface;
-import static org.awaitility.Awaitility.await;
-
-public class NodeDecommissionTest extends TestBaseImpl
-{
-
-@Test
-public void testDecomissionSucceedsForNodesOnTheSameInterface() throws
Throwable
-{
-try (Cluster control =
init(Cluster.build().withNodes(3).withNodeProvisionStrategy(OneNetworkInterface).withConfig(
-config -> {
-config.with(GOSSIP, NETWORK, NATIVE_PROTOCOL);
-}).start()))
-{
-final com.datastax.driver.core.Cluster cluster =
com.datastax.driver.core.Cluster.builder().addContactPoint("127.0.0.1").build();
-Session session = cluster.connect();
-control.get(3).nodetool("disablebinary");
-control.get(3).nodetool("decommission", "-f");
-await().atMost(10, TimeUnit.SECONDS)
- .untilAsserted(() -> Assert.assertEquals(2,
cluster.getMetadata().getAllHosts().size()));
-session.close();
-cluster.close();
-}
-}
-}
-
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15677:
-
Status: Ready to Commit (was: Review In Progress)
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15677:
-
Fix Version/s: (was: 4.0-rc)
4.0-alpha5
Since Version: 4.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/595a4528dc54bc75076acf1b17f62ce9996f863c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
I see now, thanks! Committed.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15677:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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: Make sure topology events are sent to clients when using a single network interface
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams 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 595a452 Make sure topology events are sent to clients when using a
single network interface
595a452 is described below
commit 595a4528dc54bc75076acf1b17f62ce9996f863c
Author: Alan Boudreault
AuthorDate: Mon Mar 30 14:27:55 2020 -0400
Make sure topology events are sent to clients when using a single network
interface
Patch by Alan Boudrealt and Bryn Cooke; reviewed by brandonwilliams for
CASSANDRA-15677
---
CHANGES.txt| 1 +
build.xml | 3 ++
src/java/org/apache/cassandra/transport/Event.java | 4 +-
.../org/apache/cassandra/transport/Server.java | 4 +-
.../distributed/test/NodeDecommissionTest.java | 57 ++
5 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 3b0ab6f..0c4203b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-alpha5
+ * Fix missing topology events when running multiple nodes on the same network
interface (CASSANDRA-15677)
* Create config.yml.MIDRES (CASSANDRA-15712)
* Fix handling of fully purged static rows in repaired data tracking
(CASSANDRA-15848)
* Prevent validation request submission from blocking ANTI_ENTROPY stage
(CASSANDRA-15812)
diff --git a/build.xml b/build.xml
index a53aafc..f329017 100644
--- a/build.xml
+++ b/build.xml
@@ -633,6 +633,7 @@
+
@@ -718,6 +719,7 @@
this that the new assertj's `assertj-parent-pom` depends on. -->
+
@@ -737,6 +739,7 @@
+
http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.distributed.test;
+
+import java.util.concurrent.TimeUnit;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+import com.datastax.driver.core.Session;
+import org.apache.cassandra.distributed.Cluster;
+
+import static org.apache.cassandra.distributed.api.Feature.GOSSIP;
+import static org.apache.cassandra.distributed.api.Feature.NATIVE_PROTOCOL;
+import static org.apache.cassandra.distributed.api.Feature.NETWORK;
+import static
org.apache.cassandra.distributed.impl.INodeProvisionStrategy.Strategy.OneNetworkInterface;
+import static org.awaitility.Awaitility.await;
+
+public class NodeDecommissionTest extends TestBaseImpl
+{
+
+@Test
+public void testDecomissionSucceedsForNodesOnTheSameInterface() throws
Throwable
+{
+try (Cluster control =
init(Cluster.build().withNodes(3).withNodeProvisionStrategy(OneNetworkInterface).withConfig(
+config -> {
+config.with(GOSSIP, NETWORK, NATIVE_PROTOCOL);
+}).start()))
+{
+final com.datastax.driver.core.Cluster cluster =
com.datastax.driver.core.Cluster.builder().addContactPoint("127.0.0.1").build();
+Session session = cluster.connect();
+control.get(3).nodetool("disablebinary");
+control.get(3).nodetool("decommission", "-f");
+await().atMost(10, TimeUnit.SECONDS)
+ .untilAsserted(() -> Assert.assertEquals(2,
cluster.getMetadata().getAllHosts().size()));
+session.close();
+cluster.close();
+}
+}
+}
+
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129739#comment-17129739
]
Bryn Cooke commented on CASSANDRA-15677:
Without Alan's change the decommissioned node is never reported to have left
the cluster because the topology event is never sent. I verified that the test
failed without his change.
That being said, if there is a more targeted way of testing this functionality
then it would be better. I could take another look if you feel this is likely
to be possible without large refactoring.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129719#comment-17129719
]
Brandon Williams commented on CASSANDRA-15677:
--
I'm not sure how this decom test actually tests this, can you explain?
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15865) Flaky dtest hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow
[ https://issues.apache.org/jira/browse/CASSANDRA-15865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129708#comment-17129708 ] Josh McKenzie commented on CASSANDRA-15865: --- Moving to beta as it's a) test only (i.e. not product), b) flaky, and c) looks like it's JDK11 related. > Flaky dtest > hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow > --- > > Key: CASSANDRA-15865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15865 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-beta > > > I've seen this fail a couple of times under JDK11, when it doesn't appear to > be related to the changes under test. > > -- 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-15865) Flaky dtest hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow
[ https://issues.apache.org/jira/browse/CASSANDRA-15865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-15865: -- Fix Version/s: (was: 4.0-alpha) 4.0-beta > Flaky dtest > hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow > --- > > Key: CASSANDRA-15865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15865 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-beta > > > I've seen this fail a couple of times under JDK11, when it doesn't appear to > be related to the changes under test. > > -- 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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129677#comment-17129677
]
Bryn Cooke commented on CASSANDRA-15677:
I've added links to the ticket.
I'm new to this so if I need to run more tests then I can do so.
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129650#comment-17129650
]
Brandon Williams commented on CASSANDRA-15677:
--
Do you have links to the CI runs?
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15712:
-
Fix Version/s: 4.0-alpha5
Source Control Link:
https://github.com/apache/cassandra/commit/6755487dcd58797de00ee99e26adc71479e7c1c0
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed. thanks!
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
> Fix For: 4.0-alpha5
>
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15712:
-
Status: Ready to Commit (was: Review In Progress)
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15712:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams
Status: Review In Progress (was: Patch Available)
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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: Create config.yml.MIDRES
This is an automated email from the ASF dual-hosted git repository. brandonwilliams 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 6755487 Create config.yml.MIDRES 6755487 is described below commit 6755487dcd58797de00ee99e26adc71479e7c1c0 Author: Ekaterina Dimitrova AuthorDate: Mon Jun 8 20:26:39 2020 -0400 Create config.yml.MIDRES Patch by Ekaterina Dimitrova, reviewed by brandonwilliams for CASSANDRA-15712 --- .circleci/config-2_1.yml.mid_res.patch | 224 +++ .circleci/config.yml.MIDRES| 2404 .circleci/generate.sh |1 - .circleci/generate_midres.sh |8 + .circleci/readme.md|3 + CHANGES.txt|1 + 6 files changed, 2640 insertions(+), 1 deletion(-) diff --git a/.circleci/config-2_1.yml.mid_res.patch b/.circleci/config-2_1.yml.mid_res.patch new file mode 100644 index 000..56b0887 --- /dev/null +++ b/.circleci/config-2_1.yml.mid_res.patch @@ -0,0 +1,224 @@ +diff --git .circleci/config-2_1.yml .circleci/config-2_1.yml +index ab621241a4..9c11f60d5d 100644 +--- .circleci/config-2_1.yml .circleci/config-2_1.yml +@@ -19,32 +19,44 @@ default_env_vars: _env_vars + j8_par_executor: _par_executor + executor: + name: java8-executor +-#exec_resource_class: xlarge +- parallelism: 4 ++exec_resource_class: medium ++ parallelism: 25 + + j8_small_par_executor: _small_par_executor + executor: + name: java8-executor +-#exec_resource_class: xlarge +- parallelism: 1 ++exec_resource_class: large ++ parallelism: 10 + + j8_medium_par_executor: _medium_par_executor + executor: + name: java8-executor +-#exec_resource_class: xlarge +- parallelism: 1 ++exec_resource_class: large ++ parallelism: 10 ++ ++j8_large_par_executor: _large_par_executor ++ executor: ++name: java8-executor ++exec_resource_class: large ++ parallelism: 50 ++ ++j8_very_large_par_executor: _very_large_par_executor ++ executor: ++name: java8-executor ++exec_resource_class: xlarge ++ parallelism: 100 + + j8_seq_executor: _seq_executor + executor: + name: java8-executor +-#exec_resource_class: xlarge ++exec_resource_class: medium + parallelism: 1 # sequential, single container tests: no parallelism benefits + + j11_par_executor: _par_executor + executor: + name: java11-executor +-#exec_resource_class: xlarge +- parallelism: 4 ++exec_resource_class: medium ++ parallelism: 25 + + j11_small_par_executor: _small_par_executor + executor: +@@ -52,6 +64,12 @@ j11_small_par_executor: _small_par_executor + #exec_resource_class: xlarge + parallelism: 1 + ++j11_large_par_executor: _large_par_executor ++ executor: ++name: java11-executor ++exec_resource_class: large ++ parallelism: 50 ++ + j8_with_dtests_jobs: _with_dtests_jobs + jobs: + - j8_build +@@ -425,7 +443,7 @@ jobs: + target: fqltool-test + + j8_dtests-with-vnodes: +-<<: *j8_par_executor ++<<: *j8_large_par_executor + steps: + - attach_workspace: + at: /home/cassandra +@@ -439,7 +457,7 @@ jobs: + pytest_extra_args: '--use-vnodes --num-tokens=32 --skip-resource-intensive-tests' + + j11_dtests-with-vnodes: +-<<: *j11_par_executor ++<<: *j11_large_par_executor + steps: + - attach_workspace: + at: /home/cassandra +@@ -454,7 +472,7 @@ jobs: + pytest_extra_args: '--use-vnodes --num-tokens=32 --skip-resource-intensive-tests' + + j8_dtests-no-vnodes: +-<<: *j8_par_executor ++<<: *j8_large_par_executor + steps: + - attach_workspace: + at: /home/cassandra +@@ -468,7 +486,7 @@ jobs: + pytest_extra_args: '--skip-resource-intensive-tests' + + j11_dtests-no-vnodes: +-<<: *j11_par_executor ++<<: *j11_large_par_executor + steps: + - attach_workspace: + at: /home/cassandra +@@ -483,7 +501,7 @@ jobs: + pytest_extra_args: '--skip-resource-intensive-tests' + + j8_upgradetests-no-vnodes: +-<<: *j8_par_executor ++<<: *j8_very_large_par_executor + steps: + - attach_workspace: + at: /home/cassandra +@@ -500,7 +518,7 @@ jobs: + pytest_extra_args: '--execute-upgrade-tests' + + j8_cqlsh-dtests-py2-with-vnodes: +-<<: *j8_par_executor ++<<: *j8_large_par_executor + steps: + - attach_workspace: + at: /home/cassandra +@@ -515,7 +533,7 @@ jobs: + extra_env_args: 'CQLSH_PYTHON=/usr/bin/python2.7' + + j8_cqlsh-dtests-py3-with-vnodes: +-<<: *j8_par_executor ++<<: *j8_large_par_executor + steps: + - attach_workspace: + at: /home/cassandra +@@ -530,7 +548,7 @@ jobs: + extra_env_args: 'CQLSH_PYTHON=/usr/bin/python3.6' + +
[jira] [Created] (CASSANDRA-15866) stream sstable attached index files entirely with data file
ZhaoYang created CASSANDRA-15866: Summary: stream sstable attached index files entirely with data file Key: CASSANDRA-15866 URL: https://issues.apache.org/jira/browse/CASSANDRA-15866 Project: Cassandra Issue Type: Improvement Components: Consistency/Streaming Reporter: ZhaoYang Assignee: ZhaoYang When sstable is streamed entirely, there is no need to rebuild sstable attached index on receiver if index files can be streamed entirely. -- 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-13994) Remove COMPACT STORAGE internals before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129473#comment-17129473
]
Jeff Jirsa commented on CASSANDRA-13994:
I promise you lots of people are still running native proto v3, please don't
remove it this far into the alphas.
> Remove COMPACT STORAGE internals before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
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-13994) Remove COMPACT STORAGE internals before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129456#comment-17129456
]
Ekaterina Dimitrova commented on CASSANDRA-13994:
-
Thanks [~slebresne]!
[~ifesdjeen] and [~djoshi], any thoughts on:
* the 2ndary index
* [~slebresne]'s proposal also to remove native protocol V3
* considering the ML discussion and what [~slebresne] also mentioned, do you
agree to complete this work and commit while still in Alpha?
I will rebase and do another pass after we take a decision on those. Thanks!
> Remove COMPACT STORAGE internals before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
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-14888) Several mbeans are not unregistered when dropping a keyspace and table
[ https://issues.apache.org/jira/browse/CASSANDRA-14888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-14888: Status: Changes Suggested (was: Review In Progress) > Several mbeans are not unregistered when dropping a keyspace and table > -- > > Key: CASSANDRA-14888 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14888 > Project: Cassandra > Issue Type: Bug > Components: Observability/Metrics >Reporter: Ariel Weisberg >Assignee: Alex Deparvu >Priority: Urgent > Labels: patch-available > Fix For: 4.0-beta > > Attachments: CASSANDRA-14888.patch > > > CasCommit, CasPrepare, CasPropose, ReadRepairRequests, > ShortReadProtectionRequests, AntiCompactionTime, BytesValidated, > PartitionsValidated, RepairPrepareTime, RepairSyncTime, > RepairedDataInconsistencies, ViewLockAcquireTime, ViewReadTime, > WriteFailedIdealCL > Basically for 3 years people haven't known what they are doing because the > entire thing is kind of obscure. Fix it and also add a dtest that detects if > any mbeans are left behind after dropping a table and keyspace. -- 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-15863) dtest failure TestReplaceAddress.test_restart_failed_replace
[ https://issues.apache.org/jira/browse/CASSANDRA-15863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129285#comment-17129285 ] Berenguer Blasi edited comment on CASSANDRA-15863 at 6/9/20, 3:18 PM: -- This seems to be both a test problem and a legit C* problem, so moving to alpha Doing as well in this ticket - dtest-large.replace_address_test.TestReplaceAddress.test_resume_failed_replace - dtest-large.replace_address_test.TestReplaceAddress.test_restart_failed_replace_with_reset_resume_state was (Author: bereng): This seems to be both a test problem and a legit C* problem, so moving to alpha > dtest failure TestReplaceAddress.test_restart_failed_replace > > > Key: CASSANDRA-15863 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15863 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-alpha > > > This has been > [broken|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_restart_failed_replace/history/] > for ages -- 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-14888) Several mbeans are not unregistered when dropping a keyspace and table
[
https://issues.apache.org/jira/browse/CASSANDRA-14888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129384#comment-17129384
]
Caleb Rackliffe commented on CASSANDRA-14888:
-
Finished looking at the tests, and had a couple minor comments:
1.) {{TableMetricsTest#testMetricsCleanupOnDrop()}} already uses
{{recreateTable()}}, so you might be able to get away with using a descriptive
static name for the table.
2.) We might not need {{OrderedJUnit4ClassRunner}} in {{KeyspaceMetricsTest}}.
3.) {{KeyspaceMetricsTest#registerUnregister()}} could perhaps be renamed
{{testMetricsCleanupOnDrop()}} to follow the pattern from {{TableMetricsTest}}.
4.) Echoing [~cnlwsu]'s earlier suggestion, a brief test around un-registering
MV metrics (ex. in {{ViewWriteMetrics}}) would be a good idea. (The number of
metrics there is small, so I don't expect we'd need to add any more complex
machinery for that. The unit test would catch leaks going forward...)
Otherwise, this patch looks like a nice step in the right direction.
> Several mbeans are not unregistered when dropping a keyspace and table
> --
>
> Key: CASSANDRA-14888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14888
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Alex Deparvu
>Priority: Urgent
> Labels: patch-available
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-14888.patch
>
>
> CasCommit, CasPrepare, CasPropose, ReadRepairRequests,
> ShortReadProtectionRequests, AntiCompactionTime, BytesValidated,
> PartitionsValidated, RepairPrepareTime, RepairSyncTime,
> RepairedDataInconsistencies, ViewLockAcquireTime, ViewReadTime,
> WriteFailedIdealCL
> Basically for 3 years people haven't known what they are doing because the
> entire thing is kind of obscure. Fix it and also add a dtest that detects if
> any mbeans are left behind after dropping a table and keyspace.
--
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-14888) Several mbeans are not unregistered when dropping a keyspace and table
[ https://issues.apache.org/jira/browse/CASSANDRA-14888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-14888: Status: Review In Progress (was: Changes Suggested) > Several mbeans are not unregistered when dropping a keyspace and table > -- > > Key: CASSANDRA-14888 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14888 > Project: Cassandra > Issue Type: Bug > Components: Observability/Metrics >Reporter: Ariel Weisberg >Assignee: Alex Deparvu >Priority: Urgent > Labels: patch-available > Fix For: 4.0-beta > > Attachments: CASSANDRA-14888.patch > > > CasCommit, CasPrepare, CasPropose, ReadRepairRequests, > ShortReadProtectionRequests, AntiCompactionTime, BytesValidated, > PartitionsValidated, RepairPrepareTime, RepairSyncTime, > RepairedDataInconsistencies, ViewLockAcquireTime, ViewReadTime, > WriteFailedIdealCL > Basically for 3 years people haven't known what they are doing because the > entire thing is kind of obscure. Fix it and also add a dtest that detects if > any mbeans are left behind after dropping a table and keyspace. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15848) Fully purged static row causes NPE in repaired data tracking
[
https://issues.apache.org/jira/browse/CASSANDRA-15848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15848:
Since Version: 4.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/4d1bdb129c3103c51b470b4a008039fe85d7571f
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks, committed to trunk in {{4d1bdb129c3103c51b470b4a008039fe85d7571f}}
There 2 dtest failure, both timeouts, which I couldn't reproduce locally.
> Fully purged static row causes NPE in repaired data tracking
>
>
> Key: CASSANDRA-15848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15848
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> During repaired data tracking, if the result of applying the purge function
> to a static row is null, an exception is thrown from RepairedDataInfo. This
> will cause a read exception from the replica and could lead to unavailable
> results if hit on multiple replicas. A workaround is to disable repaired data
> tracking.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Improve handling of static rows in repaired data tracking
This is an automated email from the ASF dual-hosted git repository.
samt 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 4d1bdb1 Improve handling of static rows in repaired data tracking
4d1bdb1 is described below
commit 4d1bdb129c3103c51b470b4a008039fe85d7571f
Author: Sam Tunnicliffe
AuthorDate: Thu May 28 09:54:47 2020 +0100
Improve handling of static rows in repaired data tracking
Patch by Sam Tunnicliffe; reviewed by Marcus Eriksson for CASSANDRA-15848
---
CHANGES.txt| 1 +
.../org/apache/cassandra/db/RepairedDataInfo.java | 14 +--
.../org/apache/cassandra/db/ReadCommandTest.java | 10 +++--
.../apache/cassandra/db/RepairedDataInfoTest.java | 45 +-
4 files changed, 53 insertions(+), 17 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 69e58a2..b15c71a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-alpha5
+ * Fix handling of fully purged static rows in repaired data tracking
(CASSANDRA-15848)
* Prevent validation request submission from blocking ANTI_ENTROPY stage
(CASSANDRA-15812)
* Add fqltool and auditlogviewer to rpm and deb packages (CASSANDRA-14712)
* Include DROPPED_COLUMNS in schema digest computation (CASSANDRA-15843)
diff --git a/src/java/org/apache/cassandra/db/RepairedDataInfo.java
b/src/java/org/apache/cassandra/db/RepairedDataInfo.java
index be636d3..c136f26 100644
--- a/src/java/org/apache/cassandra/db/RepairedDataInfo.java
+++ b/src/java/org/apache/cassandra/db/RepairedDataInfo.java
@@ -173,17 +173,7 @@ class RepairedDataInfo
protected Row applyToStatic(Row row)
{
-if (repairedCounter.isDone())
-return row;
-
-assert purger != null;
-Row purged = purger.applyToRow(row);
-if (!purged.isEmpty())
-{
-isFullyPurged = false;
-purged.digest(getPerPartitionDigest());
-}
-return row;
+return applyToRow(row);
}
protected Row applyToRow(Row row)
@@ -193,7 +183,7 @@ class RepairedDataInfo
assert purger != null;
Row purged = purger.applyToRow(row);
-if (purged != null)
+if (purged != null && !purged.isEmpty())
{
isFullyPurged = false;
purged.digest(getPerPartitionDigest());
diff --git a/test/unit/org/apache/cassandra/db/ReadCommandTest.java
b/test/unit/org/apache/cassandra/db/ReadCommandTest.java
index 0824168..c3687f1 100644
--- a/test/unit/org/apache/cassandra/db/ReadCommandTest.java
+++ b/test/unit/org/apache/cassandra/db/ReadCommandTest.java
@@ -164,6 +164,7 @@ public class ReadCommandTest
TableMetadata.Builder metadata6 =
TableMetadata.builder(KEYSPACE, CF6)
.addPartitionKeyColumn("key", BytesType.instance)
+ .addStaticColumn("s", AsciiType.instance)
.addClusteringColumn("col", AsciiType.instance)
.addRegularColumn("a", AsciiType.instance)
.addRegularColumn("b", AsciiType.instance)
@@ -979,7 +980,8 @@ public class ReadCommandTest
cfs.disableAutoCompaction();
setGCGrace(cfs, 600);
-// Partition with a single, fully deleted row
+// Partition with a fully deleted static row and a single, fully
deleted regular row
+RowUpdateBuilder.deleteRow(cfs.metadata(), 0,
ByteBufferUtil.bytes("key")).apply();
RowUpdateBuilder.deleteRow(cfs.metadata(), 0,
ByteBufferUtil.bytes("key"), "cc").apply();
cfs.forceBlockingFlush();
cfs.getLiveSSTables().forEach(sstable -> mutateRepaired(cfs, sstable,
111, null));
@@ -1029,7 +1031,8 @@ public class ReadCommandTest
new RowUpdateBuilder(cfs.metadata.get(), 0,
ByteBufferUtil.bytes("key-0")).clustering("cc").add("a",
ByteBufferUtil.bytes("a")).build().apply();
cfs.forceBlockingFlush();
cfs.getLiveSSTables().forEach(sstable -> mutateRepaired(cfs, sstable,
111, null));
-// Fully deleted partition in an unrepaired sstable, so not included
in the intial digest
+// Fully deleted partition (static and regular rows) in an unrepaired
sstable, so not included in the intial digest
+RowUpdateBuilder.deleteRow(cfs.metadata(), 0,
ByteBufferUtil.bytes("key-1")).apply();
RowUpdateBuilder.deleteRow(cfs.metadata(), 0,
ByteBufferUtil.bytes("key-1"), "cc").apply();
cfs.forceBlockingFlush();
@@ -1064,8 +1067,9 @@ public class ReadCommandTest
cfs.disableAutoCompaction();
setGCGrace(cfs, 0);
-// Partition with a single, fully deleted row which will be fully
purged
+//
[jira] [Updated] (CASSANDRA-15863) dtest failure TestReplaceAddress.test_restart_failed_replace
[ https://issues.apache.org/jira/browse/CASSANDRA-15863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15863: Fix Version/s: (was: 4.0-beta) 4.0-alpha > dtest failure TestReplaceAddress.test_restart_failed_replace > > > Key: CASSANDRA-15863 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15863 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-alpha > > > This has been > [broken|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_restart_failed_replace/history/] > for ages -- 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-15863) dtest failure TestReplaceAddress.test_restart_failed_replace
[ https://issues.apache.org/jira/browse/CASSANDRA-15863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129285#comment-17129285 ] Berenguer Blasi commented on CASSANDRA-15863: - This seems to be both a test problem and a legit C* problem, so moving to alpha > dtest failure TestReplaceAddress.test_restart_failed_replace > > > Key: CASSANDRA-15863 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15863 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > This has been > [broken|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_restart_failed_replace/history/] > for ages -- 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-13994) Remove COMPACT STORAGE internals before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129271#comment-17129271
]
Sylvain Lebresne commented on CASSANDRA-13994:
--
Looked at the patch. I left a few nitpicks [on this
commit|https://github.com/pcmanus/cassandra/commit/0ab608cbb6f78657ae6b3e99cea0f47d84aa3dad].
More general remarks/questions:
* I'd be in favor of removing support for the native protocol V3 while at it.
V4 has been out since pre-C* 3.0, and V3 still use the cell layout in the
paging state, which force us to keep some legacy code around like
{{CellInLegacyOrderIterator}} in {{BTreeRow.java}} (plus, some complexity in
{{PagingState}} can be nixed if we remove it). Overall, I find it doubtful that
anyone would still be on V3 on 3.X+, but even if someone is, I think forcing
them to upgrade to V4 pre-upgrade to 4.0 is a good idea even outside of the
benefit of allowing us to remove some code.
* In {{TableMetadata:}}
** I think we should remove the {{#isCompound}} method, as only compact tables
could ever be non-compound, so "compound" does not make sense anymore. Also, we
shouldn't remove the {{&& flags.contains(Flag.COMPOUND)}} part from
{{Flag#isSupported}}, as a non-compound table is _not_ supported anymore and is
indicative of someone forgetting to use {{DROP COMPACT STORAGE}}.
** We should however keep the {{CompactTable#isSuperColumnMapColumn}} method
and its call (though it's probably not worth keeping the {{CompactTables}}
class for that; a static method in {{TableMetadata}} is probably fine; I pushed
a commit doing just that
[here|https://github.com/pcmanus/cassandra/commit/0ab608cbb6f78657ae6b3e99cea0f47d84aa3dad]
if you'd like) .
* In {{SchemaEvent.java}}, in {{repr(TableMetadata)}}, we should keep the
"isCounter" case (we still support counter tables). However, we should remove
the "isCompound" entry (for the reason mentioned above).
* In {{ColumnFamilyStore}}, at the end of the ctor, the code to detect
unsupported indexes has been commented out. Is that intentional?
* Maybe worth removing the references to {{COMPACT STORAGE}} in the doc,
namely those in {{doc/source/cql/ddl.rst}}.
* I'm a bit unsure what our story about upgrading KEYS indexes is, and in
particular, I'm unsure we can remove them like that. That is, while we could
ask users to drop their KEYS index and re-create them afterwards, this cannot
be done without downtime (for anything touching the index), and are we OK with
that?
{quote}About the system table Built_indexes, I saw there is some
SystemKeyspaceMigrator40 class, I guess on start we can check and migrate this
table there (if it was not already migrated) ?
{quote}
That's an option, and I'm ok if that's done. But fwiw, I'm equally ok with
letting it be. Basically, that table simply has a {{value}} column that is
unused, but as that table is meant for internal consumption in the first place,
that feel like a pretty minor detail. So either way is fine with me.
{quote}We definitely need to be very careful when removing usage of compact
storage methods, since most of the usage is in around the storage engine.
{quote}
I wanted to point out that all the hard, deep, storage engine level changes
have been done when removing thrift, some times ago. The patch here is actually
pretty simple and almost exclusively touch CQL. It's also pretty easy to
convince oneself that the majority of the change is just removing dead code.
The one exception imo is the 2ndary index question, and that's worth being
careful, but the rest is pretty straightforward.
{quote}Also, it might be useful to know the impact of the removal and whether
or not we got anything from it performance-wise
{quote}
Related to my previous point, I'm cool if we do performance testing, that never
hurt, but I think this is *very* low on the list of tickets that justify the
effort. Again, we're merely removing a bunch of 'if' in CQL that are never
taken anymore, so the performance impact is almost surely non measurable, one
way or another.
> Remove COMPACT STORAGE internals before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make
[jira] [Updated] (CASSANDRA-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15712:
Test and Documentation Plan:
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[Java11 CI
run]|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]
[[Java8 CI
run]|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
Status: Patch Available (was: In Progress)
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 1:03 PM:
--
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[Java11 CI
run]|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]
[[Java8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11
|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 1:01 PM:
--
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11
|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 1:00 PM:
--
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
[J11|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 1:00 PM:
--
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
[J11|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 12:59 PM:
---
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI
run|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 12:59 PM:
---
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI
run|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run
|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]
]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 12:58 PM:
---
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run
|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]
]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run
|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 12:57 PM:
---
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk ]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[[J8 CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run
|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk
]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712] [[J8
CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run
|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 12:57 PM:
---
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk
]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712] [[J8
CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run
|[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk
]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712] [[J8
CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run |
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 12:56 PM:
---
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk
]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712] [[J8
CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI
run][|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk
]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712] [[J8
CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[[J11 CI
run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 12:56 PM:
---
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk
]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712] [[J8
CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run |
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk
]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712] [[J8
CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI
run][|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova edited comment on CASSANDRA-15712 at 6/9/20, 12:56 PM:
---
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[[trunk
]|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712] [[J8
CI run]
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[[J11 CI
run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]]
was (Author: e.dimitrova):
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[trunk |https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[J8 CI run
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15712) Introduce MIDRES config in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129246#comment-17129246
]
Ekaterina Dimitrova commented on CASSANDRA-15712:
-
I inherited this work from Kevin.
- config.yml.MIDRES with the discussed configuration was created using a new
generate_midres.sh script with patch config-2_1.yml.mid_res.patch.
- readme.md updated
[trunk |https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15712]
[J8 CI run
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/a0388562-9880-41df-9fc2-ad91ac1d4383]
[J11 CI run
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/211/workflows/601d44e9-a78d-4c73-b14b-2bfbe74a953e]
> Introduce MIDRES config in CircleCI
> ---
>
> Key: CASSANDRA-15712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15712
> Project: Cassandra
> Issue Type: Improvement
> Components: CI, Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: CI
>
> From document:
> [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]
> We have identified that the current HIGHRES configuration seems to require
> resources that might not bring the best cost efficiency to the build.
> We have also identified several "good compromise" configurations that allow
> to get decent performance out of the test suites, without going all out on
> the big config.
> It seems it would be useful for a lot of people to have this available as a
> {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we
> do not need to argue on modifying the {{HIGHRES}} configuration so as to not
> impact the people already using it, but can still have easy access the
> "compromise" config.
--
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-15812) Submitting Validation requests can block ANTI_ENTROPY stage
[
https://issues.apache.org/jira/browse/CASSANDRA-15812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15812:
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/04533e6cdae94f91a62d769c874156d81301dc7d
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks, committed to trunk in {{04533e6cdae94f91a62d769c874156d81301dc7d}}.
[~blerer] and I also discussed this patch in the context of draft
[CEP-3|https://cwiki.apache.org/confluence/display/CASSANDRA/%28DRAFT%29+-+CEP-3%3A+Guardrails].
Guardrails could provide a cleaner mechanism to manage the hard and soft
limits on concurrent validations.
> Submitting Validation requests can block ANTI_ENTROPY stage
>
>
> Key: CASSANDRA-15812
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15812
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> RepairMessages are handled on Stage.ANTI_ENTROPY, which has a thread pool
> with core/max capacity of one, ie. we can only process one message at a time.
>
> Scheduling validation compactions may however block the stage completely, by
> blocking on CompactionManager's ValidationExecutor while submitting a new
> validation compaction, in cases where there are already more validations
> running than can be executed in parallel.
--
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:
-
Test and Documentation Plan:
Added unit tests.
Circle Ci:
[https://circleci.com/workflow-run/cfcdbee3-c982-4ff7-ab87-e1b4c36cfdcd]
was:
Added unit tests.
Circle Ci:
https://app.circleci.com/pipelines/github/jasonstack/cassandra/153/workflows/39d0da06-96dc-4795-aa39-e4f428ba8ea7
> 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-beta
>
>
> 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-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129230#comment-17129230 ] ZhaoYang commented on CASSANDRA-15855: -- sorry for the delay.. iirc, race condition between view builder and view schema propagation exists on 3.0/3.11/4.0.. should we mark flaky on all version? or do you think the test is more stable on 3.0/3.11? > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Avoid blocking AntiEntropyStage when submitting validation requests
This is an automated email from the ASF dual-hosted git repository. samt 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 04533e6 Avoid blocking AntiEntropyStage when submitting validation requests 04533e6 is described below commit 04533e6cdae94f91a62d769c874156d81301dc7d Author: Sam Tunnicliffe AuthorDate: Wed May 13 19:20:41 2020 +0100 Avoid blocking AntiEntropyStage when submitting validation requests Patch by Sam Tunnicliffe; reviewed by Benjamin Lerer for CASSANDRA-15812 Switches ValidationExecutor's work queue to LinkedBlockingQueue to avoid blocking AntiEntropyStage when the executor is saturated. This requires VE.corePoolSize to be set to concurrent_validations as now it will always prefer to queue requests rather than start new threads. This commit also adds a hard limit on concurrent_validations, as allowing an unbounded number of validations to run concurrently is never safe. This was always true, but setting a high value here is now more dangerous as it controls the number of core, not max, threads. This hard limit is linked to concurrent_compactors, so operators may set concurrent_validations between 1 and concurrent_compactors. The meaning of setting it < 1 has changed from "unbounded" to "whatever concurrent_compactors is set to". This safety valve can be overridden with a system property at startup and/or a JMX property. CASSANDRA-9292 removed the 1hr timeout on prepare messages, but this was inadvertently undone when CASSANDRA-13397 was committed. As nothing long running is done in the repair phase anymore, this timeout can safely be reduced. If using RepairCommandPoolFullStrategy.queue, the core pool size for repairCommandExecutor must be increased from the default value of 1 or else all concurrent tasks will be queued and no more threads created. --- CHANGES.txt| 1 + conf/cassandra.yaml| 9 +- src/java/org/apache/cassandra/config/Config.java | 2 +- .../cassandra/config/DatabaseDescriptor.java | 29 - .../cassandra/db/compaction/CompactionManager.java | 32 +- .../cassandra/service/ActiveRepairService.java | 56 ++--- .../apache/cassandra/service/StorageService.java | 37 +- .../cassandra/service/StorageServiceMBean.java | 4 + .../cassandra/distributed/impl/Instance.java | 2 +- .../distributed/test/RepairCoordinatorTimeout.java | 6 +- .../cassandra/config/DatabaseDescriptorTest.java | 49 +++- .../db/compaction/ValidationExecutorTest.java | 125 + .../cassandra/service/ActiveRepairServiceTest.java | 106 + 13 files changed, 427 insertions(+), 31 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 81efa76..69e58a2 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0-alpha5 + * Prevent validation request submission from blocking ANTI_ENTROPY stage (CASSANDRA-15812) * Add fqltool and auditlogviewer to rpm and deb packages (CASSANDRA-14712) * Include DROPPED_COLUMNS in schema digest computation (CASSANDRA-15843) * Fix Cassandra restart from rpm install (CASSANDRA-15830) diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index 3a44a09..79f6434 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -814,8 +814,13 @@ column_index_cache_size_in_kb: 2 # to the number of cores. #concurrent_compactors: 1 -# Number of simultaneous repair validations to allow. Default is unbounded -# Values less than one are interpreted as unbounded (the default) +# Number of simultaneous repair validations to allow. If not set or set to +# a value less than 1, it defaults to the value of concurrent_compactors. +# To set a value greeater than concurrent_compactors at startup, the system +# property cassandra.allow_unlimited_concurrent_validations must be set to +# true. To dynamically resize to a value > concurrent_compactors on a running +# node, first call the bypassConcurrentValidatorsLimit method on the +# org.apache.cassandra.db:type=StorageService mbean # concurrent_validations: 0 # Number of simultaneous materialized view builder tasks to allow. diff --git a/src/java/org/apache/cassandra/config/Config.java b/src/java/org/apache/cassandra/config/Config.java index 6d42656..34ac049 100644 --- a/src/java/org/apache/cassandra/config/Config.java +++ b/src/java/org/apache/cassandra/config/Config.java @@ -216,7 +216,6 @@ public class Config public volatile int compaction_large_partition_warning_threshold_mb = 100; public int min_free_space_per_drive_in_mb = 50; -public volatile int concurrent_validations = Integer.MAX_VALUE; public volatile int concurrent_materialized_view_builders = 1; /** @@ -416,6 +415,7 @@
[jira] [Updated] (CASSANDRA-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhaoYang updated CASSANDRA-15855: - Reviewers: Andres de la Peña, ZhaoYang, ZhaoYang (was: Andres de la Peña, ZhaoYang) Andres de la Peña, ZhaoYang, ZhaoYang (was: Andres de la Peña) Status: Review In Progress (was: Patch Available) > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15812) Submitting Validation requests can block ANTI_ENTROPY stage
[ https://issues.apache.org/jira/browse/CASSANDRA-15812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129225#comment-17129225 ] Sam Tunnicliffe commented on CASSANDRA-15812: - Thanks, the failing tests are covered by CASSANDRA-15792, CASSANDRA-15313 & CASSANDRA-15865 > Submitting Validation requests can block ANTI_ENTROPY stage > > > Key: CASSANDRA-15812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15812 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-alpha > > > RepairMessages are handled on Stage.ANTI_ENTROPY, which has a thread pool > with core/max capacity of one, ie. we can only process one message at a time. > > Scheduling validation compactions may however block the stage completely, by > blocking on CompactionManager's ValidationExecutor while submitting a new > validation compaction, in cases where there are already more validations > running than can be executed in parallel. -- 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-15865) Flaky dtest hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow
[
https://issues.apache.org/jira/browse/CASSANDRA-15865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15865:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/dtest
Discovered By: Unit Test
Fix Version/s: 4.0-alpha
Severity: Normal
Status: Open (was: Triage Needed)
I haven't dug into it, but at first glance it looks like there could be a
problem with the dtest:
{code:python}
for node in node1, node2:
res = self._launch_nodetool_cmd(node, 'statushandoff')
assert 'Hinted handoff is running' == res.rstrip()
res = self._launch_nodetool_cmd(node, 'getmaxhintwindow')
assert 'Current max hint window: 30 ms' == res.rstrip()
self._do_hinted_handoff(node1, node2, True)
node1.start(wait_other_notice=True)
self._launch_nodetool_cmd(node, 'setmaxhintwindow 1')
assert 'Current max hint window: 1 ms' == res.rstrip()
self._do_hinted_handoff(node1, node2, False, keyspace='ks2')
{code}
The call to {{setmaxhintwindow}} to 1ms uses {{node}}, not {{node1}} which
could be affected by the ordering of the output from {{nodetool
statushandoff}}. {{_do_hinted_handoff}} writes to {{node1}} when {{node2}} is
shutdown, so if the max window is set on {{node2}} by mistake, the test will
fail as per the reported error:
{code}
self =
@since('4.0')
def test_hintedhandoff_setmaxwindow(self):
"""
Test global hinted handoff against max_hint_window_in_ms update via
nodetool
"""
node1, node2 = self._start_two_node_cluster({'hinted_handoff_enabled':
True, "max_hint_window_in_ms": 30})
for node in node1, node2:
res = self._launch_nodetool_cmd(node, 'statushandoff')
assert 'Hinted handoff is running' == res.rstrip()
res = self._launch_nodetool_cmd(node, 'getmaxhintwindow')
assert 'Current max hint window: 30 ms' == res.rstrip()
self._do_hinted_handoff(node1, node2, True)
node1.start(wait_other_notice=True)
self._launch_nodetool_cmd(node, 'setmaxhintwindow 1')
res = self._launch_nodetool_cmd(node, 'getmaxhintwindow')
assert 'Current max hint window: 1 ms' == res.rstrip()
> self._do_hinted_handoff(node1, node2, False, keyspace='ks2')
hintedhandoff_test.py:146:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
hintedhandoff_test.py:76: in _do_hinted_handoff
query_c1c2(session, n, ConsistencyLevel.ONE, tolerate_missing=True,
must_be_missing=True)
tools/data.py:40: in query_c1c2
assertions.assert_length_equal(rows, 0)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
object_with_length = [Row(c1='value1', c2='value2')], expected_length = 0
def assert_length_equal(object_with_length, expected_length):
"""
Assert an object has a specific length.
@param object_with_length The object whose length will be checked
@param expected_length The expected length of the object
Examples:
assert_length_equal(res, nb_counter)
"""
assert len(object_with_length) == expected_length, \
"Expected {} to have length {}, but instead is of length {}"\
> .format(object_with_length, expected_length,
> len(object_with_length))
E AssertionError: Expected [Row(c1='value1', c2='value2')] to have length
0, but instead is of length 1
tools/assertions.py:269: AssertionError
{code}
> Flaky dtest
> hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow
> ---
>
> Key: CASSANDRA-15865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15865
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> I've seen this fail a couple of times under JDK11, when it doesn't appear to
> be related to the changes under test.
>
>
--
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-15865) Flaky dtest hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow
Sam Tunnicliffe created CASSANDRA-15865: --- Summary: Flaky dtest hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow Key: CASSANDRA-15865 URL: https://issues.apache.org/jira/browse/CASSANDRA-15865 Project: Cassandra Issue Type: Bug Reporter: Sam Tunnicliffe I've seen this fail a couple of times under JDK11, when it doesn't appear to be related to the changes under test. -- 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-15812) Submitting Validation requests can block ANTI_ENTROPY stage
[ https://issues.apache.org/jira/browse/CASSANDRA-15812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15812: --- Status: Ready to Commit (was: Review In Progress) > Submitting Validation requests can block ANTI_ENTROPY stage > > > Key: CASSANDRA-15812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15812 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-alpha > > > RepairMessages are handled on Stage.ANTI_ENTROPY, which has a thread pool > with core/max capacity of one, ie. we can only process one message at a time. > > Scheduling validation compactions may however block the stage completely, by > blocking on CompactionManager's ValidationExecutor while submitting a new > validation compaction, in cases where there are already more validations > running than can be executed in parallel. -- 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-15812) Submitting Validation requests can block ANTI_ENTROPY stage
[ https://issues.apache.org/jira/browse/CASSANDRA-15812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129215#comment-17129215 ] Benjamin Lerer commented on CASSANDRA-15812: The change looks good and the failing tests seems unrelated. Thanks a lot. > Submitting Validation requests can block ANTI_ENTROPY stage > > > Key: CASSANDRA-15812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15812 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-alpha > > > RepairMessages are handled on Stage.ANTI_ENTROPY, which has a thread pool > with core/max capacity of one, ie. we can only process one message at a time. > > Scheduling validation compactions may however block the stage completely, by > blocking on CompactionManager's ValidationExecutor while submitting a new > validation compaction, in cases where there are already more validations > running than can be executed in parallel. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15752) Range read concurrency factor didn't consider range merger
[
https://issues.apache.org/jira/browse/CASSANDRA-15752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-15752:
--
Reviewers: Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> 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-beta
>
>
> 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-15812) Submitting Validation requests can block ANTI_ENTROPY stage
[ https://issues.apache.org/jira/browse/CASSANDRA-15812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129154#comment-17129154 ] Sam Tunnicliffe commented on CASSANDRA-15812: - [~blerer] I've removed support for the old blocking behaviour and rebased, CI is running now ||Branch||JDK8||JDK11|| |[15812-trunk|https://github.com/beobal/cassandra/commits/15812-trunk]|[CircleCI|https://app.circleci.com/pipelines/github/beobal/cassandra/40/workflows/38230d47-53d3-415a-a1da-7d517b2c603b]|[CircleCI|https://app.circleci.com/pipelines/github/beobal/cassandra/40/workflows/cb744bb4-dc23-4eff-b888-96d622da3e30]| > Submitting Validation requests can block ANTI_ENTROPY stage > > > Key: CASSANDRA-15812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15812 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-alpha > > > RepairMessages are handled on Stage.ANTI_ENTROPY, which has a thread pool > with core/max capacity of one, ie. we can only process one message at a time. > > Scheduling validation compactions may however block the stage completely, by > blocking on CompactionManager's ValidationExecutor while submitting a new > validation compaction, in cases where there are already more validations > running than can be executed in parallel. -- 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-15719) DOC - Primary range repair should be run on every datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-15719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-15719:
--
Summary: DOC - Primary range repair should be run on every datacenter
(was: The primary range repair should be run on every datacenter)
> DOC - Primary range repair should be run on every datacenter
>
>
> Key: CASSANDRA-15719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15719
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Blog
>Reporter: Jane Deng
>Priority: Normal
>
> In the Cassandra document page:
> [http://cassandra.apache.org/doc/latest/operating/repair.html], there is an
> explanation which makes confusion on users' side:
> {quote}The {{-pr}} flag will only repair the “primary” ranges on a node, so
> you can repair your entire cluster by running {{nodetool repair -pr}} on each
> node in a single datacenter.
> {quote}
> This made confusion that "running nodetool repair -pr on each node in a
> single DC" was sufficient to do a full repair on a multi-DC cluster.
> The correct way to use the primary range repair should be
> {quote}if you are using “nodetool repair -pr” you must run it on *EVERY* node
> in *EVERY* data center, no skipping allowed.
> {quote}
> Please make a doc fix. Thanks.
--
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-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15773:
---
Fix Version/s: 4.0-beta
Source Control Link:
https://github.com/apache/cassandra/commit/bc600f1bd5b188030305b964e5aef1b0ea70f634
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into trunk at bc600f1bd5b188030305b964e5aef1b0ea70f634
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
> Fix For: 4.0-beta
>
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
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: Add BufferPoolMetricsTest
This is an automated email from the ASF dual-hosted git repository.
blerer 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 bc600f1 Add BufferPoolMetricsTest
bc600f1 is described below
commit bc600f1bd5b188030305b964e5aef1b0ea70f634
Author: Stephen Mallette
AuthorDate: Wed Apr 29 11:51:03 2020 -0400
Add BufferPoolMetricsTest
patch by Stephen Mallette; reviewed by David Capwell and by Benjamin Lerer
for CASSANDRA-15773
---
.../apache/cassandra/metrics/BatchMetricsTest.java | 1 -
.../cassandra/metrics/BufferPoolMetricsTest.java | 192 +
.../cassandra/utils/memory/BufferPoolTest.java | 9 +
3 files changed, 201 insertions(+), 1 deletion(-)
diff --git a/test/unit/org/apache/cassandra/metrics/BatchMetricsTest.java
b/test/unit/org/apache/cassandra/metrics/BatchMetricsTest.java
index 900ac75..c3bf794 100644
--- a/test/unit/org/apache/cassandra/metrics/BatchMetricsTest.java
+++ b/test/unit/org/apache/cassandra/metrics/BatchMetricsTest.java
@@ -40,7 +40,6 @@ import
org.apache.cassandra.metrics.DecayingEstimatedHistogramReservoir.Estimate
import static org.apache.cassandra.cql3.statements.BatchStatement.metrics;
import static
org.apache.cassandra.metrics.DecayingEstimatedHistogramReservoir.*;
import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertTrue;
import static org.quicktheories.QuickTheory.qt;
import static org.quicktheories.generators.Generate.intArrays;
import static org.quicktheories.generators.SourceDSL.integers;
diff --git a/test/unit/org/apache/cassandra/metrics/BufferPoolMetricsTest.java
b/test/unit/org/apache/cassandra/metrics/BufferPoolMetricsTest.java
new file mode 100644
index 000..fade96c
--- /dev/null
+++ b/test/unit/org/apache/cassandra/metrics/BufferPoolMetricsTest.java
@@ -0,0 +1,192 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.metrics;
+
+import java.util.Random;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+
+import org.apache.cassandra.OrderedJUnit4ClassRunner;
+import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.exceptions.ConfigurationException;
+import org.apache.cassandra.io.compress.BufferType;
+import org.apache.cassandra.utils.memory.BufferPool;
+import org.apache.cassandra.utils.memory.BufferPoolTest;
+
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.assertj.core.api.Assertions.assertThatExceptionOfType;
+import static org.junit.Assert.assertEquals;
+
+@RunWith(OrderedJUnit4ClassRunner.class)
+public class BufferPoolMetricsTest
+{
+private static final BufferPoolMetrics metrics = new BufferPoolMetrics();
+
+@BeforeClass()
+public static void setup() throws ConfigurationException
+{
+DatabaseDescriptor.daemonInitialization();
+}
+
+@Before
+public void setUp()
+{
+BufferPool.MEMORY_USAGE_THRESHOLD = 16 * 1024L * 1024L;
+}
+
+@After
+public void cleanUp()
+{
+BufferPoolTest.resetBufferPool();
+metrics.misses.mark(metrics.misses.getCount() * -1);
+}
+
+@Test
+public void testMetricsSize()
+{
+// basically want to test changes in the metric being reported as the
buffer pool grows - starts at zero
+assertThat(metrics.size.getValue()).isEqualTo(BufferPool.sizeInBytes())
+ .isEqualTo(0);
+
+// the idea is to test changes in the sizeOfBufferPool metric which
starts at zero. it will bump up
+// after the first request for a ByteBuffer and the idea from there
will be to keep requesting them
+// until it bumps a second time at which point there should be some
confidence that thie metric is
+// behaving as expected. these assertions should occur well within the
value of the MEMORY_USAGE_THRESHOLD
+// given the maxBufferSize (just covering the case of the weirdest
random seed in the multiverse i guess - a
+// while
[jira] [Updated] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15773:
---
Reviewers: Benjamin Lerer, David Capwell (was: David Capwell, Dinesh Joshi)
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
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-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129029#comment-17129029
]
Benjamin Lerer commented on CASSANDRA-15773:
The patch looks good to me. :-)
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
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-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15773:
---
Status: Ready to Commit (was: Review In Progress)
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15841) Fix flaky junit.framework.TestSuite.org.apache.cassandra.io.sstable.CQLSSTableWriterTest-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-15841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15841: --- Fix Version/s: (was: 4.0-beta) > Fix flaky > junit.framework.TestSuite.org.apache.cassandra.io.sstable.CQLSSTableWriterTest-cdc > > > Key: CASSANDRA-15841 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15841 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Failing for the past [29 > buils|https://ci-cassandra.apache.org/job/Cassandra-trunk/154/testReport/junit.framework/TestSuite/org_apache_cassandra_io_sstable_CQLSSTableWriterTest_cdc/] > java.lang.NullPointerException > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC$CDCSizeTracker.shutdown(CommitLogSegmentManagerCDC.java:312) > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:89) > at > org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:413) > at > org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:467) > at > org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:785) > at > org.apache.cassandra.io.sstable.CQLSSTableWriterTest.setup(CQLSSTableWriterTest.java:62) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15841) Fix flaky junit.framework.TestSuite.org.apache.cassandra.io.sstable.CQLSSTableWriterTest-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-15841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15841: --- Resolution: Duplicate Status: Resolved (was: Open) > Fix flaky > junit.framework.TestSuite.org.apache.cassandra.io.sstable.CQLSSTableWriterTest-cdc > > > Key: CASSANDRA-15841 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15841 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Failing for the past [29 > buils|https://ci-cassandra.apache.org/job/Cassandra-trunk/154/testReport/junit.framework/TestSuite/org_apache_cassandra_io_sstable_CQLSSTableWriterTest_cdc/] > java.lang.NullPointerException > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC$CDCSizeTracker.shutdown(CommitLogSegmentManagerCDC.java:312) > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:89) > at > org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:413) > at > org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:467) > at > org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:785) > at > org.apache.cassandra.io.sstable.CQLSSTableWriterTest.setup(CQLSSTableWriterTest.java:62) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15842) Fix flaky org.apache.cassandra.schema.SchemaTest.testTransKsMigration-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-15842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15842: --- Since Version: 4.0-alpha4 Source Control Link: https://github.com/apache/cassandra/commit/2621e07e87c1a5b53476871618740248d07607f2 Resolution: Fixed Status: Resolved (was: Ready to Commit) Thanks for the patch. Committed into trunk at 2621e07e87c1a5b53476871618740248d07607f2 > Fix flaky org.apache.cassandra.schema.SchemaTest.testTransKsMigration-cdc > - > > Key: CASSANDRA-15842 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15842 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 0.5h > Remaining Estimate: 0h > > Failing for the past [28 > builds|https://ci-cassandra.apache.org/job/Cassandra-trunk/153/testReport/org.apache.cassandra.schema/SchemaTest/testTransKsMigration_cdc/] > java.lang.NullPointerException > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC$CDCSizeTracker.shutdown(CommitLogSegmentManagerCDC.java:312) > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:89) > at > org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:413) > at > org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:467) > at > org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:785) > at > org.apache.cassandra.schema.SchemaTest.testTransKsMigration(SchemaTest.java:46) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15841) Fix flaky junit.framework.TestSuite.org.apache.cassandra.io.sstable.CQLSSTableWriterTest-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-15841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15841: --- Status: Open (was: Patch Available) > Fix flaky > junit.framework.TestSuite.org.apache.cassandra.io.sstable.CQLSSTableWriterTest-cdc > > > Key: CASSANDRA-15841 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15841 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Failing for the past [29 > buils|https://ci-cassandra.apache.org/job/Cassandra-trunk/154/testReport/junit.framework/TestSuite/org_apache_cassandra_io_sstable_CQLSSTableWriterTest_cdc/] > java.lang.NullPointerException > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC$CDCSizeTracker.shutdown(CommitLogSegmentManagerCDC.java:312) > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:89) > at > org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:413) > at > org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:467) > at > org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:785) > at > org.apache.cassandra.io.sstable.CQLSSTableWriterTest.setup(CQLSSTableWriterTest.java:62) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix SchemaTest.testTransKsMigration-cdc and CQLSSTableWriterTest-cdc
This is an automated email from the ASF dual-hosted git repository.
blerer 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 2621e07 Fix SchemaTest.testTransKsMigration-cdc and
CQLSSTableWriterTest-cdc
2621e07 is described below
commit 2621e07e87c1a5b53476871618740248d07607f2
Author: Bereng
AuthorDate: Mon Jun 1 12:32:27 2020 +0200
Fix SchemaTest.testTransKsMigration-cdc and CQLSSTableWriterTest-cdc
patch by Berenguer Blasi; reviewed by Benjamin Lerer for CASSANDRA-15842
The tests were constantly failing for the cdc test run due to the fact
that CDCSizeTracker.shutdown was throwing a NPE if the method was called
while CDCSizeTracker was not started.
The fix ensure that the test start the commitlog and that
CDCSizeTracker.shutdown is a NOOP if the tracker has not been started.
---
.../apache/cassandra/db/commitlog/CommitLogSegmentManagerCDC.java| 5 -
test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java | 2 ++
test/unit/org/apache/cassandra/schema/SchemaTest.java| 2 ++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git
a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDC.java
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDC.java
index bdd4f74..66c8a39 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDC.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDC.java
@@ -309,7 +309,10 @@ public class CommitLogSegmentManagerCDC extends
AbstractCommitLogSegmentManager
public void shutdown()
{
-cdcSizeCalculationExecutor.shutdown();
+if (cdcSizeCalculationExecutor != null &&
!cdcSizeCalculationExecutor.isShutdown())
+{
+cdcSizeCalculationExecutor.shutdown();
+}
}
private void addSize(long toAdd)
diff --git
a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
index 931d9ec..f035658 100644
--- a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
@@ -37,6 +37,7 @@ import org.apache.cassandra.cql3.*;
import org.apache.cassandra.cql3.functions.UDHelper;
import org.apache.cassandra.cql3.functions.types.*;
import org.apache.cassandra.db.Keyspace;
+import org.apache.cassandra.db.commitlog.CommitLog;
import org.apache.cassandra.dht.*;
import org.apache.cassandra.exceptions.*;
import org.apache.cassandra.schema.Schema;
@@ -59,6 +60,7 @@ public class CQLSSTableWriterTest
@BeforeClass
public static void setup() throws Exception
{
+CommitLog.instance.start();
SchemaLoader.cleanupAndLeaveDirs();
Keyspace.setInitialized();
StorageService.instance.initServer();
diff --git a/test/unit/org/apache/cassandra/schema/SchemaTest.java
b/test/unit/org/apache/cassandra/schema/SchemaTest.java
index 32a5620..64b1341 100644
--- a/test/unit/org/apache/cassandra/schema/SchemaTest.java
+++ b/test/unit/org/apache/cassandra/schema/SchemaTest.java
@@ -26,6 +26,7 @@ import org.junit.Test;
import org.apache.cassandra.SchemaLoader;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.db.Keyspace;
+import org.apache.cassandra.db.commitlog.CommitLog;
import org.apache.cassandra.gms.Gossiper;
import static org.junit.Assert.assertNotNull;
@@ -43,6 +44,7 @@ public class SchemaTest
@Test
public void testTransKsMigration() throws IOException
{
+CommitLog.instance.start();
SchemaLoader.cleanupAndLeaveDirs();
Schema.instance.loadFromDisk();
assertEquals(0, Schema.instance.getNonSystemKeyspaces().size());
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15842) Fix flaky org.apache.cassandra.schema.SchemaTest.testTransKsMigration-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-15842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15842: --- Status: Ready to Commit (was: Review In Progress) > Fix flaky org.apache.cassandra.schema.SchemaTest.testTransKsMigration-cdc > - > > Key: CASSANDRA-15842 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15842 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 0.5h > Remaining Estimate: 0h > > Failing for the past [28 > builds|https://ci-cassandra.apache.org/job/Cassandra-trunk/153/testReport/org.apache.cassandra.schema/SchemaTest/testTransKsMigration_cdc/] > java.lang.NullPointerException > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC$CDCSizeTracker.shutdown(CommitLogSegmentManagerCDC.java:312) > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:89) > at > org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:413) > at > org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:467) > at > org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:785) > at > org.apache.cassandra.schema.SchemaTest.testTransKsMigration(SchemaTest.java:46) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15849) Remove generated files from apache-cassandra-*-src.tar.gz artifacts
[ https://issues.apache.org/jira/browse/CASSANDRA-15849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15849: --- Fix Version/s: (was: 4.0-beta) 4.0-alpha5 4.0 Source Control Link: https://github.com/apache/cassandra/commit/334024751c4dd2726ff244f691687647a0e94c5f Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [334024751c4dd2726ff244f691687647a0e94c5f |https://github.com/apache/cassandra/commit/334024751c4dd2726ff244f691687647a0e94c5f] > Remove generated files from apache-cassandra-*-src.tar.gz artifacts > --- > > Key: CASSANDRA-15849 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15849 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0, 4.0-alpha5 > > > The apache-cassandra-*-src.tar.gz source artifacts contain a lot of generated > files. > These need to be excluded when putting together the source tarball. -- 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 cassandra-3.11 updated (04b0049 -> e498539)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 04b0049 Merge branch 'cassandra-3.0' into cassandra-3.11 new 3340247 Remove generated files from apache-cassandra-*-src.tar.gz artifacts new c092c46 Merge branch 'cassandra-2.2' into cassandra-3.0 new e498539 Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .gitignore | 1 + CHANGES.txt | 1 + build.xml | 4 3 files changed, 6 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (880b07c -> c092c46)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 880b07c Merge branch 'cassandra-2.2' into cassandra-3.0 new 3340247 Remove generated files from apache-cassandra-*-src.tar.gz artifacts new c092c46 Merge branch 'cassandra-2.2' into cassandra-3.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .gitignore | 1 + CHANGES.txt | 1 + build.xml | 4 3 files changed, 6 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated: Remove generated files from apache-cassandra-*-src.tar.gz artifacts
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-2.2 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-2.2 by this push: new 3340247 Remove generated files from apache-cassandra-*-src.tar.gz artifacts 3340247 is described below commit 334024751c4dd2726ff244f691687647a0e94c5f Author: Mick Semb Wever AuthorDate: Wed Jun 3 15:41:33 2020 +0200 Remove generated files from apache-cassandra-*-src.tar.gz artifacts patch by Mick Semb Wever; reviewed by Robert Stupp for CASSANDRA-15849 --- .gitignore | 1 + CHANGES.txt | 1 + build.xml | 4 3 files changed, 6 insertions(+) diff --git a/.gitignore b/.gitignore index acaa51a..8954831 100644 --- a/.gitignore +++ b/.gitignore @@ -71,3 +71,4 @@ lib/jsr223/jython/*.jar lib/jsr223/jython/cachedir lib/jsr223/scala/*.jar +.ant_targets \ No newline at end of file diff --git a/CHANGES.txt b/CHANGES.txt index 00507d2..788b2bf 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.2.18 + * Remove generated files from source artifact (CASSANDRA-15849) * Remove duplicated tools binaries from tarballs (CASSANDRA-15768) * Duplicate results with DISTINCT queries in mixed mode (CASSANDRA-15501) * Disable JMX rebinding (CASSANDRA-15653) diff --git a/build.xml b/build.xml index 0fa2380..83fb674 100644 --- a/build.xml +++ b/build.xml @@ -1153,6 +1153,10 @@ + + + + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit e49853914bd407827093cebf5151db0ebe2eba9e Merge: 04b0049 c092c46 Author: Mick Semb Wever AuthorDate: Tue Jun 9 09:44:50 2020 +0200 Merge branch 'cassandra-3.0' into cassandra-3.11 .gitignore | 1 + CHANGES.txt | 1 + build.xml | 4 3 files changed, 6 insertions(+) diff --cc .gitignore index f5b1ce1,8954831..b6fd009 --- a/.gitignore +++ b/.gitignore @@@ -71,7 -71,4 +71,8 @@@ lib/jsr223/jython/*.ja lib/jsr223/jython/cachedir lib/jsr223/scala/*.jar -.ant_targets +/.ant-targets-build.xml ++.ant_targets + +# Generated files from the documentation +doc/source/configuration/cassandra_config_file.rst - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit c092c4610e05b42d2fb2439cf4930bfdd4c84594 Merge: 880b07c 3340247 Author: Mick Semb Wever AuthorDate: Mon Jun 8 22:33:09 2020 +0200 Merge branch 'cassandra-2.2' into cassandra-3.0 .gitignore | 1 + CHANGES.txt | 1 + build.xml | 4 3 files changed, 6 insertions(+) diff --cc CHANGES.txt index ff00579,788b2bf..3fdbb96 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,19 -1,5 +1,20 @@@ -2.2.18 +3.0.21 + * Fix replica-side filtering returning stale data with CL > ONE (CASSANDRA-8272, CASSANDRA-8273) + * Fix duplicated row on 2.x upgrades when multi-rows range tombstones interact with collection ones (CASSANDRA-15805) + * Rely on snapshotted session infos on StreamResultFuture.maybeComplete to avoid race conditions (CASSANDRA-15667) + * EmptyType doesn't override writeValue so could attempt to write bytes when expected not to (CASSANDRA-15790) + * Fix index queries on partition key columns when some partitions contains only static data (CASSANDRA-13666) + * Avoid creating duplicate rows during major upgrades (CASSANDRA-15789) + * liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted (CASSANDRA-15674) + * Fix Debian init start/stop (CASSANDRA-15770) + * Fix infinite loop on index query paging in tables with clustering (CASSANDRA-14242) + * Fix chunk index overflow due to large sstable with small chunk length (CASSANDRA-15595) + * cqlsh return non-zero status when STDIN CQL fails (CASSANDRA-15623) + * Don't skip sstables in slice queries based only on local min/max/deletion timestamp (CASSANDRA-15690) + * Memtable memory allocations may deadlock (CASSANDRA-15367) + * Run evictFromMembership in GossipStage (CASSANDRA-15592) +Merged from 2.2: + * Remove generated files from source artifact (CASSANDRA-15849) * Remove duplicated tools binaries from tarballs (CASSANDRA-15768) * Duplicate results with DISTINCT queries in mixed mode (CASSANDRA-15501) * Disable JMX rebinding (CASSANDRA-15653) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (7bbc97e -> 6978307)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 7bbc97e Merge branch 'cassandra-3.11' into trunk new 3340247 Remove generated files from apache-cassandra-*-src.tar.gz artifacts new c092c46 Merge branch 'cassandra-2.2' into cassandra-3.0 new e498539 Merge branch 'cassandra-3.0' into cassandra-3.11 new 6978307 Merge branch 'cassandra-3.11' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .gitignore | 1 + CHANGES.txt | 1 + build.xml | 4 3 files changed, 6 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 6978307b79b39501af91512fb7c243deb0ef7a5a Merge: 7bbc97e e498539 Author: Mick Semb Wever AuthorDate: Tue Jun 9 09:46:27 2020 +0200 Merge branch 'cassandra-3.11' into trunk .gitignore | 1 + CHANGES.txt | 1 + build.xml | 4 3 files changed, 6 insertions(+) diff --cc CHANGES.txt index 4487420,f1f8a0e..81efa76 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -51,59 -15,12 +51,60 @@@ Merged from 3.0 * Allow selecting static column only when querying static index (CASSANDRA-14242) * cqlsh return non-zero status when STDIN CQL fails (CASSANDRA-15623) * Don't skip sstables in slice queries based only on local min/max/deletion timestamp (CASSANDRA-15690) - * Memtable memory allocations may deadlock (CASSANDRA-15367) - * Run evictFromMembership in GossipStage (CASSANDRA-15592) Merged from 2.2: + * Remove generated files from source artifact (CASSANDRA-15849) * Remove duplicated tools binaries from tarballs (CASSANDRA-15768) * Duplicate results with DISTINCT queries in mixed mode (CASSANDRA-15501) + +4.0-alpha4 + * Add client request size server metrics (CASSANDRA-15704) + * Add additional logging around FileUtils and compaction leftover cleanup (CASSANDRA-15705) + * Mark system_views/system_virtual_schema as non-alterable keyspaces in cqlsh (CASSANDRA-15711) + * Fail incremental repair if an old version sstable is involved (CASSANDRA-15612) + * Fix overflows on StreamingTombstoneHistogramBuilder produced by large deletion times (CASSANDRA-14773) + * Mark system_views/system_virtual_schema as system keyspaces in cqlsh (CASSANDRA-15706) + * Avoid unnecessary collection/iterator allocations during btree construction (CASSANDRA-15390) + * Repair history tables should have TTL and TWCS (CASSANDRA-12701) + * Fix cqlsh erroring out on Python 3.7 due to webbrowser module being absent (CASSANDRA-15572) + * Fix IMH#acquireCapacity() to return correct Outcome when endpoint reserve runs out (CASSANDRA-15607) + * Fix nodetool describering output (CASSANDRA-15682) + * Only track ideal CL failure when request CL met (CASSANDRA-15696) + * Fix flaky CoordinatorMessagingTest and docstring in OutboundSink and ConsistentSession (CASSANDRA-15672) + * Fix force compaction of wrapping ranges (CASSANDRA-15664) + * Expose repair streaming metrics (CASSANDRA-15656) + * Set now in seconds in the future for validation repairs (CASSANDRA-15655) + * Emit metric on preview repair failure (CASSANDRA-15654) + * Use more appropriate logging levels (CASSANDRA-15661) + * Fixed empty check in TrieMemIndex due to potential state inconsistency in ConcurrentSkipListMap (CASSANDRA-15526) + * Added UnleveledSSTables global and table level metric (CASSANDRA-15620) + * Added Virtual Table exposing Cassandra relevant system properties (CASSANDRA-15616, CASSANDRA-15643) + * Improve the algorithmic token allocation in case racks = RF (CASSANDRA-15600) + * Fix ConnectionTest.testAcquireReleaseOutbound (CASSANDRA-15308) + * Include finalized pending sstables in preview repair (CASSANDRA-15553) + * Reverted to the original behavior of CLUSTERING ORDER on CREATE TABLE (CASSANDRA-15271) + * Correct inaccurate logging message (CASSANDRA-15549) + * Unset GREP_OPTIONS (CASSANDRA-14487) + * Update to Python driver 3.21 for cqlsh (CASSANDRA-14872) + * Fix missing Keyspaces in cqlsh describe output (CASSANDRA-15576) + * Fix multi DC nodetool status output (CASSANDRA-15305) + * updateCoordinatorWriteLatencyTableMetric can produce misleading metrics (CASSANDRA-15569) + * Make cqlsh and cqlshlib Python 2 & 3 compatible (CASSANDRA-10190) + * Improve the description of nodetool listsnapshots command (CASSANDRA-14587) + * allow embedded cassandra launched from a one-jar or uno-jar (CASSANDRA-15494) + * Update hppc library to version 0.8.1 (CASSANDRA-12995) + * Limit the dependencies used by UDFs/UDAs (CASSANDRA-14737) + * Make native_transport_max_concurrent_requests_in_bytes updatable (CASSANDRA-15519) + * Cleanup and improvements to IndexInfo/ColumnIndex (CASSANDRA-15469) + * Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes (CASSANDRA-15470) +Merged from 3.11: + * Allow sstableloader to use SSL on the native port (CASSANDRA-14904) +Merged from 3.0: + * cqlsh return non-zero status when STDIN CQL fails (CASSANDRA-15623) + * Don't skip sstables in slice queries based only on local min/max/deletion timestamp (CASSANDRA-15690) + * Memtable memory allocations may deadlock (CASSANDRA-15367) + * Run evictFromMembership in GossipStage (CASSANDRA-15592) +Merged from 2.2: + * Duplicate results with DISTINCT queries in mixed mode (CASSANDRA-15501) * Disable JMX rebinding (CASSANDRA-15653) Merged from 2.1: * Fix parse error in cqlsh COPY FROM and formatting for map of
