[jira] [Updated] (CASSANDRA-15869) MemoryOutputStream overflow on large bloom filter
[
https://issues.apache.org/jira/browse/CASSANDRA-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15869:
-
Source Control Link: https://github.com/apache/cassandra/pull/620
Test and Documentation Plan:
Large sstable can be loaded again.
CircleCi:
[https://circleci.com/workflow-run/69685b9a-f356-46ef-939f-851cc1d29a4f]
> MemoryOutputStream overflow on large bloom filter
> -
>
> Key: CASSANDRA-15869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15869
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to
> reconstruct BF Memory without re-ordering bytes, see
> {{OffsetBitSet#deserialize}}. But {{MemoryOutputStream}} use {{INT}} to track
> position and will overflow when BF size exceeds 2GB.
> {code:java|title=stacktrace}
> error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
> -- StackTrace --
> java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
> 4588588016
> at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
> at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
> at
> org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15869) MemoryOutputStream overflow on large bloom filter
[
https://issues.apache.org/jira/browse/CASSANDRA-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15869:
-
Status: Patch Available (was: Open)
> MemoryOutputStream overflow on large bloom filter
> -
>
> Key: CASSANDRA-15869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15869
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to
> reconstruct BF Memory without re-ordering bytes, see
> {{OffsetBitSet#deserialize}}. But {{MemoryOutputStream}} use {{INT}} to track
> position and will overflow when BF size exceeds 2GB.
> {code:java|title=stacktrace}
> error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
> -- StackTrace --
> java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
> 4588588016
> at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
> at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
> at
> org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15869) MemoryOutputStream overflow on large bloom filter
[
https://issues.apache.org/jira/browse/CASSANDRA-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15869:
-
Description:
Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to reconstruct
BF Memory without re-ordering bytes, see {{OffsetBitSet#deserialize}}. But
{{MemoryOutputStream}} use {{INT}} to track position and will overflow when BF
size exceeds 2GB.
{code:java|title=stacktrace}
error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
-- StackTrace --
java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
4588588016
at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
at
org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
{code}
was:
Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to reconstruct
BF Memory without re-ordering bytes, see {{OffsetBitSet#deserialize}}. But
{{MemoryOutputStream}} use {{INT}} to track position and will overflow when BF
size exceeds 2GB (eg. 500gb sstable).
{code:java|title=stacktrace}
error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
-- StackTrace --
java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
4588588016
at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
at
org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
{code}
> MemoryOutputStream overflow on large bloom filter
> -
>
> Key: CASSANDRA-15869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15869
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to
> reconstruct BF Memory without re-ordering bytes, see
> {{OffsetBitSet#deserialize}}. But {{MemoryOutputStream}} use {{INT}} to track
> position and will overflow when BF size exceeds 2GB.
> {code:java|title=stacktrace}
> error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
> -- StackTrace --
> java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
> 4588588016
> at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
> at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
> at
> org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15869) MemoryOutputStream overflow on large bloom filter
[
https://issues.apache.org/jira/browse/CASSANDRA-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130671#comment-17130671
]
ZhaoYang edited comment on CASSANDRA-15869 at 6/11/20, 5:06 AM:
btw, this is failing for 500GB sstable during internal stress testing...
was (Author: jasonstack):
btw, this is failing for 500GB sstable...
> MemoryOutputStream overflow on large bloom filter
> -
>
> Key: CASSANDRA-15869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15869
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to
> reconstruct BF Memory without re-ordering bytes, see
> {{OffsetBitSet#deserialize}}. But {{MemoryOutputStream}} use {{INT}} to track
> position and will overflow when BF size exceeds 2GB (eg. 500gb sstable).
> {code:java|title=stacktrace}
> error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
> -- StackTrace --
> java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
> 4588588016
> at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
> at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
> at
> org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [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=17132664#comment-17132664
]
Caleb Rackliffe commented on CASSANDRA-14888:
-
[~stillalex] There is one real problem I think we need to address. In
{{KeyspaceMetricNameFactory#release()}}, we call {{createMetricName()}}, which
adds names to {{allMetrics}}, _while we're iterating over_ {{allMetrics}}.
You'll either need to store {{MetricName}} instances in {{allMetrics}}, so you
can avoid the call to {{createMetricName()}}, or go back to something more like
the approach in {{TableMetrics}}, keeping the metric lifecycle separate from
the factory itself. (I lean toward the {{TableMetrics}} approach, given the
helper methods might make it a little easier to add things going forward, and
it doesn't fragment the responsibilities of the factory, but I could be wrong
there.)
By the way, when we get to a good place (maybe after the MV test is ready) I'll
cherry-pick your commit into my fork and run it through CircleCI. (The free
tier hardware is a bit lacking...)
> 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] [Commented] (CASSANDRA-15867) Update Jackson version to 2.9.10.1 because there are security issues in 2.9.5
[ https://issues.apache.org/jira/browse/CASSANDRA-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132659#comment-17132659 ] Brandon Williams commented on CASSANDRA-15867: -- Why is the included jackson-databind labeled 2.9.10.4, but the build.xml change specifies 2.9.10.1? > 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 >Priority: Normal > 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] [Comment Edited] (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=17132545#comment-17132545
]
Caleb Rackliffe edited comment on CASSANDRA-14888 at 6/10/20, 6:29 PM:
---
[~stillalex] Two minor things:
1.) I think there's a [minor
typo|https://github.com/apache/cassandra/compare/trunk...stillalex:CASSANDRA-14888#diff-8f3132f0fa1e03f77fd29bc9b8163fe3R65]
in {{KeyspaceMetricsTest#testMetricsCleanupOnDrop()}}.
2.) You probably don't need the JavaDoc comment for
{{ReleasableMetric#release()}}, unless there's something more substantial we
need to say there.
Just heads up...there also may have been an issue (which is now resolved) w/
compiling trunk at the time you rebased.
Do you mind creating a quick PR so we can discuss the patch inline?
was (Author: maedhroz):
[~stillalex] Two minor things:
1.) I think there's a [minor
typo|https://github.com/apache/cassandra/compare/trunk...stillalex:CASSANDRA-14888#diff-8f3132f0fa1e03f77fd29bc9b8163fe3R65]
in {{KeyspaceMetricsTest#testMetricsCleanupOnDrop()}}.
2.) You probably don't need the JavaDoc comment for
{{ReleasableMetric#release()}}, unless there's something more substantial we
need to say there.
Just heads up...there also may have been an issue (which is now resolved) w/
compiling trunk at the time you rebased.
> 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-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=17132545#comment-17132545
]
Caleb Rackliffe edited comment on CASSANDRA-14888 at 6/10/20, 6:22 PM:
---
[~stillalex] Two minor things:
1.) I think there's a [minor
typo|https://github.com/apache/cassandra/compare/trunk...stillalex:CASSANDRA-14888#diff-8f3132f0fa1e03f77fd29bc9b8163fe3R65]
in {{KeyspaceMetricsTest#testMetricsCleanupOnDrop()}}.
2.) You probably don't need the JavaDoc comment for
{{ReleasableMetric#release()}}, unless there's something more substantial we
need to say there.
Just heads up...there also may have been an issue (which is now resolved) w/
compiling trunk at the time you rebased.
was (Author: maedhroz):
[~stillalex] Two minor things:
1.) I think there's a [minor
typo|https://github.com/apache/cassandra/compare/trunk...stillalex:CASSANDRA-14888#diff-8f3132f0fa1e03f77fd29bc9b8163fe3R65]
in {{KeyspaceMetricsTest#testMetricsCleanupOnDrop()}}.
2.) You probably don't need the JavaDoc comment for
{{ReleasableMetric#release()}}, unless there's something more substantial we
need to say there.
> 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-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=17132545#comment-17132545
]
Caleb Rackliffe edited comment on CASSANDRA-14888 at 6/10/20, 6:17 PM:
---
[~stillalex] Two minor things:
1.) I think there's a [minor
typo|https://github.com/apache/cassandra/compare/trunk...stillalex:CASSANDRA-14888#diff-8f3132f0fa1e03f77fd29bc9b8163fe3R65]
in {{KeyspaceMetricsTest#testMetricsCleanupOnDrop()}}.
2.) You probably don't need the JavaDoc comment for
{{ReleasableMetric#release()}}, unless there's something more substantial we
need to say there.
was (Author: maedhroz):
[~stillalex] I think there's a [minor
typo|https://github.com/apache/cassandra/compare/trunk...stillalex:CASSANDRA-14888#diff-8f3132f0fa1e03f77fd29bc9b8163fe3R65]
in {{KeyspaceMetricsTest#testMetricsCleanupOnDrop()}}, but otherwise things
look good so far. (One other minor nit...you probably don't need the JavaDoc
comment for {{ReleasableMetric#release()}}, unless there's something more
substantial we need to say there.)
> 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] [Commented] (CASSANDRA-15822) DOC - Improve C* configuration docs
[ https://issues.apache.org/jira/browse/CASSANDRA-15822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132585#comment-17132585 ] Lorina Poland commented on CASSANDRA-15822: --- (y) Thanks! > DOC - Improve C* configuration docs > --- > > Key: CASSANDRA-15822 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15822 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 4.0-alpha5 > > > Two sections, Getting started > Configuring and Configuration, could use > improvement. > Adding information about some of the other config files besides > cassandra.yaml is one key goal. > > At the risk of contaminating one ticket with another project, I started > creating a separate glossary file, so that key terms in configuration can be > linked to a glossary that describes terms. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15870) When 3.0 reads 2.1 data with a regular column set it expects the cellName to contain a element and fails if not true
[
https://issues.apache.org/jira/browse/CASSANDRA-15870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132551#comment-17132551
]
David Capwell commented on CASSANDRA-15870:
---
I have a patch for 3.0, will need to make sure its good with 3.11 as well.
The patch detects this case and allows operators to choose 1 of 3 behaviors
1) assert error - matches 3.0 behavior to reject; this is the default as its
the safest
2) attempt to migrate - if the data is a frozen collection, try migrating it to
a multi-cell collection
3) log and drop - this matches 2.1 behavior
> When 3.0 reads 2.1 data with a regular column set it expects the
> cellName to contain a element and fails if not true
> --
>
> Key: CASSANDRA-15870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15870
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Local/SSTable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
>
> {code}
> java.lang.AssertionError
> at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:48)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1461)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1380)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:549)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:523)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:336)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.readStaticRow(SSTableSimpleIterator.java:133)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.(SSTableIdentityIterator.java:59)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:364)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:132)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:123)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:207)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:160)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:174)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:93)
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:240)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:191)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:89)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:345)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 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:83)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This exception is similar to other JIRA such as CASSANDRA-14113 but under
> root causing both exceptions, they only share the same symptom and not the
> same root cause; hence a new JIRA.
> This was found when a frozen collection was found when a multi-cell
> collection was expected. When this happened LegacyCellName#collectionElement
> comes back as null which eventually gets asserted against in BufferCell
> (complex cell needs a path).
--
This message was
[cassandra-website] branch asf-site updated (4db8d07 -> 06ef521)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard 4db8d07 generate docs for eac91582
add 06e2ad8 Update README.md for new simpler development cycle. Remove
content/ folder as it is now served from asf-staging and asf-site branches.
add 1ad5e74 Add a dummy file to keep the content directory in git, as it
needs to exist to be mounted as a volume in the docker run.
add 06ef521 generate docs for 1ad5e747
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (4db8d07)
\
N -- N -- N refs/heads/asf-site (06ef521)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
.asf.yaml | 2 +-
README.md | 32 +-
content/doc/3.11.7/objects.inv | Bin 8167 -> 8123 bytes
content/doc/3.11.7/searchindex.js | 2 +-
content/doc/3.11.7/tools/nodetool/bootstrap.html | 5 +-
.../3.11.7/tools/nodetool/enablefullquerylog.html | 7 +-
content/doc/3.11.7/tools/nodetool/getreplicas.html | 261 --
.../doc/3.11.7/tools/nodetool/handoffwindow.html | 251 --
content/doc/3.11.7/tools/nodetool/nodetool.html| 7 +-
content/doc/3.11/objects.inv | Bin 8167 -> 8123 bytes
content/doc/3.11/searchindex.js| 2 +-
content/doc/3.11/tools/nodetool/bootstrap.html | 5 +-
.../3.11/tools/nodetool/enablefullquerylog.html| 7 +-
content/doc/3.11/tools/nodetool/getreplicas.html | 261 --
content/doc/3.11/tools/nodetool/handoffwindow.html | 251 --
content/doc/3.11/tools/nodetool/nodetool.html | 7 +-
.../{index.html => cass_cl_archive_file.html} | 65 +++-
.../4.0-alpha5/configuration/cass_env_sh_file.html | 376 +
.../{index.html => cass_jvm_options_file.html} | 36 +-
.../configuration/cass_logback_xml_file.html | 373
.../cass_rackdc_file.html} | 134
.../{index.html => cass_topo_file.html}| 71 +++-
...sandra_config_file.html => cass_yaml_file.html} | 34 +-
.../configuration/cassandra_config_file.html | 200 +--
content/doc/4.0-alpha5/configuration/index.html| 20 +-
content/doc/4.0-alpha5/development/ci.html | 5 +
.../4.0-alpha5/getting_started/configuring.html| 61 ++--
.../{configuration/index.html => glossary.html}| 116 ---
content/doc/4.0-alpha5/new/auditlogging.html | 22 +-
.../doc/4.0-alpha5/new/transientreplication.html | 4 +-
content/doc/4.0-alpha5/objects.inv | Bin 9472 -> 9641 bytes
content/doc/4.0-alpha5/operating/index.html| 4 +-
content/doc/4.0-alpha5/searchindex.js | 2 +-
content/doc/4.0-alpha5/tools/cassandra_stress.html | 2 +
.../doc/4.0-alpha5/tools/nodetool/bootstrap.html | 5 +-
.../tools/nodetool/enablefullquerylog.html | 7 +-
.../doc/4.0-alpha5/tools/nodetool/getreplicas.html | 263 --
.../4.0-alpha5/tools/nodetool/handoffwindow.html | 253 --
.../doc/4.0-alpha5/tools/nodetool/nodetool.html| 7 +-
.../{index.html => cass_cl_archive_file.html} | 65 +++-
.../doc/latest/configuration/cass_env_sh_file.html | 376 +
.../{index.html => cass_jvm_options_file.html} | 36 +-
.../configuration/cass_logback_xml_file.html | 373
.../cass_rackdc_file.html} | 134
.../{index.html => cass_topo_file.html}| 71 +++-
...sandra_config_file.html => cass_yaml_file.html} | 34 +-
.../configuration/cassandra_config_file.html | 200 +--
content/doc/latest/configuration/index.html| 20 +-
content/doc/latest/development/ci.html | 5 +
.../doc/latest/getting_started/configuring.html| 61 ++--
.../{configuration/index.html => glossary.html}| 116 ---
content/doc/latest/new/auditlogging.html | 22 +-
content/doc/latest/new/transientreplication.html | 4 +-
content/doc/latest/objects.inv | Bin 9472 -> 9641 bytes
content/doc/latest/operating/index.html| 4 +-
content/doc/latest/searchindex.js |
[jira] [Updated] (CASSANDRA-15870) When 3.0 reads 2.1 data with a regular column set it expects the cellName to contain a element and fails if not true
[
https://issues.apache.org/jira/browse/CASSANDRA-15870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15870:
--
Bug Category: Parent values: Availability(12983)Level 1 values: Response
Crash(12991)
Complexity: Normal
Discovered By: Workload Replay
Severity: Normal
Assignee: David Capwell
Status: Open (was: Triage Needed)
> When 3.0 reads 2.1 data with a regular column set it expects the
> cellName to contain a element and fails if not true
> --
>
> Key: CASSANDRA-15870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15870
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Local/SSTable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
>
> {code}
> java.lang.AssertionError
> at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:48)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1461)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1380)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:549)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:523)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:336)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.readStaticRow(SSTableSimpleIterator.java:133)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.(SSTableIdentityIterator.java:59)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:364)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:132)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:123)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:207)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:160)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:174)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:93)
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:240)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:191)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:89)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:345)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 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:83)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This exception is similar to other JIRA such as CASSANDRA-14113 but under
> root causing both exceptions, they only share the same symptom and not the
> same root cause; hence a new JIRA.
> This was found when a frozen collection was found when a multi-cell
> collection was expected. When this happened LegacyCellName#collectionElement
> comes back as null which eventually gets asserted against in BufferCell
> (complex cell needs a path).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15870) When 3.0 reads 2.1 data with a regular column set it expects the cellName to contain a element and fails if not true
[
https://issues.apache.org/jira/browse/CASSANDRA-15870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132560#comment-17132560
]
David Capwell commented on CASSANDRA-15870:
---
I tested and couldn't replicate this via thrift or CQL, but it is easy to
reproduce by asking Cassandra to load a sstable. Tools which generate sstables
externally can cause this mismatch, but can also happen when migrating the data
from one cluster to another; assuming the source schema was frozen and the
destination was multi-cell (which is how the test was written).
> When 3.0 reads 2.1 data with a regular column set it expects the
> cellName to contain a element and fails if not true
> --
>
> Key: CASSANDRA-15870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15870
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Local/SSTable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
>
> {code}
> java.lang.AssertionError
> at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:48)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1461)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1380)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:549)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:523)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:336)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.readStaticRow(SSTableSimpleIterator.java:133)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.(SSTableIdentityIterator.java:59)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:364)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:132)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:123)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:207)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:160)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:174)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:93)
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:240)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:191)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:89)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:345)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 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:83)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This exception is similar to other JIRA such as CASSANDRA-14113 but under
> root causing both exceptions, they only share the same symptom and not the
> same root cause; hence a new JIRA.
> This was found when a frozen collection was found when a multi-cell
> collection was expected. When this happened LegacyCellName#collectionElement
> comes back as null which eventually gets asserted against in BufferCell
> (complex cell needs a path).
--
This message was sent by
[jira] [Commented] (CASSANDRA-15822) DOC - Improve C* configuration docs
[
https://issues.apache.org/jira/browse/CASSANDRA-15822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132552#comment-17132552
]
Michael Semb Wever commented on CASSANDRA-15822:
Merge to the {{asf-site}} branch. Can you please verify everything is ok on
https://cassandra.apache.org [~polandll] ?
> DOC - Improve C* configuration docs
> ---
>
> Key: CASSANDRA-15822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15822
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Lorina Poland
>Assignee: Lorina Poland
>Priority: Normal
> Fix For: 4.0-alpha5
>
>
> Two sections, Getting started > Configuring and Configuration, could use
> improvement.
> Adding information about some of the other config files besides
> cassandra.yaml is one key goal.
>
> At the risk of contaminating one ticket with another project, I started
> creating a separate glossary file, so that key terms in configuration can be
> linked to a glossary that describes terms.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15822) DOC - Improve C* configuration docs
[
https://issues.apache.org/jira/browse/CASSANDRA-15822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132552#comment-17132552
]
Michael Semb Wever edited comment on CASSANDRA-15822 at 6/10/20, 5:46 PM:
--
Merged to the {{asf-site}} branch. Can you please verify everything is ok on
https://cassandra.apache.org [~polandll] ?
was (Author: michaelsembwever):
Merge to the {{asf-site}} branch. Can you please verify everything is ok on
https://cassandra.apache.org [~polandll] ?
> DOC - Improve C* configuration docs
> ---
>
> Key: CASSANDRA-15822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15822
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Lorina Poland
>Assignee: Lorina Poland
>Priority: Normal
> Fix For: 4.0-alpha5
>
>
> Two sections, Getting started > Configuring and Configuration, could use
> improvement.
> Adding information about some of the other config files besides
> cassandra.yaml is one key goal.
>
> At the risk of contaminating one ticket with another project, I started
> creating a separate glossary file, so that key terms in configuration can be
> linked to a glossary that describes terms.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-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=17132545#comment-17132545
]
Caleb Rackliffe commented on CASSANDRA-14888:
-
[~stillalex] I think there's a [minor
typo|https://github.com/apache/cassandra/compare/trunk...stillalex:CASSANDRA-14888#diff-8f3132f0fa1e03f77fd29bc9b8163fe3R65]
in {{KeyspaceMetricsTest#testMetricsCleanupOnDrop()}}, but otherwise things
look good so far. (One other minor nit...you probably don't need the JavaDoc
comment for {{ReleasableMetric#release()}}, unless there's something more
substantial we need to say there.)
> 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] [Created] (CASSANDRA-15870) When 3.0 reads 2.1 data with a regular column set it expects the cellName to contain a element and fails if not true
David Capwell created CASSANDRA-15870:
-
Summary: When 3.0 reads 2.1 data with a regular column set
it expects the cellName to contain a element and fails if not true
Key: CASSANDRA-15870
URL: https://issues.apache.org/jira/browse/CASSANDRA-15870
Project: Cassandra
Issue Type: Bug
Components: Cluster/Schema, Local/SSTable
Reporter: David Capwell
{code}
java.lang.AssertionError
at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:48)
at
org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1461)
at
org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1380)
at
org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:549)
at
org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:523)
at
org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:336)
at
org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.readStaticRow(SSTableSimpleIterator.java:133)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.(SSTableIdentityIterator.java:59)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:364)
at
org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
at
org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:132)
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:123)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:207)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:160)
at
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:174)
at
org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:93)
at
org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:240)
at
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:191)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:89)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
at
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:345)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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:83)
at java.lang.Thread.run(Thread.java:748)
{code}
This exception is similar to other JIRA such as CASSANDRA-14113 but under root
causing both exceptions, they only share the same symptom and not the same root
cause; hence a new JIRA.
This was found when a frozen collection was found when a multi-cell collection
was expected. When this happened LegacyCellName#collectionElement comes back
as null which eventually gets asserted against in BufferCell (complex cell
needs a path).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15822) DOC - Improve C* configuration docs
[ https://issues.apache.org/jira/browse/CASSANDRA-15822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130953#comment-17130953 ] Lorina Poland commented on CASSANDRA-15822: --- I've reviewed and tested [https://cassandra.staged.apache.org|https://cassandra.staged.apache.org/], so it's ready to merge, [~mck] > DOC - Improve C* configuration docs > --- > > Key: CASSANDRA-15822 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15822 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 4.0-alpha5 > > > Two sections, Getting started > Configuring and Configuration, could use > improvement. > Adding information about some of the other config files besides > cassandra.yaml is one key goal. > > At the risk of contaminating one ticket with another project, I started > creating a separate glossary file, so that key terms in configuration can be > linked to a glossary that describes terms. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-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=17130941#comment-17130941
]
Josh McKenzie commented on CASSANDRA-13994:
---
{quote}Until we decide on whether or not to defer this ticket to a future
release
{quote}
Time to hit up the ML [~e.dimitrova]?
> 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-alpha
>
>
> 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] [Issue Comment Deleted] (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:all-tabpanel
]
Josh McKenzie updated CASSANDRA-13994:
--
Comment: was deleted
(was: {quote}Until we decide on whether or not to defer this ticket to a future
release
{quote}
Time to hit up the ML [~e.dimitrova]?)
> 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-alpha
>
>
> 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:
-
Source Control Link:
https://github.com/apache/cassandra/commit/6317fefec80c4c35aa588a6b610c25630df656f6
(was:
https://github.com/apache/cassandra/commit/595a4528dc54bc75076acf1b17f62ce9996f863c)
Status: Resolved (was: Ready to Commit)
You're right, somehow I grabbed the commit and not the PR, my mistake. Fixed.
> 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 20m
> 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:
-
Status: Patch Available (was: Open)
> 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 20m
> 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:
-
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-alpha5
>
> Time Spent: 1h 20m
> 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-alpha5
>
> Time Spent: 1h 20m
> 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 (66cd032 -> 6dad660)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 66cd032 Revert "Make sure topology events are sent to clients when using a single network interface" new 6317fef Fix missing topology events when running multiple nodes on the same network interface new 5814130 CASSANDRA-15677 Add the ability to run dTests on the same interface. new 6dad660 CASSANDRA-15677 Add shutdown to JMX thread pool to avoid metaspace errors associated with thread leaks. There are still other thread shutdown issues remaining, but this seems to be the most serious one. 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: CHANGES.txt| 1 + build.xml | 3 + src/java/org/apache/cassandra/transport/Event.java | 4 +- .../org/apache/cassandra/transport/Server.java | 4 +- .../org/apache/cassandra/utils/FBUtilities.java| 31 ++- .../utils/progress/jmx/JMXBroadcastExecutor.java | 6 +- .../distributed/impl/AbstractCluster.java | 63 -- .../distributed/impl/INodeProvisionStrategy.java | 99 ++ .../cassandra/distributed/impl/Instance.java | 4 + .../cassandra/distributed/impl/InstanceConfig.java | 31 --- .../distributed/test/NodeDecommissionTest.java | 57 + 11 files changed, 275 insertions(+), 28 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/impl/INodeProvisionStrategy.java create mode 100644 test/distributed/org/apache/cassandra/distributed/test/NodeDecommissionTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 03/03: CASSANDRA-15677 Add shutdown to JMX thread pool to avoid metaspace errors associated with thread leaks. There are still other thread shutdown issues remaining, but this seems to be
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
commit 6dad6600393f99c3d413dffefa1bf7f6ee12b79c
Author: bryn
AuthorDate: Mon Jun 8 11:02:42 2020 +0100
CASSANDRA-15677 Add shutdown to JMX thread pool to avoid metaspace errors
associated with thread leaks. There are still other thread shutdown issues
remaining, but this seems to be the most serious one.
---
.../cassandra/utils/progress/jmx/JMXBroadcastExecutor.java | 6 --
.../apache/cassandra/distributed/impl/AbstractCluster.java | 12
.../org/apache/cassandra/distributed/impl/Instance.java | 4
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git
a/src/java/org/apache/cassandra/utils/progress/jmx/JMXBroadcastExecutor.java
b/src/java/org/apache/cassandra/utils/progress/jmx/JMXBroadcastExecutor.java
index f545f0f..f28609c 100644
--- a/src/java/org/apache/cassandra/utils/progress/jmx/JMXBroadcastExecutor.java
+++ b/src/java/org/apache/cassandra/utils/progress/jmx/JMXBroadcastExecutor.java
@@ -18,9 +18,11 @@
package org.apache.cassandra.utils.progress.jmx;
-import java.util.concurrent.Executor;
+import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
+import org.apache.cassandra.concurrent.NamedThreadFactory;
+
/**
* Holds dedicated executor for JMX event handling. Events will internally
queued by ArrayNotificationBuffer,
* synchronized by an exclusive write lock, which makes a shared single thread
executor desirable.
@@ -30,6 +32,6 @@ public final class JMXBroadcastExecutor
private JMXBroadcastExecutor() { }
-public final static Executor executor =
Executors.newSingleThreadExecutor();
+public final static ExecutorService executor =
Executors.newSingleThreadExecutor(new NamedThreadFactory("JMX"));
}
diff --git
a/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
b/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
index a164e3b..0c8421a 100644
---
a/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
+++
b/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
@@ -667,9 +667,21 @@ public abstract class AbstractCluster
implements ICluster threadSet = Thread.getAllStackTraces().keySet();
+threadSet.stream().filter(t->t.getContextClassLoader() instanceof
InstanceClassLoader).forEach(t->{
+t.setContextClassLoader(null);
+throw new RuntimeException("Unterminated thread detected " +
t.getName() + " in group " + t.getThreadGroup().getName());
+});
+}
+
// We do not want this check to run every time until we fix problems with
tread stops
private void withThreadLeakCheck(List> futures)
{
diff --git
a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
index c3e9982..989bf6e 100644
--- a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
+++ b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
@@ -108,6 +108,7 @@ import org.apache.cassandra.utils.JVMStabilityInspector;
import org.apache.cassandra.utils.Throwables;
import org.apache.cassandra.utils.concurrent.Ref;
import org.apache.cassandra.utils.memory.BufferPool;
+import org.apache.cassandra.utils.progress.jmx.JMXBroadcastExecutor;
import static java.util.concurrent.TimeUnit.MINUTES;
import static org.apache.cassandra.distributed.api.Feature.GOSSIP;
@@ -566,6 +567,9 @@ public class Instance extends IsolatedExecutor implements
IInvokableInstance
() -> Stage.shutdownAndWait(1L, MINUTES),
() ->
SharedExecutorPool.SHARED.shutdownAndWait(1L, MINUTES)
);
+error = parallelRun(error, executor,
+() ->
shutdownAndWait(Collections.singletonList(JMXBroadcastExecutor.executor))
+);
Throwables.maybeFail(error);
}).apply(isolatedExecutor);
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/03: Fix missing topology events when running multiple nodes on the same 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
commit 6317fefec80c4c35aa588a6b610c25630df656f6
Author: Alan Boudreault
AuthorDate: Mon Mar 30 14:27:55 2020 -0400
Fix missing topology events when running multiple nodes on the same network
interface
Patch by Alan Boudrealt and Bryn Cook, 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
[cassandra] 02/03: CASSANDRA-15677 Add the ability to run dTests on the same 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
commit 58141308ba661db641d405ae415b8f3e1c0ec11c
Author: bryn
AuthorDate: Wed May 20 16:16:33 2020 +0100
CASSANDRA-15677 Add the ability to run dTests on the same interface.
---
.../org/apache/cassandra/utils/FBUtilities.java| 31 ++-
.../distributed/impl/AbstractCluster.java | 51 +--
.../distributed/impl/INodeProvisionStrategy.java | 99 ++
.../cassandra/distributed/impl/InstanceConfig.java | 31 ---
4 files changed, 190 insertions(+), 22 deletions(-)
diff --git a/src/java/org/apache/cassandra/utils/FBUtilities.java
b/src/java/org/apache/cassandra/utils/FBUtilities.java
index 367138a..f82df04 100644
--- a/src/java/org/apache/cassandra/utils/FBUtilities.java
+++ b/src/java/org/apache/cassandra/utils/FBUtilities.java
@@ -148,7 +148,15 @@ public class FBUtilities
{
if (localInetAddressAndPort == null)
{
-localInetAddressAndPort =
InetAddressAndPort.getByAddress(getJustLocalAddress());
+if(DatabaseDescriptor.getRawConfig() == null)
+{
+localInetAddressAndPort =
InetAddressAndPort.getByAddress(getJustLocalAddress());
+}
+else
+{
+localInetAddressAndPort =
InetAddressAndPort.getByAddressOverrideDefaults(getJustLocalAddress(),
+
DatabaseDescriptor.getStoragePort());
+}
}
return localInetAddressAndPort;
}
@@ -175,7 +183,15 @@ public class FBUtilities
{
if (broadcastInetAddressAndPort == null)
{
-broadcastInetAddressAndPort =
InetAddressAndPort.getByAddress(getJustBroadcastAddress());
+if(DatabaseDescriptor.getRawConfig() == null)
+{
+broadcastInetAddressAndPort =
InetAddressAndPort.getByAddress(getJustBroadcastAddress());
+}
+else
+{
+broadcastInetAddressAndPort =
InetAddressAndPort.getByAddressOverrideDefaults(getJustBroadcastAddress(),
+
DatabaseDescriptor.getStoragePort());
+}
}
return broadcastInetAddressAndPort;
}
@@ -218,8 +234,15 @@ public class FBUtilities
public static InetAddressAndPort getBroadcastNativeAddressAndPort()
{
if (broadcastNativeAddressAndPort == null)
-broadcastNativeAddressAndPort =
InetAddressAndPort.getByAddressOverrideDefaults(getJustBroadcastNativeAddress(),
-
DatabaseDescriptor.getNativeTransportPort());
+if(DatabaseDescriptor.getRawConfig() == null)
+{
+broadcastNativeAddressAndPort =
InetAddressAndPort.getByAddress(getJustBroadcastNativeAddress());
+}
+else
+{
+broadcastNativeAddressAndPort =
InetAddressAndPort.getByAddressOverrideDefaults(getJustBroadcastNativeAddress(),
+
DatabaseDescriptor.getNativeTransportPort());
+}
return broadcastNativeAddressAndPort;
}
diff --git
a/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
b/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
index 5a7590c..a164e3b 100644
---
a/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
+++
b/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
@@ -32,6 +32,7 @@ import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Consumer;
import java.util.stream.Collectors;
+import java.util.stream.IntStream;
import java.util.stream.Stream;
import com.google.common.collect.Sets;
@@ -56,7 +57,6 @@ import org.apache.cassandra.distributed.api.IMessageFilters;
import org.apache.cassandra.distributed.api.IUpgradeableInstance;
import org.apache.cassandra.distributed.api.NodeToolResult;
import org.apache.cassandra.distributed.api.TokenSupplier;
-import org.apache.cassandra.distributed.shared.AbstractBuilder;
import org.apache.cassandra.distributed.shared.InstanceClassLoader;
import org.apache.cassandra.distributed.shared.MessageFilters;
import org.apache.cassandra.distributed.shared.NetworkTopology;
@@ -66,6 +66,8 @@ import org.apache.cassandra.net.Verb;
import org.apache.cassandra.utils.FBUtilities;
import org.apache.cassandra.utils.concurrent.SimpleCondition;
+import static
org.apache.cassandra.distributed.shared.NetworkTopology.addressAndPort;
+
/**
* AbstractCluster
[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=17130770#comment-17130770
]
Ekaterina Dimitrova commented on CASSANDRA-13994:
-
[~jwest], corrected, thank you!
> 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-alpha
>
>
> 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-13994) Remove COMPACT STORAGE internals before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-13994:
Fix Version/s: (was: 4.0-rc)
4.0-alpha
> 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-alpha
>
>
> 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-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:
-
Resolution: Duplicate
Status: Resolved (was: Open)
Sorry to mark the older ticket as a duplicate of the newer - it just matches
the commit history better.
> 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
[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: Open (was: Patch Available)
> 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
> 2018-10-25T13:12:58.100+0200 [ReadStage-1]
[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=17130743#comment-17130743
]
Jordan West commented on CASSANDRA-13994:
-
Until we decide on whether or not to defer this ticket to a future release, can
we mark it {{4.0-alpha}} if it changes user facing interfaces and {{4.0-beta}}
otherwise? This is a large ticket and {{4.0-rc}} isn't the appropriate target
completion stage in the release cycle.
> 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-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:all-tabpanel ] Jordan West updated CASSANDRA-15833: Fix Version/s: (was: 4.0-beta) 4.0-alpha > 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-alpha > > 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-15792) test_speculative_data_request - read_repair_test.TestSpeculativeReadRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-15792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianluca Righetto updated CASSANDRA-15792: -- Status: In Progress (was: Patch Available) > test_speculative_data_request - read_repair_test.TestSpeculativeReadRepair > -- > > Key: CASSANDRA-15792 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15792 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-beta > > > Failing on the latest trunk here: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/127/workflows/dfba669d-4a5c-4553-b6a2-85647d0d8d2b/jobs/668/tests > Failing once in 30 times as per Jenkins: > https://jenkins-cm4.apache.org/job/Cassandra-trunk-dtest/69/testReport/dtest.read_repair_test/TestSpeculativeReadRepair/test_speculative_data_request/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15792) test_speculative_data_request - read_repair_test.TestSpeculativeReadRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-15792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130730#comment-17130730 ] Gianluca Righetto commented on CASSANDRA-15792: --- [~jmckenzie] I did add some comments trying to clarify the issue: [https://github.com/grighetto/cassandra-dtest/pull/1/files#diff-60812631a43b8e1f0c9fb53d9f7487ebR530] [https://github.com/grighetto/cassandra-dtest/pull/1/files#diff-60812631a43b8e1f0c9fb53d9f7487ebR816] But I had an idea to make this deterministic, which is using byteman to check if the coordinator node got back a response from node 3 within the specified timeout, if so, we can accept the speculative write. I'll move this back to in progress real quick to implement this solution today. This doesn't change the scope though, still for 4.0-beta. > test_speculative_data_request - read_repair_test.TestSpeculativeReadRepair > -- > > Key: CASSANDRA-15792 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15792 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-beta > > > Failing on the latest trunk here: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/127/workflows/dfba669d-4a5c-4553-b6a2-85647d0d8d2b/jobs/668/tests > Failing once in 30 times as per Jenkins: > https://jenkins-cm4.apache.org/job/Cassandra-trunk-dtest/69/testReport/dtest.read_repair_test/TestSpeculativeReadRepair/test_speculative_data_request/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [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/10/20, 2:19 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 - test_replace_nonexistent_node was (Author: bereng): 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 > 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: 3.0.x, 3.11.x, 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > 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=17130721#comment-17130721
]
Sylvain Lebresne commented on CASSANDRA-13994:
--
{quote}please don't remove it this far into the alphas.
{quote}
{quote}removing protocol V3 at this point would delay the ability of many to
upgrade to Cassandra 4.0
{quote}
Fair enough, I don't mind keeping it more than that.
Though, fwiw, I do am a bit surprised by your points. Protocol v4 was added
back in 2.2.0, and was a small enough iteration over V3 that the main drivers
supported it right away. And C* 4.0 does not support upgrading from 2.X
directly at all (in fact, reminder that you need to upgrade from at least
3.0.13 or 3.11.0 according to the NEWS file). Requiring that users have
upgraded their driver version in the last 5 years didn't felt, a priori, a big
constraining ask to me. But I trust your "lots of people" and "of many" are
backed by data, so again, happy to keep V3, I just admit surprise. TIL.
> 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] [Comment Edited] (CASSANDRA-15852) Handle errors in StreamSession#prepare
[
https://issues.apache.org/jira/browse/CASSANDRA-15852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130633#comment-17130633
]
Marcus Eriksson edited comment on CASSANDRA-15852 at 6/10/20, 1:35 PM:
---
https://github.com/krummas/cassandra/commits/marcuse/15852 - on top of
CASSANDRA-15851 to be able to test
[unit tests|https://circleci.com/gh/krummas/cassandra/3389]
[jvm dtests|https://circleci.com/gh/krummas/cassandra/3388]
dtests [vnodes|https://circleci.com/gh/krummas/cassandra/3390],
[novnodes|https://circleci.com/gh/krummas/cassandra/3391]
was (Author: krummas):
https://github.com/krummas/cassandra/commits/marcuse/15852 - on top of
CASSANDRA-15851 to be able to test
I'll post cci run links once they are done
> Handle errors in StreamSession#prepare
> --
>
> Key: CASSANDRA-15852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15852
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Since CASSANDRA-12229 we don't handle errors in {{StreamSession#prepare}} -
> this makes a stream initiator hang forever if an error is thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15869) MemoryOutputStream overflow on large bloom filter
[
https://issues.apache.org/jira/browse/CASSANDRA-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130671#comment-17130671
]
ZhaoYang commented on CASSANDRA-15869:
--
btw, this is failing for 500GB sstable...
> MemoryOutputStream overflow on large bloom filter
> -
>
> Key: CASSANDRA-15869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15869
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to
> reconstruct BF Memory without re-ordering bytes, see
> {{OffsetBitSet#deserialize}}. But {{MemoryOutputStream}} use {{INT}} to track
> position and will overflow when BF size exceeds 2GB (eg. 500gb sstable).
> {code:java|title=stacktrace}
> error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
> -- StackTrace --
> java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
> 4588588016
> at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
> at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
> at
> org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-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: 3.11.x 3.0.x > 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: 3.0.x, 3.11.x, 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Updated] (CASSANDRA-15852) Handle errors in StreamSession#prepare
[
https://issues.apache.org/jira/browse/CASSANDRA-15852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15852:
Test and Documentation Plan: new test + cci runs
Status: Patch Available (was: Open)
https://github.com/krummas/cassandra/commits/marcuse/15852 - on top of
CASSANDRA-15851 to be able to test
I'll post cci run links once they are done
> Handle errors in StreamSession#prepare
> --
>
> Key: CASSANDRA-15852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15852
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Since CASSANDRA-12229 we don't handle errors in {{StreamSession#prepare}} -
> this makes a stream initiator hang forever if an error is thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15851) Add bytebuddy support for in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-15851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15851: Reviewers: Alex Petrov > Add bytebuddy support for in-jvm dtests > --- > > Key: CASSANDRA-15851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15851 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Labels: pull-request-available > > Old python dtests support byteman, but that is quite horrible to work with, > [bytebuddy|https://bytebuddy.net/#/] is much better, so we should add support > for that in the in-jvm dtests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15851) Add bytebuddy support for in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-15851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15851: Test and Documentation Plan: circle ci runs Status: Patch Available (was: Open) dtest-api PR (already merged): https://github.com/apache/cassandra-in-jvm-dtest-api/pull/11 - this gives us access to the class loader before any classes have been loaded. So far we only released a snapshot. branch: https://github.com/krummas/cassandra/commits/marcuse/15851 - this includes changes to download snapshots from repository.apache.org which we probably should drop once we have dtest-api 0.0.3 released > Add bytebuddy support for in-jvm dtests > --- > > Key: CASSANDRA-15851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15851 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Labels: pull-request-available > > Old python dtests support byteman, but that is quite horrible to work with, > [bytebuddy|https://bytebuddy.net/#/] is much better, so we should add support > for that in the in-jvm dtests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15665) StreamManager should clearly differentiate between "initiator" and "receiver" sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-15665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130550#comment-17130550
]
ZhaoYang commented on CASSANDRA-15665:
--
[~sbtourist] [~blerer] do you mind having a look?
> StreamManager should clearly differentiate between "initiator" and "receiver"
> sessions
> --
>
> Key: CASSANDRA-15665
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15665
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamManager}} does currently a suboptimal job in differentiating between
> stream sessions (in form of {{StreamResultFuture}}) which have been either
> initiated or "received", for the following reasons:
> 1) Naming is IMO confusing: a "receiver" session could actually both send and
> receive files, so technically an initiator is also a receiver.
> 2) {{StreamManager#findSession()}} assumes we should first looking into
> "initiator" sessions, then into "receiver" ones: this is a dangerous
> assumptions, in particular for test environments where the same process could
> work as both an initiator and a receiver.
> I would recommend the following changes:
> 1) Rename "receiver" with "follower" everywhere the former is used.
> 2) Introduce a new flag into {{StreamMessageHeader}} to signal if the message
> comes from an initiator or follower session, in order to correctly
> differentiate and look for sessions in {{StreamManager}}.
> While my arguments above might seem trivial, I believe they will improve
> clarity and save from potential bugs/headaches at testing time, and doing
> such changes now that we're revamping streaming for 4.0 seems the right time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15855) Mark test_populate_mv_after_insert_wide_rows as flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-15855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-15855: -- Fix Version/s: 3.11.7 3.0.21 Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra-dtest/commit/fe9015475ab8383be042c32376bb8e122dc35734 Resolution: Fixed Status: Resolved (was: Ready to Commit) > 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: 3.0.21, 3.11.7, 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-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=17130524#comment-17130524 ] Andres de la Peña commented on CASSANDRA-15855: --- Committed to dtest master as [fe9015475ab8383be042c32376bb8e122dc35734|https://github.com/apache/cassandra-dtest/commit/fe9015475ab8383be042c32376bb8e122dc35734]. > 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-dtest] branch master updated: CASSANDRA-15855 Mark flaky until root cause is solved
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/master by this push:
new fe90154 CASSANDRA-15855 Mark flaky until root cause is solved
fe90154 is described below
commit fe9015475ab8383be042c32376bb8e122dc35734
Author: Bereng
AuthorDate: Wed Jun 10 12:10:22 2020 +0100
CASSANDRA-15855 Mark flaky until root cause is solved
---
materialized_views_test.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/materialized_views_test.py b/materialized_views_test.py
index 009ca16..f1092fc 100644
--- a/materialized_views_test.py
+++ b/materialized_views_test.py
@@ -330,6 +330,12 @@ class TestMaterializedViews(Tester):
for i in range(1000):
assert_one(session, "SELECT * FROM t_by_v WHERE v = {}".format(i),
[i, i])
+@pytest.mark.xfail(reason="Should be addressed with CASSANDRA-15845")
+@since('4.0')
+def test_populate_mv_after_insert_wide_rows_version40(self):
+self.test_populate_mv_after_insert_wide_rows()
+
+@since('3.0', max_version='3.X')
def test_populate_mv_after_insert_wide_rows(self):
"""Test that a view is OK when created with existing data with wide
rows"""
session = self.prepare(consistency_level=ConsistencyLevel.QUORUM)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12126) CAS Reads Inconsistencies
[ https://issues.apache.org/jira/browse/CASSANDRA-12126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130517#comment-17130517 ] Benedict Elliott Smith commented on CASSANDRA-12126: > I'd like to move this forward personally. Sure, go for it. > CAS Reads Inconsistencies > -- > > Key: CASSANDRA-12126 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12126 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions, Legacy/Coordination >Reporter: Sankalp Kohli >Assignee: Sylvain Lebresne >Priority: Normal > Labels: LWT, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > While looking at the CAS code in Cassandra, I found a potential issue with > CAS Reads. Here is how it can happen with RF=3 > 1) You issue a CAS Write and it fails in the propose phase. A machine replies > true to a propose and saves the commit in accepted filed. The other two > machines B and C does not get to the accept phase. > Current state is that machine A has this commit in paxos table as accepted > but not committed and B and C does not. > 2) Issue a CAS Read and it goes to only B and C. You wont be able to read the > value written in step 1. This step is as if nothing is inflight. > 3) Issue another CAS Read and it goes to A and B. Now we will discover that > there is something inflight from A and will propose and commit it with the > current ballot. Now we can read the value written in step 1 as part of this > CAS read. > If we skip step 3 and instead run step 4, we will never learn about value > written in step 1. > 4. Issue a CAS Write and it involves only B and C. This will succeed and > commit a different value than step 1. Step 1 value will never be seen again > and was never seen before. > If you read the Lamport “paxos made simple” paper and read section 2.3. It > talks about this issue which is how learners can find out if majority of the > acceptors have accepted the proposal. > In step 3, it is correct that we propose the value again since we dont know > if it was accepted by majority of acceptors. When we ask majority of > acceptors, and more than one acceptors but not majority has something in > flight, we have no way of knowing if it is accepted by majority of acceptors. > So this behavior is correct. > However we need to fix step 2, since it caused reads to not be linearizable > with respect to writes and other reads. In this case, we know that majority > of acceptors have no inflight commit which means we have majority that > nothing was accepted by majority. I think we should run a propose step here > with empty commit and that will cause write written in step 1 to not be > visible ever after. > With this fix, we will either see data written in step 1 on next serial read > or will never see it which is what we want. -- 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-15858) TestRepairDataSystemTable test_repair_parent_table and test_repair_table fail
[ https://issues.apache.org/jira/browse/CASSANDRA-15858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-15858: -- Fix Version/s: 3.11.7 3.0.21 Since Version: 4.0-alpha4 Source Control Link: https://github.com/apache/cassandra-dtest/commit/4c716b1c4f15eb7a3199fb9e30a1ccea6e444523 Resolution: Fixed Status: Resolved (was: Ready to Commit) > TestRepairDataSystemTable test_repair_parent_table and test_repair_table fail > - > > Key: CASSANDRA-15858 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15858 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 3.0.21, 3.11.7, 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > They fail > [consistently|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/] > and locally as well -- 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-15858) TestRepairDataSystemTable test_repair_parent_table and test_repair_table fail
[ https://issues.apache.org/jira/browse/CASSANDRA-15858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130503#comment-17130503 ] Andres de la Peña commented on CASSANDRA-15858: --- They look good to me too, committed to dtest master as [4c716b1c4f15eb7a3199fb9e30a1ccea6e444523|https://github.com/apache/cassandra-dtest/commit/4c716b1c4f15eb7a3199fb9e30a1ccea6e444523]. > TestRepairDataSystemTable test_repair_parent_table and test_repair_table fail > - > > Key: CASSANDRA-15858 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15858 > 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 > > They fail > [consistently|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/] > and locally as well -- 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-15858) TestRepairDataSystemTable test_repair_parent_table and test_repair_table fail
[ https://issues.apache.org/jira/browse/CASSANDRA-15858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-15858: -- Status: Ready to Commit (was: Review In Progress) > TestRepairDataSystemTable test_repair_parent_table and test_repair_table fail > - > > Key: CASSANDRA-15858 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15858 > 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 > > They fail > [consistently|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/] > and locally as well -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch master updated: CASSANDRA-15858 Fix repair failing tests
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git The following commit(s) were added to refs/heads/master by this push: new 4c716b1 CASSANDRA-15858 Fix repair failing tests 4c716b1 is described below commit 4c716b1c4f15eb7a3199fb9e30a1ccea6e444523 Author: Bereng AuthorDate: Wed Jun 10 11:46:24 2020 +0100 CASSANDRA-15858 Fix repair failing tests --- repair_tests/repair_test.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/repair_tests/repair_test.py b/repair_tests/repair_test.py index 83eed8d..2c0ca81 100644 --- a/repair_tests/repair_test.py +++ b/repair_tests/repair_test.py @@ -1274,7 +1274,8 @@ class TestRepairDataSystemTable(Tester): Prepares a cluster for tests of the repair history tables by starting a 5-node cluster, then inserting 5000 values with RF=3. """ - fixture_dtest_setup.cluster.populate(5).start(wait_for_binary_proto=True) +self.cluster = fixture_dtest_setup.cluster +self.cluster.populate(5).start(wait_for_binary_proto=True) self.node1 = self.cluster.nodelist()[0] self.session = fixture_dtest_setup.patient_cql_connection(self.node1) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch master updated: CASSANDRA-15851 - add instance initializer
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
The following commit(s) were added to refs/heads/master by this push:
new c2feaad CASSANDRA-15851 - add instance initializer
new ad54e22 Merge pull request #11 from krummas/marcuse/15851
c2feaad is described below
commit c2feaad0543f7872791c67cfd8d5b9672a0998db
Author: Marcus Eriksson
AuthorDate: Thu Jun 4 10:03:50 2020 +0200
CASSANDRA-15851 - add instance initializer
---
pom.xml | 2 +-
.../cassandra/distributed/shared/AbstractBuilder.java | 13 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/pom.xml b/pom.xml
index 62c90d8..0ba9add 100644
--- a/pom.xml
+++ b/pom.xml
@@ -27,7 +27,7 @@
4.0.0
org.apache.cassandra
dtest-api
-0.0.2-SNAPSHOT
+0.0.3-SNAPSHOT
In JVM Test API
In JVM Test API
diff --git
a/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
b/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
index cc341a3..d601cda 100644
--- a/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
+++ b/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
@@ -29,6 +29,7 @@ import java.nio.file.Files;
import java.util.HashMap;
import java.util.Map;
import java.util.Objects;
+import java.util.function.BiConsumer;
import java.util.function.Consumer;
import java.util.stream.Collectors;
import java.util.stream.IntStream;
@@ -52,6 +53,7 @@ public abstract class AbstractBuilder configUpdater;
private ClassLoader sharedClassLoader =
Thread.currentThread().getContextClassLoader();
private int broadcastPort = 7012;
+private BiConsumer instanceInitializer = (cl, id) ->
{};
public AbstractBuilder(Factory factory)
{
@@ -94,6 +96,11 @@ public abstract class AbstractBuilder getInstanceInitializer()
+{
+return instanceInitializer;
+}
+
public C start() throws IOException
{
C cluster = createWithoutStarting();
@@ -255,6 +262,12 @@ public abstract class AbstractBuilder
instanceInitializer)
+{
+this.instanceInitializer = instanceInitializer;
+return (B) this;
+}
+
static String dcName(int index)
{
return "datacenter" + index;
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15869) MemoryOutputStream overflow on large bloom filter
[
https://issues.apache.org/jira/browse/CASSANDRA-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15869:
-
Description:
Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to reconstruct
BF Memory without re-ordering bytes, see {{OffsetBitSet#deserialize}}. But
{{MemoryOutputStream}} use {{INT}} to track position and will overflow when BF
size exceeds 2GB (eg. 500gb sstable).
{code:java|title=stacktrace}
error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
-- StackTrace --
java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
4588588016
at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
at
org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
{code}
was:
Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to reconstruct
BF Memory without re-ordering bytes, see {{OffsetBitSet#deserialize}}. But
{{MemoryOutputStream}} use {{INT}} to track position and will overflow when BF
size exceeds 2GB.
{code:title=stacktrace}
error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
-- StackTrace --
java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
4588588016
at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
at
org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
{code}
> MemoryOutputStream overflow on large bloom filter
> -
>
> Key: CASSANDRA-15869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15869
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to
> reconstruct BF Memory without re-ordering bytes, see
> {{OffsetBitSet#deserialize}}. But {{MemoryOutputStream}} use {{INT}} to track
> position and will overflow when BF size exceeds 2GB (eg. 500gb sstable).
> {code:java|title=stacktrace}
> error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
> -- StackTrace --
> java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
> 4588588016
> at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
> at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
> at
> org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15869) MemoryOutputStream overflow on large bloom filter
[
https://issues.apache.org/jira/browse/CASSANDRA-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15869:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable
Corruption / Loss(12986)
Complexity: Normal
Discovered By: Performance Regression Test
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> MemoryOutputStream overflow on large bloom filter
> -
>
> Key: CASSANDRA-15869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15869
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to
> reconstruct BF Memory without re-ordering bytes, see
> {{OffsetBitSet#deserialize}}. But {{MemoryOutputStream}} use {{INT}} to track
> position and will overflow when BF size exceeds 2GB.
> {code:title=stacktrace}
> error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
> -- StackTrace --
> java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
> 4588588016
> at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
> at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
> at
> org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15869) MemoryOutputStream overflow on large bloom filter
ZhaoYang created CASSANDRA-15869:
Summary: MemoryOutputStream overflow on large bloom filter
Key: CASSANDRA-15869
URL: https://issues.apache.org/jira/browse/CASSANDRA-15869
Project: Cassandra
Issue Type: Bug
Components: Local/SSTable
Reporter: ZhaoYang
Assignee: ZhaoYang
Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to reconstruct
BF Memory without re-ordering bytes, see {{OffsetBitSet#deserialize}}. But
{{MemoryOutputStream}} use {{INT}} to track position and will overflow when BF
size exceeds 2GB.
{code:title=stacktrace}
error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
-- StackTrace --
java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size:
4588588016
at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
at
org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15851) Add bytebuddy support for in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-15851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-15851: --- Labels: pull-request-available (was: ) > Add bytebuddy support for in-jvm dtests > --- > > Key: CASSANDRA-15851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15851 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Labels: pull-request-available > > Old python dtests support byteman, but that is quite horrible to work with, > [bytebuddy|https://bytebuddy.net/#/] is much better, so we should add support > for that in the in-jvm dtests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (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=17130402#comment-17130402
]
Bryn Cooke edited comment on CASSANDRA-15677 at 6/10/20, 9:03 AM:
--
It's 0.0.2 on trunk, which has the changes needed.
It looks like only 65de93d4fe2b48565955ae7e49adbadf510ed3c5 was taken from the
PR?
3fe0b77b985d76e1456241e56b4b92a965926d72 is needed as well at minimum.
TIL that github PRs do not display ordered by commit and instead in
chronological order:
[https://help.github.com/en/github/committing-changes-to-your-project/why-are-my-commits-in-the-wrong-order]
My local git log looks like this:
{noformat}
commit 5356c267de3bb1306f52c05a8afbb01dafddf28e (HEAD -> CASSANDRA-15677,
origin/CASSANDRA-15677)
Author: bryn
Date: Mon Jun 8 11:02:42 2020 +0100CASSANDRA-15677 Add shutdown to JMX
thread pool to avoid metaspace errors associated with thread leaks.
There are still other thread shutdown issues remaining, but this seems to
be the most serious one.
commit 65de93d4fe2b48565955ae7e49adbadf510ed3c5
Author: Alan Boudreault
Date: Mon Mar 30 14:27:55 2020 -0400CASSANDRA-15677 Make sure topology
events are sent to clients when using a single network interface
commit 3fe0b77b985d76e1456241e56b4b92a965926d72
Author: bryn
Date: Wed May 20 16:16:33 2020 +0100CASSANDRA-15677 Add the ability to
run dTests on the same interface.
commit 7bbc97e5835b64c49fd418581f5a45429c1806b1
Merge: 69ea5ffdbc 04b0049831
Author: Alex Petrov
Date: Fri Jun 5 19:34:13 2020 +0200Merge branch 'cassandra-3.11' into
trunk
{noformat}
was (Author: bryncooke):
It's 0.0.2 on trunk, which has the changes needed.
It looks like only 65de93d4fe2b48565955ae7e49adbadf510ed3c5 was taken from the
PR?
3fe0b77b985d76e1456241e56b4b92a965926d72 is needed as well at minimum.
TIL that github PRs do not display ordered by commit and instead in
chronological order:
[https://help.github.com/en/github/committing-changes-to-your-project/why-are-my-commits-in-the-wrong-order]
My local git log looks like this:
{noformat}
commit 5356c267de3bb1306f52c05a8afbb01dafddf28e (HEAD -> CASSANDRA-15677,
origin/CASSANDRA-15677)
Author: bryn
Date: Mon Jun 8 11:02:42 2020 +0100CASSANDRA-15677 Add shutdown to JMX
thread pool to avoid metaspace errors associated with thread leaks.
There are still other thread shutdown issues remaining, but this seems to
be the most serious one.
commit 65de93d4fe2b48565955ae7e49adbadf510ed3c5
Author: Alan Boudreault
Date: Mon Mar 30 14:27:55 2020 -0400CASSANDRA-15677 Make sure topology
events are sent to clients when using a single network interface
commit 3fe0b77b985d76e1456241e56b4b92a965926d72
Author: bryn
Date: Wed May 20 16:16:33 2020 +0100CASSANDRA-15677 Add the ability to
run dTests on the same interface.
commit 7bbc97e5835b64c49fd418581f5a45429c1806b1
Merge: 69ea5ffdbc 04b0049831
Author: Alex Petrov
Date: Fri Jun 5 19:34:13 2020 +0200Merge branch 'cassandra-3.11' into
trunk
{noformat}
> 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 20m
> 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)
[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=17130402#comment-17130402
]
Bryn Cooke commented on CASSANDRA-15677:
It's 0.0.2 on trunk, which has the changes needed.
It looks like only 65de93d4fe2b48565955ae7e49adbadf510ed3c5 was taken from the
PR?
3fe0b77b985d76e1456241e56b4b92a965926d72 is needed as well at minimum.
TIL that github PRs do not display ordered by commit and instead in
chronological order:
[https://help.github.com/en/github/committing-changes-to-your-project/why-are-my-commits-in-the-wrong-order]
My local git log looks like this:
{noformat}
commit 5356c267de3bb1306f52c05a8afbb01dafddf28e (HEAD -> CASSANDRA-15677,
origin/CASSANDRA-15677)
Author: bryn
Date: Mon Jun 8 11:02:42 2020 +0100CASSANDRA-15677 Add shutdown to JMX
thread pool to avoid metaspace errors associated with thread leaks.
There are still other thread shutdown issues remaining, but this seems to
be the most serious one.
commit 65de93d4fe2b48565955ae7e49adbadf510ed3c5
Author: Alan Boudreault
Date: Mon Mar 30 14:27:55 2020 -0400CASSANDRA-15677 Make sure topology
events are sent to clients when using a single network interface
commit 3fe0b77b985d76e1456241e56b4b92a965926d72
Author: bryn
Date: Wed May 20 16:16:33 2020 +0100CASSANDRA-15677 Add the ability to
run dTests on the same interface.
commit 7bbc97e5835b64c49fd418581f5a45429c1806b1
Merge: 69ea5ffdbc 04b0049831
Author: Alex Petrov
Date: Fri Jun 5 19:34:13 2020 +0200Merge branch 'cassandra-3.11' into
trunk
{noformat}
> 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 20m
> 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-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=17130387#comment-17130387 ] ZhaoYang commented on CASSANDRA-15855: -- work for me. > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-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: - Status: Ready to Commit (was: Review In Progress) > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > 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-15858) TestRepairDataSystemTable test_repair_parent_table and test_repair_table fail
[ https://issues.apache.org/jira/browse/CASSANDRA-15858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130365#comment-17130365 ] Berenguer Blasi commented on CASSANDRA-15858: - The above lgtm [~adelapena] #collaborating > TestRepairDataSystemTable test_repair_parent_table and test_repair_table fail > - > > Key: CASSANDRA-15858 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15858 > 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 > > They fail > [consistently|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/] > and locally as well -- 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=17130359#comment-17130359 ] Berenguer Blasi commented on CASSANDRA-15855: - [~jasonstack] it seems pretty stable both on [3.0|https://ci-cassandra.apache.org/job/Cassandra-3.0/38/testReport/dtest-novnode.materialized_views_test/TestMaterializedViews/test_populate_mv_after_insert_wide_rows/history/] and [3.11|https://ci-cassandra.apache.org/job/Cassandra-3.11/47/testReport/dtest.materialized_views_test/TestMaterializedViews/test_populate_mv_after_insert_wide_rows/history/]. Also CASSANDRA-4571 is fixver 4.0 only. A quick diagonal scroll look of the source code looks like they are different between versions. So I think it's reasonable to preserve 3.X runs. Wdyt? > Mark test_populate_mv_after_insert_wide_rows as flaky > - > > Key: CASSANDRA-15855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15855 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > See CASSANDRA-15845. This test can still fail in a flaky way so we better > mark it as such to avoid confusion and dup investigation efforts on failing > tests -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [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=17130348#comment-17130348
]
Benjamin Lerer commented on CASSANDRA-14825:
{quote}How's this going? Is anybody actively working on it as we near
completion of all the alpha tickets?{quote}
The status is still accurate. [~djoshi] and I already did part of the review.
Unfortunately we both have been busy with some other work and unable to finish
it.
> 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-15854) Truncation should fail any ongoing preview repairs
[
https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130300#comment-17130300
]
Marcus Eriksson commented on CASSANDRA-15854:
-
I'll post the patch soon, but we keep track of {{ParentRepairSession}} in
{{ActiveRepairService}}
> Truncation should fail any ongoing preview repairs
> --
>
> Key: CASSANDRA-15854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15854
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Truncation may race with preview repairs, validating different data on
> different nodes, we should abort any ongoing preview repairs if we get a
> truncation request
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15868) Update Netty version to 4.1.50 because there are security issues in 4.1.37
[ https://issues.apache.org/jira/browse/CASSANDRA-15868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130112#comment-17130112 ] Stefan Miklosovic edited comment on CASSANDRA-15868 at 6/10/20, 6:08 AM: - [https://github.com/apache/cassandra/compare/trunk...smiklosovic:CASSANDRA-15868?expand=1] was (Author: stefan.miklosovic): https://github.com/smiklosovic/cassandra/pull/new/CASSANDRA-15868 > 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 >Priority: Normal > 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] [Commented] (CASSANDRA-15868) Update Netty version to 4.1.50 because there are security issues in 4.1.37
[ https://issues.apache.org/jira/browse/CASSANDRA-15868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130112#comment-17130112 ] Stefan Miklosovic commented on CASSANDRA-15868: --- https://github.com/smiklosovic/cassandra/pull/new/CASSANDRA-15868 > 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 >Priority: Normal > 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] [Commented] (CASSANDRA-15867) Update Jackson version to 2.9.10.1 because there are security issues in 2.9.5
[ https://issues.apache.org/jira/browse/CASSANDRA-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130104#comment-17130104 ] Stefan Miklosovic commented on CASSANDRA-15867: --- [https://github.com/apache/cassandra/compare/trunk...smiklosovic:CASSANDRA-15867] > 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 >Priority: Normal > 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
