Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

I discussed this offline with Claude, he is no longer working on this. It's a pity. I think this is a very valuable thing. Commitlog's archiving and restore may be able to use the relevant code if it is completed. Patrick McFadin 于2024年9月20日 周五上午2:01写道： > Thanks for reviving this one! > > On Wed

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

No，I think still need some discuss on grammar detail after I finish the first version Patrick McFadin 于2024年9月20日 周五上午2:24写道： > Is this CEP ready for a VOTE thread? > > On Sat, Aug 24, 2024 at 8:56 PM guo Maxwell wrote: > >> Thank you for your replies, I will prepare a CEP later. >> >> Patrick M

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

> I think reserializing the payload into a new format is counter productive to > some of the performance goals of the binary logs? If you have to deserialize > and reserialize the message you are going to be throwing off a ton of extra > GC. That isn’t what happens in FQL =D. FQL creates a cus

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

Wow this is quite a rabbit hole. What is ultimately going to be written into Chronicle Queue is what writeMarshallablePayload method on AbstractLogQuery puts into that WireOut. If we take e.g. QUERY_OPTIONS into consideration, then it writes it into queryOptionsBuffer which is populated in Abstrac

Re: [EXTERNAL] [Discuss] Generic Purpose Rate Limiter in Cassandra

I just want to flag here that this is a topic I have strong opinions on, but the CEP is not really specific or detailed enough to understand precisely how it will be implemented. So, if a patch is already being produced, most of my feedback is likely to be provided some time after a patch appear

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

Well, that looks like item number one to fix when we change the serialisation format. We should clearly not duplicate query strings we have recently logged. We do however appear to also serialise the bind variables, which benefit from being in the format we already have available in memory. > O

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

I am not sure what you mean. I mean, I do, but not following. Look into FullQueryLogger (1) what it goes to put into CQL is a query like String wrapped in a Query object. It literally take a String as a representation of a query a user executed. We just replace this by serializing that query to pro

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

I agree, even if we don’t manage the optimal zero conversion. I am also not entirely convinced we need to worry about compatibility for FQL and other logs - we can just say you must use the version of C* tools you produced the log with - I would even be fine with saying this isn’t even guaranteed t

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

I think reserializing the payload into a new format is counter productive to some of the performance goals of the binary logs?If you have to deserialize and reserialize the message you are going to be throwing off a ton of extra GC.I think we have done a lot of work in recent version to reduce the

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

I think protobuf upon serialization is just a bunch of bytes anyway. If we figure out the header as David showed then we can still serialize it all with the machinery / serializers you mentioned. It can write bytes, right?! I very briefly checked and I think that protobuf is super simple and does n

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

> Do we need any of these things either? We have our own serialisation > framework and file readers and writers, and at least in the FQL case these > are the native serialisation format. > > At cursory glance it also looks to me like this would be a minimal refactor > from the current state. >

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

Sorry, I missed that. I’m not convinced any of these logs need language agnostic tools for access, but if that’s a goal for other folk I don’t feel strongly about it.On 19 Sep 2024, at 21:06, Štefan Miklošovič wrote:More to it, it is actually not only about FQL. Audit logging is on Chronicle queu

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

More to it, it is actually not only about FQL. Audit logging is on Chronicle queues too so inspecting that would be platform independent as well. CEP-12 suggests that there might be a persistent store for diagnostic events as well. If somebody wants to inspect what a node was doing after it went o

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

I think the biggest selling point for using something like protobuf is what David said - what if he wants to replay it in Go? Basing it on something language neutral enables people to replay it in whatever they want. If we have something totally custom then it is replayable just in Java without bri

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

Do we need any of these things either? We have our own serialisation framework and file readers and writers, and at least in the FQL case these are the native serialisation format. At cursory glance it also looks to me like this would be a minimal refactor from the current state.What is the reason

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

well the Maven plugin declares that it downloads protoc from Maven Central automatically _somehow_ so coding up an Ant task which does something similar shouldn't be too hard. I will investigate this idea. On Thu, Sep 19, 2024 at 9:26 PM Brandon Williams wrote: > On Thu, Sep 19, 2024 at 2:16 PM

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

On Thu, Sep 19, 2024 at 2:16 PM Štefan Miklošovič wrote: > Unfortunately there is nothing like that for Ant, protoc would need to be a > local dependency on the computer which compiles the project to be able to do > that so that is kind of a dead end. Or is there any workaround here? In the old

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

Great stuff. Keep it going. If we go to replace this then posts like this are great to gather the feedback. I like the protobuf idea. If we were on Maven then we could use the protobuf plugin which compiles the schema as part of the build and it generates Java classes from it which we might use fo

Re: [VOTE] CEP-42: Constraints Framework

Thanks for the update. My inbox search failed me :D On Thu, Sep 19, 2024 at 11:31 AM Bernardo Botella < conta...@bernardobotella.com> wrote: > Hi Patrick, > > Thanks for taking a look at this and keeping the house tidy. > > I announced the voting results on a sepparate thread: > lists.apache.org

Housekeeping on CEPs

Hi everyone, You might have noticed I just did a pass through the current set of CEPs. First I have to say, there are some great ones in here and love the process we have created. It's a great sign of maturity for the project. As I was going through I noticed some things to remind everyone about.

Re: [VOTE] CEP-42: Constraints Framework

Hi Patrick, Thanks for taking a look at this and keeping the house tidy. I announced the voting results on a sepparate thread: https://lists.apache.org/thread/v73cwc8p80xx7zpkldjq6w1qrkf2k9h0 As a follow up, this is not stalled, and I’m currently working on a patch that will be soon available

Re: [DISCUSS] CEP-39: Cost Based Optimizer

