[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

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

cluded" bound, > 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&p error in it for &

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

record if it's valid 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 &qu

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

to define `skipCache` in `KeyQuery`. I guess that diverges quite a bit > >>> 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

[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 que

[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 see

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

I always 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. > > &

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

), > otherwise your new 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 > >

[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 thread!

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

>>>>>> 2. > >>>>>>> Why does not 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. > >

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

rs. Although, 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

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-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 Matthias

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: Proposal

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

s for the 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. > > >

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

t accept this 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 > "

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

Bests, 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

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 > > > > ke

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

seconds? Seconds? 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: > >

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

dTimestamp with VersionedRecord in your > >>>> last e-mail, didn't you? Just double-checking if I understood what you > >>>> are proposing.) > >>>> > >>>> > >>>> 70) > >>>> I agree with Matthias that adding a n

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

That implies that I am in favor of modifying > >>>>> get(key, > >>>>> asOf) to set the correct validTo. > >>>>> > >>>>> > >>>>> 60) > >>>>> I am in favor of renaming ValueIterator to Versioned

[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: [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 > > acc

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

> 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

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

d isDescending() 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. > > > >

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-1038: Add Custom Error Handler to Producer

ption will 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: &

[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

nect and MirrorMaker 2. Can we > add > > a > > > default implementation 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

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

ion. For simpicity they just return > > > SWALLOW > > > > > from the function, because it elegantly handles all known cases. > > > > > 2. The interface has evolved to support a new exception. > > > > > 3. The user has upgraded their Kafka client.

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

ng much less risky > > now > > > > the > > > > > scope > > > > > is tighter. > > > > > > > > > > [AJS1] It would be nice to have default implementations of the > handle > > > > > methods > > &g

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

suggest 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

[DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Hi all, I'd like to kick off a discussion for KIP-1059 that suggests adding a new feature to the Producer flush() method. https://cwiki.apache.org/confluence/display/KAFKA/KIP-1059%3A+Enable+the+Producer+flush%28%29+method+to+clear+the+latest+send%28%29+error Cheers, Alieh

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

t; wrote: > >>>>>>> > >>>>>>>> Thanks for the KIP Alieh. I actually like the KIP as-is, but think > >>>>>>>> Arthem raises very good points... > >>>>>>>> > >>>>>>>> Se

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

the original buggy behavior because the bug was that we > >>>> ignored > >>>>> errors that happened in the "send()" method itself, not necessarily > the > >>>>> ones that we got from the broker. > >>>> > >>&

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

> > > > >> wrote: > > > > >>>>> > > > > >>>>> Hi Andrew, > > > > >>>>> > > > > >>>>> I like a lot of what you said, but I still believe it's better > to > > > > >&

[VOTE] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Hi all, I would like to open voting for KIP-1059: Enable the Producer flush() method to clear the latest send() error . Cheers, Alieh

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

type > Map >> ?> commitOptions. Would we want to define something more specific? > >> I was also curious about this text: > >>> The new method clears the latest error produced by > `send(ProducerRecord)` > >> and transits the transaction back from the erro

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Hi all, Looking at the PR corresponding to the KIP, there are some points worthy of mention: 1) clearing the error ends up dirty/messy code in `TransactionManager`. 2) By clearing the error, we are actually doing an illegal transition from `ABORTABL

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

d still > has the CommitOption as well. > > Thanks, > Justine > > On Wed, Jun 26, 2024 at 2:15 PM Alieh Saeedi > > wrote: > > > Hi all, > > > > > > Looking at the PR <https://github.com/apache/kafka/pull/16332> > > corresponding to the KIP, th

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

my mind, I'm wondering if there is a way we can > validate the "posion pill" records application side before we even try to > send them) > > Justine > > On Wed, Jun 26, 2024 at 4:38 PM Alieh Saeedi > > wrote: > > > Hi Justine, > > > >

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

a way we can > validate the "posion pill" records application side before we even try to > send them) > > Justine > > On Wed, Jun 26, 2024 at 4:38 PM Alieh Saeedi > > wrote: > > > Hi Justine, > > > > I did not update the KIP with `TxnSendOpti

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

` interface, I am not sure how this was done in the > >> past (eg, KIP-266 added `Consumer.poll(Duration)` w/o a default > >> implementation), if we need a default implementation for backward > >> compatibility or not? If we do want to add one, I think it would be > >&

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

-9279 > > <https://issues.apache.org/jira/browse/KAFKA-9279> but under specific > > circumstances that are controlled. I really am concerned about opening > new > > avenues for bugs with EOS and hesitate to handle any other types of > errors. > > I think if we all

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

> UnknownTopicOrPartitionError in another way. As for the other checks, acls, > validation etc. I am not aware of that being in Alieh's scope, but we > should be clear about exactly what we are doing. > > All errors that fall into ApiException seems too broad to me. > >

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

rors to make sure they make sense. > I just want to feel confident that we aren't just making a decision without > considering the consequences carefully. > > Justine > > On Tue, Jul 2, 2024 at 12:30 PM Alieh Saeedi > > wrote: > > > Hey Justine, > > > &g

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

tedVersionException, > > > and possibly others. > > > > > > @Justine -- do you think it would be possible to develop either a > better > > > definition for the kinds of "excluded" errors that should not be > covered > > by > > > thi

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

ions > > Finally, I'd also like to ask the people who have already voted (Andrew, > Matthias) if, at the time they voted, they believed that the API would > handle all errors, or only the subset of errors that would cause a record > to be rejected from a batch before it c

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

ing noise to the API (with the new overloaded variant of send) > for a > > > > feature that will likely bring confusion and even frustration to > anyone > > > > besides maintainers of Kafka Streams who tries to use it. > > > > > > > > If the only co

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

just wanted to make the point that we shouldn't > necessarily > > >>>>>>> dismiss > > >>>>>>> API changes that allow for optimizations. > > >>>>>>> > > >>>>>>> -Artem >

Re: [DISCUSS] KIP-1065: Add "retry" return-option to ProductionExceptionHandler

Hi all, Thanks for the KIP, Matthias. Yes, adding the `RETRY` option to `ProductionExceptionhandler` enables us to have a further fix in order to make KAFKA-16508 backward compatible. @Sophie: Regarding other built-in handlers: Do you mean 1) adding `RETRY` to `DeserializationExceptionHandler` i

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

ret >> > >> > >> 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 clas

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

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 > >

[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

[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

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

>> > >>> > >>> > >>> On Wed, Apr 17, 2024 at 8:03 AM Omnia Ibrahim > > >>> wrote: > >>> > >>>> Hi Alieh, > >>>> Thanks for the KIP! I have couple of comments > >>>> - You mentioned i

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

be solved by 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

Re: [DISCUSS] KIP-1088: Replace KafkaClientSupplier with KafkaClientInterceptor

Thanks Matthias for the KIP. A quick question regarding the sentence `It would be invalid to create a new client instance `: What would happen if the implemented class creates a new instance, or, in other words, how do we prevent it? Considering that `Config` is going to be passed in as well (the

Re: [VOTE] KIP-1094 Add a new constructor method with nextOffsets to ConsumerRecords

e: [VOTE] KIP-1094 Add a new constructor method with > nextOffsets to ConsumerRecords > > > > +1 (binding) > > > > Thanks for the KIP! > > Lucas > > > > On Fri, Oct 4, 2024 at 2:29 AM Matthias J. Sax wrote: > >> > >> +1 (binding) > >>

[VOTE] KIP-1094 Add a new constructor method with nextOffsets to ConsumerRecords

Hi all I would like to call a vote for KIP-1094. Please take a moment to review the proposal and submit your vote. KIP: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1094%3A+Add+a+new+constructor+method+with+nextOffsets+to+ConsumerRecords Thanks, Alieh

Re: [DISCUSS] KIP-1094 Add a new constructor method with nextOffsets to ConsumerRecords

e. Thanks, Alieh On Tue, Oct 1, 2024 at 1:40 PM Alieh Saeedi wrote: > Thanks, Sophie and Kirk. > > You raised good points, Kirk. > Regarding your first question: KAFKA-17622 > <https://issues.apache.org/jira/browse/KAFKA-17622> (one of the linked > jira tickets) p

Re: [DISCUSS] KIP-1094 Add a new constructor method with nextOffsets to ConsumerRecords

d be something along the lines > of > > "The `nextOffsets` method returns a map of `TopicPartition` to > > `OffsetAndMetadata` objects and `OffsetAndMetadata` contains the next > > offset and the last leader epoch per partition" > > > > Other than that, t

Re: [DISCUSS] KIP-1094 Add a new constructor method with nextOffsets to ConsumerRecords

Bejeck > wrote: > > >> > > >>> Hi Alieh, > > >>> > > >>> Thanks for the KIP, it will be very useful to Kafka Streams. > > >>> I have one comment. In the "Proposed Changes" section, you mention > the > > >>

Re: [DISCUSS] KIP-1094 Add a new constructor method with nextOffsets to ConsumerRecords

wise we can maybe move to a vote? > > > On Mon, Sep 30, 2024 at 5:11 AM Alieh Saeedi > > wrote: > > > Hi all, > > > > thanks for the feedbacks. > > Since there is consensus in deprecating the current constructor, we can > > deprecate it for n

[DISCUSS] KIP-1094 Add a new constructor method with nextOffsets to ConsumerRecords

Hi all, I would like to open a discussion for KIP-1094: Add a new constructor method with `nextOffsets` to `ConsumerRecords`. You can find the detailed proposal here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1094%3A+Add+a+new+constructor+method+with+nextOffsets+to+ConsumerRecords I

Re: [VOTE]: KIP-1071: Streams Rebalance Protocol

Thanks for the effort. I really appreciate the time and dedication you put into this. +1(non-binding) Cheers, Alieh On Wed, Nov 27, 2024 at 11:31 AM Bruno Cadonna wrote: > Hi all, > > We (Lucas and myself) would like to call for a vote on KIP-1071: Streams > Rebalance Protocol: https://cwiki.a

[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

[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

[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-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-16965) Add a "root cause" exception as a nested exception to TimeoutException for Producer

Alieh Saeedi created KAFKA-16965: Summary: Add a "root cause" exception as a nested exception to TimeoutException for Producer Key: KAFKA-16965 URL: https://issues.apache.org/jira/browse/K

[jira] [Resolved] (KAFKA-16248) Kafka consumer should cache leader offset ranges

[ https://issues.apache.org/jira/browse/KAFKA-16248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alieh Saeedi resolved KAFKA-16248. -- Resolution: Fixed > Kafka consumer should cache leader offset ran

[jira] [Resolved] (KAFKA-17622) Kafka Streams Timeout During Partition Rebalance

[ https://issues.apache.org/jira/browse/KAFKA-17622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alieh Saeedi resolved KAFKA-17622. -- Resolution: Fixed > Kafka Streams Timeout During Partition Rebala

[jira] [Created] (KAFKA-17600) Add nextOffsets to the ConsumerRecords

Alieh Saeedi created KAFKA-17600: Summary: Add nextOffsets to the ConsumerRecords Key: KAFKA-17600 URL: https://issues.apache.org/jira/browse/KAFKA-17600 Project: Kafka Issue Type

[jira] [Created] (KAFKA-17622) Kafka Streams Timeout During Partition Rebalance - Seeking Insights on NotLeaderOrFollowerException

Alieh Saeedi created KAFKA-17622: Summary: Kafka Streams Timeout During Partition Rebalance - Seeking Insights on NotLeaderOrFollowerException Key: KAFKA-17622 URL: https://issues.apache.org/jira/browse/KAFKA

[jira] [Created] (KAFKA-18126) Refactoring to split the GroupMetadataManager in AK

Alieh Saeedi created KAFKA-18126: Summary: Refactoring to split the GroupMetadataManager in AK Key: KAFKA-18126 URL: https://issues.apache.org/jira/browse/KAFKA-18126 Project: Kafka Issue

[jira] [Created] (KAFKA-18887) Implement Admin API extensions beyond list/describe group (delete group, offset-related APIs)

Alieh Saeedi created KAFKA-18887: Summary: Implement Admin API extensions beyond list/describe group (delete group, offset-related APIs) Key: KAFKA-18887 URL: https://issues.apache.org/jira/browse/KAFKA-18887

[jira] [Created] (KAFKA-18971) Update AK system tests for AK 4.0

Alieh Saeedi created KAFKA-18971: Summary: Update AK system tests for AK 4.0 Key: KAFKA-18971 URL: https://issues.apache.org/jira/browse/KAFKA-18971 Project: Kafka Issue Type: Task