[jira] [Commented] (CASSANDRA-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Jordan West (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014718#comment-17014718
 ] 

Jordan West commented on CASSANDRA-15213:
-

(y) I'll add the configurable stripe count and look more into bucket 
distribution as well as better benchmarking

> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Benedict Elliott Smith (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014715#comment-17014715
 ] 

Benedict Elliott Smith edited comment on CASSANDRA-15213 at 1/13/20 11:00 PM:
--

> but its encouraging we are seeing improved performance and memory usage with 
> the test we have and this branch

(y)

Yep, it's looking really promising.


was (Author: benedict):
> but its encouraging we are seeing improved performance and memory usage with 
> the test we have and this branch

(y)

> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Benedict Elliott Smith (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014704#comment-17014704
 ] 

Benedict Elliott Smith edited comment on CASSANDRA-15213 at 1/13/20 10:59 PM:
--

Just to reiterate, though, it's still not a great test, and it might be 
worthwhile improving it first.  Ideally we would have tighter control on the 
amount of competition we're measuring, since that's what we're interested in.  
We probably also do not want to visit the same values in the same order for 
every invocation, as this can lead to increased synchrony in execution lowering 
overall throughput artificially.  We also probably _do_ want to use the same 
random sequence on each run, to improve reproducibility.



was (Author: benedict):
Just to reiterate, though, it's still not a great test, and it might be 
worthwhile improving it first.  Ideally we would have tighter control on the 
amount of competition we're measuring, since that's what we're interested in.  
We probably also do not want to visit the same values in the same order for 
every execution, as this can lead to increased synchrony in execution lowering 
overall throughput artificially.  We also probably _do_ want to use the same 
random sequence on each run, to improve reproducibility.


> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Benedict Elliott Smith (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014715#comment-17014715
 ] 

Benedict Elliott Smith commented on CASSANDRA-15213:


> but its encouraging we are seeing improved performance and memory usage with 
> the test we have and this branch

(y)

> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Jordan West (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014713#comment-17014713
 ] 

Jordan West edited comment on CASSANDRA-15213 at 1/13/20 10:55 PM:
---

PEBKAC. I was rushing to run the bm between meetings and used the wrong branch. 
I am able to reproduce your numbers: 

{code}
 [java] Benchmark   Mode  Cnt 
Score Error  Units
 [java] LatencyTrackingBench.benchInsertToDEHR thrpt5  
39263498.481 ± 1809260.330  ops/s
 [java] LatencyTrackingBench.benchLatencyMetricsWrite  thrpt5  
10473724.356 ±  137670.100  ops/s

{code}

EDIT: I agree re: an improved benchmark but its encouraging we are seeing 
improved performance and memory usage with the test we have and this branch. 


was (Author: jrwest):
PEBKAC. I was rushing to run the bm between meetings and used the wrong branch. 
I am able to reproduce your numbers: 

{code}
 [java] Benchmark   Mode  Cnt 
Score Error  Units
 [java] LatencyTrackingBench.benchInsertToDEHR thrpt5  
39263498.481 ± 1809260.330  ops/s
 [java] LatencyTrackingBench.benchLatencyMetricsWrite  thrpt5  
10473724.356 ±  137670.100  ops/s

{code}

> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Jordan West (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014713#comment-17014713
 ] 

Jordan West commented on CASSANDRA-15213:
-

PEBKAC. I was rushing to run the bm between meetings and used the wrong branch. 
I am able to reproduce your numbers: 

{code}
 [java] Benchmark   Mode  Cnt 
Score Error  Units
 [java] LatencyTrackingBench.benchInsertToDEHR thrpt5  
39263498.481 ± 1809260.330  ops/s
 [java] LatencyTrackingBench.benchLatencyMetricsWrite  thrpt5  
10473724.356 ±  137670.100  ops/s

{code}

> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Benedict Elliott Smith (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014704#comment-17014704
 ] 

Benedict Elliott Smith commented on CASSANDRA-15213:


Just to reiterate, though, it's still not a great test, and it might be 
worthwhile improving it first.  Ideally we would have tighter control on the 
amount of competition we're measuring, since that's what we're interested in.  
We probably also do not want to visit the same values in the same order for 
every execution, as this can lead to increased synchrony in execution lowering 
overall throughput artificially.  We also probably _do_ want to use the same 
random sequence on each run, to improve reproducibility.


> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Benedict Elliott Smith (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014686#comment-17014686
 ] 

Benedict Elliott Smith commented on CASSANDRA-15213:


Interesting.  I get:

{code}
addAndGet
# Run progress: 0.00% complete, ETA 00:00:13
# Fork: 1 of 1
# Warmup Iteration   1: 39047588.027 ops/s
# Warmup Iteration   2: 42432555.911 ops/s
# Warmup Iteration   3: 42290231.202 ops/s
Iteration   1: 42252484.876 ops/s
Iteration   2: 41715818.895 ops/s
Iteration   3: 40307394.422 ops/s
Iteration   4: 40383945.073 ops/s
Iteration   5: 38825162.703 ops/s


Result 
"org.apache.cassandra.test.microbench.LatencyTrackingBench.benchInsertToDEHR":
  40696961.194 ±(99.9%) 5170160.207 ops/s [Average]
{code}

{code}
compareAndSet
# Run progress: 0.00% complete, ETA 00:00:13
# Fork: 1 of 1
# Warmup Iteration   1: 18926088.938 ops/s
# Warmup Iteration   2: 19504293.182 ops/s
# Warmup Iteration   3: 19261074.598 ops/s
Iteration   1: 19399456.839 ops/s
Iteration   2: 18979470.788 ops/s
Iteration   3: 18720138.076 ops/s
Iteration   4: 18458839.475 ops/s
Iteration   5: 18776539.883 ops/s


Result 
"org.apache.cassandra.test.microbench.LatencyTrackingBench.benchInsertToDEHR":
  18866889.012 ±(99.9%) 1351167.820 ops/s [Average]
{code}

i.e. twice the throughput with {{addAndGet}}. There is no material difference 
to my version:

{code}
public void updateBucket(AtomicLongArray buckets, int index, long value)
{
index = stripedIndex(index, (int) Thread.currentThread().getId() & 
(nStripes - 1));
buckets.addAndGet(index, value);
}
{code}

It's possible it's an issue of JDK?  Perhaps yours is not replacing 
{{addAndGet}} with the relevant {{lock xadd}} assembly?  This seems pretty 
unlikely, I think this has happened for a long time, but you could try looking 
at the assembly that's produced.

> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Jordan West (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014661#comment-17014661
 ] 

Jordan West commented on CASSANDRA-15213:
-

Using {{addAndGet}} I see performance comparable to 3.0 and prior to 
CASSANDRA-14281.

{codee}
15213 (4 core, 4 stripes, striping & linear search, addAndGet):

 [java] Benchmark   Mode  Cnt
ScoreError  Units
 [java] LatencyTrackingBench.benchInsertToDEHR thrpt5  
5742550.865 ± 256043.651  ops/s
 [java] LatencyTrackingBench.benchLatencyMetricsWrite  thrpt5  
1979885.731 ± 117381.276  ops/s

{/code}

Here is how I implemented update bucket in case I missed something
{code:java}
public void updateBucket(AtomicLongArray buckets, int index, long value)
{
int stripe = (int) (Thread.currentThread().getId() & (nStripes - 1));
buckets.addAndGet(stripedIndex(index, stripe), value);
}
{/code}

> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Jordan West (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014661#comment-17014661
 ] 

Jordan West edited comment on CASSANDRA-15213 at 1/13/20 9:27 PM:
--

Using {{addAndGet}} I see performance comparable to 3.0 and prior to 
CASSANDRA-14281.

{codee}
15213 (4 core, 4 stripes, striping & linear search, addAndGet):

 [java] Benchmark   Mode  Cnt
ScoreError  Units
 [java] LatencyTrackingBench.benchInsertToDEHR thrpt5  
5742550.865 ± 256043.651  ops/s
 [java] LatencyTrackingBench.benchLatencyMetricsWrite  thrpt5  
1979885.731 ± 117381.276  ops/s

{/code}

Here is how I implemented update bucket in case I missed something
{code:java}
public void updateBucket(AtomicLongArray buckets, int index, long value)
{
int stripe = (int) (Thread.currentThread().getId() & (nStripes - 1));
buckets.addAndGet(stripedIndex(index, stripe), value);
}
{code}


was (Author: jrwest):
Using {{addAndGet}} I see performance comparable to 3.0 and prior to 
CASSANDRA-14281.

{codee}
15213 (4 core, 4 stripes, striping & linear search, addAndGet):

 [java] Benchmark   Mode  Cnt
ScoreError  Units
 [java] LatencyTrackingBench.benchInsertToDEHR thrpt5  
5742550.865 ± 256043.651  ops/s
 [java] LatencyTrackingBench.benchLatencyMetricsWrite  thrpt5  
1979885.731 ± 117381.276  ops/s

{/code}

Here is how I implemented update bucket in case I missed something
{code:java}
public void updateBucket(AtomicLongArray buckets, int index, long value)
{
int stripe = (int) (Thread.currentThread().getId() & (nStripes - 1));
buckets.addAndGet(stripedIndex(index, stripe), value);
}
{/code}

> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-15213) DecayingEstimatedHistogramReservoir Inefficiencies

