While I agree that time spent working on a feature is not necessarily a clear
indicator of maturity, one can judge the scope of work and thought that went
into Accord by both its separate repository, and the working branch.
I think that merging/accepting SASI was not a mistake. There were sever
I’m also supportive of proceeding to merge.The CEP contributors have worked incredibly hard on the protocol and feature and I’m proud it’s reached this point.If the concern is trunk stability - we have been deploying trunk-derived builds for over six months and will continue to do so post-merge. Ma
Absolutely, happy to share. All tests were done using easy-cass-stress v9
and easy-cass-lab, with the latest released 5.0 (not including 15452 or
20092). Instructions at the end.
> Regarding allocation rate vs throughput, unfortunately allocation rate vs
throughput are not connected linearly,
Y
Jon, thank you for testing!, can you share your CPU profile and test load
details? Have you tested it with CASSANDRA-20092 changes included?
>> Allocations related to codahale were < 1%.
Just to clarify: in the initial mail by memory footprint I mean the static
amount of memory used to store metri
It sounds like we are all pretty interested in seeing this feature land and
the branch maintenance is causing overhead that could be spent on
finalisation. +1 on merging, particularly given the feature flag work.
Once more unto the breach 💪
On Fri, 7 Mar 2025 at 6:56 PM, Benedict wrote:
> There
Definitely +1 on registry + docs. I believe that's part of the OTel Java
SDK [1][2]
I did some performance testing yesterday and was able to replicate the
findings where the codahale code path took 7-10% of CPU time. The only
caveat is that it only happens with compaction disabled. Once compact
Hi,
Please see message below with instructions on submitting talk proposals for
Community Over Code 2025.
*The deadline for submissions is April 21st 2025.*
Please note there is usually no deadline extension for this conference, so
I'd highly recommend submitting your proposals on time.
You can
+1
On Mon, Mar 10, 2025 at 9:28 AM Dinesh Joshi wrote:
> +1
>
> On Sun, Mar 9, 2025 at 5:18 AM Mick Semb Wever wrote:
>
>> Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
>> and its IP Clearance:
>> https://incubator.apache.org/ip-clearance/cassandra-ccm.html
>>
>> All cons
Because we want to validate against the latest code in trunk, else we are
validating stale behaviours. The cost of rebasing is high, so we do not do it
frequently. That means we will likely stop developing OSS-first, as the focus
will have to move to our internal branch that satisfies these crit
Hey Radim, thanks for bringing this to the list.
In general, I'm supportive of the second option you shared ("Exposing neutral
methods") but want to make sure I understand how CRaC would work in practice.
Could you clarify this part:
> Naturally it is possible to close the session object comple
The vote has passed with three binding +1s and no vetoes
On 2025/02/28 20:30:38 Bernardo Botella wrote:
> +1 (nb)
>
> Awesome milestone
>
> On Fri, Feb 28, 2025 at 11:06 Josh McKenzie wrote:
>
> > +1 - great work everyone!
> >
> > On Fri, Feb 28, 2025, at 1:58 PM, Dinesh Joshi wrote:
> >
> > +
Just speaking up as a supporter for considering this change. From a
userland perspective, I've been reading up on CRaC, and I see this
attacking some of the same requirements that Graal and Quarkus are trying
to solve. This is a worth direction to pursue.
The CqlSession will need to re-connect, an
+1
On Sun, Mar 9, 2025 at 5:18 AM Mick Semb Wever wrote:
> Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
> and its IP Clearance:
> https://incubator.apache.org/ip-clearance/cassandra-ccm.html
>
> All consent from original authors of the donation, and tracking of
> collecte
+1 (nb)
On 2025/03/09 12:17:34 Mick Semb Wever wrote:
> Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
> and its IP Clearance:
> https://incubator.apache.org/ip-clearance/cassandra-ccm.html
>
> All consent from original authors of the donation, and tracking of
> collected CL
Merging is certainly not blocked on my account. Benedict, I wouldn’t
describe myself as disappointed. It’s awesome work and I’ve tried to
acknowledge the amazing correctness testing that’s been done. I think we
should have a high bar for big changes like this and I was curious about
how we will add
Just something to be mindful about what we had *before* codahale in
Cassandra and avoid that again. Pre 1.1 it was pretty much impossible to
collect metrics without looking at code (there were efficient custom made
things, but each metric was reported differently) and that stuck through
until 2.2 d
> Having something like a registry and standardizing/enforcing all metric types
> is something we should be sure to maintain.
A registry w/documentation on each metric indicating *what it's actually
measuring and what it means* would be great for our users.
On Mon, Mar 10, 2025, at 3:46 PM, Chri
Hi Patrick,
> attacking some of the same requirements that Graal and Quarkus are
trying to solve
thanks for the support! Yes, Graal (and Leyden) are kind of competing
solutions for the startup problem. We're trying to hit the sweet spot
between not requiring significant redesign (as is somet
Hi Abe,
I would expect that if the control connection is terminated, on the next
request it would be re-established including the handshake you mention.
This shouldn't be different from a connection being broken due to
network error. In the POC PR I am calling just `DriverChannel.close()`,
th
19 matches
Mail list logo
