I think that's right, using a closed range makes sense to consume the data
provided by "sstablemetadata", which also provides closed ranges.
Especially because with half-open ranges we couldn't compact a sstable with
a single big partition, of which we might only know the token but no the
partition
Reading the responses here and taking a step back, I think the current behavior
of nodetool compact is probably the correct behavior. The main use case I can
see for using nodetool compact is someone wants to take some sstable and
compact it with all the overlapping sstables. So you run “sstab
+1 to new flags. A released, albeit undocumented, behavior is still a
contract with the end user. Flags (and documentation) seem like the right
path to address the situation.
Cheers,
Derek
On Tue, Jul 26, 2022 at 7:28 AM Benedict Elliott Smith
wrote:
>
> I think a change like this could be dan
+1 to Benedict and Ekaterina's points - adding new flags to explicitly
introduce the new behavior and documenting the hell out of both the default and
the new flags seems like the right play. There's quite possibly a lot of
tooling out there in the wild that relies on the current behavior and br
I also like the idea with the flags plus improving the documentation as my
understanding was that it is not really documented and can be confusing and
risky for end users.
On Tue, 26 Jul 2022 at 9:28, Benedict Elliott Smith
wrote:
>
> I think a change like this could be dangerous for a lot of ex
I think a change like this could be dangerous for a lot of existing automation
built atop nodetool.
I’m not sure this change is worthwhile. I think it would be better to introduce
e.g. -ste and -ete for “start token exclusive” and “end token exclusive” so
that users can opt-in to whichever sc
+1, I think that makes the most sense.
Kind Regards,
Brandon
On Tue, Jul 26, 2022 at 8:19 AM J. D. Jordan wrote:
>
> I like the third option, especially if it makes it consistent with repair,
> which has supported ranges longer and I would guess most people would think
> the compact ranges wor
I like the third option, especially if it makes it consistent with repair,
which has supported ranges longer and I would guess most people would think the
compact ranges work the same as the repair ranges.
-Jeremiah Jordan
> On Jul 26, 2022, at 6:49 AM, Andrés de la Peña wrote:
>
>
> Hi all
[Public]
Hi Bowen,
Thanks for your reply. Now it is clear that what are some benefits of this
patch. I will send it for review once it is ready and hopefully it gets
accepted.
Thanks,
Amit
From: Bowen Song via dev
Sent: Tuesday, July 26, 2022 5:36 PM
To: dev@cassandra.apache.org
Subject: Re:
Hi Amit,
That's some brilliant tests you have done there. It shows that the
compaction throughput not only can be a bottleneck on the speed of
insert operations, but it can also stress the JVM garbage collector. As
a result of GC pressure, it can cause other things, such as insert, to fail.
Hi all,
CASSANDRA-17575 has detected that token ranges in nodetool compact are
interpreted as closed on both sides. For example, the command "nodetool
compact -st 10 -et 50" will compact the tokens in [10, 50]. This way of
interpreting token ranges is unusual since token ranges are usually
half-op
[Public]
Hi Bowen,
Thanks for the reply and it helped to identify the failure point. Tested
compaction throughput with different values and threads active in compaction
reports "java.lang.OutOfMemoryError: Map failed" error with 1024 MB/s earlier
compared to other values. This shows with lower
12 matches
Mail list logo
