[
https://issues.apache.org/jira/browse/CASSANDRA-17575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17571890#comment-17571890
]
Andres de la Peña commented on CASSANDRA-17575:
-----------------------------------------------
As pointed out by [~jjordan] on [the mail
list|https://lists.apache.org/[email protected]], using
closed intervals for token range compactions actually makes sense. The token
ranges passed to {{nodetool compact}} would probably come from
{{{}sstablemetadata{}}}, which presents the first and last tokens in the
sstable. This is a closed interval, matched by {{nodetool compact}} closed
intervals.
Also, a common use case is compacting a sstable with a single big partition.
Half-open intervals don't allow to compact a single token, whereas closed
intervals do allow it.
What it is quite confusing, besides the lack of documentation, is that manual
compaction uses {{Range<Token>}} as argument, and the {{Range}} class is
half-open by definition (see
[here|https://github.com/apache/cassandra/blob/1f067051537618804ca9d0c66b903be74b942b22/src/java/org/apache/cassandra/dht/Range.java#L33]
and
[here|https://github.com/apache/cassandra/blob/1f067051537618804ca9d0c66b903be74b942b22/src/java/org/apache/cassandra/dht/Range.java#L236-L239]).
However, when compacting we interpret those ranges as if they where closed.
We could use the closed interval {{Bounds}} instead of {{Range}} to better
represent the intervals, but unfortunately {{Bounds}} are not-wrapping whereas
the manual compaction methods support wrapping ranges. Also, even if we moved
to {{Bounds}} we would still need to keep the ranges on the JMX methods for
backwards compatibility.
So I'm just modifying the help of {{nodetool compact}} and adding some comments
on the related methods about how the ranges are interpreted:
||PR||CI||
|[3.11
|https://github.com/apache/cassandra/pull/1742]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1959/workflows/3f391a29-a6b3-4c3a-927f-b33bf8ababf0]|
|[4.0
|https://github.com/apache/cassandra/pull/1743]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1958/workflows/120ace71-13ef-4968-b50c-3d1cc899eef4]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1958/workflows/49e528f0-7203-4e53-b240-fca559724296]|
|[4.1
|https://github.com/apache/cassandra/pull/1744]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1960/workflows/d03a643e-e180-40ff-9700-bd9ab5b093bb]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1960/workflows/03a70f7e-155a-43fb-97c2-cfb64fb35937]|
|[trunk|https://github.com/apache/cassandra/pull/1745]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1957/workflows/93336e6a-f6ef-4476-90ab-f678b898385d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1957/workflows/fdd6d458-2eea-4e4c-9330-771ff2f8b50b]|
> forceCompactionForTokenRange when using a wrapped range may include sstables
> not within that range
> --------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-17575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17575
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
> Reporter: David Capwell
> Assignee: Andres de la Peña
> Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1-beta, 4.1.x
>
>
> This was found in CASSANDRA-17537
> When you compact the range (32, 31] this should include everything BUT 32,
> but in the test
> org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest#testTokenRangeCompaction
> it found that SSTables with the bounds (32, 32) were getting included in the
> set of SSTables to compact
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
