’s good to have sidecar expose this and expose common
> patterns that people actually use.
>
> If sidecar wishes to expose exec and take the fact that this API could
> break on it, I am +0 to that. I mostly am trying to highlight the risk
>
> On Jun 20, 2025, at 2:54 PM, Jon Ha
bound "simple mode" and a
> "--raw for experts" is the way to go.
>
> On Thu, Jun 19, 2025, at 1:23 PM, Jon Haddad wrote:
>
> I understand the motivation to decouple the command line configuration
> from what we expose to end users, and to an extent, agree with
I understand the motivation to decouple the command line configuration from
what we expose to end users, and to an extent, agree with the reasoning.
However, for folks like me that know the command line options and regularly
do things that you might not have planned out, I'd appreciate an escape
ha
+1
On Fri, Jun 13, 2025 at 11:40 AM Mick Semb Wever wrote:
> +1
>
> On Fri, 13 Jun 2025 at 13:58, Josh McKenzie wrote:
>
>> +1
>>
>> On Fri, Jun 13, 2025, at 7:56 AM, Josh McKenzie wrote:
>>
>> [DISCUSS] thread:
>> https://lists.apache.org/thread/vr7j2ob92k6fbcwvlfo60l3scylzdbft
>>
>> Text to v
I'd be very happy to see async-profiler included with C* I've made
extensive use of it in my performance evaluations [1][2], and even posted a
video about it [3] for general Java perf analysis (among others). It's
part of easy-cass-lab and is easily the most informative tool I've found
for the ge
xtra data scan
>
> This isn’t really the whole story. The amount of wasted scans on index
> repairs is negligible. If a difference is detected with snapshot repairs
> though, you have to read the entire partition from both the view and base
> table to calculate what needs to be fi
I have had great results with it. Shenandoah plus off heap trie memtables
can improve throughput by more than 2x when you have lower latency
requirements.
Lets do it.
On Mon, May 26, 2025 at 12:00 PM Dmitry Konstantinov
wrote:
> Hi all,
>
> I've created a task to mark JDK 17 as production-read
t cell's timestamps to determine if
> we've got missed writes?
>
>
> Within a single partition, timestamps should always be unique and
> incrementing. I think that would work on a per-column level.
>
> * With the two SSTable components, a tombstone index & a MV
I've written a few dozen tools over the years and have been happy with
JCommander. Picocli looks to follow pretty much all the same conventions,
but has a few nicer features on top. I'd love to see the entire project
standardize on it.
On Tue, May 20, 2025 at 2:29 AM Štefan Miklošovič
wrote:
>
able1: (1, 1, null, 1)
>-
>
>SSTable2: (1, null, 1, 1)
>
> *Node 2*
>
>-
>
>SSTable3: (1, 1, 1, 1)
>
> How can we ensure that a hash or Merkle tree computed at the SSTable level
> would produce the same result on both nodes for this row?
>
>
it
because of the users who want to do A/B tests against JVM versions, or want
the ability to debug potential java release issues in production without a
staging environment.
Jon
On Tue, May 20, 2025 at 9:07 AM Brandon Williams wrote:
> On Tue, May 20, 2025 at 10:59 AM Jon Haddad
> wrote:
> This gets stated on perhaps an annual basis, so perhaps we should start
> having these conversations on wiki to avoid the repetition.
>
>
>
> On 20 May 2025, at 16:37, Jon Haddad wrote:
>
>
> There’s no “leaving users in the lurch” by requiring JDK upgrades.
>
>
There’s no “leaving users in the lurch” by requiring JDK upgrades.
If users are using containers (pretty much everyone i talk to) then the JDK
is included, versions don’t matter.
If not, every modern Linux distro supports multiple installed JDKS. Again,
not a problem.
So far the only convincing
lot of
> possibilities, query wise, as well.
> This is something I’m not entirely sure about—how exactly do we use the
> local index to support the global index (i.e., the MV)? If the MV relies on
> local indexes during the query path, we can definitely dig deeper into how
> repair could w
The repo is now under the apache org:
https://github.com/apache/cassandra-easy-stress
On Mon, May 12, 2025 at 12:41 PM Jordan West wrote:
> Great! With that the vote passes with 10 +1s and no -1s. We are ready to
> initiate the transfer once INFRA picks it back up. Looks like Jon has been
> work
Could we could do that for regular repair as well? which would make a
validation possible with barely any IO?
Sstable attached merkle trees?
On Sat, May 17, 2025 at 5:36 PM Jon Haddad wrote:
> What if you built the merkle tree for each sstable as a storage attached
> index?
>
&g
deeper into how
> repair could work with that design.
>
> The proposed design in this CEP aims to treat the base table and its MV
> like any other regular tables, so that operations such as compaction and
> repair can be handled in the same way in most cases.
>
> On Sat, May 17,
ges in
> the base table, those ranges may span the entire MV token range. As a
> result, we need to scan the entire MV to generate all the necessary Merkle
> trees. For efficiency, we perform this as a single pass over the entire
> table rather than scanning a small range of the base or
Congrats!!
On Fri, May 16, 2025 at 4:13 PM Alexandre DUTRA wrote:
> Great news, and so well deserved! Congratulations Bret!
>
> Le ven. 16 mai 2025 à 19:00, Jeremiah Jordan a
> écrit :
>
>> Congrats Bret!
>>
>> On May 16, 2025 at 4:00:12 PM, Mick Semb Wever wrote:
>>
>>>
>>> The Project Manag
above, only a small percentage of the data would actually be
repaired at any given time.
Just a thought to save a little filesystem churn.
On Fri, May 16, 2025 at 10:55 AM Jon Haddad wrote:
> Nevermind about the height thing i guess its the same property.
>
> I’m done for now :)
se table token order and vise versa.
>
> On Fri, May 16, 2025, at 9:54 AM, Jon Haddad wrote:
>
> Thanks for the explanation, I appreciate it. I think you might still be
> glossing over an important point - which I'll make singularly here.
> There's a number of things
ex
Still a really hard problem.
Jon
On Thu, May 15, 2025 at 6:12 PM Jon Haddad wrote:
> There's a lot here that's still confusing to me. Maybe you can help me
> understand it better? Apologies in advance for the text wall :)
>
> I'll use this schema as an example
e equivalent.
>
> In short: Even for production use cases having RF=3 in one data center,
> we can see that the MV repair consumes temporary disk space and a small,
> usually negligible amount of extra CPU for tree construction; other costs
> match full repair.
>
> Additionally, w
tances it would be having to also expand the cluster to handle the
>> additional disk requirements. It turns an inconsistency problem into a
>> major operational headache that can take weeks to resolve.
>>
>> Agreed. The rebuild would not be required during normal operations
but the problem is operators aren't always going to
>> know when that data loss occurs. Not everything is as visible as a lost
>> quorum of replicas or blown up SSTables.
>>
>> On Wed, May 14, 2025, at 2:38 PM, Blake Eggleston wrote:
>>
>> Maybe, I’m not really fam
; it has an inevitable performance hit. I think that the performance of the
> repair process is definitely an important consideration and it would be
> helpful to have some benchmarks to have an idea of how long this repair
> process would take for lightweight and denser tables.
>
> On Wed,
uarantees, even if
>> it has an inevitable performance hit. I think that the performance of the
>> repair process is definitely an important consideration and it would be
>> helpful to have some benchmarks to have an idea of how long this repair
>> process would take fo
the ability to slap a SAI index on the
local MV while we're at it, that's a killer feature.
If we can't figure out how to repair a local MV, then there's no way we can
do it globally.
Jon
On Wed, May 14, 2025 at 4:28 AM Jon Haddad wrote:
> I've got several concern
e table's primary key columns that means
>>
>> The requirement for materialized views (MVs) to include the base table's
>> primary key appears to be primarily a syntactic constraint specific to
>> Apache Cassandra. For instance, in DynamoDB, the DDL for defining a Glob
> Or compaction hasn’t made a mistake, or cell merge reconciliation hasn’t
made a mistake, or volume bitrot hasn’t caused you to lose a file.
> Repair isnt’ just about “have all transaction commits landed”. It’s “is
the data correct N days after it’s written”.
Don't forget about restoring from a b
When I read this question, I have to wonder if you're approaching this as a
general solution to replace search, or if you're intending on using SAI as
a means to filter within a partition. It's designed to solve the latter.
The overhead of an SAI query scales with the number of SSTables you read.
Congrats!!!
On Mon, May 12, 2025 at 10:14 AM Ekaterina Dimitrova
wrote:
> Congrats, Abe! Thank you for all your awesome work!
>
> On Mon, 12 May 2025 at 13:12, Brad wrote:
>
>> Congrats, Abe!
>>
>> On Mon, May 12, 2025 at 12:46 PM Alex Petrov wrote:
>>
>>> Hello folks of the dev list,
>>>
>>>
+1
On Mon, May 12, 2025 at 7:28 AM Ariel Weisberg wrote:
> Hi dev@,
>
> I would like to start the voting for CEP-46: Finish Transient
> Replication/Witnesses
>
> Proposal:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=353601959
> Discussion:
> https://lists.apache.org/threa
or annoyance for projects in
> development, but the real concern I have with any large change is how it
> complicates the process of fixing bugs across versions. On the other hand,
> I don’t think that incorrectly casting objects has historically been a
> source of pain for us, so it se
Why not?
Personally, I hate the idea of treating a codebase (any codebase) like a
house of cards that can't be touched. It never made sense to me to try to
bundle new features / bug fixes with improvements to code quality.
Making the code more reliable should be a goal in itself, rather than a
s
Based on David and Blake’s responses, it sounds like we don’t need to block
on anything.
I realize you may be making a broader point, but in this instance it sounds
like there’s nothing here preventing an accord based MV implementation. Now
that i understand more about how it would be done, it als
Glad to see folks are looking to improve MVs. Definitely one of the areas
we need some attention paid to.
Do you have a patch already for this? We haven't had a discussion yet
about winding down new development in trunk but IMO we should probably stop
merging big things in soon and focus on gett
It took me a bit to wrap my head around how this works, but now that I
think I understand the idea, it sounds like a solid improvement. Being
able to achieve the same results as quorum but costing 1/3 less is a *big
deal* and I know several teams that would be interested.
One thing I'm curious ab
So Mick - just to be clear, it sounds like you're asking if we need a VOTE
thread, but also saying you want one regardless of ASF policy. Am I
understanding you correctly?
On Mon, May 5, 2025 at 3:37 AM Mick Semb Wever wrote:
> .
>
>
>> This IP Clearance form is not yet completed. Pleas
I've renamed the repo to cassandra-easy-stress and filed INFRA-26785 to
initiate the transfer.
https://issues.apache.org/jira/browse/INFRA-26785
Will update here when it's moved over.
Jon
On Fri, May 2, 2025 at 3:48 PM Jon Haddad wrote:
> Could use some love, but not too bad.
Could use some love, but not too bad.
On Fri, May 2, 2025 at 3:44 PM Patrick McFadin wrote:
> Lazily. Yes, bring it on over. But... how do the docs look? *runs away
>
> On Fri, May 2, 2025 at 12:39 PM Jon Haddad
> wrote:
>
>> Since we only need lazy consensus here - it
Since we only need lazy consensus here - it sounds like i can go ahead and
rename the repo to cassandra-easy-stress and transfer it over to Apache.
On Thu, May 1, 2025 at 1:37 PM Aaron wrote:
> +1
>
> On Thu, May 1, 2025 at 4:27 PM Dave Herrington
> wrote:
>
>> +1 (nb)
>>
>> -Dave
>>
>> On Wed,
os, docs, website, and comments etc
> operate a “Commit Then Review
> <https://www.apache.org/foundation/glossary.html#CommitThenReview>”
> policy"
>
> Kind Regards,
> Brandon
>
>
> On Thu, May 1, 2025 at 3:21 PM Jon Haddad wrote:
>
>> I propose we en
I propose we encourage committers commit docs without review or a JIRA.
On Thu, May 1, 2025 at 8:06 AM Jon Haddad wrote:
> Stefan,
>
> Any feature developed for Cassandra is a collaborative effort. The public
> branches of accord have been available for months. Have you contribu
Stefan,
Any feature developed for Cassandra is a collaborative effort. The public
branches of accord have been available for months. Have you contributed to
the accord docs? You've had plenty of opportunity.
It looks like you're turning your own thread into an airing of grievances.
It's not pa
I love the idea of having great docs, but blocking at this point probably
hurts the project more than it helps. How about we see if we can find
people that are actually interested in working on them? Figuring that out
needs to happen regardless. I suspect not many of us want to, or have time
to.
Stefan, I agree with you, that's a pretty terrible way to go about writing
docs, and I'm not sure if you're being hyperbolic. I really don't think
it's what Patrick is suggesting.
LLMs are great at taking some notes and examples and turning it into docs.
You don't need to have it write everything,
Id be perfectly fine keeping the name. People do know it, its been around
for two years.
As long as no one minds that i continue to own and maintain easy-cass-lab,
keeping the name works for me.
On Wed, Apr 30, 2025 at 8:42 AM Paulo Motta wrote:
> -incubator (please do not reply this discussio
+1
On Wed, Apr 30, 2025 at 8:18 AM Jordan West wrote:
> +1
>
> On Wed, Apr 30, 2025 at 8:15 AM Jordan West wrote:
>
>> (general@incubator cc'd)
>>
>> Please vote on the acceptance of the easy-cass-stress (to be renamed
>> cassandra-stress) and its IP Clearance:
>>
>> https://incubator.apache.or
Congrats!!
On Wed, Apr 30, 2025 at 6:07 AM Mick Semb Wever wrote:
> Congrats!
>
> On Wed, 30 Apr 2025 at 13:44, Josh McKenzie wrote:
>
>> Hey there Cassandra Devs!
>>
>> The Apache Cassandra PMC is very happy to announce that Jaydeep Chovatia
>> has
>> accepted the invitation to become a comm
Hey everyone!
The Project Management Committee (PMC) for Apache Cassandra is delighted to
announce that David Capwell has joined the PMC!
Thank you David for all your contributions to the project over the years.
The PMC - Project Management Committee - manages and guides the direction
of the pro
the Cassandra website
> repo. Did I miss that it's built when building the server?
>
> On Mon, Apr 28, 2025 at 10:19 AM Jon Haddad
> wrote:
>
>> I strongly prefer we didn't install things on users systems they didn't
>> ask for. I think we're also
I strongly prefer we didn't install things on users systems they didn't ask
for. I think we're also wasting people's time by building the website by
default.
ant isn't a popular tool. The more we ask people to know about it, the
more we turn people away from the project. I'm personally unwillin
> If 5.0 supports 17, then 7.0 should too, if we are to say we support
5.0 to 7.0 upgrades.
I have to disagree with this. I don't see a good reason have a tight
coupling of JVM versions to C* versions, and I also don't see a good reason
to overlap outside of CI. Even on CI, the reasoning is a
; view?
>
> On Wed, 23 Apr 2025 at 13:42, Jon Haddad wrote:
>
>> So to be clear - are we simultaneously calling Java 17 in 5.0 deprecated
>> AND experimental?
>>
>>
>>
>> On Wed, Apr 23, 2025 at 10:23 AM Joseph Lynch
>> wrote:
>>
>>&g
So to be clear - are we simultaneously calling Java 17 in 5.0 deprecated
AND experimental?
On Wed, Apr 23, 2025 at 10:23 AM Joseph Lynch wrote:
> +1 given "Have it for *at least* 1 MAJOR in deprecated status
> (deprecate-then-remove)"
>
> How does that sit with you Joey?
>>
> Great! Really app
Thanks Doug!!
Supporting vnodes is huge and I'm excited to see it being worked on. My
experience has been most environments are using them, and single token
clusters are outliers. Usually run by folks who have been part of the
project for a long time, and often committers. I'm looking forward t
Just a reminder!
The deadline to submit a proposal closes at 6:59 PM 21 Apr 2025 in Central
Daylight Time (UTC-05:00) timezone.
Jon
On Mon, Mar 10, 2025 at 6:51 AM Paulo Motta wrote:
> Hi,
>
> Please see message below with instructions on submitting talk proposals
> for Community Over Code 202
any other
> concerns and call a vote if not.
>
> Thanks everyone for the engagement.
>
> On Fri, Apr 11, 2025, at 11:22 AM, Josh McKenzie wrote:
>
> So we avoid 6.1, 7.2, etc? Does this imply that each release is allowed
> to make breaking changes (assuming they followed th
+1
On Thu, Apr 17, 2025 at 9:15 AM Josh McKenzie wrote:
> +1
>
> On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote:
>
> [DISCUSS] thread:
> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
>
> The proposed new versioning mechanism:
>
>1. We no longer use semver .MINOR
>
lue. The constraint is
> more of a weakly applied suggestion._
>
> This is not true. You can not really put there null. See other discussion
> about this behaviour on ML.
>
> On Wed, Apr 16, 2025 at 6:36 PM Jon Haddad
> wrote:
>
>> I think the world is fairly use
I think the world is fairly used to NOT NULL in line with the type. I
don't see much value in paving our own path for things that are established
norms. Let's not reinvent wheels that don't need reinventing.
I also think it's fine if the generated CQL from describe doesn't match the
user's input
On Fri, Apr 11, 2025 at 2:09 PM Jeff Jirsa wrote:
>
>
> > On Apr 11, 2025, at 1:15 PM, Jon Haddad wrote:
> >
> >
> > I also keep running up against my concern about treating object store as
> a write back cache instead of write through. "Tiering" data o
/www.man7.org/linux/man-pages/man7/lvmcache.7.html
On Sat, Mar 8, 2025 at 3:00 PM Jon Haddad wrote:
> I really like the data directories and replication configuration. I think
> it makes a ton of sense to put it in the yaml, but we should probably yaml
> it all, and not nest JSON :),
rts to
> introduce this small "discrepancy" that we seem to favor one specific type
> / format over the others.
>
> On Fri, Apr 11, 2025 at 6:25 PM Jon Haddad
> wrote:
>
>> I agree NOT NULL is nicer than check not null.
>>
>> Taking the JSON bit
“CHECK NOT NULL”
>>>> is the full token introduced rather than “CHECK” separately from
>>>> constraints that are checked.
>>>>
>>>> If “check” is introduced as a standalone reserved keyword: my primary
>>>> feedback is on the introducti
+1.
It's the proper signal to the community. A .1 release could still be done
as an exception, but I have a hard time thinking of a case other than
supporting a newer JDK without any other changes.
On Fri, Apr 11, 2025 at 7:19 AM Jeremiah Jordan wrote:
> +1 from me.
> No more wondering what th
+1
On Mon, Apr 7, 2025 at 10:40 AM Caleb Rackliffe
wrote:
> +1
>
> On Mon, Apr 7, 2025 at 7:37 AM Brandon Williams <
> brandonwilli...@apache.org> wrote:
>
>> Proposing the test build of Cassandra 5.0.4 for release.
>>
>> sha1: b81163b04b1d99036730ff233595d7bfb88611d1
>> Git: https://github.com/
Bringing this back up.
I don't think we have any reason to hold up renaming the version. We can
have a separate discussion about what upgrade paths are supported, but
let's at least address this one issue of version number so we can have
consistent messaging. When i talk to people about the next
This looks like a really nice improvement to me.
On Thu, Apr 10, 2025 at 7:27 AM Štefan Miklošovič
wrote:
> Recently, David Capwell was commenting on constraints in one of Slack
> threads (1) in dev channel and he suggested that the current form of "not
> null" constraint we have right now in p
27;s taken a transitive dependency. Might
>> be bad form on the plugin's part, but certainly possible.
>>
>> I've gotten the impression that there's not a lot of enthusiasm for
>> breaking apart the main Cassandra module, but I have wondered if it'd be
>
common place to access metrics to provide
> the correspondent virtual tables at least.
> Regarding docs - I like this. I actually did something similar in one of
> my non-open source projects by adding a description to each metric to be
> able to render docs + to validate during a build th
metric types is something we should be sure to
> maintain.
>
> Chris
>
> On Fri, Mar 7, 2025 at 1:33 PM Jon Haddad wrote:
>
> As long as operators are able to use all the OTel tooling, I'm happy. I'm
> not looking to try to decide what the metrics API looks like, a
This is all really exciting. Getting a built in, orchestrated repair is a
massive achievement. Thank you for your work on this, it's incredibly
valuable to the community!!
Jon
On Sun, Mar 9, 2025 at 2:25 PM Jaydeep Chovatia
wrote:
> No problem, Dave! Thank you.
>
> Jaydeep
>
> On Sun, Mar 9,
+1
On Sun, Mar 9, 2025 at 9:52 AM wrote:
> +1
>
>
> On Mar 9, 2025, at 7:50 AM, Jeremiah Jordan
> wrote:
>
> +1
>
> On Sun, Mar 9, 2025 at 8:03 AM Brandon Williams wrote:
>
>> +1
>>
>> Kind Regards,
>> Brandon
>>
>> On Sun, Mar 9, 2025 at 7:18 AM Mick Semb Wever wrote:
>> >
>> > Please vote
e "0s".
> I am thinking that the strategies maybe should live in cassandra.yaml and
> not table properties because they're usually a property of the node being
> setup, tables can't magically make you have more locations to store data in.
>
> Nice thing about this i
/ node for years, now I'm thinking about 100TB / node.
Jon
On Sat, Mar 8, 2025 at 6:31 AM Jon Haddad wrote:
> Thanks Jordan and Joey for the additional info.
>
> One thing I'd like to clarify - what I'm mostly after is 100% of my data
> on object store, local disk
y. That brought me around to needing an
>> implementation we own that we can optimize properly as others have
>> discussed.
>>
>> Regarding what percent of data should be in the cold store I would love
>> to see an implementation that allows what Jon is proposin
osh McKenzie wrote:
> >
> >
> >
> > if the plan is to rip out something old and unmaintained and replace
> with something new, I think there's a huge win to be had by implementing
> the standard that everyone's using now.
> >
> > Strong +1 on a
everything except (e.g) snapshots would be
> treated as it is now.
>
> But, I can see how this will take a very, very long time to implement.
> This is a complex CEP to tackle. I remember this topic being discussed in
> the past as well. I _think_ there were at least two occasions whe
what that is going to look like does not mean I am
> dismissive.
>
> (1) https://lists.apache.org/thread/ofh2q52p92cr89wh2l3djsm5n9dmzzsg
>
> On Fri, Mar 7, 2025 at 5:44 PM Jon Haddad wrote:
>
>> Nobody is saying you can't work with a mount, and this isn't a
&g
>>
>>> Azure (this one is quite sophisticated), lot of options ...
>>>
>>>
>>> https://learn.microsoft.com/en-us/azure/storage/blobs/blobfuse2-how-to-deploy?tabs=RHEL
>>>
>>> S3, lot of options how to mount that
>>>
>>> https
lopment for the time being. I’m not sure when we will
> prioritise any of the above.
>
> Our resources are finite and we’ve exhausted them (literally), so it’s
> pretty much pick one of the above. I don’t really mind which you pick, but
> I won’t personally be prioritising merge after
cause
>> >>
>> >> I have (yet another) presentation and this would be a cool update.
>> >>
>> >>
>> >> On Wed, Mar 5, 2025 at 1:22 AM Benedict Elliott Smith
>> >>
>> >> wrote:
>> >>
>> >> >
&g
main Cassandra module, but I have wondered if it'd be
> worth making an exception for the interfaces plugins are supposed to code
> against. It'd be nice to depend on those without pulling in the rest of the
> project, and it'd be another step towards reducing the risk o
xclude the local
storage as cache option, and should be accounted for in the design.
Jon
[1] https://issues.apache.org/jira/browse/CASSANDRA-19663
On Thu, Mar 6, 2025 at 10:31 AM Joel Shepherd wrote:
> On 3/6/2025 7:16 AM, Jon Haddad wrote:
>
> Assuming everything else is identical, mig
Assuming everything else is identical, might not matter for S3. However,
not every object store has a filesystem mount.
Regarding sprawling dependencies, we can always make the provider specific
libraries available as a separate download and put them on their own thread
with a separate class path.
t; be down to others to decide if they are willing to undertake this work
>>
>> I think the fallback option for now, however, is to abuse unsafe to allow
>> us to override the implementation details of Codahale metrics. So we can
>> decouple the performance discussion for now from
gt;
>>>>
>>>> Is anyone else interested in continuing to discuss this topic?
>>>>
>>>> guo Maxwell 于2024年9月20日周五 09:44写道：
>>>>
>>>>> I discussed this offline with Claude, he is no longer working on this.
>>>>>
>>
I've got a few thoughts...
On the performance side, I took a look at a few CPU profiles from past
benchmarks and I'm seeing DropWizard taking ~ 3% of CPU time. Is there a
specific workload you're running where you're seeing it take up a
significant % of CPU time? Could you share some metrics, pr
Congrats Aaron!
On Tue, Mar 4, 2025 at 10:26 AM Jordan West wrote:
> Congratulations!!
> On Tue, Mar 4, 2025 at 09:57 Tolbert, Andy wrote:
>
>> Congrats Aaron!
>>
>> On Tue, Mar 4, 2025 at 11:24 AM Francisco Guerrero
>> wrote:
>>
>>> Congratulations Aaron!
>>>
>>> On 2025/03/04 00:23:49 Patric
Welcome!
On Tue, Mar 4, 2025 at 10:25 AM Jordan West wrote:
> Congratulations!!
>
> On Tue, Mar 4, 2025 at 10:16 Arjun Ashok wrote:
>
>> Congratulations Bernardo !!
>>
>> On Mon, Mar 3, 2025 at 11:31 PM Štefan Miklošovič
>> wrote:
>>
>>> The Project Management Committee (PMC) for Apache Cassan
Very exciting!
I have a client that's very interested in Accord, so I should have budget
to dig into it, especially on the performance side of things.
Jon
On Tue, Mar 4, 2025 at 9:57 AM Dmitry Konstantinov
wrote:
> Thank you to all Accord and TCM contributors, it is really exciting to see
> a
I’ve encountered a handful of spinning platters, but not a lot.
I think we should generally optimize for the common case, not the
exception.
On Thu, Feb 27, 2025 at 9:51 AM Josh McKenzie wrote:
> This is a significant enough performance problem *in normal operations*
> I'd consider it a bug an
Welcome!!
On Thu, Feb 20, 2025 at 4:21 PM Patrick McFadin wrote:
> Welcome and congratulations Maxwell and Dmitry!
>
> On Thu, Feb 20, 2025 at 2:07 PM Jacek Lewandowski
> wrote:
> >
> > Congratulations guys!
> >
> >
> > - - -- --- - -
> > Jacek Lewandowski
> >
> >
> > c
The PMC for Apache Cassandra is delighted to announce that Caleb Rackliffe
has joined it's membership!
Caleb has been a member of the community for 10 years and is one of the
most active committers on the project.
Please join us in welcoming Caleb to his new role!
Jon
On behalf of the Cassandra
Cloud seems to be 512K（If I remember correctly).
>>
>> Just like 19488, give the test method, see who can assist in the test ,
>> and provide the results.
>>
>> Jon Haddad 于2025年2月13日周四 08:30写道：
>>
>>> Can you elaborate why? This would be several hundr
Yeah, also I lean strongly towards using the Java driver.
Dogfooding the Java driver has real benefits. I don't see any benefit to
maintaining the SimpleClient.
Jon
On Thu, Feb 13, 2025 at 12:25 PM Tolbert, Andy wrote:
> Thanks Abe! I had a bit of a blind spot in checking for prior tickets.
Hey Andy,
This seems like a reasonable proposal.
We can probably skip cassandra-stress, since it looks like easy-cass-stress
can be donated. That does need a driver upgrade to support a vector
workload, but imo there's no point in investing more in cassandra-stress
when we have an alternative wi
;> I have not read the ticket in detail, so apologies if this was already
>> discussed there or elsewhere.
>>
>> On Wed, Feb 12, 2025 at 3:01 PM Jon Haddad
>> wrote:
>> >
>> > Hey folks,
>> >
>> > Over the last 9 months Jordan and I h
1 - 100 of 418 matches
Mail list logo