I am personally in favor of the idea and some of the finer details can be worked around I think. In https://issues.apache.org/jira/browse/CASSANDRA-19769 I added a AST for CQL for tests and improving our testing, which led me to file several tickets as it found bugs…. There is a large part of m

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

Is this CEP ready for a VOTE thread? On Sat, Aug 24, 2024 at 8:56 PM guo Maxwell wrote: > Thank you for your replies, I will prepare a CEP later. > > Patrick McFadin 于2024年8月20日周二 02:11写道： > >> +1 This is a CEP >> >> On Mon, Aug 19, 2024 at 10:50 AM Jon Haddad wrote: >> >>> Given the fairly la

Re: [Discuss] Repair inside C*

Not quite; finishing touches on the CEP and design doc are in flight (as of last / this week). Soon(tm). On Thu, Sep 19, 2024, at 2:07 PM, Patrick McFadin wrote: > Is this CEP ready for a VOTE thread? > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-37+%28DRAFT%29+Apache+Cassandra+Un

Re: [VOTE] CEP-42: Constraints Framework

I'm going to cap this thread. Vote passes with no binding -1s. On Tue, Jul 2, 2024 at 2:25 PM Jordan West wrote: > +1 > > On Tue, Jul 2, 2024 at 12:15 Francisco Guerrero > wrote: > >> +1 >> >> On 2024/07/02 18:45:33 Josh McKenzie wrote: >> > +1 >> > >> > On Tue, Jul 2, 2024, at 1:18 PM, Abe Rat

Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

The work has begun but we don't have a VOTE thread for this CEP. Can one get started? On Mon, May 6, 2024 at 9:24 PM Jaydeep Chovatia wrote: > Sure, Caleb. I will include the work as part of CASSANDRA-19534 > in the CEP-41. > > Jaydeep > >

Re: [DISCUSSION] CEP-38: CQL Management API

no. Maxim and I have had some offline discussions. We need to make some changes before we can be ready to vote on it. On Thu, Sep 19, 2024 at 11:09 AM Patrick McFadin wrote: > There is no VOTE thread for this CEP. Is this ready for one? > > On Tue, Jan 9, 2024 at 3:28 AM Maxim Muzafarov wrote:

Re: [DISCUSS] CEP-39: Cost Based Optimizer

Did this get resolved? Is it ready for a VOTE thread? On Tue, Jan 2, 2024 at 1:41 PM Benedict wrote: > The CEP expressly includes an item for coordinated cardinality estimation, > by producing whole cluster summaries. I’m not sure if you addressed this in > your feedback, it’s not clear what you

Re: [DISCUSSION] CEP-38: CQL Management API

There is no VOTE thread for this CEP. Is this ready for one? On Tue, Jan 9, 2024 at 3:28 AM Maxim Muzafarov wrote: > Jon, > > That sounds good. Let's make these commands rely on the settings > virtual table and keep the initial changes as minimal as possible. > > We've also scheduled a Cassandr

Re: [Discuss] Repair inside C*

Is this CEP ready for a VOTE thread? https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-37+%28DRAFT%29+Apache+Cassandra+Unified+Repair+Solution On Sun, Feb 25, 2024 at 12:25 PM Jaydeep Chovatia < chovatia.jayd...@gmail.com> wrote: > Thanks, Josh. I've just updated the CEP >

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

I personally don’t mind switching off Chronicle Queue. I have a transformer function to convert the FQL logs to Thrift (don’t judge) and use easy-cas to reply on a cluster… replying FQL from Chronicle Queue was far slower than Thrift and was hard to push the cluster as the client was the bottle

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

Thanks for reviving this one! On Wed, Sep 18, 2024 at 12:06 AM guo Maxwell wrote: > Is there any update on this topic? It seems that things can make a big > progress if Jake Luciani can find someone who can make the > FileSystemProvider code accessible. > > Jon Haddad 于2023年12月16日周六 05:29写道：

CEP-32: Open-Telemetry integration

Here's another stalled CEP. In this case, no discuss thread or Jira. Yuki (or anyone else) know the status of this CEP? https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-32%3A+%28DRAFT%29+OpenTelemetry+integration Patrick

Re: [DISCUSS] CEP-31 negotiated authentication

This is an area of interest for me personally and is an important feature. Not sure if the original author is going to see it through since we've not had any discussion on it for a while. Is anybody interested in picking this up? Dinesh On Thu, Sep 19, 2024 at 10:54 AM Patrick McFadin wrote: >

Re: [DISCUSS] CEP-31 negotiated authentication

Hi Jacek, I was doing some housekeeping on CEPs and noticed this stalled. Is this still a CEP you are advocating for? Anyone else that knows the status, feel free to add in. Patrick On Wed, May 31, 2023 at 8:26 AM Derek Chen-Becker wrote: > Hi Jacek, > > I took a quick look through the CEP an

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

Agree with Benedict's proposal here. In circumstances when I've needed to capture and work with FQL, I've found it cumbersome to work with Chronicle. The dial-home functionality and release process changes put it over the top for me. – Scott On Sep 19, 2024, at 8:40 AM, Josh McKenzie wrote: th

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

> there is another perfectly sensible option My apologies; I wasn't clear. *If we choose to continue to use chronicle queue*, what I enumerated was the only logical option I saw for us. Altogether I think we should just move away from the library as you've laid out here Benedict. On Thu, Sep 19

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

No, there is another perfectly sensible option: just implement a simple serialisation format ourselves.I am against forking their code; that is a much higher maintenance burden than just writing something simple ourselves. We’ve spent longer collectively discussing and maintaining this dependency t

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

> a jerk move, but they started it with this weird release model I think that's the only option given their release model and lack of backporting bugfixes to the latest ea. Either you run tip of the spear, pay them for bugfixes, or run what's effectively an unsupported LTS in the form of ea. So