[jira] [Commented] (CASSANDRA-15389) Minimize BTree iterator allocations
[
https://issues.apache.org/jira/browse/CASSANDRA-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013314#comment-17013314
]
Benedict Elliott Smith commented on CASSANDRA-15389:
Sure, it's probably easier to show, so take a look at [this
branch|https://github.com/belliottsmith/cassandra/commits/15389-suggest]. It's
late and my OCD got the better of me, so I also tweaked the method parameter
order so that types of parameter are grouped together, separated by the
recipient type, i.e. they go {{accumulator, accumulatorArg, Comparator,
comparatorArg, initialValue}}. Debatably initialValue should go after
{{accumulatorArg}}, but it felt right to be consistently at the end. Feel free
to use/discard what you feel inclined towards.
> Minimize BTree iterator allocations
> ---
>
> Key: CASSANDRA-15389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15389
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Compaction
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 4.0
>
>
> Allocations of BTree iterators contribute a lot amount of garbage to the
> compaction and read paths.
> This patch removes most btree iterator allocations on hot paths by:
> • using Row#apply where appropriate on frequently called methods
> (Row#digest, Row#validateData
> • adding BTree accumulate method. Like the apply method, this method walks
> the btree with a function that takes and returns a long argument, this
> eliminates iterator allocations without adding helper object allocations
> (BTreeRow#hasComplex, BTreeRow#hasInvalidDeletions, BTreeRow#dataSize,
> BTreeRow#unsharedHeapSizeExcludingData, Rows#collectStats,
> UnfilteredSerializer#serializedRowBodySize) as well as eliminating the
> allocation of helper objects in places where apply was used previously^[1]^.
> • Create map of columns in SerializationHeader, this lets us avoid
> allocating a btree search iterator for each row we serialize.
> These optimizations reduce garbage created during compaction by up to 13.5%
>
> [1] the memory test does measure memory allocated by lambdas capturing objects
--
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-15389) Minimize BTree iterator allocations
[
https://issues.apache.org/jira/browse/CASSANDRA-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013307#comment-17013307
]
Blake Eggleston commented on CASSANDRA-15389:
-
{quote}Looking at your implementation I realise it’s possible to simply define
accept(Consumer c, V v) in terms of accept(BiConsumer c, V1 v1, V2
v2) by simply invoking accept(Consumer::accept, c, v), which should be more
than clear enough.
{quote}
I don’t follow. Could you provide some more detail about what you’re thinking?
> Minimize BTree iterator allocations
> ---
>
> Key: CASSANDRA-15389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15389
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Compaction
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 4.0
>
>
> Allocations of BTree iterators contribute a lot amount of garbage to the
> compaction and read paths.
> This patch removes most btree iterator allocations on hot paths by:
> • using Row#apply where appropriate on frequently called methods
> (Row#digest, Row#validateData
> • adding BTree accumulate method. Like the apply method, this method walks
> the btree with a function that takes and returns a long argument, this
> eliminates iterator allocations without adding helper object allocations
> (BTreeRow#hasComplex, BTreeRow#hasInvalidDeletions, BTreeRow#dataSize,
> BTreeRow#unsharedHeapSizeExcludingData, Rows#collectStats,
> UnfilteredSerializer#serializedRowBodySize) as well as eliminating the
> allocation of helper objects in places where apply was used previously^[1]^.
> • Create map of columns in SerializationHeader, this lets us avoid
> allocating a btree search iterator for each row we serialize.
> These optimizations reduce garbage created during compaction by up to 13.5%
>
> [1] the memory test does measure memory allocated by lambdas capturing objects
--
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-15389) Minimize BTree iterator allocations
[
https://issues.apache.org/jira/browse/CASSANDRA-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013294#comment-17013294
]
Benedict Elliott Smith edited comment on CASSANDRA-15389 at 1/11/20 12:44 AM:
--
very nice!
If we change the order of parameter provision to the {{BiLongAccumulator}}, we
can (if we want) do the same trick of just supplying
{{accumulate(LongAccumulator::apply, accumulator, initialValue)}} to keep only
one implementation without the extra (admittedly minor) obfuscation.
I still need to double check the fine details of a couple of the methods, but I
think we're pretty much close to done here.
was (Author: benedict):
very nice!
If we change the order of parameter provision to the BiLongAccumulator, we can
(if we want) do the same trick of just supplying
{{accumulate(LongAccumulator::apply, accumulator, initialValue)}} to keep only
one implementation without the extra (admittedly minor) obfuscation.
I still need to double check the fine details of a couple of the methods, but I
think we're pretty much close to done here.
> Minimize BTree iterator allocations
> ---
>
> Key: CASSANDRA-15389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15389
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Compaction
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 4.0
>
>
> Allocations of BTree iterators contribute a lot amount of garbage to the
> compaction and read paths.
> This patch removes most btree iterator allocations on hot paths by:
> • using Row#apply where appropriate on frequently called methods
> (Row#digest, Row#validateData
> • adding BTree accumulate method. Like the apply method, this method walks
> the btree with a function that takes and returns a long argument, this
> eliminates iterator allocations without adding helper object allocations
> (BTreeRow#hasComplex, BTreeRow#hasInvalidDeletions, BTreeRow#dataSize,
> BTreeRow#unsharedHeapSizeExcludingData, Rows#collectStats,
> UnfilteredSerializer#serializedRowBodySize) as well as eliminating the
> allocation of helper objects in places where apply was used previously^[1]^.
> • Create map of columns in SerializationHeader, this lets us avoid
> allocating a btree search iterator for each row we serialize.
> These optimizations reduce garbage created during compaction by up to 13.5%
>
> [1] the memory test does measure memory allocated by lambdas capturing objects
--
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-15389) Minimize BTree iterator allocations
[
https://issues.apache.org/jira/browse/CASSANDRA-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013294#comment-17013294
]
Benedict Elliott Smith commented on CASSANDRA-15389:
very nice!
If we change the order of parameter provision to the BiLongAccumulator, we can
(if we want) do the same trick of just supplying
{{accumulate(LongAccumulator::apply, accumulator, initialValue)}} to keep only
one implementation without the extra (admittedly minor) obfuscation.
I still need to double check the fine details of a couple of the methods, but I
think we're pretty much close to done here.
> Minimize BTree iterator allocations
> ---
>
> Key: CASSANDRA-15389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15389
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Compaction
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 4.0
>
>
> Allocations of BTree iterators contribute a lot amount of garbage to the
> compaction and read paths.
> This patch removes most btree iterator allocations on hot paths by:
> • using Row#apply where appropriate on frequently called methods
> (Row#digest, Row#validateData
> • adding BTree accumulate method. Like the apply method, this method walks
> the btree with a function that takes and returns a long argument, this
> eliminates iterator allocations without adding helper object allocations
> (BTreeRow#hasComplex, BTreeRow#hasInvalidDeletions, BTreeRow#dataSize,
> BTreeRow#unsharedHeapSizeExcludingData, Rows#collectStats,
> UnfilteredSerializer#serializedRowBodySize) as well as eliminating the
> allocation of helper objects in places where apply was used previously^[1]^.
> • Create map of columns in SerializationHeader, this lets us avoid
> allocating a btree search iterator for each row we serialize.
> These optimizations reduce garbage created during compaction by up to 13.5%
>
> [1] the memory test does measure memory allocated by lambdas capturing objects
--
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-15389) Minimize BTree iterator allocations
[ https://issues.apache.org/jira/browse/CASSANDRA-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013293#comment-17013293 ] Blake Eggleston commented on CASSANDRA-15389: - yep, forgot to commit it, it should be there now > Minimize BTree iterator allocations > --- > > Key: CASSANDRA-15389 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15389 > Project: Cassandra > Issue Type: Sub-task > Components: Local/Compaction >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0 > > > Allocations of BTree iterators contribute a lot amount of garbage to the > compaction and read paths. > This patch removes most btree iterator allocations on hot paths by: > • using Row#apply where appropriate on frequently called methods > (Row#digest, Row#validateData > • adding BTree accumulate method. Like the apply method, this method walks > the btree with a function that takes and returns a long argument, this > eliminates iterator allocations without adding helper object allocations > (BTreeRow#hasComplex, BTreeRow#hasInvalidDeletions, BTreeRow#dataSize, > BTreeRow#unsharedHeapSizeExcludingData, Rows#collectStats, > UnfilteredSerializer#serializedRowBodySize) as well as eliminating the > allocation of helper objects in places where apply was used previously^[1]^. > • Create map of columns in SerializationHeader, this lets us avoid > allocating a btree search iterator for each row we serialize. > These optimizations reduce garbage created during compaction by up to 13.5% > > [1] the memory test does measure memory allocated by lambdas capturing objects -- 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-15389) Minimize BTree iterator allocations
[
https://issues.apache.org/jira/browse/CASSANDRA-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013292#comment-17013292
]
Benedict Elliott Smith edited comment on CASSANDRA-15389 at 1/11/20 12:38 AM:
--
bq. Good idea about complex data accumulation in collect stats. I ended up
adding and using BiLongAccumulator to make all cases garbage free.
Sounds great! Though looking at the code currently posted, I think it’s still
capturing a reference to the {{collector}}? I think you may have simply not
posted your latest changes.
bq. This seems like it makes sense, but everything may just be looking like a
nail to me, so let me know if you have a better idea
My personal view is it's absolutely fine to duplicate code somewhere like this,
and I’ve done that in some patches I'll be posting soon. I think clarity for
the reader is also valuable, and if the methods are maintained next to each
other and clearly marked as copy/paste variants because we don't have a macro
language, I think that's fine and probably preferable.
However, I think in this case it's fine either way. Looking at your
implementation I realise it’s possible to simply define {{accept(Consumer c,
V v)}} in terms of {{accept(BiConsumer c, V1 v1, V2 v2)}} by simply
invoking {{accept(Consumer::accept, c, v)}}, which should be more than clear
enough.
It’s a shame this is a recursive function so we won’t be able to benefit from
inlining, and will probably incur an extra virtual invocation cost. It might
be that we anyway win by splitting implementations, but it may not be worth
overthinking.
Other random thoughts:
* I think it might be helpful to treat {{apply}} to the same restructure you’ve
done to {{accumulate}} - which helped me a great deal in reading that.
* {{isStopSentinel}}: do we use {{Long.MIN_VALUE}} anymore? Should we also
consider optionally permitting a stop sentinel to be provided, so we can make
{{minDeletionTime}} more efficient? I don’t think we have anywhere that needs
more than one stop sentinel anymore, so I think it’s probably an acceptable
complication.
* nit: {{ComplexColumnData.accumulate}} should we call the parameter e.g.
{{initialValue}} to distinguish it from those {{accumulate}} methods that take
a value to start from in the tree?
was (Author: benedict):
bq. Good idea about complex data accumulation in collect stats. I ended up
adding and using BiLongAccumulator to make all cases garbage free.
Sounds great! Though looking at the code currently posted, I think it’s still
capturing a reference to the {{collector}}? I think you may have simply not
posted your latest changes.
bq. This seems like it makes sense, but everything may just be looking like a
nail to me, so let me know if you have a better idea
My personal view is it's absolutely fine to duplicate code somewhere like this,
and I’ve done that in some patches I'll be posting soon. I think clarity for
the reader is also valuable, and if the methods are maintained next to each
other and clearly marked as copy/paste variants because we don't have a macro
language, I think that's fine and probably preferable.
However, I think in this case it's fine either way. Looking at your
implementation I realise it’s possible to simply define {{accept(Consumer c,
V v)}} in terms of {{accept(BiConsumer c, V1 v1, V2 v2)}} by simply
invoking {{accept(Consumer::accept, c, v)}}, which should be more than clear
enough.
It’s a shame this is a recursive function so we won’t be able to benefit from
inlining, and will probably incur an extra virtual invocation cost. It might
be that we anyway win by splitting implementations, but it may not be worth
overthinking.
FWIW, I think it might be helpful to treat {{apply}} to the same restructure
you’ve done to {{accumulate}} - which helped me a great deal in reading that.
{{isStopSentinel}}: do we use {{Long.MIN_VALUE}} anymore? Should we also
consider optionally permitting a stop sentinel to be provided, so we can make
{{minDeletionTime}} more efficient? I don’t think we have anywhere that needs
more than one stop sentinel anymore, so I think it’s probably an acceptable
complication.
nit: {{ComplexColumnData.accumulate}} should we call the parameter e.g.
{{initialValue}} to distinguish it from those {{accumulate}} methods that take
a value to start from in the tree?
> Minimize BTree iterator allocations
> ---
>
> Key: CASSANDRA-15389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15389
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Compaction
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 4.0
>
>
> Allocations of BTree iterators contribute a lot amount
[jira] [Commented] (CASSANDRA-15389) Minimize BTree iterator allocations
[
https://issues.apache.org/jira/browse/CASSANDRA-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013292#comment-17013292
]
Benedict Elliott Smith commented on CASSANDRA-15389:
bq. Good idea about complex data accumulation in collect stats. I ended up
adding and using BiLongAccumulator to make all cases garbage free.
Sounds great! Though looking at the code currently posted, I think it’s still
capturing a reference to the {{collector}}? I think you may have simply not
posted your latest changes.
bq. This seems like it makes sense, but everything may just be looking like a
nail to me, so let me know if you have a better idea
My personal view is it's absolutely fine to duplicate code somewhere like this,
and I’ve done that in some patches I'll be posting soon. I think clarity for
the reader is also valuable, and if the methods are maintained next to each
other and clearly marked as copy/paste variants because we don't have a macro
language, I think that's fine and probably preferable.
However, I think in this case it's fine either way. Looking at your
implementation I realise it’s possible to simply define {{accept(Consumer c,
V v)}} in terms of {{accept(BiConsumer c, V1 v1, V2 v2)}} by simply
invoking {{accept(Consumer::accept, c, v)}}, which should be more than clear
enough.
It’s a shame this is a recursive function so we won’t be able to benefit from
inlining, and will probably incur an extra virtual invocation cost. It might
be that we anyway win by splitting implementations, but it may not be worth
overthinking.
FWIW, I think it might be helpful to treat {{apply}} to the same restructure
you’ve done to {{accumulate}} - which helped me a great deal in reading that.
{{isStopSentinel}}: do we use {{Long.MIN_VALUE}} anymore? Should we also
consider optionally permitting a stop sentinel to be provided, so we can make
{{minDeletionTime}} more efficient? I don’t think we have anywhere that needs
more than one stop sentinel anymore, so I think it’s probably an acceptable
complication.
nit: {{ComplexColumnData.accumulate}} should we call the parameter e.g.
{{initialValue}} to distinguish it from those {{accumulate}} methods that take
a value to start from in the tree?
> Minimize BTree iterator allocations
> ---
>
> Key: CASSANDRA-15389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15389
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Compaction
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 4.0
>
>
> Allocations of BTree iterators contribute a lot amount of garbage to the
> compaction and read paths.
> This patch removes most btree iterator allocations on hot paths by:
> • using Row#apply where appropriate on frequently called methods
> (Row#digest, Row#validateData
> • adding BTree accumulate method. Like the apply method, this method walks
> the btree with a function that takes and returns a long argument, this
> eliminates iterator allocations without adding helper object allocations
> (BTreeRow#hasComplex, BTreeRow#hasInvalidDeletions, BTreeRow#dataSize,
> BTreeRow#unsharedHeapSizeExcludingData, Rows#collectStats,
> UnfilteredSerializer#serializedRowBodySize) as well as eliminating the
> allocation of helper objects in places where apply was used previously^[1]^.
> • Create map of columns in SerializationHeader, this lets us avoid
> allocating a btree search iterator for each row we serialize.
> These optimizations reduce garbage created during compaction by up to 13.5%
>
> [1] the memory test does measure memory allocated by lambdas capturing objects
--
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-15389) Minimize BTree iterator allocations
[ https://issues.apache.org/jira/browse/CASSANDRA-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013279#comment-17013279 ] Blake Eggleston commented on CASSANDRA-15389: - ok I think I’ve addressed everything here, a few notes: * I’ve added BiFunction / BiLongAccumulator support, making AbstractRow#digest and Rows#collectStats garbage free. Again, using the accessor pattern here to avoid duplicated code. This seems like it makes sense, but everything may just be looking like a nail to me, so let me know if you have a better idea. * In addition to removing the null check from hasInvalidDeletions, we now also stop accumulating as soon as we find an invalid deletion * Good idea about complex data accumulation in collect stats. I ended up adding and using BiLongAccumulator to make all cases garbage free. > Minimize BTree iterator allocations > --- > > Key: CASSANDRA-15389 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15389 > Project: Cassandra > Issue Type: Sub-task > Components: Local/Compaction >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0 > > > Allocations of BTree iterators contribute a lot amount of garbage to the > compaction and read paths. > This patch removes most btree iterator allocations on hot paths by: > • using Row#apply where appropriate on frequently called methods > (Row#digest, Row#validateData > • adding BTree accumulate method. Like the apply method, this method walks > the btree with a function that takes and returns a long argument, this > eliminates iterator allocations without adding helper object allocations > (BTreeRow#hasComplex, BTreeRow#hasInvalidDeletions, BTreeRow#dataSize, > BTreeRow#unsharedHeapSizeExcludingData, Rows#collectStats, > UnfilteredSerializer#serializedRowBodySize) as well as eliminating the > allocation of helper objects in places where apply was used previously^[1]^. > • Create map of columns in SerializationHeader, this lets us avoid > allocating a btree search iterator for each row we serialize. > These optimizations reduce garbage created during compaction by up to 13.5% > > [1] the memory test does measure memory allocated by lambdas capturing objects -- 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: ninja-fix: not all the test targets exist on previous branches (CASSANDRA-15496)
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 98b16ae ninja-fix: not all the test targets exist on previous
branches (CASSANDRA-15496)
98b16ae is described below
commit 98b16aedabf38f5e314c0f7401ec855e263d24ce
Author: mck
AuthorDate: Fri Jan 10 20:35:27 2020 +0100
ninja-fix: not all the test targets exist on previous branches
(CASSANDRA-15496)
---
jenkins-dsl/cassandra_job_dsl_seed.groovy | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index 5ca843a..bf665bd 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -319,9 +319,14 @@ cassandraBranches.each {
triggerInterval = '@weekly'
}
-// Skip test-cdc on cassandra-2.2 and cassandra-3.0 branches
-if ((targetName == 'test-cdc') && ((branchName == 'cassandra-2.2') ||
(branchName == 'cassandra-3.0'))) {
+// Skip tests that don't exist before cassandra-3.11
+if ((targetName == 'test-cdc' || targetName == 'stress-test') &&
((branchName == 'cassandra-2.2') || (branchName == 'cassandra-3.0'))) {
println("Skipping ${targetName} on branch ${branchName}")
+
+// Skip tests that don't exist before cassandra-4.0
+} else if ((targetName == 'fqltool-test') && ((branchName ==
'cassandra-2.2') || (branchName == 'cassandra-3.0') || (branchName ==
'cassandra-3.11'))) {
+println("Skipping ${targetName} on branch ${branchName}")
+
} else {
job("${jobNamePrefix}-${targetName}") {
disabled(false)
-
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
[
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013139#comment-17013139
]
Benedict Elliott Smith commented on CASSANDRA-15213:
I'm inclined to agree that a simple approach is best, and simply offering a
tunable parameter to modify the number of stripes on startup might be
sufficient. Here's some further minor feedback/suggestions:
# It's faster to use {{addAndGet}} than {{compareAndSet}} because it's
guaranteed to succeed - the increment occurs whilst holding the cache line in
an exclusive state, so it will always execute as quickly as the first failed
{{compareAndSet}}
# Combined with this, it probably makes most sense to pick a "random" bucket
using e.g. {{Thread.currentThread().getId() & (stripes-1)}}, to always increment
# Finally, it might make sense to "shuffle" the ordinary buckets as well, so
that logically adjacent buckets are not spatially adjacent; since a histogram
is _likely_ to receive updates to mostly oscillating around a given median
point, this means there won't be any false-sharing competition between two
updates to two logically adjacent buckets
I think at this point it then makes most sense to improve the benchmarks, in
one case to account for memory latency of lookup, and in another to produce
more realistic distributions of values.
> 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
[cassandra-dtest] branch master updated: Integrate SJK into nodetool
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 a83ede4 Integrate SJK into nodetool
a83ede4 is described below
commit a83ede433c9737aa0088cbd6092e6d1651290d10
Author: Ekaterina Dimitrova
AuthorDate: Tue Jan 7 13:55:51 2020 -0500
Integrate SJK into nodetool
Patch by Ekaterina Dimitrov, reviewed by brandonwilliams for
CASSANDRA-12197
---
nodetool_test.py | 34 ++
1 file changed, 34 insertions(+)
diff --git a/nodetool_test.py b/nodetool_test.py
index 012780b..381e917 100644
--- a/nodetool_test.py
+++ b/nodetool_test.py
@@ -445,3 +445,37 @@ class TestNodetool(Tester):
out_sorted = node_describe.split()
out_sorted.sort()
return (node_describe, out_sorted)
+
+@since('4.0')
+def test_sjk(self):
+"""
+Verify that SJK generally works.
+"""
+
+cluster = self.cluster
+cluster.populate([1]).start()
+node = cluster.nodelist()[0]
+
+out, err, _ = node.nodetool('sjk --help')
+logger.debug(out)
+hasPattern = False
+for line in out.split(os.linesep):
+if "ttop [Thread Top] Displays threads from JVM process"
== line:
+hasPattern = True
+assert hasPattern == True, "Expected help about SJK ttop"
+
+out, err, _ = node.nodetool('sjk')
+logger.debug(out)
+hasPattern = False
+for line in out.split(os.linesep):
+if "ttop [Thread Top] Displays threads from JVM process"
== line:
+hasPattern = True
+assert hasPattern == True, "Expected help about SJK ttop"
+
+out, err, _ = node.nodetool('sjk hh -n 10 --live')
+logger.debug(out)
+hasPattern = False
+for line in out.split(os.linesep):
+if re.match('.*Instances.*Bytes.*Type.*', line):
+hasPattern = True
+assert hasPattern == True, "Expected 'SJK hh' output"
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15498) Empty clustering instead of Clustering.EMPTY
[ https://issues.apache.org/jira/browse/CASSANDRA-15498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15498: - Fix Version/s: (was: 4.x) 4.0-alpha Since Version: 3.11.0 Source Control Link: https://github.com/apache/cassandra/commit/c6544fd200d1965b08ae2c40d2f9fd756a4367a9 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed. > Empty clustering instead of Clustering.EMPTY > > > Key: CASSANDRA-15498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > Attachments: Screen Shot 2020-01-10 at 1.03.19 PM.png, Screen Shot > 2020-01-10 at 1.03.36 PM.png, Screen Shot 2020-01-10 at 1.03.53 PM.png > > > It seems that there are several ways to produce an empty clustering (with > Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when > copying another empty clustering (such as Clustering.EMPTY) , and also during > deserialization when calling to Clustering.make -- 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-15498) Empty clustering instead of Clustering.EMPTY
[ https://issues.apache.org/jira/browse/CASSANDRA-15498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15498: - Status: Ready to Commit (was: Review In Progress) > Empty clustering instead of Clustering.EMPTY > > > Key: CASSANDRA-15498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > Attachments: Screen Shot 2020-01-10 at 1.03.19 PM.png, Screen Shot > 2020-01-10 at 1.03.36 PM.png, Screen Shot 2020-01-10 at 1.03.53 PM.png > > > It seems that there are several ways to produce an empty clustering (with > Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when > copying another empty clustering (such as Clustering.EMPTY) , and also during > deserialization when calling to Clustering.make -- 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-15498) Empty clustering instead of Clustering.EMPTY
[ https://issues.apache.org/jira/browse/CASSANDRA-15498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15498: - Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams) Brandon Williams, Brandon Williams (was: Brandon Williams) Status: Review In Progress (was: Patch Available) > Empty clustering instead of Clustering.EMPTY > > > Key: CASSANDRA-15498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > Attachments: Screen Shot 2020-01-10 at 1.03.19 PM.png, Screen Shot > 2020-01-10 at 1.03.36 PM.png, Screen Shot 2020-01-10 at 1.03.53 PM.png > > > It seems that there are several ways to produce an empty clustering (with > Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when > copying another empty clustering (such as Clustering.EMPTY) , and also during > deserialization when calling to Clustering.make -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Ensure that empty clusterings with kind==CLUSTERING are Clustering.EMPTY
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new c6544fd Ensure that empty clusterings with kind==CLUSTERING are
Clustering.EMPTY
c6544fd is described below
commit c6544fd200d1965b08ae2c40d2f9fd756a4367a9
Author: Ekaterina Dimitrova
AuthorDate: Fri Jan 3 19:10:01 2020 -0500
Ensure that empty clusterings with kind==CLUSTERING are Clustering.EMPTY
Patch by Ekaterina Dimitrova, reviewed by brandonwilliams for
CASSANDRA-15498
---
CHANGES.txt| 1 +
.../org/apache/cassandra/db/AbstractBufferClusteringPrefix.java| 5 ++---
src/java/org/apache/cassandra/db/Clustering.java | 7 +--
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 3540115..9378900 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -12,6 +12,7 @@
* 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)
diff --git
a/src/java/org/apache/cassandra/db/AbstractBufferClusteringPrefix.java
b/src/java/org/apache/cassandra/db/AbstractBufferClusteringPrefix.java
index 95bc777..dd4a095 100644
--- a/src/java/org/apache/cassandra/db/AbstractBufferClusteringPrefix.java
+++ b/src/java/org/apache/cassandra/db/AbstractBufferClusteringPrefix.java
@@ -24,7 +24,6 @@ import org.apache.cassandra.utils.ObjectSizes;
public abstract class AbstractBufferClusteringPrefix extends
AbstractClusteringPrefix
{
public static final ByteBuffer[] EMPTY_VALUES_ARRAY = new ByteBuffer[0];
-private static final long EMPTY_SIZE =
ObjectSizes.measure(Clustering.make(EMPTY_VALUES_ARRAY));
protected final Kind kind;
protected final ByteBuffer[] values;
@@ -62,11 +61,11 @@ public abstract class AbstractBufferClusteringPrefix
extends AbstractClusteringP
public long unsharedHeapSize()
{
-return EMPTY_SIZE + ObjectSizes.sizeOnHeapOf(values);
+return Clustering.EMPTY_SIZE + ObjectSizes.sizeOnHeapOf(values);
}
public long unsharedHeapSizeExcludingData()
{
-return EMPTY_SIZE + ObjectSizes.sizeOnHeapExcludingData(values);
+return Clustering.EMPTY_SIZE +
ObjectSizes.sizeOnHeapExcludingData(values);
}
}
diff --git a/src/java/org/apache/cassandra/db/Clustering.java
b/src/java/org/apache/cassandra/db/Clustering.java
index e585a8f..451a087 100644
--- a/src/java/org/apache/cassandra/db/Clustering.java
+++ b/src/java/org/apache/cassandra/db/Clustering.java
@@ -29,12 +29,15 @@ import org.apache.cassandra.io.util.DataInputBuffer;
import org.apache.cassandra.io.util.DataInputPlus;
import org.apache.cassandra.io.util.DataOutputBuffer;
import org.apache.cassandra.io.util.DataOutputPlus;
+import org.apache.cassandra.utils.ObjectSizes;
import org.apache.cassandra.utils.memory.AbstractAllocator;
import static
org.apache.cassandra.db.AbstractBufferClusteringPrefix.EMPTY_VALUES_ARRAY;
public interface Clustering extends ClusteringPrefix
{
+static final long EMPTY_SIZE = ObjectSizes.measure(new
BufferClustering(EMPTY_VALUES_ARRAY));
+
public static final Serializer serializer = new Serializer();
public long unsharedHeapSizeExcludingData();
@@ -43,7 +46,7 @@ public interface Clustering extends ClusteringPrefix
{
// Important for STATIC_CLUSTERING (but must copy empty native
clustering types).
if (size() == 0)
-return kind() == Kind.STATIC_CLUSTERING ? this : new
BufferClustering(EMPTY_VALUES_ARRAY);
+return kind() == Kind.STATIC_CLUSTERING ? this : EMPTY;
ByteBuffer[] newValues = new ByteBuffer[size()];
for (int i = 0; i < size(); i++)
@@ -78,7 +81,7 @@ public interface Clustering extends ClusteringPrefix
public static Clustering make(ByteBuffer... values)
{
-return new BufferClustering(values);
+return values.length == 0 ? EMPTY : new BufferClustering(values);
}
/**
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15498) Empty clustering instead of Clustering.EMPTY
[ https://issues.apache.org/jira/browse/CASSANDRA-15498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15498: Test and Documentation Plan: Screenshots from the CI attached Status: Patch Available (was: In Progress) > Empty clustering instead of Clustering.EMPTY > > > Key: CASSANDRA-15498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > Attachments: Screen Shot 2020-01-10 at 1.03.19 PM.png, Screen Shot > 2020-01-10 at 1.03.36 PM.png, Screen Shot 2020-01-10 at 1.03.53 PM.png > > > It seems that there are several ways to produce an empty clustering (with > Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when > copying another empty clustering (such as Clustering.EMPTY) , and also during > deserialization when calling to Clustering.make -- 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-15498) Empty clustering instead of Clustering.EMPTY
[ https://issues.apache.org/jira/browse/CASSANDRA-15498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15498: Attachment: Screen Shot 2020-01-10 at 1.03.53 PM.png Screen Shot 2020-01-10 at 1.03.36 PM.png Screen Shot 2020-01-10 at 1.03.19 PM.png > Empty clustering instead of Clustering.EMPTY > > > Key: CASSANDRA-15498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > Attachments: Screen Shot 2020-01-10 at 1.03.19 PM.png, Screen Shot > 2020-01-10 at 1.03.36 PM.png, Screen Shot 2020-01-10 at 1.03.53 PM.png > > > It seems that there are several ways to produce an empty clustering (with > Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when > copying another empty clustering (such as Clustering.EMPTY) , and also during > deserialization when calling to Clustering.make -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: update changes
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 74e4b53 update changes 74e4b53 is described below commit 74e4b53c5e6dd4940f8677f05b4b6ba8f6c25882 Author: Brandon Williams AuthorDate: Fri Jan 10 11:55:03 2020 -0600 update changes --- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGES.txt b/CHANGES.txt index 8e5907d..3540115 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -11,6 +11,7 @@ * 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) 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) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15498) Empty clustering instead of Clustering.EMPTY
[ https://issues.apache.org/jira/browse/CASSANDRA-15498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013092#comment-17013092 ] Ekaterina Dimitrova commented on CASSANDRA-15498: - Patch for trunk added [here|https://github.com/ekaterinadimitrova2/cassandra/tree/13595-continue]. Pull request ready for review: [here|https://github.com/ekaterinadimitrova2/cassandra/pull/12] > Empty clustering instead of Clustering.EMPTY > > > Key: CASSANDRA-15498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > It seems that there are several ways to produce an empty clustering (with > Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when > copying another empty clustering (such as Clustering.EMPTY) , and also during > deserialization when calling to Clustering.make -- 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-15498) Empty clustering instead of Clustering.EMPTY
[ https://issues.apache.org/jira/browse/CASSANDRA-15498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15498: Bug Category: Parent values: Correctness(12982) Complexity: Normal Discovered By: User Report Platform: (was: All) Reviewers: Brandon Williams Severity: Normal Status: Open (was: Triage Needed) > Empty clustering instead of Clustering.EMPTY > > > Key: CASSANDRA-15498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > It seems that there are several ways to produce an empty clustering (with > Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when > copying another empty clustering (such as Clustering.EMPTY) , and also during > deserialization when calling to Clustering.make -- 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-12197) Integrate top threads command in nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-12197: - Source Control Link: https://github.com/apache/cassandra/commit/82dc72088f85c7ed7ac7b74ae62cf2b751c8bb64 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks! > Integrate top threads command in nodetool > - > > Key: CASSANDRA-12197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12197 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: J.B. Langston >Assignee: Ekaterina Dimitrova >Priority: Low > Labels: pull-request-available > Fix For: 4.0 > > Attachments: Screen Shot 2020-01-07 at 10.26.51 AM.png, Screen Shot > 2020-01-07 at 10.27.24 AM.png, Screen Shot 2020-01-07 at 10.30.31 AM.png, > Screen Shot 2020-01-10 at 12.32.34 PM.png, Screen Shot 2020-01-10 at 12.32.56 > PM.png, Screen Shot 2020-01-10 at 12.33.16 PM.png > > Time Spent: 10m > Remaining Estimate: 0h > > SJK (https://github.com/aragozin/jvm-tools) has a command called ttop that > displays the top threads within the JVM, sorted either by CPU utilization or > heap allocation rate. When diagnosing garbage collection or high cpu > utilization, this is very helpful information. It would be great if users > can get this directly with nodetool without having to download something > else. SJK is Apache 2.0 licensed so it might be possible leverage its code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12197) Integrate top threads command in nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-12197: - Status: Ready to Commit (was: Review In Progress) > Integrate top threads command in nodetool > - > > Key: CASSANDRA-12197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12197 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: J.B. Langston >Assignee: Ekaterina Dimitrova >Priority: Low > Labels: pull-request-available > Fix For: 4.0 > > Attachments: Screen Shot 2020-01-07 at 10.26.51 AM.png, Screen Shot > 2020-01-07 at 10.27.24 AM.png, Screen Shot 2020-01-07 at 10.30.31 AM.png, > Screen Shot 2020-01-10 at 12.32.34 PM.png, Screen Shot 2020-01-10 at 12.32.56 > PM.png, Screen Shot 2020-01-10 at 12.33.16 PM.png > > Time Spent: 10m > Remaining Estimate: 0h > > SJK (https://github.com/aragozin/jvm-tools) has a command called ttop that > displays the top threads within the JVM, sorted either by CPU utilization or > heap allocation rate. When diagnosing garbage collection or high cpu > utilization, this is very helpful information. It would be great if users > can get this directly with nodetool without having to download something > else. SJK is Apache 2.0 licensed so it might be possible leverage its code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12197) Integrate top threads command in nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-12197: - Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams) Brandon Williams, Brandon Williams Status: Review In Progress (was: Patch Available) > Integrate top threads command in nodetool > - > > Key: CASSANDRA-12197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12197 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: J.B. Langston >Assignee: Ekaterina Dimitrova >Priority: Low > Labels: pull-request-available > Fix For: 4.0 > > Attachments: Screen Shot 2020-01-07 at 10.26.51 AM.png, Screen Shot > 2020-01-07 at 10.27.24 AM.png, Screen Shot 2020-01-07 at 10.30.31 AM.png, > Screen Shot 2020-01-10 at 12.32.34 PM.png, Screen Shot 2020-01-10 at 12.32.56 > PM.png, Screen Shot 2020-01-10 at 12.33.16 PM.png > > Time Spent: 10m > Remaining Estimate: 0h > > SJK (https://github.com/aragozin/jvm-tools) has a command called ttop that > displays the top threads within the JVM, sorted either by CPU utilization or > heap allocation rate. When diagnosing garbage collection or high cpu > utilization, this is very helpful information. It would be great if users > can get this directly with nodetool without having to download something > else. SJK is Apache 2.0 licensed so it might be possible leverage its code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Integrate SJK into nodetool
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 82dc720 Integrate SJK into nodetool 82dc720 is described below commit 82dc72088f85c7ed7ac7b74ae62cf2b751c8bb64 Author: Ekaterina Dimitrova AuthorDate: Thu Nov 21 09:51:33 2019 -0500 Integrate SJK into nodetool Patch by Ekaterina Dimotrova, reviewed by brandonwilliams for CASSANDRA-12197 --- build.xml | 25 +- lib/jcommander-1.30.jar| Bin 0 -> 60376 bytes lib/jvm-attach-api-1.5.jar | Bin 0 -> 76025 bytes lib/licenses/LICENSE-2.0.txt | 202 + lib/mxdump-0.14.jar| Bin 0 -> 7377 bytes lib/sjk-cli-0.14.jar | Bin 0 -> 14194 bytes lib/sjk-core-0.14.jar | Bin 0 -> 257437 bytes lib/sjk-json-0.14.jar | Bin 0 -> 40456 bytes lib/sjk-stacktrace-0.14.jar| Bin 0 -> 267577 bytes src/java/org/apache/cassandra/tools/NodeProbe.java | 18 +- src/java/org/apache/cassandra/tools/NodeTool.java | 2 + .../org/apache/cassandra/tools/nodetool/Sjk.java | 485 + .../apache/cassandra/tools/nodetool/TpStats.java | 2 + 13 files changed, 732 insertions(+), 2 deletions(-) diff --git a/build.xml b/build.xml index 0050b30..a458023 100644 --- a/build.xml +++ b/build.xml @@ -583,6 +583,15 @@ + + + + + + + + + @@ -653,6 +662,13 @@ + + + + + + + @@ -764,7 +780,14 @@ - + + + + + + + + http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on
[jira] [Updated] (CASSANDRA-15498) Empty clustering instead of Clustering.EMPTY
[ https://issues.apache.org/jira/browse/CASSANDRA-15498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15498: Fix Version/s: 4.x > Empty clustering instead of Clustering.EMPTY > > > Key: CASSANDRA-15498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > It seems that there are several ways to produce an empty clustering (with > Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when > copying another empty clustering (such as Clustering.EMPTY) , and also during > deserialization when calling to Clustering.make -- 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-15498) Empty clustering instead of Clustering.EMPTY
Ekaterina Dimitrova created CASSANDRA-15498: --- Summary: Empty clustering instead of Clustering.EMPTY Key: CASSANDRA-15498 URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 Project: Cassandra Issue Type: Bug Components: Legacy/Local Write-Read Paths Reporter: Ekaterina Dimitrova It seems that there are several ways to produce an empty clustering (with Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when copying another empty clustering (such as Clustering.EMPTY) , and also during deserialization when calling to Clustering.make -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15498) Empty clustering instead of Clustering.EMPTY
[ https://issues.apache.org/jira/browse/CASSANDRA-15498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-15498: --- Assignee: Ekaterina Dimitrova > Empty clustering instead of Clustering.EMPTY > > > Key: CASSANDRA-15498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15498 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > It seems that there are several ways to produce an empty clustering (with > Kind.CLUSTERING) without using Clustering.EMPTY. They can be produced when > copying another empty clustering (such as Clustering.EMPTY) , and also during > deserialization when calling to Clustering.make -- 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-13917) COMPACT STORAGE queries on dense static tables accept hidden column1 and value columns
[
https://issues.apache.org/jira/browse/CASSANDRA-13917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-13917:
-
Status: Open (was: Resolved)
Re-opening because this patch breaks things badly. Did you run the tests after
the move of {{isHiddenColumn}} to {{getColumnDefinition}}? Because if so, our
tests aren't very good.
The committed version, that move {{isHiddenColumn}} to {{getColumnDefinition}},
means the compact column is invisible internally, which is wrong, it must be
accessible internally.
Concretely, a simple test that creates a 2ndary index, wait for it to be built,
and then restart the node will fail on restart with
{noformat}
java.lang.RuntimeException: Unknown column value during deserialization
at
org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:353)
~[main/:na]
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:496)
~[main/:na]
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:365)
~[main/:na]
at
org.apache.cassandra.io.sstable.format.SSTableReader$2.run(SSTableReader.java:544)
~[main/:na]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_152]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[na:1.8.0_152]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[na:1.8.0_152]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[na:1.8.0_152]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
[main/:na]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_152]
{noformat}
because the {{SystemKeyspace.BUILT_INDEXES}} table is compact, so when it tries
to open the header of the sstables for this table, the {{getColumnDefinition}}
returns {{null}} for the {{value}} column, even though it obviously exists and
should be returned.
> COMPACT STORAGE queries on dense static tables accept hidden column1 and
> value columns
> --
>
> Key: CASSANDRA-13917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13917
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Alex Petrov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Labels: lhf
> Fix For: 3.0.x, 3.11.x
>
> Attachments: 13917-3.0-testall-13.12.2019, 13917-3.0-testall-2.png,
> 13917-3.0-testall-20.11.2019.png, 13917-3.0.png,
> 13917-3.11-testall-13.12.2019, 13917-3.11-testall-2.png,
> 13917-3.11-testall-20.11.2019.png, 13917-3.11.png
>
>
> Test for the issue:
> {code}
> @Test
> public void testCompactStorage() throws Throwable
> {
> createTable("CREATE TABLE %s (a int PRIMARY KEY, b int, c int) WITH
> COMPACT STORAGE");
> assertInvalid("INSERT INTO %s (a, b, c, column1) VALUES (?, ?, ?,
> ?)", 1, 1, 1, ByteBufferUtil.bytes('a'));
> // This one fails with Some clustering keys are missing: column1,
> which is still wrong
> assertInvalid("INSERT INTO %s (a, b, c, value) VALUES (?, ?, ?, ?)",
> 1, 1, 1, ByteBufferUtil.bytes('a'));
> assertInvalid("INSERT INTO %s (a, b, c, column1, value) VALUES (?, ?,
> ?, ?, ?)", 1, 1, 1, ByteBufferUtil.bytes('a'), ByteBufferUtil.bytes('b'));
> assertEmpty(execute("SELECT * FROM %s"));
> }
> {code}
> Gladly, these writes are no-op, even though they succeed.
> {{value}} and {{column1}} should be completely hidden. Fixing this one should
> be as easy as just adding validations.
--
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-12197) Integrate top threads command in nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013084#comment-17013084 ] Ekaterina Dimitrova commented on CASSANDRA-12197: - Thanks [~brandon.williams] Corrected. Also CI completed successfully after rebase. Results attached as screenshots. I think it is ready for commit. Please check. > Integrate top threads command in nodetool > - > > Key: CASSANDRA-12197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12197 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: J.B. Langston >Assignee: Ekaterina Dimitrova >Priority: Low > Labels: pull-request-available > Fix For: 4.0 > > Attachments: Screen Shot 2020-01-07 at 10.26.51 AM.png, Screen Shot > 2020-01-07 at 10.27.24 AM.png, Screen Shot 2020-01-07 at 10.30.31 AM.png, > Screen Shot 2020-01-10 at 12.32.34 PM.png, Screen Shot 2020-01-10 at 12.32.56 > PM.png, Screen Shot 2020-01-10 at 12.33.16 PM.png > > Time Spent: 10m > Remaining Estimate: 0h > > SJK (https://github.com/aragozin/jvm-tools) has a command called ttop that > displays the top threads within the JVM, sorted either by CPU utilization or > heap allocation rate. When diagnosing garbage collection or high cpu > utilization, this is very helpful information. It would be great if users > can get this directly with nodetool without having to download something > else. SJK is Apache 2.0 licensed so it might be possible leverage its code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12197) Integrate top threads command in nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-12197: Attachment: Screen Shot 2020-01-10 at 12.33.16 PM.png Screen Shot 2020-01-10 at 12.32.56 PM.png Screen Shot 2020-01-10 at 12.32.34 PM.png > Integrate top threads command in nodetool > - > > Key: CASSANDRA-12197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12197 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: J.B. Langston >Assignee: Ekaterina Dimitrova >Priority: Low > Labels: pull-request-available > Fix For: 4.0 > > Attachments: Screen Shot 2020-01-07 at 10.26.51 AM.png, Screen Shot > 2020-01-07 at 10.27.24 AM.png, Screen Shot 2020-01-07 at 10.30.31 AM.png, > Screen Shot 2020-01-10 at 12.32.34 PM.png, Screen Shot 2020-01-10 at 12.32.56 > PM.png, Screen Shot 2020-01-10 at 12.33.16 PM.png > > Time Spent: 10m > Remaining Estimate: 0h > > SJK (https://github.com/aragozin/jvm-tools) has a command called ttop that > displays the top threads within the JVM, sorted either by CPU utilization or > heap allocation rate. When diagnosing garbage collection or high cpu > utilization, this is very helpful information. It would be great if users > can get this directly with nodetool without having to download something > else. SJK is Apache 2.0 licensed so it might be possible leverage its code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15497) Implement node bootstrap in in-JVM tests
[ https://issues.apache.org/jira/browse/CASSANDRA-15497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15497: Change Category: Quality Assurance Complexity: Normal Priority: High (was: Normal) Status: Open (was: Triage Needed) > Implement node bootstrap in in-JVM tests > > > Key: CASSANDRA-15497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15497 > Project: Cassandra > Issue Type: New Feature > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > > Currently, we do not have an ability to add nodes to the running in-jvm > cluster, either by bootstrap or replacement process. We need to add an > ability to add nodes in inactive state, start them up, and bootstrap to test > streaming, range movements, and operations that occur during these processes. -- 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-15497) Implement node bootstrap in in-JVM tests
Alex Petrov created CASSANDRA-15497: --- Summary: Implement node bootstrap in in-JVM tests Key: CASSANDRA-15497 URL: https://issues.apache.org/jira/browse/CASSANDRA-15497 Project: Cassandra Issue Type: New Feature Components: Test/dtest Reporter: Alex Petrov Assignee: Alex Petrov Currently, we do not have an ability to add nodes to the running in-jvm cluster, either by bootstrap or replacement process. We need to add an ability to add nodes in inactive state, start them up, and bootstrap to test streaming, range movements, and operations that occur during these processes. -- 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-14781) Log message when mutation passed to CommitLog#add(Mutation) is too large is not descriptive enough
[
https://issues.apache.org/jira/browse/CASSANDRA-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012980#comment-17012980
]
Jordan West edited comment on CASSANDRA-14781 at 1/10/20 4:24 PM:
--
A few code review comments below. I did want to discuss if we are going to
address the user facing concerns Aleksey brought up in this ticket? The patch
addresses the operators lack of visibility into keyspace/table/partitions but
still results in timeouts for the user. Are we going to address those in a
separate ticket? My thought is that something for the operators is better than
no patch (having been blind in this situation before besides custom tools) but
if the user facing changes require protocol changes we should probably fix it
pre-4.0 like we have or plan to w/ other similar tickets – but that could still
be in a separate ticket.
Code Comments:
* -{{Mutation#serializedSize}}: you should only need one field to memoize the
size and can you pass version directly to {{Serializer#serializedSize}} instead
of the switch afterwards?- never mind [~n.v.harikrishna] pointed out code in
{{BlockingReadRepairs}} that makes this statement false.
* We also shouldn’t duplicate the implementations between counter and regular
mutations
* {{validateSize}}: since the two implementations are identical you could move
them to a \{{default}} implementation in {{IMutation}}
* {\{MaxMutationExceededException}}: the sort in {{#prepareMessage}} could get
pretty expensive, is it necessary? It also looks like there is an edge case
where “and more” will be added even when there aren’t more. Using
{{listIterator.hasNext()}} instead of {{topPartitions.size() > 0}} should fix
that
was (Author: jrwest):
A few code review comments below. I did want to discuss if we are going to
address the user facing concerns Aleksey brought up in this ticket? The patch
addresses the operators lack of visibility into keyspace/table/partitions but
still results in timeouts for the user. Are we going to address those in a
separate ticket? My thought is that something for the operators is better than
no patch (having been blind in this situation before besides custom tools) but
if the user facing changes require protocol changes we should probably fix it
pre-4.0 like we have or plan to w/ other similar tickets – but that could still
be in a separate ticket.
Code Comments:
* {{Mutation#serializedSize}}: you should only need one field to memoize the
size and can you pass version directly to {{Serializer#serializedSize}} instead
of the switch afterwards?
* We also shouldn’t duplicate the implementations between counter and regular
mutations
* {{validateSize}}: since the two implementations are identical you could move
them to a \{{default}} implementation in {{IMutation}}
* {\{MaxMutationExceededException}}: the sort in {{#prepareMessage}} could get
pretty expensive, is it necessary? It also looks like there is an edge case
where “and more” will be added even when there aren’t more. Using
{{listIterator.hasNext()}} instead of {{topPartitions.size() > 0}} should fix
that
> Log message when mutation passed to CommitLog#add(Mutation) is too large is
> not descriptive enough
> --
>
> Key: CASSANDRA-14781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14781
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints, Local/Commit Log, Messaging/Client
>Reporter: Jordan West
>Assignee: Tom Petracca
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-14781.patch, CASSANDRA-14781_3.0.patch,
> CASSANDRA-14781_3.11.patch
>
>
> When hitting
> [https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L256-L257],
> the log message produced does not help the operator track down what data is
> being written. At a minimum the keyspace and cfIds involved would be useful
> (and are available) – more detail might not be reasonable to include.
--
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
[
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012511#comment-17012511
]
Jordan West edited comment on CASSANDRA-15213 at 1/10/20 4:14 PM:
--
I've updated [https://github.com/jrwest/cassandra/tree/jwest/15213] with the
changes you suggested. Regarding the extra bucket, I realized that even more
simply we could return {{bucketOffsets.length}} if the estimate is greater than
or equal to it – saving us an access in this case altogether.
Also added a very simple striping approach -- without any attempts at
distributed the buckets more uniformly. The performance is about the same (the
runs are within each others' margin of error) and still significantly better
than before CASSANDRA-14281. From the memory consumption perspective, however,
4 stripes ends up allocating more than 12MiB after startup. This isn't
surprising because with a single stripe (or pre CASSANDRA-14281) after startup
was a little more than 3MiB and we're quadrupling the size of each array.
However, these won't grow under contention like {{LongAdder[]}} would: memory
consumption is on the order of the number of histograms created not number
created and contention as before. I've found comparable performance using 2
stripes on my 4 core machine. I have an 8 core available to me I can test with
tomorrow. If the memory consumption is still a concern I can investigate
on-demand striping but I prefer the simpler approach and think the trade-offs
of 2-4 stripes is reasonable.
{code:java}
3.0 (4 core):
[java] Benchmark Mode Cnt
Score Error Units
[java] LatencyTrackingBench.benchInsertToDEHR thrpt 5
5848504.963 ± 147881.511 ops/s
[java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5
1946154.537 ± 623185.290 ops/s
Trunk (4 core)
[java] Benchmark Mode Cnt
Score Error Units
[java] LatencyTrackingBench.benchInsertToDEHR thrpt 5
21887453.678 ± 2108481.285 ops/s
[java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5
8908817.316 ± 115453.642 ops/s
15213 (4 core, linear search changes only):
[java] Benchmark Mode Cnt
Score Error Units
[java] LatencyTrackingBench.benchInsertToDEHR thrpt 5
24646022.304 ± 1052105.818 ops/s
[java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5
9175928.594 ± 269984.204 ops/s
15213 (4 core, 4 stripes, striping and linear search):
[java] Benchmark Mode Cnt Score
Error Units
[java] LatencyTrackingBench.benchInsertToDEHR thrpt 5
18818181.576 ± 506997.366 ops/s
[java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5
8895569.814 ± 154219.113 ops/s
{code}
was (Author: jrwest):
I've updated [https://github.com/jrwest/cassandra/tree/jwest/15213] with the
changes you suggested. Regarding the extra bucket, I realized that even more
simply we could return {{bucketOffsets.length}} if the estimate is greater than
or equal to it – saving us an access in this case altogether.
Also added a very simple striping approach. The performance is about the same
(the runs are within each others' margin of error) and still significantly
better than before CASSANDRA-14281. From the memory consumption perspective,
however, 4 stripes ends up allocating more than 12MiB after startup. This isn't
surprising because with a single stripe (or pre CASSANDRA-14281) after startup
was a little more than 3MiB and we're quadrupling the size of each array.
However, these won't grow under contention like {{LongAdder[]}} would: memory
consumption is on the order of the number of histograms created not number
created and contention as before. I've found comparable performance using 2
stripes on my 4 core machine. I have an 8 core available to me I can test with
tomorrow. If the memory consumption is still a concern I can investigate
on-demand striping but I prefer the simpler approach and think the trade-offs
of 2-4 stripes is reasonable.
{code:java}
3.0 (4 core):
[java] Benchmark Mode Cnt
Score Error Units
[java] LatencyTrackingBench.benchInsertToDEHR thrpt 5
5848504.963 ± 147881.511 ops/s
[java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5
1946154.537 ± 623185.290 ops/s
Trunk (4 core)
[java] Benchmark Mode Cnt
Score Error Units
[java] LatencyTrackingBench.benchInsertToDEHR thrpt 5
21887453.678 ± 2108481.285 ops/s
[java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5
[jira] [Updated] (CASSANDRA-12993) License headers missing in some source files
[ https://issues.apache.org/jira/browse/CASSANDRA-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-12993: --- Source Control Link: [e27810efcc848a9ce1320d31f4ef57b210201e22|https://github.com/apache/cassandra/commit/e27810efcc848a9ce1320d31f4ef57b210201e22] Resolution: Fixed Status: Resolved (was: Ready to Commit) > License headers missing in some source files > > > Key: CASSANDRA-12993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12993 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Tomas Repik >Assignee: Venkata Harikrishna Nukala >Priority: Normal > Fix For: 4.0 > > > The following source files are without license headers: > doc/source/_static/extra.css > src/java/org/apache/cassandra/db/commitlog/IntervalSet.java > src/java/org/apache/cassandra/utils/IntegerInterval.java > test/unit/org/apache/cassandra/db/commitlog/CommitLogCQLTest.java > test/unit/org/apache/cassandra/utils/IntegerIntervalsTest.java > tools/stress/src/org/apache/cassandra/stress/WorkManager.java > Could you please confirm the licensing of code and/or content/s, and add > license headers? -- 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-12993) License headers missing in some source files
[ https://issues.apache.org/jira/browse/CASSANDRA-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-12993: --- Status: Ready to Commit (was: Review In Progress) > License headers missing in some source files > > > Key: CASSANDRA-12993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12993 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Tomas Repik >Assignee: Venkata Harikrishna Nukala >Priority: Normal > Fix For: 4.0 > > > The following source files are without license headers: > doc/source/_static/extra.css > src/java/org/apache/cassandra/db/commitlog/IntervalSet.java > src/java/org/apache/cassandra/utils/IntegerInterval.java > test/unit/org/apache/cassandra/db/commitlog/CommitLogCQLTest.java > test/unit/org/apache/cassandra/utils/IntegerIntervalsTest.java > tools/stress/src/org/apache/cassandra/stress/WorkManager.java > Could you please confirm the licensing of code and/or content/s, and add > license headers? -- 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-12993) License headers missing in some source files
[ https://issues.apache.org/jira/browse/CASSANDRA-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-12993: --- Reviewers: Jordan West, Benedict Elliott Smith (was: Benedict Elliott Smith, Jordan West) Jordan West, Benedict Elliott Smith Status: Review In Progress (was: Patch Available) > License headers missing in some source files > > > Key: CASSANDRA-12993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12993 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Tomas Repik >Assignee: Venkata Harikrishna Nukala >Priority: Normal > Fix For: 4.0 > > > The following source files are without license headers: > doc/source/_static/extra.css > src/java/org/apache/cassandra/db/commitlog/IntervalSet.java > src/java/org/apache/cassandra/utils/IntegerInterval.java > test/unit/org/apache/cassandra/db/commitlog/CommitLogCQLTest.java > test/unit/org/apache/cassandra/utils/IntegerIntervalsTest.java > tools/stress/src/org/apache/cassandra/stress/WorkManager.java > Could you please confirm the licensing of code and/or content/s, and add > license headers? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: [CASSANDRA-12993] Added license text.
This is an automated email from the ASF dual-hosted git repository.
benedict 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 e27810e [CASSANDRA-12993] Added license text.
e27810e is described below
commit e27810efcc848a9ce1320d31f4ef57b210201e22
Author: nvharikrishna
AuthorDate: Thu Jan 9 01:01:30 2020 +0530
[CASSANDRA-12993] Added license text.
---
doc/source/_static/extra.css | 17 +
.../org/apache/cassandra/db/commitlog/IntervalSet.java | 18 ++
.../org/apache/cassandra/utils/IntegerInterval.java| 18 ++
.../cassandra/db/commitlog/CommitLogCQLTest.java | 18 ++
.../apache/cassandra/utils/IntegerIntervalsTest.java | 18 ++
.../src/org/apache/cassandra/stress/WorkManager.java | 18 ++
6 files changed, 107 insertions(+)
diff --git a/doc/source/_static/extra.css b/doc/source/_static/extra.css
index 715e2a8..5e40dd7 100644
--- a/doc/source/_static/extra.css
+++ b/doc/source/_static/extra.css
@@ -1,3 +1,20 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
div:not(.highlight) > pre {
background: #fff;
border: 1px solid #e1e4e5;
diff --git a/src/java/org/apache/cassandra/db/commitlog/IntervalSet.java
b/src/java/org/apache/cassandra/db/commitlog/IntervalSet.java
index 371c646..45db2f6 100644
--- a/src/java/org/apache/cassandra/db/commitlog/IntervalSet.java
+++ b/src/java/org/apache/cassandra/db/commitlog/IntervalSet.java
@@ -1,3 +1,21 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
package org.apache.cassandra.db.commitlog;
import java.io.IOException;
diff --git a/src/java/org/apache/cassandra/utils/IntegerInterval.java
b/src/java/org/apache/cassandra/utils/IntegerInterval.java
index f600136..b26ac45 100644
--- a/src/java/org/apache/cassandra/utils/IntegerInterval.java
+++ b/src/java/org/apache/cassandra/utils/IntegerInterval.java
@@ -1,3 +1,21 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
package org.apache.cassandra.utils;
import java.util.*;
diff --git a/test/unit/org/apache/cassandra/db/commitlog/CommitLogCQLTest.java
b/test/unit/org/apache/cassandra/db/commitlog/CommitLogCQLTest.java
index 7235600..4725bcf 100644
--- a/test/unit/org/apache/cassandra/db/commitlog/CommitLogCQLTest.java
+++ b/test/unit/org/apache/cassandra/db/commitlog/CommitLogCQLTest.java
@@ -1,3 +1,21 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with
[jira] [Commented] (CASSANDRA-14781) Log message when mutation passed to CommitLog#add(Mutation) is too large is not descriptive enough
[
https://issues.apache.org/jira/browse/CASSANDRA-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012980#comment-17012980
]
Jordan West commented on CASSANDRA-14781:
-
A few code review comments below. I did want to discuss if we are going to
address the user facing concerns Aleksey brought up in this ticket? The patch
addresses the operators lack of visibility into keyspace/table/partitions but
still results in timeouts for the user. Are we going to address those in a
separate ticket? My thought is that something for the operators is better than
no patch (having been blind in this situation before besides custom tools) but
if the user facing changes require protocol changes we should probably fix it
pre-4.0 like we have or plan to w/ other similar tickets – but that could still
be in a separate ticket.
Code Comments:
* {{Mutation#serializedSize}}: you should only need one field to memoize the
size and can you pass version directly to {{Serializer#serializedSize}} instead
of the switch afterwards?
* We also shouldn’t duplicate the implementations between counter and regular
mutations
* {{validateSize}}: since the two implementations are identical you could move
them to a \{{default}} implementation in {{IMutation}}
* {\{MaxMutationExceededException}}: the sort in {{#prepareMessage}} could get
pretty expensive, is it necessary? It also looks like there is an edge case
where “and more” will be added even when there aren’t more. Using
{{listIterator.hasNext()}} instead of {{topPartitions.size() > 0}} should fix
that
> Log message when mutation passed to CommitLog#add(Mutation) is too large is
> not descriptive enough
> --
>
> Key: CASSANDRA-14781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14781
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints, Local/Commit Log, Messaging/Client
>Reporter: Jordan West
>Assignee: Tom Petracca
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-14781.patch, CASSANDRA-14781_3.0.patch,
> CASSANDRA-14781_3.11.patch
>
>
> When hitting
> [https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L256-L257],
> the log message produced does not help the operator track down what data is
> being written. At a minimum the keyspace and cfIds involved would be useful
> (and are available) – more detail might not be reasonable to include.
--
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-12993) License headers missing in some source files
[ https://issues.apache.org/jira/browse/CASSANDRA-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012989#comment-17012989 ] Jordan West commented on CASSANDRA-12993: - +1. The files had missing headers and they should be added. > License headers missing in some source files > > > Key: CASSANDRA-12993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12993 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Tomas Repik >Assignee: Venkata Harikrishna Nukala >Priority: Normal > Fix For: 4.0 > > > The following source files are without license headers: > doc/source/_static/extra.css > src/java/org/apache/cassandra/db/commitlog/IntervalSet.java > src/java/org/apache/cassandra/utils/IntegerInterval.java > test/unit/org/apache/cassandra/db/commitlog/CommitLogCQLTest.java > test/unit/org/apache/cassandra/utils/IntegerIntervalsTest.java > tools/stress/src/org/apache/cassandra/stress/WorkManager.java > Could you please confirm the licensing of code and/or content/s, and add > license headers? -- 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-14781) Log message when mutation passed to CommitLog#add(Mutation) is too large is not descriptive enough
[
https://issues.apache.org/jira/browse/CASSANDRA-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012915#comment-17012915
]
Aleksey Yeschenko commented on CASSANDRA-14781:
---
Could you flip the size fields to {{int}} from {{long}}? (not a full review,
just a super quick skim related to my only previous point)
> Log message when mutation passed to CommitLog#add(Mutation) is too large is
> not descriptive enough
> --
>
> Key: CASSANDRA-14781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14781
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints, Local/Commit Log, Messaging/Client
>Reporter: Jordan West
>Assignee: Tom Petracca
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-14781.patch, CASSANDRA-14781_3.0.patch,
> CASSANDRA-14781_3.11.patch
>
>
> When hitting
> [https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L256-L257],
> the log message produced does not help the operator track down what data is
> being written. At a minimum the keyspace and cfIds involved would be useful
> (and are available) – more detail might not be reasonable to include.
--
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-15216) Cross node message creation times are disabled by default
[ https://issues.apache.org/jira/browse/CASSANDRA-15216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012910#comment-17012910 ] Aleksey Yeschenko commented on CASSANDRA-15216: --- [~e.dimitrova] go for it. We could have a wider discussion, but it's hard for me to imagine why someone would object to this default switch. Just make sure to update NEWS.txt to note that the change has taken place. > Cross node message creation times are disabled by default > - > > Key: CASSANDRA-15216 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15216 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Benedict Elliott Smith >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-alpha > > > This can cause a lot of wasted work for messages that have timed out on the > coordinator. We should generally assume that our users have setup NTP on > their clusters, and that clocks are modestly in sync, since it’s a > requirement for general correctness of last write wins. -- 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-15496) Split out Jenkins test-all builds to individual builds for each of the test targets
[ https://issues.apache.org/jira/browse/CASSANDRA-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012757#comment-17012757 ] Michael Semb Wever commented on CASSANDRA-15496: Cassandra-builds patched committed. > Split out Jenkins test-all builds to individual builds for each of the test > targets > --- > > Key: CASSANDRA-15496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15496 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > Currently the test-all target does nothing but execute the test target. > This is because the test targets finishes with unit test failures. > As these jenkins jobs are automated here: > https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L44 > ; it is easy enough to remove the "test-all" target, replacing it with > separate jobs for 'stress-test', 'fqltool-test', and 'long-test'. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: Split out Jenkins test-all builds to individual builds for each of the test targets (CASSANDRA-15496)
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 f44ecdc Split out Jenkins test-all builds to individual builds for
each of the test targets (CASSANDRA-15496)
f44ecdc is described below
commit f44ecdcf71193f67c7976fe22652a6a6bbe1b203
Author: mck
AuthorDate: Fri Jan 10 10:28:28 2020 +0100
Split out Jenkins test-all builds to individual builds for each of the test
targets (CASSANDRA-15496)
---
jenkins-dsl/cassandra_job_dsl_seed.groovy | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index cf31ac1..5ca843a 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -41,7 +41,7 @@ if(binding.hasVariable("CASSANDRA_BRANCHES")) {
cassandraBranches = "${CASSANDRA_BRANCHES}".split(",")
}
// Ant test targets
-def testTargets = ['test', 'test-all', 'test-burn', 'test-cdc',
'test-compression', 'test-jvm-dtest-forking']
+def testTargets = ['test', 'test-burn', 'test-cdc', 'test-compression',
'test-jvm-dtest-forking', 'stress-test', 'fqltool-test', 'long-test']
if(binding.hasVariable("CASSANDRA_ANT_TEST_TARGETS")) {
testTargets = "${CASSANDRA_ANT_TEST_TARGETS}".split(",")
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15293) Static columns not include in mutation size calculation
[ https://issues.apache.org/jira/browse/CASSANDRA-15293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15293: --- Test and Documentation Plan: unit test added (was: ??) > Static columns not include in mutation size calculation > --- > > Key: CASSANDRA-15293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15293 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging, Observability/Metrics >Reporter: Vincent White >Priority: Low > Fix For: 3.0.20, 3.11.6, 4.0-alpha > > > Patch to include any updates to static columns in the data size calculation > of PartitionUpdate. > ||Patch|| > |[Trunk/3.11|https://github.com/vincewhite/cassandra/commits/include_update_to_static_columns_in_update_size]| -- 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-15293) Static columns not include in mutation size calculation
[ https://issues.apache.org/jira/browse/CASSANDRA-15293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15293: --- Fix Version/s: (was: 3.11.x) (was: 4.x) (was: 3.0.x) 4.0-alpha 3.11.6 3.0.20 Source Control Link: https://github.com/apache/cassandra/commit/c2f201f147029c044b7a1f774cba7b6ab615945e Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as c2f201f147029c044b7a1f774cba7b6ab615945e > Static columns not include in mutation size calculation > --- > > Key: CASSANDRA-15293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15293 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging, Observability/Metrics >Reporter: Vincent White >Priority: Low > Fix For: 3.0.20, 3.11.6, 4.0-alpha > > > Patch to include any updates to static columns in the data size calculation > of PartitionUpdate. > ||Patch|| > |[Trunk/3.11|https://github.com/vincewhite/cassandra/commits/include_update_to_static_columns_in_update_size]| -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (63b3de9 -> 364651d)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 63b3de9 Merge branch 'cassandra-3.11' into trunk new c2f201f Include updates to static column in mutation size calculations new 094180b Merge branch 'cassandra-3.0' into cassandra-3.11 new 364651d 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 + .../cassandra/db/partitions/PartitionUpdate.java | 9 + .../db/partition/PartitionUpdateTest.java | 23 ++ 3 files changed, 33 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 094180ba070dd30d2c89a98289c05796d0d03a91
Merge: 9635e55 c2f201f
Author: Mick Semb Wever
AuthorDate: Fri Jan 10 11:41:50 2020 +0100
Merge branch 'cassandra-3.0' into cassandra-3.11
CHANGES.txt| 1 +
.../cassandra/db/partitions/PartitionUpdate.java | 9 +
.../db/partition/PartitionUpdateTest.java | 23 ++
3 files changed, 33 insertions(+)
diff --cc CHANGES.txt
index d8563c7,620eb35..408048b
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
-3.0.20
+3.11.6
+ * 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:
+ * 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)
* Fix sstabledump's position key value when partitions have multiple rows
(CASSANDRA-14721)
diff --cc test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
index bfa9796,7dff91f..0330b65
--- a/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
+++ b/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
@@@ -49,6 -52,27 +49,29 @@@ public class PartitionUpdateTest extend
}
@Test
+ public void testMutationSize()
+ {
+ createTable("CREATE TABLE %s (key text, clustering int, a int, s int
static, PRIMARY KEY(key, clustering))");
+ CFMetaData cfm = currentTableMetadata();
+
-PartitionUpdate update = new RowUpdateBuilder(cfm,
FBUtilities.timestampMicros(), "key0").add("s", 1).buildUpdate();
-int size1 = update.dataSize();
-Assert.assertEquals(20, size1);
++UpdateBuilder builder = UpdateBuilder.create(cfm, "key0");
++builder.newRow().add("s", 1);
++builder.newRow(1).add("a", 2);
++int size1 = builder.build().dataSize();
++Assert.assertEquals(44, size1);
+
-update = new RowUpdateBuilder(cfm, FBUtilities.timestampMicros(),
"key0").clustering(1).add("a", 2).buildUpdate();
-int size2 = update.dataSize();
++builder = UpdateBuilder.create(cfm, "key0");
++builder.newRow(1).add("a", 2);
++int size2 = builder.build().dataSize();
+ Assert.assertTrue(size1 != size2);
+
-update = new RowUpdateBuilder(cfm, FBUtilities.timestampMicros(),
"key0").buildUpdate();
-int size3 = update.dataSize();
-Assert.assertTrue(size1 != size3);
++builder = UpdateBuilder.create(cfm, "key0");
++int size3 = builder.build().dataSize();
+ Assert.assertTrue(size2 != size3);
+
+ }
+
+ @Test
public void testOperationCountWithCompactTable()
{
createTable("CREATE TABLE %s (key text PRIMARY KEY, a int) WITH
COMPACT STORAGE");
-
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: Include updates to static column in mutation size calculations
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new c2f201f Include updates to static column in mutation size calculations
c2f201f is described below
commit c2f201f147029c044b7a1f774cba7b6ab615945e
Author: Vincent White
AuthorDate: Mon Aug 26 03:38:52 2019 +
Include updates to static column in mutation size calculations
patch by Vincent White; reviewed by Mick Semb Wever for CASSANDRA-15293
---
CHANGES.txt | 1 +
.../cassandra/db/partitions/PartitionUpdate.java| 9 +
.../cassandra/db/partition/PartitionUpdateTest.java | 21 +
3 files changed, 31 insertions(+)
diff --git a/CHANGES.txt b/CHANGES.txt
index 44719b4..620eb35 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.20
+ * 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)
* Fix sstabledump's position key value when partitions have multiple rows
(CASSANDRA-14721)
diff --git a/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
b/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
index 5f74780..f476f5b 100644
--- a/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
+++ b/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
@@ -372,6 +372,15 @@ public class PartitionUpdate extends AbstractBTreePartition
public int dataSize()
{
int size = 0;
+
+if (holder.staticRow != null)
+{
+for (ColumnData cd : holder.staticRow.columnData())
+{
+size += cd.dataSize();
+}
+}
+
for (Row row : this)
{
size += row.clustering().dataSize();
diff --git
a/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
b/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
index a069db1..7dff91f 100644
--- a/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
+++ b/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
@@ -52,6 +52,27 @@ public class PartitionUpdateTest extends CQLTester
}
@Test
+public void testMutationSize()
+{
+createTable("CREATE TABLE %s (key text, clustering int, a int, s int
static, PRIMARY KEY(key, clustering))");
+CFMetaData cfm = currentTableMetadata();
+
+PartitionUpdate update = new RowUpdateBuilder(cfm,
FBUtilities.timestampMicros(), "key0").add("s", 1).buildUpdate();
+int size1 = update.dataSize();
+Assert.assertEquals(20, size1);
+
+update = new RowUpdateBuilder(cfm, FBUtilities.timestampMicros(),
"key0").clustering(1).add("a", 2).buildUpdate();
+int size2 = update.dataSize();
+Assert.assertTrue(size1 != size2);
+
+update = new RowUpdateBuilder(cfm, FBUtilities.timestampMicros(),
"key0").buildUpdate();
+int size3 = update.dataSize();
+Assert.assertTrue(size1 != size3);
+Assert.assertTrue(size2 != size3);
+
+}
+
+@Test
public void testOperationCountWithCompactTable()
{
createTable("CREATE TABLE %s (key text PRIMARY KEY, a int) WITH
COMPACT STORAGE");
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 364651d2a5f2b86a57bf2332555413109c1179eb
Merge: 63b3de9 094180b
Author: Mick Semb Wever
AuthorDate: Fri Jan 10 11:42:52 2020 +0100
Merge branch 'cassandra-3.11' into trunk
CHANGES.txt| 1 +
.../cassandra/db/partitions/PartitionUpdate.java | 9 +
.../db/partition/PartitionUpdateTest.java | 23 ++
3 files changed, 33 insertions(+)
diff --cc CHANGES.txt
index f41d218,408048b..8e5907d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,21 -1,10 +1,22 @@@
-3.11.6
+4.0-alpha3
+ * 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)
+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:
+ * 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)
* Fix sstabledump's position key value when partitions have multiple rows
(CASSANDRA-14721)
diff --cc test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
index 8f2f35b,0330b65..a4555c8
--- a/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
+++ b/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
@@@ -49,17 -49,39 +49,40 @@@ public class PartitionUpdateTest extend
}
@Test
+ public void testMutationSize()
+ {
+ createTable("CREATE TABLE %s (key text, clustering int, a int, s int
static, PRIMARY KEY(key, clustering))");
-CFMetaData cfm = currentTableMetadata();
++TableMetadata cfm = currentTableMetadata();
+
+ UpdateBuilder builder = UpdateBuilder.create(cfm, "key0");
+ builder.newRow().add("s", 1);
+ builder.newRow(1).add("a", 2);
+ int size1 = builder.build().dataSize();
+ Assert.assertEquals(44, size1);
+
+ builder = UpdateBuilder.create(cfm, "key0");
+ builder.newRow(1).add("a", 2);
+ int size2 = builder.build().dataSize();
+ Assert.assertTrue(size1 != size2);
+
+ builder = UpdateBuilder.create(cfm, "key0");
+ int size3 = builder.build().dataSize();
+ Assert.assertTrue(size2 != size3);
+
+ }
+
+ @Test
-public void testOperationCountWithCompactTable()
+public void testUpdateAllTimestamp()
{
-createTable("CREATE TABLE %s (key text PRIMARY KEY, a int) WITH
COMPACT STORAGE");
-CFMetaData cfm = currentTableMetadata();
+createTable("CREATE TABLE %s (key text, clustering int, a int, b int,
c int, s int static, PRIMARY KEY(key, clustering))");
+TableMetadata cfm = currentTableMetadata();
-PartitionUpdate update = new RowUpdateBuilder(cfm,
FBUtilities.timestampMicros(), "key0").add("a", 1)
-
.buildUpdate();
-Assert.assertEquals(1, update.operationCount());
+long timestamp = FBUtilities.timestampMicros();
+RowUpdateBuilder rub = new RowUpdateBuilder(cfm, timestamp,
"key0").clustering(1).add("a", 1);
+PartitionUpdate pu = rub.buildUpdate();
+PartitionUpdate pu2 = new PartitionUpdate.Builder(pu,
0).updateAllTimestamp(0).build();
-update = new RowUpdateBuilder(cfm, FBUtilities.timestampMicros(),
"key0").buildUpdate();
-Assert.assertEquals(0, update.operationCount());
+Assert.assertTrue(pu.maxTimestamp() > 0);
+Assert.assertTrue(pu2.maxTimestamp() == 0);
}
}
[cassandra] branch cassandra-3.11 updated (9635e55 -> 094180b)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9635e55 Merge branch 'cassandra-3.0' into cassandra-3.11 new c2f201f Include updates to static column in mutation size calculations new 094180b 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 + .../cassandra/db/partitions/PartitionUpdate.java | 9 + .../db/partition/PartitionUpdateTest.java | 23 ++ 3 files changed, 33 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15293) Static columns not include in mutation size calculation
[ https://issues.apache.org/jira/browse/CASSANDRA-15293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15293: --- Status: Ready to Commit (was: Review In Progress) > Static columns not include in mutation size calculation > --- > > Key: CASSANDRA-15293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15293 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging, Observability/Metrics >Reporter: Vincent White >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.x > > > Patch to include any updates to static columns in the data size calculation > of PartitionUpdate. > ||Patch|| > |[Trunk/3.11|https://github.com/vincewhite/cassandra/commits/include_update_to_static_columns_in_update_size]| -- 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-15496) Split out Jenkins test-all builds to individual builds for each of the test targets
[ https://issues.apache.org/jira/browse/CASSANDRA-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15496: --- Test and Documentation Plan: asf jenkins Status: Patch Available (was: In Progress) > Split out Jenkins test-all builds to individual builds for each of the test > targets > --- > > Key: CASSANDRA-15496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15496 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > Currently the test-all target does nothing but execute the test target. > This is because the test targets finishes with unit test failures. > As these jenkins jobs are automated here: > https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L44 > ; it is easy enough to remove the "test-all" target, replacing it with > separate jobs for 'stress-test', 'fqltool-test', and 'long-test'. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15496) Split out Jenkins test-all builds to individual builds for each of the test targets
[ https://issues.apache.org/jira/browse/CASSANDRA-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012628#comment-17012628 ] Michael Semb Wever commented on CASSANDRA-15496: Patches: - cassandra-builds: https://github.com/apache/cassandra-builds/compare/master...thelastpickle:mck/15496--replace-test-all - 3.0: https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15496 - 3.11: https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15496 - trunk: https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15496 > Split out Jenkins test-all builds to individual builds for each of the test > targets > --- > > Key: CASSANDRA-15496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15496 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > Currently the test-all target does nothing but execute the test target. > This is because the test targets finishes with unit test failures. > As these jenkins jobs are automated here: > https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L44 > ; it is easy enough to remove the "test-all" target, replacing it with > separate jobs for 'stress-test', 'fqltool-test', and 'long-test'. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15496) Split out Jenkins test-all builds to individual builds for each of the test targets
[ https://issues.apache.org/jira/browse/CASSANDRA-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15496: --- Change Category: Quality Assurance Complexity: Low Hanging Fruit Assignee: Michael Semb Wever Status: Open (was: Triage Needed) > Split out Jenkins test-all builds to individual builds for each of the test > targets > --- > > Key: CASSANDRA-15496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15496 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > Currently the test-all target does nothing but execute the test target. > This is because the test targets finishes with unit test failures. > As these jenkins jobs are automated here: > https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L44 > ; it is easy enough to remove the "test-all" target, replacing it with > separate jobs for 'stress-test', 'fqltool-test', and 'long-test'. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15496) Split out Jenkins test-all builds to individual builds for each of the test targets
Michael Semb Wever created CASSANDRA-15496: -- Summary: Split out Jenkins test-all builds to individual builds for each of the test targets Key: CASSANDRA-15496 URL: https://issues.apache.org/jira/browse/CASSANDRA-15496 Project: Cassandra Issue Type: Task Components: Test/unit Reporter: Michael Semb Wever Currently the test-all target does nothing but execute the test target. This is because the test targets finishes with unit test failures. As these jenkins jobs are automated here: https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L44 ; it is easy enough to remove the "test-all" target, replacing it with separate jobs for 'stress-test', 'fqltool-test', and 'long-test'. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15293) Static columns not include in mutation size calculation
[ https://issues.apache.org/jira/browse/CASSANDRA-15293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012548#comment-17012548 ] Michael Semb Wever edited comment on CASSANDRA-15293 at 1/10/20 8:06 AM: - Thanks [~VincentWhite]. ||branch||circleci||asf jenkins pipeline||asf jenkins dtests|| |[cassandra-3.0_15293|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15293]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15293]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/53/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/53/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/719/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/719]| |[cassandra-3.11_15293|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15293]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15293]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/54/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/54/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/720/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/720]| |[trunk_15293|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15293]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15293]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/55/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/55/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/721/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/721]| was (Author: michaelsembwever): Thanks [~VincentWhite]. ||branch||circleci||asf jenkins testall||asf jenkins dtests|| |[cassandra-3.0_15293|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15293]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15293]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/53/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/53/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/719/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/719]| |[cassandra-3.11_15293|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15293]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15293]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/54/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/54/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/720/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/720]| |[trunk_15293|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15293]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15293]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/55/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/55/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/721/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/721]| > Static columns not include in mutation size calculation > --- > > Key: CASSANDRA-15293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15293 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging, Observability/Metrics >Reporter: Vincent White >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.x > > > Patch to include any updates to static columns in the data size calculation > of PartitionUpdate. > ||Patch|| > |[Trunk/3.11|https://github.com/vincewhite/cassandra/commits/include_update_to_static_columns_in_update_size]| -- 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-15293) Static columns not include in mutation size calculation
[ https://issues.apache.org/jira/browse/CASSANDRA-15293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012548#comment-17012548 ] Michael Semb Wever commented on CASSANDRA-15293: Thanks [~VincentWhite]. ||branch||circleci||asf jenkins testall||asf jenkins dtests|| |[cassandra-3.0_15293|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15293]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15293]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/53/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/53/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/719/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/719]| |[cassandra-3.11_15293|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15293]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15293]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/54/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/54/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/720/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/720]| |[trunk_15293|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15293]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15293]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/55/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-pipeline/55/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/721/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/721]| > Static columns not include in mutation size calculation > --- > > Key: CASSANDRA-15293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15293 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging, Observability/Metrics >Reporter: Vincent White >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.x > > > Patch to include any updates to static columns in the data size calculation > of PartitionUpdate. > ||Patch|| > |[Trunk/3.11|https://github.com/vincewhite/cassandra/commits/include_update_to_static_columns_in_update_size]| -- 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