[Jordan West (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014661#comment-17014661
 ] 

Jordan West edited comment on CASSANDRA-15213 at 1/13/20 9:27 PM:
--

Using {{addAndGet}} I see performance comparable to 3.0 and prior to 
CASSANDRA-14281.

{code}
15213 (4 core, 4 stripes, striping & linear search, addAndGet):

 [java] Benchmark   Mode  Cnt
ScoreError  Units
 [java] LatencyTrackingBench.benchInsertToDEHR thrpt5  
5742550.865 ± 256043.651  ops/s
 [java] LatencyTrackingBench.benchLatencyMetricsWrite  thrpt5  
1979885.731 ± 117381.276  ops/s

{code}

Here is how I implemented update bucket in case I missed something
{code:java}
public void updateBucket(AtomicLongArray buckets, int index, long value)
{
int stripe = (int) (Thread.currentThread().getId() & (nStripes - 1));
buckets.addAndGet(stripedIndex(index, stripe), value);
}
{code}


was (Author: jrwest):
Using {{addAndGet}} I see performance comparable to 3.0 and prior to 
CASSANDRA-14281.

{codee}
15213 (4 core, 4 stripes, striping & linear search, addAndGet):

 [java] Benchmark   Mode  Cnt
ScoreError  Units
 [java] LatencyTrackingBench.benchInsertToDEHR thrpt5  
5742550.865 ± 256043.651  ops/s
 [java] LatencyTrackingBench.benchLatencyMetricsWrite  thrpt5  
1979885.731 ± 117381.276  ops/s

{/code}

Here is how I implemented update bucket in case I missed something
{code:java}
public void updateBucket(AtomicLongArray buckets, int index, long value)
{
int stripe = (int) (Thread.currentThread().getId() & (nStripes - 1));
buckets.addAndGet(stripedIndex(index, stripe), value);
}
{code}

> DecayingEstimatedHistogramReservoir Inefficiencies
> --
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Benedict Elliott Smith
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user 
> schemas, and this will grow significantly under contention and user schemas 
> with many tables.  This is because {{LongAdder}} is a very heavy class 
> designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of 
> performance in the contended case, by simply increasing the size of our 
> primitive backing array and providing multiple buckets, with each thread 
> picking a bucket to increment, or simply multiple backing arrays.  Probably a 
> better way still to do this would be to introduce some competition detection 
> to the update, much like {{LongAdder}} utilises, that increases the number of 
> backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that 
> are likely to be updated together, so that we do not need to duplicate the 
> entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the 
> new networking work (without filtering it was > 10% of the CPU used overall). 
>  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, 
> to save the random memory access costs.



--
This message was sent by Atlassian 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-14878) Race condition when setting bootstrap flags

