[
https://issues.apache.org/jira/browse/CASSANDRA-14397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510859#comment-16510859
]
Alex Petrov edited comment on CASSANDRA-14397 at 6/13/18 6:51 PM:
------------------------------------------------------------------
[~krummas] thank you for the patch! +1 LGTM, I just have 2 minor comments:
* We might benefit from also adding the call to {{isStopRequested}} to
{{AbortableUnfilteredPartitionTransformation#applyToPartition}}. This way
[CompactionManager#doCleanupOne|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L1158-L1159]
and
[CompactionTask#runMayThrow|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionTask.java#L200-L201]
won't need to have this logic separately. Also, it will be self-contained in a
single class, which might be a good thing. The downside of that is that
upstream transformations {{applyToPartition}} calls will be still made, but it
might be minor enough considering potentially simpler code. What do you think?
* I've tried to reuse {{CompactionIteratorTest}} to write a more "precise"
test (also, get rid of sleeps there), and so far
[this|https://gist.github.com/ifesdjeen/4caf84423fa321ceca79d9b8c041fe0c] was
what I came up with. In short, relying on timing is a good thing for review and
it was nice to be able to use with this test while reviewing, but testing
compaction iterator directly might have a benefit of both knowing that
{{CompactionInterruptedException}} is thrown in a precise moment in time, and
might remove some flakiness (which to be honest I could not reproduce locally,
but as your comment says it begs to).
was (Author: ifesdjeen):
[~krummas] thank you for the patch! It looks good, I just have 2 minor comments:
* We might benefit from also adding the call to {{isStopRequested}} to
{{AbortableUnfilteredPartitionTransformation#applyToPartition}}. This way
[CompactionManager#doCleanupOne|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L1158-L1159]
and
[CompactionTask#runMayThrow|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionTask.java#L200-L201]
won't need to have this logic separately. Also, it will be self-contained in a
single class, which might be a good thing. The downside of that is that
upstream transformations {{applyToPartition}} calls will be still made, but it
might be minor enough considering potentially simpler code. What do you think?
* I've tried to reuse {{CompactionIteratorTest}} to write a more "precise"
test (also, get rid of sleeps there), and so far
[this|https://gist.github.com/ifesdjeen/4caf84423fa321ceca79d9b8c041fe0c] was
what I came up with. In short, relying on timing is a good thing for review and
it was nice to be able to use with this test while reviewing, but testing
compaction iterator directly might have a benefit of both knowing that
{{CompactionInterruptedException}} is thrown in a precise moment in time, and
might remove some flakiness (which to be honest I could not reproduce locally,
but as your comment says it begs to).
> Stop compactions quicker when compacting wide partitions
> --------------------------------------------------------
>
> Key: CASSANDRA-14397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14397
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Priority: Major
> Fix For: 4.x
>
>
> We should allow compactions to be stopped when compacting wide partitions,
> this will help when a user wants to run upgradesstables for example.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
