Looks like this is out and there's a 5.0-rc release. Is a 4.1.6 release
with a fix for CASSANDRA-19668 coming?
On Sat, Jun 29, 2024 at 2:39 AM Mick Semb Wever wrote:
>
> The votes fails with a veto in place having made CASSANDRA-19668 an
> 5.0-rc blocker.
>
> Once 19668 lands we will need an im
>From a user PoV, I'd call G1 drastically friendlier than CMS in that it
tends to be well-behaved under a variety of workloads and heap sizes right
out of the box without the kind of dark-art tuning and overnight surprises
you get with CMS. Granted the smallest heap I have now is 2GB, but that's
n
Not sure how many people this would end up applying to, but.. how does this
affect write latency in batch or group mode? I'm running across what seems
to be a latency bottleneck in NVME drives that lack a capacitor-backed
cache where writes take ~5-10ms in batch mode, though the drive is of
course
To deal with this, I've just made a very small Bash script that looks at
commitlog age, then set the script as an "ExecStartPre=" in systemd:
if [[ -d '/opt/cassandra/data/data' && $(/usr/bin/find
/opt/cassandra/data/commitlog/ -name 'CommitLog*.log' -mtime -8 | wc -l)
-eq 0 ]]; then
>&2 echo "
Personally, I'd planned to upgrade to 4.0 on JDK8 but only wait a few weeks
before starting to update to JDK11 afterwards. Everything else we run's
been updated to JDK11, so the Cassandra clusters are the odd one out at
this point.
On Mon, Jul 13, 2020 at 12:19 PM Jordan West wrote:
> Thanks fo
While the protocol's being changed, does it make sense to add in
CASSANDRA-13292 as well? Or at least, some sort of ability to choose a hash
algorithm?
On Wed, Oct 9, 2019 at 1:32 PM Dinesh Joshi wrote:
> +1
>
> Dinesh
>
> > On Oct 9, 2019, at 12:41 PM, Joshua McKenzie
> wrote:
> >
> >>
> >> ea
he messaging version of the destination node and sent the appropriate hash
> back.
>
> -Joey
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-13291
> [2] https://issues.apache.org/jira/browse/CASSANDRA-13292
> [3] https://issues.apache.org/jira/browse/CASSANDRA-14611
>
They also don't matter for digests, as long as we're assuming all nodes in
the cluster are non-malicious (which is a pretty reasonable and probably
necessary assumption). Or at least, deliberate collisions don't.
Accidental collisions do, but 128 bits is sufficient to make that
sufficiently unlike
Thanks to open source, you can answer yourself:
https://github.com/apache/cassandra/search?q=md5&unscoped_q=md5
At a glance, looks like it's used for digest verification, and to get a
good hash distribution on the RandomPartitioner
I haven't done the math, but I suspect CRC32's just not good enoug
A big one to add to your list there, IMO as a user:
* API for determining detailed repair state (and history?). Essentially,
something beyond just "Is some sort of repair running?" so that tools like
Reaper can parallelize better.
On Sun, Sep 9, 2018 at 8:30 AM, Stefan Podkowinski wrote:
> Does
My two cents as a (relatively small) user. I'm coming at this from the
ops/user side, so my apologies if some of these don't make sense based on a
more detailed understanding of the codebase:
Repair is definitely a major missing piece of Cassandra. Integrated would
be easier, but a sidecar might
11 matches
Mail list logo
