Re: [DISCUSS] KIP-1038: Add Custom Error Handler to Producer

uggest RetriableResponse and NonRetriableResponse. > > Thanks, > Andrew > > > On 13 May 2024, at 23:17, Alieh Saeedi > wrote: > > > > Hi all, > > > > > > Thanks for all the valid points you listed. > > > > > > KIP updates and ad

Re: [DISCUSS] KIP-1038: Add Custom Error Handler to Producer

> > > the > > > > > scope > > > > > is tighter. > > > > > > > > > > [AJS1] It would be nice to have default implementations of the > handle > > > > > methods > > > > > so an implementor would not need

Re: [DISCUSS] KIP-1038: Add Custom Error Handler to Producer

ption. > > > > > 3. The user has upgraded their Kafka client. > > > > > > > > > > Now a new kind of error gets dropped on the floor without user's > > > > intention > > > > > and it would be super hard to detect and debug. > &

Re: [DISCUSS] KIP-1038: Add Custom Error Handler to Producer

mentation of the exception handler that allows for some > > simple > > > behavior to be tweaked via configuration property? Two things that > would > > be > > > nice to have would be A) an upper bound on the retry time for > > > unknown-topic-partition

[VOTE] KIP-1038: Add Custom Error Handler to Producer

Hi all, It seems that we have no more comments, discussions, or feedback on KIP-1038; therefore, I’d like to open voting for the KIP: Add Custom Error Handler to Producer Cheers, Alieh

Re: [DISCUSS] KIP-1038: Add Custom Error Handler to Producer

be added to this PR LATER. Looking forward to your feedback again. Cheers, Alieh On Thu, Apr 25, 2024 at 11:46 PM Kirk True wrote: > Hi Alieh, > > Thanks for the updates! > > Comments inline... > > > > On Apr 25, 2024, at 1:10 PM, Alieh Saeedi > wrote: > > &

Re: [DISCUSS] KIP-1038: Add Custom Error Handler to Producer

y adding two new configuration options: > > > > oversized.record.behavior=fail > > retry.on.unknown.topic.or.partition=true > > > > What I’m not yet able to wrap my head around is: what exactly would the > > logic in the handler be? I’m not very imaginative, s

Re: [DISCUSS] KIP-1038: Add Custom Error Handler to Producer

> > 2) Why do we use `producer.` prefix for a *producer* config? Should it > be `exception.handler` only? > > > -Matthias > > On 4/22/24 7:38 AM, Alieh Saeedi wrote: > > Thank you all for the feedback! > > > > Addressing the main concern: The KIP is about givi

Re: [DISCUSS] KIP-1038: Add Custom Error Handler to Producer

2024 at 8:03 AM Omnia Ibrahim > > >>> wrote: > >>> > >>>> Hi Alieh, > >>>> Thanks for the KIP! I have couple of comments > >>>> - You mentioned in the KIP motivation, > >>>>> Another example for which a productio

[DISCUSS] KIP-1038: Add Custom Error Handler to Producer

Hi all, Here is the KIP-1038: Add Custom Error Handler to Producer. I look forward to your feedback! Cheers, Alieh

[VOTE] KIP-969: Support range interactive queries (IQv2) for versioned state stores

Hi everyone, Thanks to everyone who has reviewed KIP-969, and participated in the discussion thread! I'd also like to thank you in advance for taking the time to vote. Cheers, Alieh

Re: [DISCUSS] KIP-969: Support range interactive queries for versioned state stores

gt; sort, so we should only provide the ordering guarantee we can provide > efficiently, and we shouldn't restrict our future evolution too much > by this. I think a global ordering by timestamp is sufficient for this > KIP, so I vote for option 2. > > Cheers, > Lucas > > On F

Re: [DISCUSS] KIP-997 Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify WindowKeyQuery and WindowRangeQuery

Thanks, Hanyu, for the KIP and all the updates. I just do not understand the purpose of defining new time ranges (`newTimeFrom`, `newTimeTo`). Why don't we simply re-use the existing time range variables? Bests, Alieh On Thu, Nov 30, 2023 at 8:34 PM Hanyu (Peter) Zheng wrote: > new KIP link: >

Re: [DISCUSS] KIP-969: Support range interactive queries for versioned state stores

t; > >> > >> MultiVersionedRangeQuery.withLowerKeyBound(k1).fromTime(t1).latest().toTime(t2) >> > >> > Is it [t1, t2] or [-INF, t2]? >> > (I would say the latter, but somebody else would say differently) >> > >> > The two class solution

Re: [VOTE] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

g) > > > > Lucas > > > > On Tue, Nov 21, 2023 at 11:26 AM Alieh Saeedi > > wrote: > >> > >> Thanks, Matthias; I changed it to `ANY` which is the shortest and not > >> misleading. > >> > >> Cheers, > >> Alieh > >