[Brandon Williams (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014659#comment-17014659
 ] 

Brandon Williams commented on CASSANDRA-14878:
--

+1, committed

> Race condition when setting bootstrap flags
> ---
>
> Key: CASSANDRA-14878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14878
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sergio Bossa
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.20, 3.11.6, 4.0
>
> Attachments: Screen Shot 2020-01-13 at 1.03.19 PM.png, Screen Shot 
> 2020-01-13 at 1.03.41 PM.png, Screen Shot 2020-01-13 at 1.04.05 PM.png, 
> Screen Shot 2020-01-13 at 1.04.29 PM.png, Screen Shot 2020-01-13 at 1.04.55 
> PM.png, Screen Shot 2020-01-13 at 12.41.41 PM.png, Screen Shot 2020-01-13 at 
> 12.42.47 PM.png, Screen Shot 2020-01-13 at 12.43.28 PM.png, Screen Shot 
> 2020-01-13 at 12.44.36 PM.png, Screen Shot 2020-01-13 at 12.48.24 PM.png, 
> Screen Shot 2020-01-13 at 12.48.35 PM.png, Screen Shot 2020-01-13 at 12.48.49 
> PM.png
>
>
> {{StorageService#bootstrap()}} is supposed to wait for bootstrap to finish, 
> but Guava calls the future listeners 
> [after|https://github.com/google/guava/blob/ec2dedebfa359991cbcc8750dc62003be63ec6d3/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L890]
>  unparking its waiters, which causes a race on when the 
> {{bootstrapFinished()}} will be executed, making it non-deterministic.



--
This message was sent by Atlassian 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-14878) Race condition when setting bootstrap flags

[Brandon Williams (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-14878:
-
  Fix Version/s: (was: 3.11.x)
 (was: 4.x)
 (was: 3.0.x)
 4.0
 3.11.6
 3.0.20
  Since Version: 3.0 alpha 1
Source Control Link: 
https://github.com/apache/cassandra/commit/301168b60331bbd01864265a02fce9b63b94b823
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Race condition when setting bootstrap flags
> ---
>
> Key: CASSANDRA-14878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14878
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sergio Bossa
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.20, 3.11.6, 4.0
>
> Attachments: Screen Shot 2020-01-13 at 1.03.19 PM.png, Screen Shot 
> 2020-01-13 at 1.03.41 PM.png, Screen Shot 2020-01-13 at 1.04.05 PM.png, 
> Screen Shot 2020-01-13 at 1.04.29 PM.png, Screen Shot 2020-01-13 at 1.04.55 
> PM.png, Screen Shot 2020-01-13 at 12.41.41 PM.png, Screen Shot 2020-01-13 at 
> 12.42.47 PM.png, Screen Shot 2020-01-13 at 12.43.28 PM.png, Screen Shot 
> 2020-01-13 at 12.44.36 PM.png, Screen Shot 2020-01-13 at 12.48.24 PM.png, 
> Screen Shot 2020-01-13 at 12.48.35 PM.png, Screen Shot 2020-01-13 at 12.48.49 
> PM.png
>
>
> {{StorageService#bootstrap()}} is supposed to wait for bootstrap to finish, 
> but Guava calls the future listeners 
> [after|https://github.com/google/guava/blob/ec2dedebfa359991cbcc8750dc62003be63ec6d3/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L890]
>  unparking its waiters, which causes a race on when the 
> {{bootstrapFinished()}} will be executed, making it non-deterministic.



--
This message was sent by Atlassian 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-14878) Race condition when setting bootstrap flags

[Brandon Williams (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-14878:
-
Reviewers: Brandon Williams, Brandon Williams  (was: Brandon Williams)
   Brandon Williams, Brandon Williams
   Status: Review In Progress  (was: Patch Available)

> Race condition when setting bootstrap flags
> ---
>
> Key: CASSANDRA-14878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14878
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sergio Bossa
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Screen Shot 2020-01-13 at 1.03.19 PM.png, Screen Shot 
> 2020-01-13 at 1.03.41 PM.png, Screen Shot 2020-01-13 at 1.04.05 PM.png, 
> Screen Shot 2020-01-13 at 1.04.29 PM.png, Screen Shot 2020-01-13 at 1.04.55 
> PM.png, Screen Shot 2020-01-13 at 12.41.41 PM.png, Screen Shot 2020-01-13 at 
> 12.42.47 PM.png, Screen Shot 2020-01-13 at 12.43.28 PM.png, Screen Shot 
> 2020-01-13 at 12.44.36 PM.png, Screen Shot 2020-01-13 at 12.48.24 PM.png, 
> Screen Shot 2020-01-13 at 12.48.35 PM.png, Screen Shot 2020-01-13 at 12.48.49 
> PM.png
>
>
> {{StorageService#bootstrap()}} is supposed to wait for bootstrap to finish, 
> but Guava calls the future listeners 
> [after|https://github.com/google/guava/blob/ec2dedebfa359991cbcc8750dc62003be63ec6d3/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L890]
>  unparking its waiters, which causes a race on when the 
> {{bootstrapFinished()}} will be executed, making it non-deterministic.



--
This message was sent by Atlassian 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-14878) Race condition when setting bootstrap flags

[Brandon Williams (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-14878:
-
Status: Ready to Commit  (was: Review In Progress)

> Race condition when setting bootstrap flags
> ---
>
> Key: CASSANDRA-14878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14878
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sergio Bossa
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Screen Shot 2020-01-13 at 1.03.19 PM.png, Screen Shot 
> 2020-01-13 at 1.03.41 PM.png, Screen Shot 2020-01-13 at 1.04.05 PM.png, 
> Screen Shot 2020-01-13 at 1.04.29 PM.png, Screen Shot 2020-01-13 at 1.04.55 
> PM.png, Screen Shot 2020-01-13 at 12.41.41 PM.png, Screen Shot 2020-01-13 at 
> 12.42.47 PM.png, Screen Shot 2020-01-13 at 12.43.28 PM.png, Screen Shot 
> 2020-01-13 at 12.44.36 PM.png, Screen Shot 2020-01-13 at 12.48.24 PM.png, 
> Screen Shot 2020-01-13 at 12.48.35 PM.png, Screen Shot 2020-01-13 at 12.48.49 
> PM.png
>
>
> {{StorageService#bootstrap()}} is supposed to wait for bootstrap to finish, 
> but Guava calls the future listeners 
> [after|https://github.com/google/guava/blob/ec2dedebfa359991cbcc8750dc62003be63ec6d3/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L890]
>  unparking its waiters, which causes a race on when the 
> {{bootstrapFinished()}} will be executed, making it non-deterministic.



--
This message was sent by Atlassian 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: Add new bootstrap test for race condition

[brandonwilliams]

This is an automated email from the ASF dual-hosted git repository.

brandonwilliams 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 fc5576e  Add new bootstrap test for race condition
fc5576e is described below

commit fc5576e2804bc7cecd80058b6880d2fbeb026245
Author: Ekaterina Dimitrova 
AuthorDate: Mon Dec 9 11:38:40 2019 -0500

Add new bootstrap test for race condition

Patch by Ekaterina Dimitrova, reviewed by brandonwilliams for 
CASSANDRA-14878
---
 bootstrap_test.py  | 28 +++-
 byteman/bootstrap_5s_sleep.btm | 13 +
 tools/misc.py  |  5 +++--
 3 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/bootstrap_test.py b/bootstrap_test.py
index 70d54a3..9a7567f 100644
--- a/bootstrap_test.py
+++ b/bootstrap_test.py
@@ -239,6 +239,32 @@ class TestBootstrap(Tester):
 new_rows = list(session.execute("SELECT * FROM %s" % (stress_table,)))
 assert original_rows == new_rows
 
+@since('3.0')
+def test_bootstrap_waits_for_streaming_to_finish(self):
+ """
+ Test that bootstrap completes and is marked as such after 
streaming finishes.
+ """
+
+ cluster = self.cluster
+
+ logger.debug("Create a cluster")
+ cluster.populate(1)
+ node1 = cluster.nodelist()[0]
+
+ logger.debug("Start node 1")
+ node1.start(wait_for_binary_proto=True, wait_other_notice=True)
+
+ logger.debug("Insert 10k rows")
+ node1.stress(['write', 'n=10K', 'no-warmup', '-rate', 
'threads=8', '-schema', 'replication(factor=2)'])
+
+ logger.debug("Bootstrap node 2 with delay")
+ node2 = new_node(cluster, byteman_port='4200')
+ 
node2.update_startup_byteman_script('./byteman/bootstrap_5s_sleep.btm')
+ node2.start(wait_for_binary_proto=True, wait_other_notice=True)
+
+ assert_bootstrap_state(self, node2, 'COMPLETED')
+ assert node2.grep_log('Bootstrap completed', filename='debug.log')
+
 def 
test_consistent_range_movement_true_with_replica_down_should_fail(self):
 self._bootstrap_test_with_replica_down(True)
 
@@ -800,4 +826,4 @@ class TestBootstrap(Tester):
 node3.nodetool('join')
 self.assert_log_had_msg(node3, "Leaving write survey mode and joining 
ring at operator request", timeout=30)
 assert_bootstrap_state(self, node3, 'COMPLETED', user='cassandra', 
password='cassandra')
-node3.wait_for_binary_interface(timeout=30)
\ No newline at end of file
+node3.wait_for_binary_interface(timeout=30)
diff --git a/byteman/bootstrap_5s_sleep.btm b/byteman/bootstrap_5s_sleep.btm
new file mode 100644
index 000..6fa5996
--- /dev/null
+++ b/byteman/bootstrap_5s_sleep.btm
@@ -0,0 +1,13 @@
+#
+ # Sleep 5s when finishing bootstrap
+ #
+ RULE Sleep 5s when finishing bootstrap
+ CLASS org.apache.cassandra.service.StorageService
+ METHOD bootstrapFinished
+ AT ENTRY
+ # set flag to only run this rule once.
+ IF NOT flagged("done")
+ DO
+flag("done");
+Thread.sleep(5000)
+ ENDRULE
\ No newline at end of file
diff --git a/tools/misc.py b/tools/misc.py
index a4502f1..542a889 100644
--- a/tools/misc.py
+++ b/tools/misc.py
@@ -14,7 +14,7 @@ logger = logging.getLogger(__name__)
 
 
 # work for cluster started by populate
-def new_node(cluster, bootstrap=True, token=None, remote_debug_port='0', 
data_center=None):
+def new_node(cluster, bootstrap=True, token=None, remote_debug_port='0', 
data_center=None, byteman_port='0'):
 i = len(cluster.nodes) + 1
 node = Node('node%s' % i,
 cluster,
@@ -24,7 +24,8 @@ def new_node(cluster, bootstrap=True, token=None, 
remote_debug_port='0', data_ce
 str(7000 + i * 100),
 remote_debug_port,
 token,
-binary_interface=('127.0.0.%s' % i, 9042))
+binary_interface=('127.0.0.%s' % i, 9042),
+ byteman_port=byteman_port)
 cluster.add(node, not bootstrap, data_center=data_center)
 return node
 


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch cassandra-3.11 updated (094180b -> 0953f77)

[brandonwilliams]

This is an automated email from the ASF dual-hosted git repository.

brandonwilliams pushed a change to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from 094180b  Merge branch 'cassandra-3.0' into cassandra-3.11
 new 301168b  Fix race condition when setting bootstrap flags
 new 0953f77  Merge branch 'cassandra-3.0' into cassandra-3.11

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 CHANGES.txt |  1 +
 .../org/apache/cassandra/service/StorageService.java| 17 ++---
 2 files changed, 3 insertions(+), 15 deletions(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch trunk updated (b30ebb9 -> 55b463a)

[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 b30ebb9  Improve error when JVM 11 can't access required modules
 new 301168b  Fix race condition when setting bootstrap flags
 new 0953f77  Merge branch 'cassandra-3.0' into cassandra-3.11
 new 55b463a  Merge branch 'cassandra-3.11' into trunk

The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 CHANGES.txt |  1 +
 .../org/apache/cassandra/service/StorageService.java| 17 ++---
 2 files changed, 3 insertions(+), 15 deletions(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk

[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 55b463a216b6d5217e25a72ee993145c3280bcdd
Merge: b30ebb9 0953f77
Author: Brandon Williams 
AuthorDate: Mon Jan 13 15:13:53 2020 -0600

Merge branch 'cassandra-3.11' into trunk

 CHANGES.txt |  1 +
 .../org/apache/cassandra/service/StorageService.java| 17 ++---
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --cc CHANGES.txt
index 709db58,4a6867c..b6d140c
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,24 -1,9 +1,25 @@@
 -3.11.6
 +4.0-alpha3
 + * Improve error when JVM 11 can't access required modules (CASSANDRA-15468)
 + * Better handling of file deletion failures by DiskFailurePolicy 
(CASSANDRA-15143)
 + * Prevent read repair mutations from increasing read timeout 
(CASSANDRA-15442)
 + * Document 4.0 system keyspace changes, bump generations (CASSANDRA-15454)
 + * Make it possible to disable STCS-in-L0 during runtime (CASSANDRA-15445)
 + * Removed obsolete OldNetworkTopologyStrategy (CASSANDRA-13990)
 + * Align record header of FQL and audit binary log (CASSANDRA-15076)
 + * Shuffle forwarding replica for messages to non-local DC (CASSANDRA-15318)
 + * Optimise native protocol ASCII string encoding (CASSANDRA-15410)
 + * Make sure all exceptions are propagated in DebuggableThreadPoolExecutor 
(CASSANDRA-15332)
 + * Make it possible to resize concurrent read / write thread pools at runtime 
(CASSANDRA-15277)
 + * Close channels on error (CASSANDRA-15407)
 + * Add documentation for Java 11 support in Cassandra (CASSANDRA-15428)
 + * Integrate SJK into nodetool (CASSANDRA-12197)
 + * Ensure that empty clusterings with kind==CLUSTERING are Clustering.EMPTY 
(CASSANDRA-15498)
 +Merged from 3.11:
   * Fix nodetool compactionstats showing extra pending task for TWCS - patch 
implemented (CASSANDRA-15409)
   * Fix SELECT JSON formatting for the "duration" type (CASSANDRA-15075)
 - * Fix LegacyLayout to have same behavior as 2.x when handling unknown column 
names (CASSANDRA-15081)
   * Update nodetool help stop output (CASSANDRA-15401)
  Merged from 3.0:
++ * Fix race condition when setting bootstrap flags (CASSANDRA-14878)
   * Include updates to static column in mutation size calculations 
(CASSANDRA-15293)
   * Fix point-in-time recoevery ignoring timestamp of updates to static 
columns (CASSANDRA-15292)
   * GC logs are also put under $CASSANDRA_LOG_DIR (CASSANDRA-14306)
diff --cc src/java/org/apache/cassandra/service/StorageService.java
index 13cca3d,8466eb3..3588b1c
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@@ -1532,24 -1525,9 +1532,9 @@@ public class StorageService extends Not
  invalidateDiskBoundaries();
  
  setMode(Mode.JOINING, "Starting to bootstrap...", true);
 -BootStrapper bootstrapper = new 
BootStrapper(FBUtilities.getBroadcastAddress(), tokens, tokenMetadata);
 +BootStrapper bootstrapper = new 
BootStrapper(FBUtilities.getBroadcastAddressAndPort(), tokens, tokenMetadata);
  bootstrapper.addProgressListener(progressSupport);
  ListenableFuture bootstrapStream = 
bootstrapper.bootstrap(streamStateStore, useStrictConsistency && !replacing); 
// handles token update
- Futures.addCallback(bootstrapStream, new FutureCallback()
- {
- @Override
- public void onSuccess(StreamState streamState)
- {
- bootstrapFinished();
- logger.info("Bootstrap completed! for the tokens {}", tokens);
- }
- 
- @Override
- public void onFailure(Throwable e)
- {
- logger.warn("Error during bootstrap.", e);
- }
- }, MoreExecutors.directExecutor());
  try
  {
  bootstrapStream.get();


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch cassandra-3.0 updated: Fix race condition when setting bootstrap flags

[brandonwilliams]

This is an automated email from the ASF dual-hosted git repository.

brandonwilliams pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
 new 301168b  Fix race condition when setting bootstrap flags
301168b is described below

commit 301168b60331bbd01864265a02fce9b63b94b823
Author: Ekaterina Dimitrova 
AuthorDate: Thu Jan 2 07:35:51 2020 -0500

Fix race condition when setting bootstrap flags

Patch by Ekaterina Dimitrova, reviewed by brandonwilliams for 
CASSANDRA-14878
---
 CHANGES.txt |  1 +
 .../org/apache/cassandra/service/StorageService.java| 17 ++---
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index 620eb35..2edc399 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -14,6 +14,7 @@
  * Ensure that tracing doesn't break connections in 3.x/4.0 mixed mode by 
default (CASSANDRA-15385)
  * Make sure index summary redistribution does not start when compactions are 
paused (CASSANDRA-15265)
  * Ensure legacy rows have primary key livenessinfo when they contain illegal 
cells (CASSANDRA-15365)
+ * Fix race condition when setting bootstrap flags (CASSANDRA-14878)
 Merged from 2.2
  * Fix SELECT JSON output for empty blobs (CASSANDRA-15435)
  * In-JVM DTest: Set correct internode message version for upgrade test 
(CASSANDRA-15371)
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 9f5cd2b..f9efdb8 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -1267,24 +1267,11 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 BootStrapper bootstrapper = new 
BootStrapper(FBUtilities.getBroadcastAddress(), tokens, tokenMetadata);
 bootstrapper.addProgressListener(progressSupport);
 ListenableFuture bootstrapStream = 
bootstrapper.bootstrap(streamStateStore, !replacing && useStrictConsistency); 
// handles token update
-Futures.addCallback(bootstrapStream, new FutureCallback()
-{
-@Override
-public void onSuccess(StreamState streamState)
-{
-bootstrapFinished();
-logger.info("Bootstrap completed! for the tokens {}", tokens);
-}
-
-@Override
-public void onFailure(Throwable e)
-{
-logger.warn("Error during bootstrap.", e);
-}
-});
 try
 {
 bootstrapStream.get();
+bootstrapFinished();
+logger.info("Bootstrap completed for tokens {}", tokens);
 return true;
 }
 catch (Throwable e)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11

[brandonwilliams]

This is an automated email from the ASF dual-hosted git repository.

brandonwilliams pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit 0953f77fe535f96d7158fa9d076d37d9c2a9f93e
Merge: 094180b 301168b
Author: Brandon Williams 
AuthorDate: Mon Jan 13 15:12:11 2020 -0600

Merge branch 'cassandra-3.0' into cassandra-3.11

 CHANGES.txt |  1 +
 .../org/apache/cassandra/service/StorageService.java| 17 ++---
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --cc CHANGES.txt
index 408048b,2edc399..4a6867c
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -19,7 -14,8 +19,8 @@@ Merged from 3.0
   * Ensure that tracing doesn't break connections in 3.x/4.0 mixed mode by 
default (CASSANDRA-15385)
   * Make sure index summary redistribution does not start when compactions are 
paused (CASSANDRA-15265)
   * Ensure legacy rows have primary key livenessinfo when they contain illegal 
cells (CASSANDRA-15365)
+  * Fix race condition when setting bootstrap flags (CASSANDRA-14878)
 -Merged from 2.2
 +Merged from 2.2:
   * Fix SELECT JSON output for empty blobs (CASSANDRA-15435)
   * In-JVM DTest: Set correct internode message version for upgrade test 
(CASSANDRA-15371)
   * In-JVM DTest: Support NodeTool in dtest (CASSANDRA-15429)
diff --cc src/java/org/apache/cassandra/service/StorageService.java
index e7d97e9,f9efdb8..8466eb3
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@@ -1527,22 -1266,7 +1527,7 @@@ public class StorageService extends Not
  setMode(Mode.JOINING, "Starting to bootstrap...", true);
  BootStrapper bootstrapper = new 
BootStrapper(FBUtilities.getBroadcastAddress(), tokens, tokenMetadata);
  bootstrapper.addProgressListener(progressSupport);
 -ListenableFuture bootstrapStream = 
bootstrapper.bootstrap(streamStateStore, !replacing && useStrictConsistency); 
// handles token update
 +ListenableFuture bootstrapStream = 
bootstrapper.bootstrap(streamStateStore, useStrictConsistency && !replacing); 
// handles token update
- Futures.addCallback(bootstrapStream, new FutureCallback()
- {
- @Override
- public void onSuccess(StreamState streamState)
- {
- bootstrapFinished();
- logger.info("Bootstrap completed! for the tokens {}", tokens);
- }
- 
- @Override
- public void onFailure(Throwable e)
- {
- logger.warn("Error during bootstrap.", e);
- }
- });
  try
  {
  bootstrapStream.get();


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15499) Internode message builder does not add trace header

[Yifan Cai (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014656#comment-17014656
 ] 

Yifan Cai commented on CASSANDRA-15499:
---

To add more context, I am working on the other 
[patch|https://issues.apache.org/jira/browse/CASSANDRA-2848] that makes more 
messages being created with the Builder and the 
{{org.apache.cassandra.distributed.test.MessageForwardingTest}} that checks the 
tracing history fails.

> Internode message builder does not add trace header
> ---
>
> Key: CASSANDRA-15499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15499
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.x
>
>
> The messages built with the {{Builder}} 
> ({{org.apache.cassandra.net.Message.Builder}}) do not have the trace header 
> when tracing is enabled. 
> Consequently, no tracing session gets propagated to other nodes, and the 
> tracing function is broken. 
> The set of static {{out*}} methods provided (to create an out-bounding 
> message) in Message do not have the issue. They can properly add the trace 
> header when necessary. 
> To be clear, only the {{Builder}} missed adding the tracing header and it 
> should be fixed to be consistent with the {{out*}} methods.



--
This message was sent by Atlassian 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-15499) Internode message builder does not add trace header

[David Capwell (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014657#comment-17014657
 ] 

David Capwell commented on CASSANDRA-15499:
---

Based off trunk, build() is only called in a special case (forwardTo with mixed 
ids) so not a common bug, but will be as more usages of build() pop up.

Looking at other call sites for new Message, I see the below are also missing 
tracing

org.apache.cassandra.net.Message.Serializer#toPre40FailureResponse and
org.apache.cassandra.net.Message.Serializer#toPost40FailureResponse

The patch looks to improve build, but I wonder if the failure response methods 
should also be updated (my instinct is yes, but would like [~aleksey] feedback)?

> Internode message builder does not add trace header
> ---
>
> Key: CASSANDRA-15499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15499
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.x
>
>
> The messages built with the {{Builder}} 
> ({{org.apache.cassandra.net.Message.Builder}}) do not have the trace header 
> when tracing is enabled. 
> Consequently, no tracing session gets propagated to other nodes, and the 
> tracing function is broken. 
> The set of static {{out*}} methods provided (to create an out-bounding 
> message) in Message do not have the issue. They can properly add the trace 
> header when necessary. 
> To be clear, only the {{Builder}} missed adding the tracing header and it 
> should be fixed to be consistent with the {{out*}} methods.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-builds] branch master updated: Keep build-scripts compatible with python2 by limiting setuptools <45

[mck]

This is an automated email from the ASF dual-hosted git repository.

mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git


The following commit(s) were added to refs/heads/master by this push:
 new 6cd5040  Keep build-scripts compatible with python2 by limiting 
setuptools <45
6cd5040 is described below

commit 6cd504054bde5ae5507dba6d25082304327c64fa
Author: mck 
AuthorDate: Mon Jan 13 21:23:03 2020 +0100

Keep build-scripts compatible with python2 by limiting setuptools <45

ref: https://github.com/pypa/virtualenv/issues/1493
---
 build-scripts/cassandra-artifacts.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build-scripts/cassandra-artifacts.sh 
b/build-scripts/cassandra-artifacts.sh
index 35b632e..7cdda72 100755
--- a/build-scripts/cassandra-artifacts.sh
+++ b/build-scripts/cassandra-artifacts.sh
@@ -9,7 +9,8 @@
 # Sphinx is needed for the gen-doc target
 virtualenv venv
 source venv/bin/activate
-pip install Sphinx sphinx_rtd_theme
+# setuptools 45.0.0 requires python 3.5+
+pip install "setuptools<45" Sphinx sphinx_rtd_theme
 
 
 #


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15499) Internode message builder does not add trace header

[David Capwell (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Capwell updated CASSANDRA-15499:
--
Reviewers: David Capwell, David Capwell  (was: David Capwell)
   David Capwell, David Capwell
   Status: Review In Progress  (was: Patch Available)

starting review now.  At first glance the code looks fine, so starting with 
testing it.

> Internode message builder does not add trace header
> ---
>
> Key: CASSANDRA-15499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15499
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.x
>
>
> The messages built with the {{Builder}} 
> ({{org.apache.cassandra.net.Message.Builder}}) do not have the trace header 
> when tracing is enabled. 
> Consequently, no tracing session gets propagated to other nodes, and the 
> tracing function is broken. 
> The set of static {{out*}} methods provided (to create an out-bounding 
> message) in Message do not have the issue. They can properly add the trace 
> header when necessary. 
> To be clear, only the {{Builder}} missed adding the tracing header and it 
> should be fixed to be consistent with the {{out*}} methods.



--
This message was sent by Atlassian 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-15499) Internode message builder does not add trace header

[Yifan Cai (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014640#comment-17014640
 ] 

Yifan Cai commented on CASSANDRA-15499:
---

cc [~aleksey] since the change is applied to {{Message}}, which is part of the 
patch of internode messaging refactor. 

> Internode message builder does not add trace header
> ---
>
> Key: CASSANDRA-15499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15499
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.x
>
>
> The messages built with the {{Builder}} 
> ({{org.apache.cassandra.net.Message.Builder}}) do not have the trace header 
> when tracing is enabled. 
> Consequently, no tracing session gets propagated to other nodes, and the 
> tracing function is broken. 
> The set of static {{out*}} methods provided (to create an out-bounding 
> message) in Message do not have the issue. They can properly add the trace 
> header when necessary. 
> To be clear, only the {{Builder}} missed adding the tracing header and it 
> should be fixed to be consistent with the {{out*}} methods.



--
This message was sent by Atlassian 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-15499) Internode message builder does not add trace header

[Yifan Cai (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yifan Cai updated CASSANDRA-15499:
--
Status: Patch Available  (was: In Progress)

> Internode message builder does not add trace header
> ---
>
> Key: CASSANDRA-15499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15499
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.x
>
>
> The messages built with the {{Builder}} 
> ({{org.apache.cassandra.net.Message.Builder}}) do not have the trace header 
> when tracing is enabled. 
> Consequently, no tracing session gets propagated to other nodes, and the 
> tracing function is broken. 
> The set of static {{out*}} methods provided (to create an out-bounding 
> message) in Message do not have the issue. They can properly add the trace 
> header when necessary. 
> To be clear, only the {{Builder}} missed adding the tracing header and it 
> should be fixed to be consistent with the {{out*}} methods.



--
This message was sent by Atlassian 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-15499) Internode message builder does not add trace header

[Yifan Cai (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yifan Cai updated CASSANDRA-15499:
--
 Bug Category: Parent values: Correctness(12982)Level 1 values: API / 
Semantic Implementation(12988)
   Complexity: Low Hanging Fruit
Discovered By: Unit Test
Fix Version/s: 4.x
 Severity: Low
   Status: Open  (was: Triage Needed)

> Internode message builder does not add trace header
> ---
>
> Key: CASSANDRA-15499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15499
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.x
>
>
> The messages built with the {{Builder}} 
> ({{org.apache.cassandra.net.Message.Builder}}) do not have the trace header 
> when tracing is enabled. 
> Consequently, no tracing session gets propagated to other nodes, and the 
> tracing function is broken. 
> The set of static {{out*}} methods provided (to create an out-bounding 
> message) in Message do not have the issue. They can properly add the trace 
> header when necessary. 
> To be clear, only the {{Builder}} missed adding the tracing header and it 
> should be fixed to be consistent with the {{out*}} methods.



--
This message was sent by Atlassian 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-14878) Race condition when setting bootstrap flags

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-14878:

Test and Documentation Plan: 
||Branch||
|[trunk-14878|https://github.com/ekaterinadimitrova2/cassandra/tree/trunk-14878]|
|[cassandra-3.0-14878|https://github.com/ekaterinadimitrova2/cassandra/tree/cassandra-3.0-14878]|
|[cassandra-3.11-14878|https://github.com/ekaterinadimitrova2/cassandra/tree/cassandra-3.11-14878]|
|[DTest|https://github.com/ekaterinadimitrova2/cassandra-dtest/pulls]|
 Status: Patch Available  (was: In Progress)

> Race condition when setting bootstrap flags
> ---
>
> Key: CASSANDRA-14878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14878
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sergio Bossa
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Screen Shot 2020-01-13 at 1.03.19 PM.png, Screen Shot 
> 2020-01-13 at 1.03.41 PM.png, Screen Shot 2020-01-13 at 1.04.05 PM.png, 
> Screen Shot 2020-01-13 at 1.04.29 PM.png, Screen Shot 2020-01-13 at 1.04.55 
> PM.png, Screen Shot 2020-01-13 at 12.41.41 PM.png, Screen Shot 2020-01-13 at 
> 12.42.47 PM.png, Screen Shot 2020-01-13 at 12.43.28 PM.png, Screen Shot 
> 2020-01-13 at 12.44.36 PM.png, Screen Shot 2020-01-13 at 12.48.24 PM.png, 
> Screen Shot 2020-01-13 at 12.48.35 PM.png, Screen Shot 2020-01-13 at 12.48.49 
> PM.png
>
>
> {{StorageService#bootstrap()}} is supposed to wait for bootstrap to finish, 
> but Guava calls the future listeners 
> [after|https://github.com/google/guava/blob/ec2dedebfa359991cbcc8750dc62003be63ec6d3/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L890]
>  unparking its waiters, which causes a race on when the 
> {{bootstrapFinished()}} will be executed, making it non-deterministic.



--
This message was sent by Atlassian 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-14878) Race condition when setting bootstrap flags

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014538#comment-17014538
 ] 

Ekaterina Dimitrova commented on CASSANDRA-14878:
-

CI results screenshots added. Many failing dtests for version 11 but I did 
comparison with the OSS Jenkins latest builds and it looks like the same ones 
are failing even without the patch. 

> Race condition when setting bootstrap flags
> ---
>
> Key: CASSANDRA-14878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14878
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sergio Bossa
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Screen Shot 2020-01-13 at 1.03.19 PM.png, Screen Shot 
> 2020-01-13 at 1.03.41 PM.png, Screen Shot 2020-01-13 at 1.04.05 PM.png, 
> Screen Shot 2020-01-13 at 1.04.29 PM.png, Screen Shot 2020-01-13 at 1.04.55 
> PM.png, Screen Shot 2020-01-13 at 12.41.41 PM.png, Screen Shot 2020-01-13 at 
> 12.42.47 PM.png, Screen Shot 2020-01-13 at 12.43.28 PM.png, Screen Shot 
> 2020-01-13 at 12.44.36 PM.png, Screen Shot 2020-01-13 at 12.48.24 PM.png, 
> Screen Shot 2020-01-13 at 12.48.35 PM.png, Screen Shot 2020-01-13 at 12.48.49 
> PM.png
>
>
> {{StorageService#bootstrap()}} is supposed to wait for bootstrap to finish, 
> but Guava calls the future listeners 
> [after|https://github.com/google/guava/blob/ec2dedebfa359991cbcc8750dc62003be63ec6d3/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L890]
>  unparking its waiters, which causes a race on when the 
> {{bootstrapFinished()}} will be executed, making it non-deterministic.



--
This message was sent by Atlassian 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-14878) Race condition when setting bootstrap flags

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-14878:

Attachment: Screen Shot 2020-01-13 at 12.48.49 PM.png
Screen Shot 2020-01-13 at 12.48.35 PM.png
Screen Shot 2020-01-13 at 12.48.24 PM.png
Screen Shot 2020-01-13 at 12.44.36 PM.png
Screen Shot 2020-01-13 at 12.43.28 PM.png
Screen Shot 2020-01-13 at 12.42.47 PM.png
Screen Shot 2020-01-13 at 12.41.41 PM.png
Screen Shot 2020-01-13 at 1.04.55 PM.png
Screen Shot 2020-01-13 at 1.04.29 PM.png
Screen Shot 2020-01-13 at 1.04.05 PM.png
Screen Shot 2020-01-13 at 1.03.41 PM.png
Screen Shot 2020-01-13 at 1.03.19 PM.png

> Race condition when setting bootstrap flags
> ---
>
> Key: CASSANDRA-14878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14878
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sergio Bossa
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Screen Shot 2020-01-13 at 1.03.19 PM.png, Screen Shot 
> 2020-01-13 at 1.03.41 PM.png, Screen Shot 2020-01-13 at 1.04.05 PM.png, 
> Screen Shot 2020-01-13 at 1.04.29 PM.png, Screen Shot 2020-01-13 at 1.04.55 
> PM.png, Screen Shot 2020-01-13 at 12.41.41 PM.png, Screen Shot 2020-01-13 at 
> 12.42.47 PM.png, Screen Shot 2020-01-13 at 12.43.28 PM.png, Screen Shot 
> 2020-01-13 at 12.44.36 PM.png, Screen Shot 2020-01-13 at 12.48.24 PM.png, 
> Screen Shot 2020-01-13 at 12.48.35 PM.png, Screen Shot 2020-01-13 at 12.48.49 
> PM.png
>
>
> {{StorageService#bootstrap()}} is supposed to wait for bootstrap to finish, 
> but Guava calls the future listeners 
> [after|https://github.com/google/guava/blob/ec2dedebfa359991cbcc8750dc62003be63ec6d3/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L890]
>  unparking its waiters, which causes a race on when the 
> {{bootstrapFinished()}} will be executed, making it non-deterministic.



--
This message was sent by Atlassian 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-14878) Race condition when setting bootstrap flags

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014517#comment-17014517
 ] 

Ekaterina Dimitrova commented on CASSANDRA-14878:
-

||Branch||
|[trunk-14878|https://github.com/ekaterinadimitrova2/cassandra/tree/trunk-14878]|
|[cassandra-3.0-14878| 
https://github.com/ekaterinadimitrova2/cassandra/tree/cassandra-3.0-14878]|
|[cassandra-3.11-14878| 
https://github.com/ekaterinadimitrova2/cassandra/tree/cassandra-3.11-14878]|
|[DTest| https://github.com/ekaterinadimitrova2/cassandra-dtest/pulls]|

> Race condition when setting bootstrap flags
> ---
>
> Key: CASSANDRA-14878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14878
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sergio Bossa
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> {{StorageService#bootstrap()}} is supposed to wait for bootstrap to finish, 
> but Guava calls the future listeners 
> [after|https://github.com/google/guava/blob/ec2dedebfa359991cbcc8750dc62003be63ec6d3/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L890]
>  unparking its waiters, which causes a race on when the 
> {{bootstrapFinished()}} will be executed, making it non-deterministic.



--
This message was sent by Atlassian 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-14773) Overflow of 32-bit integer during compaction.

[Benedict Elliott Smith (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014474#comment-17014474
 ] 

Benedict Elliott Smith commented on CASSANDRA-14773:


FYI, I deliberately unassigned this to help track the likely need for another 
contributor to complete the work.

> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Vladimir Bukhtoyarov
>Priority: Urgent
> Fix For: 4.0, 4.0-beta
>
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from 
> CPU and memory perspective. Hovewer this improvement introduces the bug in 
> rounding. When rounding the expriration time which is close to  
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow 
> happens(because in scope of -CASSANDRA-13444-) data type for point was 
> changed from Long to Integer in order to reduce memory footprint), as result 
> point became negative and acts as silent poison for internal structures of 
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*. 
> Then depending of point intervals:
>  * The TombstoneHistogram produces wrong values when interval of points is 
> less then binSize, it is not critical.
>  * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point 
> intervals is great then  binSize, this case is very critical.
>  
> This is pull request [https://github.com/apache/cassandra/pull/273] that 
> reproduces the issue and provides the fix. 
>  
> The stacktrace when running(on codebase without fix) 
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
>  Source)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at 

[jira] [Assigned] (CASSANDRA-14773) Overflow of 32-bit integer during compaction.

[Josh McKenzie (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh McKenzie reassigned CASSANDRA-14773:
-

Assignee: Vladimir Bukhtoyarov

> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Vladimir Bukhtoyarov
>Priority: Urgent
> Fix For: 4.0, 4.0-beta
>
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from 
> CPU and memory perspective. Hovewer this improvement introduces the bug in 
> rounding. When rounding the expriration time which is close to  
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow 
> happens(because in scope of -CASSANDRA-13444-) data type for point was 
> changed from Long to Integer in order to reduce memory footprint), as result 
> point became negative and acts as silent poison for internal structures of 
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*. 
> Then depending of point intervals:
>  * The TombstoneHistogram produces wrong values when interval of points is 
> less then binSize, it is not critical.
>  * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point 
> intervals is great then  binSize, this case is very critical.
>  
> This is pull request [https://github.com/apache/cassandra/pull/273] that 
> reproduces the issue and provides the fix. 
>  
> The stacktrace when running(on codebase without fix) 
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
>  Source)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at 
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
>  
> The stacktrace when running(on codebase without fix)  
> 

[jira] [Comment Edited] (CASSANDRA-15468) Unable to start embedded cassandra on JDK 11

[Sam Tunnicliffe (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-15468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014332#comment-17014332
 ] 

Sam Tunnicliffe edited comment on CASSANDRA-15468 at 1/13/20 1:51 PM:
--

bq. I'd like to respectfully ask that this not be resolved yet.

Fair enough, I was a bit hasty in closing it. The patch looks good and 
absolutely improves the user experience so I've edited the title of this JIRA 
to reflect what it does. If you wouldn't mind opening follow up JIRAs for any 
work that needs to be done to support Uno-Jar or for making changes to the jar 
manifest, that'd be great.

 
||branch||CI||
|[15468-trunk|https://github.com/beobal/cassandra/tree/15468-trunk]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/15468-trunk]|

(the few test failures are unrelated)

Thanks


was (Author: beobal):
>I'd like to respectfully ask that this not be resolved yet.

Fair enough, I was a bit hasty in closing it. The patch looks good and 
absolutely improves the user experience so I've edited the title of this JIRA 
to reflect what it does. If you wouldn't mind opening follow up JIRAs for any 
work that needs to be done to support Uno-Jar or for making changes to the jar 
manifest, that'd be great.

 
||branch||CI||
|[15468-trunk|https://github.com/beobal/cassandra/tree/15468-trunk]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/15468-trunk]|

(the few test failures are unrelated)

Thanks

> Unable to start embedded cassandra on JDK 11
> 
>
> Key: CASSANDRA-15468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15468.patch
>
>
> Cassandra fails to start without the following jvm options from 
> jvm-11-server.options:
> {code:java}
> -Djdk.attach.allowAttachSelf=true
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
> --add-exports java.sql/java.sql=ALL-UNNAMED
> --add-opens java.base/java.lang.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.loader=ALL-UNNAMED
> --add-opens java.base/jdk.internal.ref=ALL-UNNAMED
> --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED
> --add-opens java.base/jdk.internal.math=ALL-UNNAMED
> --add-opens java.base/jdk.internal.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.util.jar=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> {code}
> Without these options the following stack trace appears and prevents startup
> {code:java}
> 2020-01-05T17:42:15,009 ERROR main 
> org.apache.cassandra.service.CassandraDaemon Exception encountered during 
> startup java.lang.ExceptionInInitializerError
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
>   at 
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
>   at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
>   at 
> org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> 

[jira] [Updated] (CASSANDRA-15468) Unable to start embedded cassandra on JDK 11

[Sam Tunnicliffe (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-15468:

  Fix Version/s: 4.0-alpha
  Since Version: 4.0
Source Control Link: 
https://github.com/apache/cassandra/commit/b30ebb952c53a3dae078f6883b26feca685eb7cc
 Resolution: Fixed  (was: Not A Problem)
 Status: Resolved  (was: Ready to Commit)

>I'd like to respectfully ask that this not be resolved yet.

Fair enough, I was a bit hasty in closing it. The patch looks good and 
absolutely improves the user experience so I've edited the title of this JIRA 
to reflect what it does. If you wouldn't mind opening follow up JIRAs for any 
work that needs to be done to support Uno-Jar or for making changes to the jar 
manifest, that'd be great.

 
||branch||CI||
|[15468-trunk|https://github.com/beobal/cassandra/tree/15468-trunk]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/15468-trunk]|

(the few test failures are unrelated)

Thanks

> Unable to start embedded cassandra on JDK 11
> 
>
> Key: CASSANDRA-15468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15468.patch
>
>
> Cassandra fails to start without the following jvm options from 
> jvm-11-server.options:
> {code:java}
> -Djdk.attach.allowAttachSelf=true
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
> --add-exports java.sql/java.sql=ALL-UNNAMED
> --add-opens java.base/java.lang.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.loader=ALL-UNNAMED
> --add-opens java.base/jdk.internal.ref=ALL-UNNAMED
> --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED
> --add-opens java.base/jdk.internal.math=ALL-UNNAMED
> --add-opens java.base/jdk.internal.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.util.jar=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> {code}
> Without these options the following stack trace appears and prevents startup
> {code:java}
> 2020-01-05T17:42:15,009 ERROR main 
> org.apache.cassandra.service.CassandraDaemon Exception encountered during 
> startup java.lang.ExceptionInInitializerError
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
>   at 
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
>   at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
>   at 
> org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>   at 

[jira] [Updated] (CASSANDRA-15468) Unable to start embedded cassandra on JDK 11

[Sam Tunnicliffe (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-15468:


> Unable to start embedded cassandra on JDK 11
> 
>
> Key: CASSANDRA-15468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15468.patch
>
>
> Cassandra fails to start without the following jvm options from 
> jvm-11-server.options:
> {code:java}
> -Djdk.attach.allowAttachSelf=true
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
> --add-exports java.sql/java.sql=ALL-UNNAMED
> --add-opens java.base/java.lang.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.loader=ALL-UNNAMED
> --add-opens java.base/jdk.internal.ref=ALL-UNNAMED
> --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED
> --add-opens java.base/jdk.internal.math=ALL-UNNAMED
> --add-opens java.base/jdk.internal.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.util.jar=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> {code}
> Without these options the following stack trace appears and prevents startup
> {code:java}
> 2020-01-05T17:42:15,009 ERROR main 
> org.apache.cassandra.service.CassandraDaemon Exception encountered during 
> startup java.lang.ExceptionInInitializerError
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
>   at 
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
>   at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
>   at 
> org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: 

[cassandra] branch trunk updated: Improve error when JVM 11 can't access required modules

[samt]

This is an automated email from the ASF dual-hosted git repository.

samt pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new b30ebb9  Improve error when JVM 11 can't access required modules
b30ebb9 is described below

commit b30ebb952c53a3dae078f6883b26feca685eb7cc
Author: Gus Heck 
AuthorDate: Mon Jan 13 11:40:20 2020 +

Improve error when JVM 11 can't access required modules

Patch by Gus Heck; reviewed by Sam Tunnicliffe for CASSANDRA-15468
---
 CHANGES.txt  |  1 +
 src/java/org/apache/cassandra/io/util/FileUtils.java | 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index 9378900..709db58 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0-alpha3
+ * Improve error when JVM 11 can't access required modules (CASSANDRA-15468)
  * Better handling of file deletion failures by DiskFailurePolicy 
(CASSANDRA-15143)
  * Prevent read repair mutations from increasing read timeout (CASSANDRA-15442)
  * Document 4.0 system keyspace changes, bump generations (CASSANDRA-15454)
diff --git a/src/java/org/apache/cassandra/io/util/FileUtils.java 
b/src/java/org/apache/cassandra/io/util/FileUtils.java
index 4bf42f0..549e544 100644
--- a/src/java/org/apache/cassandra/io/util/FileUtils.java
+++ b/src/java/org/apache/cassandra/io/util/FileUtils.java
@@ -88,11 +88,19 @@ public final class FileUtils
 ByteBuffer buf = ByteBuffer.allocateDirect(1);
 clean(buf);
 }
+catch (IllegalAccessException e)
+{
+logger.error("FATAL: Cassandra is unable to access required 
classes. This usually means it has been " +
+"run without the aid of the standard startup scripts or the 
scripts have been edited. If this was " +
+"intentional, and you are attempting to use Java 11+ you may 
need to add the --add-exports and " +
+"--add-opens jvm options from either jvm11-server.options or 
jvm11-client.options");
+throw new RuntimeException(e);  // causes 
ExceptionInInitializerError, will prevent startup
+}
 catch (Throwable t)
 {
-logger.error("FATAL: Cannot initialize optimized memory 
deallocator. Some data, both in-memory and on-disk, may live longer due to 
garbage collection.");
+logger.error("FATAL: Cannot initialize optimized memory 
deallocator.");
 JVMStabilityInspector.inspectThrowable(t);
-throw new RuntimeException(t);
+throw new RuntimeException(t); // causes 
ExceptionInInitializerError, will prevent startup
 }
 }
 


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-diff] branch master updated: publish a separate uberjar with the spark job and guava relocated (#5)

[marcuse]

This is an automated email from the ASF dual-hosted git repository.

marcuse pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-diff.git


The following commit(s) were added to refs/heads/master by this push:
 new 9c55826  publish a separate uberjar with the spark job and guava 
relocated (#5)
9c55826 is described below

commit 9c558265c25e855043e8e6b5c8ac5d5aca58ba06
Author: Marcus Eriksson 
AuthorDate: Mon Jan 13 13:24:51 2020 +0100

publish a separate uberjar with the spark job and guava relocated (#5)
---
 README.md|  4 ++--
 api-server/pom.xml   |  2 +-
 common/pom.xml   |  4 ++--
 pom.xml  |  3 ++-
 spark-job/pom.xml| 32 +---
 {spark-job => spark-uberjar}/pom.xml | 31 +--
 6 files changed, 13 insertions(+), 63 deletions(-)

diff --git a/README.md b/README.md
index c79e17d..5fab877 100644
--- a/README.md
+++ b/README.md
@@ -43,7 +43,7 @@ $ docker run --name cas-src -d  -p 9042:9042 cassandra:3.0.18
 $ docker run --name cas-tgt -d  -p 9043:9042 cassandra:latest
 $ docker exec cas-src cassandra-stress write n=1k
 $ docker exec cas-tgt cassandra-stress write n=1k
-$ spark-submit --verbose --files ./spark-job/localconfig.yaml --class 
org.apache.cassandra.diff.DiffJob spark-job/target/spark-job-0.1-SNAPSHOT.jar 
localconfig.yaml
+$ spark-submit --verbose --files ./spark-job/localconfig.yaml --class 
org.apache.cassandra.diff.DiffJob 
spark-uberjar/target/spark-uberjar-0.2-SNAPSHOT.jar localconfig.yaml
 # ... logs
 INFO  DiffJob:124 - FINISHED: {standard1=Matched Partitions - 1000, Mismatched 
Partitions - 0, Partition Errors - 0, Partitions Only In Source - 0, Partitions 
Only In Target - 0, Skipped Partitions - 0, Matched Rows - 1000, Matched Values 
- 6000, Mismatched Values - 0 }
 ## start api-server:
@@ -138,4 +138,4 @@ $ mvn release:prepare
 6. Stage the release for a vote
   ```shell script
 $ mvn release:perform
-  ```
\ No newline at end of file
+  ```
diff --git a/api-server/pom.xml b/api-server/pom.xml
index ab431da..4c67ed1 100644
--- a/api-server/pom.xml
+++ b/api-server/pom.xml
@@ -25,7 +25,7 @@
 
   org.apache.cassandra.diff
   diff
-  0.1-SNAPSHOT
+  0.2-SNAPSHOT
 
 
 4.0.0
diff --git a/common/pom.xml b/common/pom.xml
index f73c4f5..a25cd10 100644
--- a/common/pom.xml
+++ b/common/pom.xml
@@ -25,7 +25,7 @@
 
   org.apache.cassandra.diff
   diff
-  0.1-SNAPSHOT
+  0.2-SNAPSHOT
 
 
 4.0.0
@@ -51,4 +51,4 @@
 
 
 
-
\ No newline at end of file
+
diff --git a/pom.xml b/pom.xml
index 16b35b7..82bbf69 100644
--- a/pom.xml
+++ b/pom.xml
@@ -31,11 +31,12 @@
 org.apache.cassandra.diff
 diff
 pom
-0.1-SNAPSHOT
+0.2-SNAPSHOT
 
   common
   spark-job
   api-server
+  spark-uberjar
 
 
 
diff --git a/spark-job/pom.xml b/spark-job/pom.xml
index 4d4c8fc..c7df5bd 100644
--- a/spark-job/pom.xml
+++ b/spark-job/pom.xml
@@ -25,7 +25,7 @@
 
 org.apache.cassandra.diff
 diff
-0.1-SNAPSHOT
+0.2-SNAPSHOT
 
 
 4.0.0
@@ -68,34 +68,4 @@
 
 
 
-
-
-
-
-
-org.apache.maven.plugins
-maven-shade-plugin
-3.2.1
-
-
-
-package
-
-shade
-
-
-
-
-
-
-com.google
-relocated.com.google
-
-
-
-
-
-
-
-
 
diff --git a/spark-job/pom.xml b/spark-uberjar/pom.xml
similarity index 76%
copy from spark-job/pom.xml
copy to spark-uberjar/pom.xml
index 4d4c8fc..6bb31d7 100644
--- a/spark-job/pom.xml
+++ b/spark-uberjar/pom.xml
@@ -25,11 +25,11 @@
 
 org.apache.cassandra.diff
 diff
-0.1-SNAPSHOT
+0.2-SNAPSHOT
 
 
 4.0.0
-spark-job
+spark-uberjar
 jar
 
 
@@ -41,32 +41,11 @@
 ${project.parent.version}
 
 
-
 
-  org.jetbrains
-  annotations
-
-
-
-org.apache.spark
-spark-core_2.11
-2.3.3
-provided
-
-
-
-org.apache.spark
-spark-sql_2.11
-2.3.2
-provided
-
-
-
-
-junit
-junit
+org.apache.cassandra.diff
+spark-job
+${project.parent.version}
 
-
 
 
 


-
To unsubscribe, e-mail: 

[jira] [Updated] (CASSANDRA-15501) Duplicate results with DISTINCT queries in mixed mode 2.1/3.0

[Sam Tunnicliffe (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-15501:

Status: Ready to Commit  (was: Review In Progress)

LGTM +1

> Duplicate results with DISTINCT queries in mixed mode 2.1/3.0
> -
>
> Key: CASSANDRA-15501
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15501
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> When a client switches coordinator from a 2.1 node to a 3.0 node it sends a 
> 2.1 paging state to the 3.0 node. The 2.1 {{PagingState}} does not have 
> {{remainingInPartition}} so on the 3.0 side we default this to 
> Integer.MAX_VALUE. This value is then used to decide if the lastKey should be 
> included in the result.



--
This message was sent by Atlassian 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-15501) Duplicate results with DISTINCT queries in mixed mode 2.1/3.0

[Sam Tunnicliffe (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-15501:

Reviewers: Aleksey Yeschenko, Sam Tunnicliffe, Sam Tunnicliffe  (was: 
Aleksey Yeschenko, Sam Tunnicliffe)
   Aleksey Yeschenko, Sam Tunnicliffe, Sam Tunnicliffe  (was: 
Aleksey Yeschenko, Sam Tunnicliffe)
   Status: Review In Progress  (was: Patch Available)

> Duplicate results with DISTINCT queries in mixed mode 2.1/3.0
> -
>
> Key: CASSANDRA-15501
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15501
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> When a client switches coordinator from a 2.1 node to a 3.0 node it sends a 
> 2.1 paging state to the 3.0 node. The 2.1 {{PagingState}} does not have 
> {{remainingInPartition}} so on the 3.0 side we default this to 
> Integer.MAX_VALUE. This value is then used to decide if the lastKey should be 
> included in the result.



--
This message was sent by Atlassian 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-15501) Duplicate results with DISTINCT queries in mixed mode 2.1/3.0

[Marcus Eriksson (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-15501:

Test and Documentation Plan: new upgrade test & cci runs
 Status: Patch Available  (was: Open)

[patch|https://github.com/krummas/cassandra/commits/marcuse/distinct_duplicates]
 [tests|https://circleci.com/workflow-run/46f204cc-0a6c-4fa7-9e14-73b10e3afb20]

> Duplicate results with DISTINCT queries in mixed mode 2.1/3.0
> -
>
> Key: CASSANDRA-15501
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15501
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> When a client switches coordinator from a 2.1 node to a 3.0 node it sends a 
> 2.1 paging state to the 3.0 node. The 2.1 {{PagingState}} does not have 
> {{remainingInPartition}} so on the 3.0 side we default this to 
> Integer.MAX_VALUE. This value is then used to decide if the lastKey should be 
> included in the result.



--
This message was sent by Atlassian 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-15501) Duplicate results with DISTINCT queries in mixed mode 2.1/3.0

[Marcus Eriksson (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-15501:

 Bug Category: Parent values: Correctness(12982)Level 1 values: Transient 
Incorrect Response(12987)
   Complexity: Normal
  Component/s: Legacy/Core
Discovered By: Adhoc Test
Fix Version/s: 3.11.x
   3.0.x
Reviewers: Aleksey Yeschenko, Sam Tunnicliffe
 Severity: Normal
   Status: Open  (was: Triage Needed)

> Duplicate results with DISTINCT queries in mixed mode 2.1/3.0
> -
>
> Key: CASSANDRA-15501
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15501
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> When a client switches coordinator from a 2.1 node to a 3.0 node it sends a 
> 2.1 paging state to the 3.0 node. The 2.1 {{PagingState}} does not have 
> {{remainingInPartition}} so on the 3.0 side we default this to 
> Integer.MAX_VALUE. This value is then used to decide if the lastKey should be 
> included in the result.



--
This message was sent by Atlassian 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-15501) Duplicate results with DISTINCT queries in mixed mode 2.1/3.0

[Marcus Eriksson (Jira)]

Marcus Eriksson created CASSANDRA-15501:
---

 Summary: Duplicate results with DISTINCT queries in mixed mode 
2.1/3.0
 Key: CASSANDRA-15501
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15501
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson


When a client switches coordinator from a 2.1 node to a 3.0 node it sends a 2.1 
paging state to the 3.0 node. The 2.1 {{PagingState}} does not have 
{{remainingInPartition}} so on the 3.0 side we default this to 
Integer.MAX_VALUE. This value is then used to decide if the lastKey should be 
included in the result.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org