[jira] [Commented] (CASSANDRA-15470) Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-15470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019736#comment-17019736
]
Jordan West commented on CASSANDRA-15470:
-
[~mallika] ah right thank you. and thanks for the corrections. The patch LGTM.
I ran the new test locally and have started a circle run
[here|https://circleci.com/gh/jrwest/cassandra/tree/CASSANDRA-15470]. [~djoshi]
can you review as well? Thanks
> Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB
> & Bytes
> -
>
> Key: CASSANDRA-15470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15470
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jordan West
>Assignee: Mallika Kulkarni
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DatabaseDescriptor}} has several functions that convert between user
> supplied sizes in KB/MB and bytes. These are implemented without much
> consistency and, while unlikely, several have the potential to overflow since
> validation on the input is missing. Meanwhile, some widen the number to a
> long correctly. Options include: widening in all places or simply doing
> better validation on start up — currently only the lower bound of the valid
> range is checked for many of these fields.
> List of Affected {{DatabaseDescriptor}} Methods:
> * {{getColumnIndexSize}}
> * {{getColumnIndexCacheSize}}
> * {{getBatchSizeWarnThreshold}}
> * {{getNativeTransportFrameBlockSize}}
> * {{getRepairSessionSpaceInMegabytes}}
> * {{getNativeTransportMaxFrameSize}}
--
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-15491) Hints
[ https://issues.apache.org/jira/browse/CASSANDRA-15491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019649#comment-17019649 ] DeepakVohra commented on CASSANDRA-15491: - - Merged the changes. - Modified section on _Changing Max Hint Window at Runtime_. - Added reference to section on Token Ring/Ranges in Architecture. > Hints > - > > Key: CASSANDRA-15491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15491 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added page for hints. > https://github.com/apache/cassandra/pull/419 -- 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-15509) In-jvm upgrade dtest version parsing does not support 4.0 alpha/beta/rc builds
[ https://issues.apache.org/jira/browse/CASSANDRA-15509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019515#comment-17019515 ] Marcus Eriksson commented on CASSANDRA-15509: - pushed a slightly modified version of that regexp to the [branch|https://github.com/krummas/cassandra/commits/marcuse/15509] and tests ran [here|https://circleci.com/workflow-run/30db14da-32bb-4786-ab69-0349ed869419] > In-jvm upgrade dtest version parsing does not support 4.0 alpha/beta/rc builds > -- > > Key: CASSANDRA-15509 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15509 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > for example: > https://circleci.com/gh/krummas/cassandra/2686 -- 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-15514) Properly clean up DefaultSessionProvider#sessionCache when closing QueryReplayer
[
https://issues.apache.org/jira/browse/CASSANDRA-15514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15514:
Since Version: 4.0-alpha
Source Control Link:
https://github.com/apache/cassandra/commit/1fbd3297a9c8303ca7aa2ff30d182e5ca568de4c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
+1, committed, thanks!
> Properly clean up DefaultSessionProvider#sessionCache when closing
> QueryReplayer
>
>
> Key: CASSANDRA-15514
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15514
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The {{DefaultSessionProvider}} used by the {{QueryReplayer}} caches the
> sessions by hostname. When closing, the sessions and their associated
> clusters are closed but they never get removed from the cache.
> When connecting to the same host, the closed session is returned, which is
> unexpected.
> Besides the unexpected behavior, the session references remaining in the
> cache leaks resources.
--
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: Release session from cache when closing QueryReplayer
This is an automated email from the ASF dual-hosted git repository.
marcuse 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 1fbd329 Release session from cache when closing QueryReplayer
1fbd329 is described below
commit 1fbd3297a9c8303ca7aa2ff30d182e5ca568de4c
Author: yifan-c
AuthorDate: Fri Jan 17 22:13:50 2020 -0800
Release session from cache when closing QueryReplayer
Patch by Yifan Cai; reviewed by marcuse for CASSANDRA-15514
---
build.xml | 1 +
.../test/QueryReplayerEndToEndTest.java| 92 ++
.../apache/cassandra/fqltool/QueryReplayer.java| 10 +--
3 files changed, 98 insertions(+), 5 deletions(-)
diff --git a/build.xml b/build.xml
index 51ba2f5..961af39 100644
--- a/build.xml
+++ b/build.xml
@@ -1313,6 +1313,7 @@
encoding="utf-8">
+
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/QueryReplayerEndToEndTest.java
b/test/distributed/org/apache/cassandra/distributed/test/QueryReplayerEndToEndTest.java
new file mode 100644
index 000..9908fcc
--- /dev/null
+++
b/test/distributed/org/apache/cassandra/distributed/test/QueryReplayerEndToEndTest.java
@@ -0,0 +1,92 @@
+/*
+ * 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.distributed.test;
+
+import java.io.IOException;
+import java.util.Collections;
+import java.util.List;
+import java.util.concurrent.atomic.AtomicInteger;
+import java.util.concurrent.atomic.AtomicLong;
+import java.util.function.Predicate;
+import java.util.stream.Collectors;
+import java.util.stream.IntStream;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+import org.apache.cassandra.cql3.QueryOptions;
+import org.apache.cassandra.db.ConsistencyLevel;
+import org.apache.cassandra.distributed.Cluster;
+import org.apache.cassandra.distributed.api.Feature;
+import org.apache.cassandra.fqltool.FQLQuery;
+import org.apache.cassandra.fqltool.QueryReplayer;
+
+public class QueryReplayerEndToEndTest extends DistributedTestBase
+{
+private final AtomicLong queryStartTimeGenerator = new AtomicLong(1000);
+private final AtomicInteger ckGenerator = new AtomicInteger(1);
+
+@Test
+public void testReplayAndCloseMultipleTimes() throws Throwable
+{
+try (Cluster cluster = init(Cluster.create(3, conf ->
conf.with(Feature.NATIVE_PROTOCOL, Feature.GOSSIP, Feature.NETWORK
+{
+cluster.schemaChange("CREATE TABLE " + KEYSPACE + ".tbl (pk int,
ck int, v int, PRIMARY KEY (pk, ck))");
+List hosts = cluster.stream()
+.map(i ->
i.config().broadcastAddressAndPort().address.getHostAddress())
+.collect(Collectors.toList());
+
+final int queriesCount = 3;
+// replay for the first time, it should pass
+
replayAndClose(Collections.singletonList(makeFQLQueries(queriesCount)), hosts);
+// replay for the second time, it should pass too
+// however, if the cached sessions are not released, the second
replay will reused the closed sessions from previous replay and fail to insert
+
replayAndClose(Collections.singletonList(makeFQLQueries(queriesCount)), hosts);
+Object[][] result = cluster.coordinator(1)
+ .execute("SELECT * FROM " + KEYSPACE +
".tbl WHERE pk = ?",
+ConsistencyLevel.QUORUM, 1);
+Assert.assertEquals(String.format("Expecting to see %d rows since
it replayed twice and each with %d queries", queriesCount * 2, queriesCount),
+queriesCount * 2, result.length);
+}
+}
+
+private void replayAndClose(List> allFqlQueries,
List hosts) throws IOException
+{
+List> allowAll =
Collections.singletonList(fqlQuery -> true);
+try (QueryReplayer queryReplayer = new
QueryReplayer(allFqlQueries.iterator(), hosts, null, allowAll, null))
+{
+
[jira] [Updated] (CASSANDRA-15514) Properly clean up DefaultSessionProvider#sessionCache when closing QueryReplayer
[
https://issues.apache.org/jira/browse/CASSANDRA-15514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15514:
Status: Ready to Commit (was: Review In Progress)
> Properly clean up DefaultSessionProvider#sessionCache when closing
> QueryReplayer
>
>
> Key: CASSANDRA-15514
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15514
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The {{DefaultSessionProvider}} used by the {{QueryReplayer}} caches the
> sessions by hostname. When closing, the sessions and their associated
> clusters are closed but they never get removed from the cache.
> When connecting to the same host, the closed session is returned, which is
> unexpected.
> Besides the unexpected behavior, the session references remaining in the
> cache leaks resources.
--
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-15514) Properly clean up DefaultSessionProvider#sessionCache when closing QueryReplayer
[
https://issues.apache.org/jira/browse/CASSANDRA-15514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15514:
Reviewers: Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson)
Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson)
Status: Review In Progress (was: Patch Available)
> Properly clean up DefaultSessionProvider#sessionCache when closing
> QueryReplayer
>
>
> Key: CASSANDRA-15514
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15514
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The {{DefaultSessionProvider}} used by the {{QueryReplayer}} caches the
> sessions by hostname. When closing, the sessions and their associated
> clusters are closed but they never get removed from the cache.
> When connecting to the same host, the closed session is returned, which is
> unexpected.
> Besides the unexpected behavior, the session references remaining in the
> cache leaks resources.
--
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-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15511:
---
Fix Version/s: 4.x
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.x
>
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
--
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-15510) BTree: Improve Building, Inserting and Transforming
[
https://issues.apache.org/jira/browse/CASSANDRA-15510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15510:
---
Fix Version/s: 4.x
> BTree: Improve Building, Inserting and Transforming
> ---
>
> Key: CASSANDRA-15510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15510
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.x
>
>
> This work was originally undertaken as a follow-up to CASSANDRA-15367 to
> ensure performance is strictly improved, but it may no longer be needed for
> that purpose. It’s still hugely impactful, however. It remains to be
> decided where this should land.
> The current {{BTree}} implementation is suboptimal in a number of ways, with
> very little focus having been given to its performance besides its
> memory-occupancy. This patch aims to address that, specifically improving
> the performance and allocations involved in: building, transforming and
> inserting into a tree.
> To facilitate this work, the {{BTree}} definition is modified slightly, so
> that we can perform some simple arithmetic on tree sizes. Specifically,
> trees of depth n are defined to have a maximum capacity of {{branchFactor^n -
> 1}}, which translates into capping the number of leaf children at
> {{branchFactor-1}}, as opposed to {{branchFactor}}. Since {{branchFactor}}
> is a power of 2, this permits fast tree size arithmetic, enabling some of
> these changes.
> h2. Building
> The static build method has been modified to utilise dedicated
> {{buildPerfect}} methods that build either perfectly dense or perfectly
> sparse sub-trees. These perfect trees all share their {{sizeMap}} with each
> other, and can be built more efficiently than trees of arbitrary size. The
> specifics are described in detail in the comments, but this building block
> can be used to construct trees of any size, using at most one child at each
> level that is not either perfectly sparse or perfectly dense. Bulk methods
> are used where possible.
> For large trees this can produce up to 30x throughput improvement and 30%
> allocation reduction vs 3.0 (TBC, and to be tested vs 4.0).
> {{FastBuilder}} is introduced for building a tree in-order (or in reverse)
> without duplicate elements to resolve, without necessarily knowing the size
> upfront. This meets the needs of most use cases. Data is built directly
> into nodes, with up to one already-constructed node, and one partially
> constructed node, on each level, being mutated to share their contents in the
> event of insufficient data to populate the tree. These builders are
> thread-locally shared. These leads to minimal copying, the same sharing of
> {{sizeMap}} as above, zero wasted allocations, and results in minimal
> difference in performance between utilising the less-ergonomic static build
> and builder approach.
> For large trees this leads to ~4.5x throughput improvement, and 70% reduction
> in allocations vs a normal Builder. For small trees performance is
> comparable, but allocations similarly reduced.
> h2. Inserting
> It turns out that we only ever insert another tree into a tree, so we exploit
> this to implement an efficient union of two trees, operating on them directly
> via stacks in the transformer, instead of via a collection interface. A
> builder-like object is introduced that shares functionality with
> {{FastBuilder}}, and permits us to build the result of the union directly
> into the final nodes, reusing as much of the original trees as possible.
> Bulk methods are used where possible.
> The result is not _uniformly_ faster, but is _significantly_ faster on
> average: median _improvement_ of 1.4x (that is, 2.4x total throughput), mean
> improvement of 10x. Worst reduction is 30%, and it may be that we can
> isolate and alleviate that. Allocations are also reduced significantly, with
> a median of 30% and mean of 42% for the tested workloads. As the trees get
> larger the improvement drops, but remains uniformly lower.
> h2. Transforming
> Transformations garbage overhead is minimal, i.e. the main allocations are
> those necessary to represent the new tree. It is significantly faster and
> particularly more efficient when removing elements, utilising the shared
> functionality of the builder and transformer objects to define an efficient
> builder that reuses as much of the original tree as possible.
> We also introduce dedicated {{transform}} methods (that forbid returning
> {{null}}), and {{BiFunction}} transformations to permit efficient follow-ups.
--
This message was sent by Atlassian Jira
[jira] [Updated] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15511:
---
Description:
This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
produced by a number of common operations, by employing {{transformAndFilter}},
{{transform}} and {{FastBuilder}}
* {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
{{BTree.transform}}, so no special builders are necessary;
** {{Rows.copy}} removed
* {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
reconciler
** Zero-allocations if result of merge is same as {{existing}}
** Fewer comparisons
* {{ColumnData}} reconciler implemented in same manner
** {{Cells.reconcileComplex}} is retired
** {{ComplexColumnData}} reconciliation now
*** Garbage-free if the merge has no effect
*** Always fewer allocations
*** Fewer comparisons
* {{FastBuilder}} employed widely:
** {{ClusteringIndexNamesFilter}} deserialization
** {{Columns}} deserialization
** {{PartitionUpdate}} deserialization
** {{AbstractBTreePartition}} construction
** Misc others
The upshot of this work when combined with the proposed patch for
CASSANDRA-15367 has a dramatic impact on operations over collection types -
under contention, as much as 100x improved throughput, and hundreds of
megabytes of reduced allocations. For all operations, allocations under
contention and no contention are significantly reduced and throughput improved.
was:
This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
produced by a number of common operations, by employing {{transformAndFilter}},
{{transform}} and {{FastBuilder}}
* {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
{{BTree.transform}}, so no special builders are necessary;
** {{Rows.copy}} removed
* {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
reconciler
** Zero-allocations if result of merge is same as {{existing}}
** Fewer comparisons
* {{ColumnData}} reconciler implemented in same manner
** {{Cells.reconcileComplex}} is retired
** {{ComplexColumnData}} reconciliation now
*** Garbage-free if the merge has no effect
*** Always fewer allocations
*** Fewer comparisons
* {{FastBuilder}} employed widely:
** {{ClusteringIndexNamesFilter}} deserialization
** {{Columns}} deserialization
** {{PartitionUpdate}} deserialization
** {{AbstractBTreePartition}} construction
** Misc others
The upshot of this work when combined with the proposed patch for
CASSANDRA-15367 has a dramatic impact on operations over collection types -
under contention, as much as 100x improved throughput, and hundreds of
megabytes of reduced allocations. For all operations, allocations under
contention and no contention are significantly reduced and throughput improved.
I am still awaiting the final results of the comprehensive performance
comparison for {{AtomicBTreePartition}}, after which I will establish what
impact there might be on compaction and normal reads, both of which should be
affected by this patch.
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, all
[jira] [Comment Edited] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019381#comment-17019381
]
Benedict Elliott Smith edited comment on CASSANDRA-15511 at 1/20/20 11:03 AM:
--
I have uploaded the results of several days of performance comparisons, and for
posterity the scripts I used to generate and parse them into a spreadsheet, on
the effect of this change on inserting into a partition.
The results are pretty significant; some highlights:
Collection types are universally and dramatically improved, both contended and
uncontended:
* >99% memory consumption reduction
* ~25x throughput
Non-collection types, uncontended:
* ~25% improvement in throughput
* 50% reduction in memory allocated
Non-collections types, contended:
* vs 3.0 with locking enabled _instantly_ (i.e. upgrade to locking after first
competition)
** With 4 competing threads, across the board lower memory utilisation;
near-equivalent with 16-threads
** With 4 or 16 competing threads, ~200% throughput improvement
* vs 3.0 with default locking
** 100-200% throughput improvement
** 30-60% reduction in memory consumption
Notably, this may justify removing the partition lock entirely. This patch,
but with the lock retained, does see even fewer allocations, but the typical
effect is relatively small, and there is a similarly slight drop in throughput.
I recommend taking a look at the attached (zipped) Excel spreadsheet, which has
some nice visual formatting to see the full breakdown of results. I've also
attached as {{ods}} format for compatibility, but this loses the formatting.
was (Author: benedict):
I have uploaded the results of a several days of performance comparisons, and
for posterity the scripts I used to generate and parse them into a spreadsheet,
on the effect of this change on inserting into a partition.
The results are pretty significant; some highlights:
Collection types are universally and dramatically improved, both contended and
uncontended:
* >99% memory consumption reduction
* ~25x throughput
Non-collection types, uncontended:
* ~25% improvement in throughput
* 50% reduction in memory allocated
Non-collections types, contended:
* vs 3.0 with locking enabled _instantly_ (i.e. upgrade to locking after first
competition)
** With 4 competing threads, across the board lower memory utilisation;
near-equivalent with 16-threads
** With 4 or 16 competing threads, ~200% throughput improvement
* vs 3.0 with default locking
** 100-200% throughput improvement
** 30-60% reduction in memory consumption
Notably, this may justify removing the partition lock entirely. This patch,
but with the lock retained, does see even fewer allocations, but the typical
effect is relatively small, and there is a similarly slight drop in throughput.
I recommend taking a look at the attached (zipped) Excel spreadsheet, which has
some nice visual formatting to see the full breakdown of results. I've also
attached as {{ods}} format for compatibility, but this loses the formatting.
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> cont
[jira] [Comment Edited] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019381#comment-17019381
]
Benedict Elliott Smith edited comment on CASSANDRA-15511 at 1/20/20 11:00 AM:
--
I have uploaded the results of a several days of performance comparisons, and
for posterity the scripts I used to generate and parse them into a spreadsheet,
on the effect of this change on inserting into a partition.
The results are pretty significant; some highlights:
Collection types are universally and dramatically improved, both contended and
uncontended:
* >99% memory consumption reduction
* ~25x throughput
Non-collection types, uncontended:
* ~25% improvement in throughput
* 50% reduction in memory allocated
Non-collections types, contended:
* vs 3.0 with locking enabled _instantly_ (i.e. upgrade to locking after first
competition)
** With 4 competing threads, across the board lower memory utilisation;
near-equivalent with 16-threads
** With 4 or 16 competing threads, ~200% throughput improvement
* vs 3.0 with default locking
** 100-200% throughput improvement
** 30-60% reduction in memory consumption
Notably, this may justify removing the partition lock entirely. This patch,
but with the lock retained, does see even fewer allocations, but the typical
effect is relatively small, and there is a similarly slight drop in throughput.
I recommend taking a look at the attached (zipped) Excel spreadsheet, which has
some nice visual formatting to see the full breakdown of results. I've also
attached as {{ods}} format for compatibility, but this loses the formatting.
was (Author: benedict):
I have uploaded the results of a several days of performance comparisons, and
for posterity the scripts I used to generate and parse them into a spreadsheet,
on the effect of this change on inserting into a partition.
The results are pretty significant; some highlights:
Collection types are universally and dramatically improved:
* >99% memory consumption reduction
* ~25x throughput
Concurrent operations on non-collections:
* vs 3.0 with locking enabled _instantly_ (i.e. upgrade to locking after first
competition)
** With 4 competing threads, across the board lower memory utilisation;
near-equivalent with 16-threads
** With 4 or 16 competing threads, ~200% throughput improvement
* vs 3.0 with default locking
** 100-200% throughput improvement
** 30-60% reduction in memory consumption
~25% improvement in throughput and 50% reduction in memory allocated for
uncontended successful operations.
I recommend taking a look at the attached (zipped) Excel spreadsheet, which has
some nice visual formatting to see the full breakdown of results. I've also
attached as {{ods}} format for compatibility, but this loses the formatting.
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
> I am still awaiting the final results of the comprehensive performance
> comparison for {{AtomicBTreePartition}}, after which I will establish what
> impact there might be o
[jira] [Commented] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019381#comment-17019381
]
Benedict Elliott Smith commented on CASSANDRA-15511:
I have uploaded the results of a several days of performance comparisons, and
for posterity the scripts I used to generate and parse them into a spreadsheet,
on the effect of this change on inserting into a partition.
The results are pretty significant; some highlights:
Collection types are universally and dramatically improved:
* >99% memory consumption reduction
* ~25x throughput
Concurrent operations on non-collections:
* vs 3.0 with locking enabled _instantly_ (i.e. first upgrade to locking after
first competition)
** With 4 competing threads, across the board lower memory utilisation;
near-equivalent with 16-threads
** With 4 or 16 competing threads, ~200% throughput improvement
* vs 3.0 with default locking
** 100-200% throughput improvement
** 30-60% reduction in memory consumption
~25% improvement in throughput and 50% reduction in memory allocated for
uncontended successful operations.
I recommend taking a look at the attached (zipped) Excel spreadsheet, which has
some nice visual formatting to see the full breakdown of results. I've also
attached as {{ods}} format for compatibility, but this loses the formatting.
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
> I am still awaiting the final results of the comprehensive performance
> comparison for {{AtomicBTreePartition}}, after which I will establish what
> impact there might be on compaction and normal reads, both of which should be
> affected by this patch.
--
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-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019381#comment-17019381
]
Benedict Elliott Smith edited comment on CASSANDRA-15511 at 1/20/20 10:34 AM:
--
I have uploaded the results of a several days of performance comparisons, and
for posterity the scripts I used to generate and parse them into a spreadsheet,
on the effect of this change on inserting into a partition.
The results are pretty significant; some highlights:
Collection types are universally and dramatically improved:
* >99% memory consumption reduction
* ~25x throughput
Concurrent operations on non-collections:
* vs 3.0 with locking enabled _instantly_ (i.e. upgrade to locking after first
competition)
** With 4 competing threads, across the board lower memory utilisation;
near-equivalent with 16-threads
** With 4 or 16 competing threads, ~200% throughput improvement
* vs 3.0 with default locking
** 100-200% throughput improvement
** 30-60% reduction in memory consumption
~25% improvement in throughput and 50% reduction in memory allocated for
uncontended successful operations.
I recommend taking a look at the attached (zipped) Excel spreadsheet, which has
some nice visual formatting to see the full breakdown of results. I've also
attached as {{ods}} format for compatibility, but this loses the formatting.
was (Author: benedict):
I have uploaded the results of a several days of performance comparisons, and
for posterity the scripts I used to generate and parse them into a spreadsheet,
on the effect of this change on inserting into a partition.
The results are pretty significant; some highlights:
Collection types are universally and dramatically improved:
* >99% memory consumption reduction
* ~25x throughput
Concurrent operations on non-collections:
* vs 3.0 with locking enabled _instantly_ (i.e. first upgrade to locking after
first competition)
** With 4 competing threads, across the board lower memory utilisation;
near-equivalent with 16-threads
** With 4 or 16 competing threads, ~200% throughput improvement
* vs 3.0 with default locking
** 100-200% throughput improvement
** 30-60% reduction in memory consumption
~25% improvement in throughput and 50% reduction in memory allocated for
uncontended successful operations.
I recommend taking a look at the attached (zipped) Excel spreadsheet, which has
some nice visual formatting to see the full breakdown of results. I've also
attached as {{ods}} format for compatibility, but this loses the formatting.
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
> I am still awaiting the final results of the comprehensive performance
> comparison for {{AtomicBTreePartition}}, after which I will establish what
> impact there might be on compaction and normal reads, both of which should be
> affected by this patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsub
[jira] [Updated] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15511:
---
Attachment: atomicbtreepartition.xlsx.zip
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
> I am still awaiting the final results of the comprehensive performance
> comparison for {{AtomicBTreePartition}}, after which I will establish what
> impact there might be on compaction and normal reads, both of which should be
> affected by this patch.
--
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-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15511:
---
Attachment: perfsh.tar.gz
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Attachments: atomicbtreepartition.ods, perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
> I am still awaiting the final results of the comprehensive performance
> comparison for {{AtomicBTreePartition}}, after which I will establish what
> impact there might be on compaction and normal reads, both of which should be
> affected by this patch.
--
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-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15511:
---
Attachment: atomicbtreepartition.ods
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Attachments: atomicbtreepartition.ods
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
> I am still awaiting the final results of the comprehensive performance
> comparison for {{AtomicBTreePartition}}, after which I will establish what
> impact there might be on compaction and normal reads, both of which should be
> affected by this patch.
--
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-15514) Properly clean up DefaultSessionProvider#sessionCache when closing QueryReplayer
[
https://issues.apache.org/jira/browse/CASSANDRA-15514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15514:
Reviewers: Marcus Eriksson
> Properly clean up DefaultSessionProvider#sessionCache when closing
> QueryReplayer
>
>
> Key: CASSANDRA-15514
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15514
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The {{DefaultSessionProvider}} used by the {{QueryReplayer}} caches the
> sessions by hostname. When closing, the sessions and their associated
> clusters are closed but they never get removed from the cache.
> When connecting to the same host, the closed session is returned, which is
> unexpected.
> Besides the unexpected behavior, the session references remaining in the
> cache leaks resources.
--
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