Re: [DISCUSS] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

escending() since the results could also be unordered now > > that we agreed that the results are unordered by default. If both -- > > isDescending() and isAscending -- are false neither > > withDescendingTimestamps() nor withAscendingTimestamps() was called. > > > > Best

Re: [VOTE] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

> We could also use `UNDEFINED` / `UNSPECIFIED` / `NONE` / `ANY` ? > > In the end, the result _might_ be ordered, we just don't guarantee any > order. > > > -Matthias > > On 11/20/23 9:17 AM, Alieh Saeedi wrote: > > Hi all, > > I added the public enum `Resu

Re: [VOTE] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

, Alieh On Mon, Nov 20, 2023 at 1:40 PM Alieh Saeedi wrote: > Thank you, Guozhag and Bruno, for reviewing the KIP and reading the whole > discussion thread. I appreciate your help:) > The KIP is now corrected and updated. > > Cheers, > Alieh > > On Mon, Nov 20, 2023 a

Re: [VOTE] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

e global and partial ordering are > > modifiable with the corresponding methods defined for the class." > > > > Since this KIP is only for a single key, there's no key ordering but > > only timestamp ordering right? Maybe the javadoc can be updated > > a

[VOTE] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

Hi all, Following my recent message in the discussion thread, I am opening the voting for KIP-968. Thanks for your votes in advance. Cheers, Alieh

Re: [DISCUSS] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

>>>>> get(key, > >>>>> asOf) to set the correct validTo. > >>>>> > >>>>> > >>>>> 60) > >>>>> I am in favor of renaming ValueIterator to VersionedRecordIterator > and > >>>>>

Re: [DISCUSS] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

> >>>> last e-mail, didn't you? Just double-checking if I understood what you > >>>> are proposing.) > >>>> > >>>> > >>>> 70) > >>>> I agree with Matthias that adding a new method on the > >>>> Ver

Re: [DISCUSS] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

econds? Sure we could agree on one, but I think it is > more elegant to just make the validTo exclusive. Actually, you used it > as exclusive in your examples. > > > Thanks for the KIP! > > Best, > Bruno > > On 11/1/23 9:01 PM, Alieh Saeedi wrote: > > Hi all, &g

Re: [DISCUSS] KIP-969: Support range interactive queries for versioned state stores

4. > > Why do we need orderByKey() and orderByTimestamp()? > > Aren't withAscendingKeys(), withDescendingKeys(), > > withAscendingTimestamps(), and withDescendingTimestamps() sufficient? > > > > > > 5. > > In example 2, why is > > > > key,value: 2,

Re: [DISCUSS] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

, Alieh On Tue, Oct 24, 2023 at 10:01 PM Alieh Saeedi wrote: > Thank you, Matthias, Bruno, and Guozhang for keeping the discussion going. > > Here is the list of changes I made: > >1. I enriched the "Example" section as Bruno suggested. Do you please >have a loo

Re: [DISCUSS] KIP-969: Support range interactive queries for versioned state stores

