[jira] [Updated] (CASSANDRA-15869) MemoryOutputStream overflow on large bloom filter

2020-06-10 Thread ZhaoYang (Jira)


 [ 
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

2020-06-10 Thread ZhaoYang (Jira)


 [ 
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

2020-06-10 Thread ZhaoYang (Jira)


 [ 
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

2020-06-10 Thread ZhaoYang (Jira)


[ 
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

2020-06-10 Thread Caleb Rackliffe (Jira)


[ 
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

2020-06-10 Thread Brandon Williams (Jira)


[ 
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

2020-06-10 Thread Caleb Rackliffe (Jira)


[ 
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

2020-06-10 Thread Caleb Rackliffe (Jira)


[ 
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

2020-06-10 Thread Caleb Rackliffe (Jira)


[ 
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

2020-06-10 Thread Lorina Poland (Jira)


[ 
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

2020-06-10 Thread David Capwell (Jira)


[ 
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)

2020-06-10 Thread mck
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

2020-06-10 Thread David Capwell (Jira)


 [ 
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

2020-06-10 Thread David Capwell (Jira)


[ 
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

2020-06-10 Thread Michael Semb Wever (Jira)


[ 
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

2020-06-10 Thread Michael Semb Wever (Jira)


[ 
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

2020-06-10 Thread Caleb Rackliffe (Jira)


[ 
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

2020-06-10 Thread David Capwell (Jira)
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

2020-06-10 Thread Lorina Poland (Jira)


[ 
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

2020-06-10 Thread Josh McKenzie (Jira)


[ 
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

2020-06-10 Thread Josh McKenzie (Jira)


 [ 
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

2020-06-10 Thread Brandon Williams (Jira)


 [ 
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

2020-06-10 Thread Brandon Williams (Jira)


 [ 
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

2020-06-10 Thread Brandon Williams (Jira)


 [ 
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

2020-06-10 Thread Brandon Williams (Jira)


 [ 
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)

2020-06-10 Thread brandonwilliams
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

2020-06-10 Thread brandonwilliams
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

2020-06-10 Thread brandonwilliams
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.

2020-06-10 Thread brandonwilliams
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

2020-06-10 Thread Ekaterina Dimitrova (Jira)


[ 
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

2020-06-10 Thread Ekaterina Dimitrova (Jira)


 [ 
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

2020-06-10 Thread Jon Meredith (Jira)


 [ 
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

2020-06-10 Thread Jon Meredith (Jira)


 [ 
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

2020-06-10 Thread Jordan West (Jira)


[ 
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

2020-06-10 Thread Jordan West (Jira)


 [ 
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

2020-06-10 Thread Gianluca Righetto (Jira)


 [ 
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

2020-06-10 Thread Gianluca Righetto (Jira)


[ 
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

2020-06-10 Thread Berenguer Blasi (Jira)


[ 
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

2020-06-10 Thread Sylvain Lebresne (Jira)


[ 
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

2020-06-10 Thread Marcus Eriksson (Jira)


[ 
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

2020-06-10 Thread ZhaoYang (Jira)


[ 
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

2020-06-10 Thread Berenguer Blasi (Jira)


 [ 
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

2020-06-10 Thread Marcus Eriksson (Jira)


 [ 
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

2020-06-10 Thread Marcus Eriksson (Jira)


 [ 
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

2020-06-10 Thread Marcus Eriksson (Jira)


 [ 
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

2020-06-10 Thread ZhaoYang (Jira)


[ 
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

2020-06-10 Thread Jira


 [ 
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

2020-06-10 Thread Jira


[ 
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

2020-06-10 Thread adelapena
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

2020-06-10 Thread Benedict Elliott Smith (Jira)


[ 
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

2020-06-10 Thread Jira


 [ 
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

2020-06-10 Thread Jira


[ 
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

2020-06-10 Thread Jira


 [ 
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

2020-06-10 Thread adelapena
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

2020-06-10 Thread ifesdjeen
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

2020-06-10 Thread ZhaoYang (Jira)


 [ 
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

2020-06-10 Thread ZhaoYang (Jira)


 [ 
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

2020-06-10 Thread ZhaoYang (Jira)
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

2020-06-10 Thread ASF GitHub Bot (Jira)


 [ 
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

2020-06-10 Thread Bryn Cooke (Jira)


[ 
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

2020-06-10 Thread Bryn Cooke (Jira)


[ 
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

2020-06-10 Thread ZhaoYang (Jira)


[ 
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

2020-06-10 Thread ZhaoYang (Jira)


 [ 
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

2020-06-10 Thread Berenguer Blasi (Jira)


[ 
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

2020-06-10 Thread Berenguer Blasi (Jira)


[ 
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

2020-06-10 Thread Benjamin Lerer (Jira)


[ 
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

2020-06-10 Thread Marcus Eriksson (Jira)


[ 
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

2020-06-10 Thread Stefan Miklosovic (Jira)


[ 
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

2020-06-10 Thread Stefan Miklosovic (Jira)


[ 
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

2020-06-10 Thread Stefan Miklosovic (Jira)


[ 
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