his query type, with "key range > over latest" semantics. -- The issue is of course, that uses need to > know that the query would return `ValueAndTimestamp` and not plain `V` > (or we add a translation step to unwrap the value, but we would lose the > "validFrom

Re: [DISCUSS] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

updates, Alieh! > > > > > > The example in the KIP uses the allVersions() method which we agreed to > > > remove. > > > > > > Regarding your questions: > > > 1. asOf vs. until: I am fine with both but slightly prefer until. > > > 2. W

Re: [DISCUSS] KIP-992 Proposal to introduce IQv2 Query Types: TimestampedKeyQuery and TimestampedRangeQuery

Hey Hanyu, Thanks for the KIP. It seems good to me. Just one point: AFAIK, we are going to remove "get" from the name of all getter methods. Cheers, Alieh On Thu, Oct 19, 2023 at 5:44 PM Hanyu (Peter) Zheng wrote: > Hello everyone, > > I would like to start the discussion for KIP-992:

Re: [DISCUSS] KIP-985 Add reverseRange and reverseAll query over kv-store in IQv2

Hi, just pointing to javadocs for range() and reverseRange(): range(): *@return The iterator for this range, from smallest to largest bytes.* reverseRange(): * @return The reverse iterator for this range, from largest to smallest key bytes. Cheers, Alieh On Thu, Oct 12, 2023 at 7:32 AM

Re: [VOTE] KIP-960: Support single-key_single-timestamp interactive queries (IQv2) for versioned state stores

> > > > > > So it should be `K key()` and `Optional asOfTimestamp()`. > > > > > > > > > > > > Otherwise the KIP LGTM. > > > > > > > > > > > > +1 (binding) > > > > > > > > > > > > -Matthia

Re: [DISCUSS] KIP-969: Support range interactive queries for versioned state stores

ough, range queries always return > > iterators, it would make sense to also separate range queries for > > versioned state stores into range queries that return one single version > > of the keys within a range and range queries that return multiple > > version of the keys within

Re: [DISCUSS] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

specifying a range return the latest version? I would > >>>>>>> expect that it returns all versions since an empty lower or upper > >>>>>>> limit is interpreted as no limit. > >>>>>>> > >>>>>>> 3. > >>>&

[VOTE] KIP-960: Support single-key_single-timestamp interactive queries (IQv2) for versioned state stores

Hi everyone, Since KIP-960 is reduced to the simplest IQ type and all further comments are related to the following-up KIPs, I decided to finalize it at this point. A huge thank you to everyone who has reviewed this KIP (and also the following-up ones), and participated in the discussion

Re: [DISCUSS] KIP-960: Support interactive queries (IQv2) for versioned state stores

w interactive query types will throw NPEs for custom store > implementations which do not support the new methods. > Best,VictoriaOn Thursday, August 17, 2023 at 07:25:22 AM EDT, Alieh > Saeedi wrote: > > Hey Matthias, > thanks for the feedback > > I think if one mate

Re: [DISCUSS] KIP-960: Support interactive queries (IQv2) for versioned state stores

ways have a hard time to reason about generics, > so maybe trying out both approaches might shed some light? > > > > > -Matthias > > > On 8/15/23 9:03 AM, Alieh Saeedi wrote: > > Hi all, > > thanks to all for the great points you mentioned. > > > &

[DISCUSS] KIP-969: Support range interactive queries for versioned state stores

Hi all, I splitted KIP-960 into three separate KIPs. Therefore, please continue discussions about range interactive queries here. You can

[DISCUSS] KIP-968: Support single-key_multi-timestamp interactive queries (IQv2) for versioned state stores

Hi all, I splitted KIP-960 into three separate KIPs. Therefore, please continue discussions about single-key, multi-timestamp interactive

[jira] [Created] (KAFKA-15348) Range IQs with versioned state stores

Alieh Saeedi created KAFKA-15348: Summary: Range IQs with versioned state stores Key: KAFKA-15348 URL: https://issues.apache.org/jira/browse/KAFKA-15348 Project: Kafka Issue Type: Sub-task

[jira] [Created] (KAFKA-15347) Single-Key_multi-timestamp IQs with versioned state stores

Alieh Saeedi created KAFKA-15347: Summary: Single-Key_multi-timestamp IQs with versioned state stores Key: KAFKA-15347 URL: https://issues.apache.org/jira/browse/KAFKA-15347 Project: Kafka

[jira] [Created] (KAFKA-15346) Single-Key_single-multi-timestamp IQs with versioned state stores

Alieh Saeedi created KAFKA-15346: Summary: Single-Key_single-multi-timestamp IQs with versioned state stores Key: KAFKA-15346 URL: https://issues.apache.org/jira/browse/KAFKA-15346 Project: Kafka

Re: [DISCUSS] KIP-960: Support interactive queries (IQv2) for versioned state stores

>> from the current proposal, but I'll leave it here anyways for you to > >>> consider it (even if you decide to stick with the current model). > >>> > >>> 4. Please make sure to specify in every range-based method whether the > >>> bounds are

Re: [DISCUSS] KIP-960: Support interactive queries (IQv2) for versioned state stores

lid range overlaps the search time-range, > > or must it be fully included? Or would we only say, that the `validFrom` > > timestamp that is stored must be in the search range (what implies that > > the lower end would be a non-overlapping but "fully included"

Re: [DISCUSS] KIP-960: Support interactive queries (IQv2) for versioned state stores

d, > while the upper end would be a overlapping bound). > > For key-range / time-range queries: do we return the result in `` > order or `` order? Also, what about reverse iterators? > > About ` ValueIterator` -- think the JavaDocs have c error in it for > `peekNextRecord` (also, s

[DISCUSS] KIP-960: Support interactive queries (IQv2) for versioned state stores

Hi all, I would like to propose a KIP to support IQv2 for versioned state stores. https://cwiki.apache.org/confluence/display/KAFKA/KIP-960%3A+Support+interactive+queries+%28IQv2%29+for+versioned+state+stores Looking forward to your feedback! Cheers, Alieh

[jira] [Created] (KAFKA-15257) Support interactive queries (IQv2) with versioned state store

Alieh Saeedi created KAFKA-15257: Summary: Support interactive queries (IQv2) with versioned state store Key: KAFKA-15257 URL: https://issues.apache.org/jira/browse/KAFKA-15257 Project: Kafka