[jira] [Created] (KAFKA-16925) stream-table join does not immediately forward expired records on restart

Ayoub Omari created KAFKA-16925: --- Summary: stream-table join does not immediately forward expired records on restart Key: KAFKA-16925 URL: https://issues.apache.org/jira/browse/KAFKA-16925 Project

[jira] [Created] (KAFKA-16808) Consumer join Group requests response contains 2 different members

Badhusha Muhammed created KAFKA-16808: - Summary: Consumer join Group requests response contains 2 different members Key: KAFKA-16808 URL: https://issues.apache.org/jira/browse/KAFKA-16808 Project

[jira] [Created] (KAFKA-16700) Kafka Streams: possible message loss on KTable-KTable FK Left Join

Karsten Stöckmann created KAFKA-16700: - Summary: Kafka Streams: possible message loss on KTable-KTable FK Left Join Key: KAFKA-16700 URL: https://issues.apache.org/jira/browse/KAFKA-16700 Project

[jira] [Resolved] (KAFKA-16644) FK join emits duplicate tombstone on left-side delete

[ https://issues.apache.org/jira/browse/KAFKA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax resolved KAFKA-16644. - Resolution: Duplicate > FK join emits duplicate tombstone on left-side del

[jira] [Created] (KAFKA-16644) FK join emit duplicate tombstone on left-side delete

Matthias J. Sax created KAFKA-16644: --- Summary: FK join emit duplicate tombstone on left-side delete Key: KAFKA-16644 URL: https://issues.apache.org/jira/browse/KAFKA-16644 Project: Kafka

[jira] [Created] (KAFKA-16434) ForeignKey INNER join does not unset join result when FK becomes null

Ayoub Omari created KAFKA-16434: --- Summary: ForeignKey INNER join does not unset join result when FK becomes null Key: KAFKA-16434 URL: https://issues.apache.org/jira/browse/KAFKA-16434 Project: Kafka

Re: Request to join

Hi, Please send an email to dev-subscr...@kafka.apache.org to subscribe to the group. Thanks. Luke On Mon, Mar 25, 2024 at 4:19 PM durairaj t wrote: > >

Request to join

[jira] [Created] (KAFKA-16407) ForeignKey INNER join ignores FK change when its previous value is null

Ayoub Omari created KAFKA-16407: --- Summary: ForeignKey INNER join ignores FK change when its previous value is null Key: KAFKA-16407 URL: https://issues.apache.org/jira/browse/KAFKA-16407 Project: Kafka

[jira] [Created] (KAFKA-16394) ForeignKey LEFT join propagates null value on foreignKey change

Ayoub Omari created KAFKA-16394: --- Summary: ForeignKey LEFT join propagates null value on foreignKey change Key: KAFKA-16394 URL: https://issues.apache.org/jira/browse/KAFKA-16394 Project: Kafka

Re: [DISCUSS] KIP-955: Add stream-table join on foreign key

Igor, I did drop the ball on this discussion. Sorry about this. Too many things are happening at the same time. Also I do not think that emitting multiple records from the stream-table FK join is a 'weird' behaviour because this is exactly how the standard SQL behaves and many stream

[jira] [Resolved] (KAFKA-14747) FK join should record discarded subscription responses

[ https://issues.apache.org/jira/browse/KAFKA-14747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax resolved KAFKA-14747. - Fix Version/s: 3.8.0 Resolution: Fixed > FK join should record discar

[jira] [Created] (KAFKA-16333) Removed Deprecated methods KTable#join

Matthias J. Sax created KAFKA-16333: --- Summary: Removed Deprecated methods KTable#join Key: KAFKA-16333 URL: https://issues.apache.org/jira/browse/KAFKA-16333 Project: Kafka Issue Type: Sub

[jira] [Created] (KAFKA-16332) Remove Deprecated builder methods for Time/Session/Join/SlidingWindows

Matthias J. Sax created KAFKA-16332: --- Summary: Remove Deprecated builder methods for Time/Session/Join/SlidingWindows Key: KAFKA-16332 URL: https://issues.apache.org/jira/browse/KAFKA-16332 Project

Re: Join request

To subscribe, please follow instructions from the webpage https://kafka.apache.org/contact -Matthias On 2/23/24 1:15 AM, kashi mori wrote: Hi, please add my email to the mailin list

Join request

Hi, please add my email to the mailin list

[jira] [Resolved] (KAFKA-14049) Relax Non Null Requirement for KStreamGlobalKTable Left Join

[ https://issues.apache.org/jira/browse/KAFKA-14049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Akermann resolved KAFKA-14049. - Resolution: Fixed > Relax Non Null Requirement for KStreamGlobalKTable Left J

[jira] [Created] (KAFKA-16123) KStreamKStreamJoinProcessor forwards null records for left/outer joins unconditionally of the join window.

Florin Akermann created KAFKA-16123: --- Summary: KStreamKStreamJoinProcessor forwards null records for left/outer joins unconditionally of the join window. Key: KAFKA-16123 URL: https://issues.apache.org/jira

[jira] [Resolved] (KAFKA-14748) Relax non-null FK left-join requirement

[ https://issues.apache.org/jira/browse/KAFKA-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Akermann resolved KAFKA-14748. - Resolution: Fixed > Relax non-null FK left-join requirem

[jira] [Created] (KAFKA-15592) Member does not need to always try to join a group when a groupId is configured

Philip Nee created KAFKA-15592: -- Summary: Member does not need to always try to join a group when a groupId is configured Key: KAFKA-15592 URL: https://issues.apache.org/jira/browse/KAFKA-15592 Project

[jira] [Resolved] (KAFKA-14936) Add Grace Period To Stream Table Join

[ https://issues.apache.org/jira/browse/KAFKA-14936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Walker Carlson resolved KAFKA-14936. Resolution: Done > Add Grace Period To Stream Table J

[jira] [Created] (KAFKA-15337) Disable *-subscription-store-changelog topic creation for foreign key join in Kafka Streams

Rohan created KAFKA-15337: - Summary: Disable *-subscription-store-changelog topic creation for foreign key join in Kafka Streams Key: KAFKA-15337 URL: https://issues.apache.org/jira/browse/KAFKA-15337

[jira] [Resolved] (KAFKA-13197) KStream-GlobalKTable join semantics don't match documentation

eam-GlobalKTable join semantics don't match documentation > - > > Key: KAFKA-13197 > URL: https://issues.apache.org/jira/browse/KAFKA-13197 > Project: Kafka > Issue Type: Bug

Re: [DISCUSS] KIP-955: Add stream-table join on foreign key

Matthias, I think that I clouded this discussion a bit with the possible 'fat' message requirement for the one specific use case that I worked on. Therefore I would like to take a step back and to focus just on the actual KIP-955 that only proposes to create a stream-table join on foreign key

Re: [DISCUSS] KIP-955: Add stream-table join on foreign key

Thanks. Seems we are on the same page now what the requirement are? That's good progress! This solution was considered when in KIP-213 for the existing table-table FK join. There is a discussion on disadvantages of using this approach in the article related to KIP-213 and I think the same

Re: [DISCUSS] KIP-955: Add stream-table join on foreign key

to demonstrate that even in tht simple case the existing table-table join on FK will not work. However the use case I have in general may have 1:1, 1:0, or 1:n relations. One complex business entity I had to deal with called "transportation waybill" that has 25 child tables. Number of chi

Re: [DISCUSS] KIP-955: Add stream-table join on foreign key

:1 If I understand correctly, you want to join on orderId. If the join is 1:1, it means that there is only a single table-record for each unique orderId. Thus, orderId could be the PK of the table. If that's correct, you could use orderId as the key of "orderItems" and do a regular

Re: [DISCUSS] KIP-955: Add stream-table join on foreign key

Hi Matthias, Hi Matthias, Thanks for your comments. I would like to clarify the use case a little more to show why existing table-table foreign key join will not work for the use case I am trying to address. Let’s consider the very simple use case with the parent messages in one Kafka

Re: [DISCUSS] KIP-955: Add stream-table join on foreign key

Thanks a lot for providing more background. It's getting much clear to me now. Couple of follow up questions: It is not possible to use table-table join in this case because triggering events are supplied separately from the actual data entity that needs to be "assembled" and th

[jira] [Created] (KAFKA-15303) Foreign key joins no longer triggered by events on the right side of the join after deployment with a new compatible Avro schema

Charles-Eddy created KAFKA-15303: Summary: Foreign key joins no longer triggered by events on the right side of the join after deployment with a new compatible Avro schema Key: KAFKA-15303 URL: https

[VOTE] KIP-955: Add stream-table join on foreign key

Hi All, I would like to call a Vote on KIP-955: Add stream-table join on foreign key. KIP link is here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-955%3A+Add+stream-table+join+on+foreign+key Mostly I would like to get consensus on the need for this new API to Kafka Streams. The actual

[jira] [Created] (KAFKA-15299) Support left stream-table join on foreign key

Igor Fomenko created KAFKA-15299: Summary: Support left stream-table join on foreign key Key: KAFKA-15299 URL: https://issues.apache.org/jira/browse/KAFKA-15299 Project: Kafka Issue Type

Re: [DISCUSS] KIP-955: Add stream-table join on foreign key

that needs to be joined with the order table to have the full data entity (for example multiple line items of the purchase order needs to be added from the line items child table). It is not possible to use table-table join in this case because triggering events are supplied separately from the actual d

Re: [DISCUSS] KIP-955: Add stream-table join on foreign key

Igor, thanks for the KIP. Interesting proposal. I am wondering a little bit about the use-case and semantics, and if it's really required to add what you propose? Please correct me if I am wrong. In the end, a stream-table join is a "stream enrichment" (via a table lookup).

[DISCUSS] KIP-955: Add stream-table join on foreign key

Hello developers of the Kafka Streams, I would like to start discussion on KIP-955: Add stream-table join on foreign key <https://cwiki.apache.org/confluence/display/KAFKA/KIP-955%3A+Add+stream-table+join+on+foreign+key> This KIP proposes the new API to join KStrem with KTable based on f

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

guish between records with the same key and same timestamp. > > > > > > Just an idea! Maybe Walker comes up with something better. > > > > > > Best, > > > Bruno > > > > > > On 05.06.23 20:38, Victoria Xia wrote: > > >> Hi Walker, > >

Re: [VOTE] KIP-923: Add A Grace Period to Stream Table Join

Hi all, This vote thread has been open over 72 hours, and has sufficient votes so I'll close the voting at this time. +4 binding votes +2 non-binding votes KIP-923 has PASSED. Thanks all for your votes Walker On Tue, Jun 6, 2023 at 8:13 AM John Roesler wrote: > Thanks for the KIP, Walker! >

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

and same timestamp. > > > > Just an idea! Maybe Walker comes up with something better. > > > > Best, > > Bruno > > > > On 05.06.23 20:38, Victoria Xia wrote: > >> Hi Walker, > >> > >> Thanks for the latest updates! The KIP l

Re: [VOTE] KIP-923: Add A Grace Period to Stream Table Join

Thanks for the KIP, Walker! I’m +1 (binding) Thanks, John On Mon, Jun 5, 2023, at 13:39, Victoria Xia wrote: > Hi Walker, > > Thanks for the KIP! Left a clarification question on the discussion thread > just now but it's about an implementation detail, so I don't think it > changes anything in

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

Walker comes up with something better. Best, Bruno On 05.06.23 20:38, Victoria Xia wrote: Hi Walker, Thanks for the latest updates! The KIP looks great. Just one question about the changelog topic for the join buffer: The KIP says "When a failure occurs the buffer will try to recover

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

timestamp. Just an idea! Maybe Walker comes up with something better. Best, Bruno On 05.06.23 20:38, Victoria Xia wrote: Hi Walker, Thanks for the latest updates! The KIP looks great. Just one question about the changelog topic for the join buffer: The KIP says "When a failure occurs the b

Re: [VOTE] KIP-923: Add A Grace Period to Stream Table Join

Hi Walker, Thanks for the KIP! Left a clarification question on the discussion thread just now but it's about an implementation detail, so I don't think it changes anything in this vote thread. +1 (non-binding) Cheers, Victoria On Mon, Jun 5, 2023 at 10:23 AM Bill Bejeck wrote: > Hi Walker,

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

Hi Walker, Thanks for the latest updates! The KIP looks great. Just one question about the changelog topic for the join buffer: The KIP says "When a failure occurs the buffer will try to recover from an OffsetCheckpoint if possible. If not it will reload the buffer from a compacted chang

Re: [VOTE] KIP-923: Add A Grace Period to Stream Table Join

Hi Walker, Thanks for the KIP. I've caught up on the discussion thread and I'm satisfied with all responses. +1(binding) -Bill On Mon, Jun 5, 2023 at 10:20 AM Bruno Cadonna wrote: > Hi Walker, > > Thank you for the KIP! > > +1 (binding) > > Best, > Bruno > > On 24.05.23 23:00, Walker

Re: [VOTE] KIP-923: Add A Grace Period to Stream Table Join

Hi Walker, +1 (non-binding) Cheers, Lucas On Mon, Jun 5, 2023 at 4:20 PM Bruno Cadonna wrote: > > Hi Walker, > > Thank you for the KIP! > > +1 (binding) > > Best, > Bruno > > On 24.05.23 23:00, Walker Carlson wrote: > > Hello everybody, > > > > I'm opening the vote on KIP-923 here > >

Re: [VOTE] KIP-923: Add A Grace Period to Stream Table Join

Hi Walker, Thank you for the KIP! +1 (binding) Best, Bruno On 24.05.23 23:00, Walker Carlson wrote: Hello everybody, I'm opening the vote on KIP-923 here . If we have more to discus please continue the discussion on the existing thread

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

ed through the subtopology. That means once the record is added to the buffer its offset is added to the offsets to commit -- independently of whether the record was evicted from the buffer and sent to the join node or not. Now, let's assume the following scenario 1. a record is read from the input topic

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

o commit -- independently of whether the > record was evicted from the buffer and sent to the join node or not. > Now, let's assume the following scenario > 1. a record is read from the input topic and added to the buffer, but > not evicted to be processed by the join node. > 2. When the p

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

The offset of a record is added to the offsets to commit once the record is streamed through the subtopology. That means once the record is added to the buffer its offset is added to the offsets to commit -- independently of whether the record was evicted from the buffer and sent to the

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

they are replicated already. 3) I see that I'm out voted on the dropping of records thing. We will pass them on and try to join them if possible. This might cause some null results, but increasing the table history retention should help that. 4) I can add some on the kip. But its pretty directly adding

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

ng records that fall outside of the buffer's time interval the join should skip the buffer and try to join the record immediately. In the end, a stream-table join is a unwindowed join, i.e., no grouping is applied to the records. What do you and other folks think about this proposal? 4

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

examples with the "bad" join results I said without buffering the stream it would look like that, but that was incomplete. If the look up was simply looking at the latest version of the table when the stream records came in then the results were possible. If we are using the point in t

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

re type, as it would be a breaking change, potentially required an application re-set, or following the upgrade path for versioned state stores, and also changing the program to explicitly materialize using a versioned store. Also note, that we might not materialize the actual join table, but on

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

Xia wrote: > > Thanks for the updates, Walker! Looks great, though I do have a couple > questions about the latest updates: > >1. The new example says that without stream-side buffering, "ex" and >"fy" are possible join results. How could those

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

Thanks for the updates, Walker! Looks great, though I do have a couple questions about the latest updates: 1. The new example says that without stream-side buffering, "ex" and "fy" are possible join results. How could those join results happen? The example vers

[VOTE] KIP-923: Add A Grace Period to Stream Table Join

Hello everybody, I'm opening the vote on KIP-923 here . If we have more to discus please continue the discussion on the existing thread https://www.mail-archive.com/dev@kafka.apache.org/msg130657.html best, Walker

[jira] [Resolved] (KAFKA-7497) Kafka Streams should support self-join on streams

[ https://issues.apache.org/jira/browse/KAFKA-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax resolved KAFKA-7497. Resolution: Fixed > Kafka Streams should support self-join on stre

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

t ordering, but if the stream is buffered to join on timestamp instead of offset doesn't it already seem like we care more about time in this case? If we end up adding more options it might make sense to do this. Maybe offset order processing can be a follow up? I'll add a section for this in Rejected Alter

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

ons: 1. Is the order that records exit the buffer in necessarily the same as the order that records enter the buffer in, or no? Based on the description in the KIP, it sounds like the answer is no, i.e., records will exit the buffer in increasing timestamp order, which means that they may be or

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

the buffer in increasing timestamp order, which means that they may be ordered (even for the same key) compared to the input order. 2. What happens if the join grace period is nonzero, and a stream-side record arrives with a timestamp that is older than the current stream time minus the grace period

Re: [DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

> > Hello everybody, > > I have a stream proposal to improve the stream table join by adding a grace > period and buffer to the stream side of the join to allow processing in > timestamp order matching the recent improvements of the versioned tables. > > Please take a l

[GitHub] [kafka-site] mjsax merged pull request #507: MINOR: update docs note about spurious stream-stream join results

mjsax merged PR #507: URL: https://github.com/apache/kafka-site/pull/507 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail:

[GitHub] [kafka-site] vcrfxia commented on pull request #507: MINOR: update docs note about spurious stream-stream join results

vcrfxia commented on PR #507: URL: https://github.com/apache/kafka-site/pull/507#issuecomment-1526201667 @mjsax can you review? Looks like I don't have permissions to add reviewers. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to

[GitHub] [kafka-site] vcrfxia opened a new pull request, #507: MINOR: update docs note about spurious stream-stream join results

vcrfxia opened a new pull request, #507: URL: https://github.com/apache/kafka-site/pull/507 Make changes from https://github.com/apache/kafka/pull/13642 live. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL

[DISCUSS] KIP-923: Add A Grace Period to Stream Table Join

Hello everybody, I have a stream proposal to improve the stream table join by adding a grace period and buffer to the stream side of the join to allow processing in timestamp order matching the recent improvements of the versioned tables. Please take a look here <https://cwiki.apache.

[jira] [Created] (KAFKA-14936) Add Grace Period To Stream Table Join

Walker Carlson created KAFKA-14936: -- Summary: Add Grace Period To Stream Table Join Key: KAFKA-14936 URL: https://issues.apache.org/jira/browse/KAFKA-14936 Project: Kafka Issue Type

Re: Fwd: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

2023 at 2:26 PM Guozhang Wang > wrote: > >> Thanks Victoria. >> >> 1) I have no concerns about the filter operator's proposed semantics. >> >> 2) For aggregations, I have meta question in mind to discuss first, >> which is for those operators that generate

Re: Fwd: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

gt; which is for those operators that generate a table, which is > materialized as versioned, how we should emit out of order data if the > operator still needs to. A quick look at the following operations > today: > > a. Read topic as a table source > b. KStream#toTable &

Re: Fwd: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

still needs to. A quick look at the following operations today: a. Read topic as a table source b. KStream#toTable c. Aggregated from a stream d. Aggregated from a table e. From a table-table join. f. From a stateless table operator like a `table.filter`. Per this KIP, case d) and e) should

Re: Fwd: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

Mar 22, 2023 at 10:08 AM Subject: Re: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores To: Thanks for voting, everyone! We have three binding yes votes with no objections during four full days of voting. I will close the vote and mark the KIP as accepted, right in time for th

Re: Fwd: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

IP > > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-914%3A+DSL+Processor+Semantics+for+Versioned+Stores> > > itself with more detail about each of these changes. Please let me know if > > there are any concerns. In the absence of dissent, I'd like to include >

[jira] [Resolved] (KAFKA-14209) Optimize stream stream self join to use single state store

[ https://issues.apache.org/jira/browse/KAFKA-14209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vicky Papavasileiou resolved KAFKA-14209. - Resolution: Implemented > Optimize stream stream self join to use single st

Re: Fwd: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

ct: Re: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores To: Thanks for voting, everyone! We have three binding yes votes with no objections during four full days of voting. I will close the vote and mark the KIP as accepted, right in time for the 3.5 release. Thanks, Victoria On Wed, M

Fwd: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

g with the rest of KIP-914 in the 3.5 release. Apologies for not noticing these additional semantics implications earlier, Victoria -- Forwarded message - From: Victoria Xia Date: Wed, Mar 22, 2023 at 10:08 AM Subject: Re: [VOTE] KIP-914 Join Processor Semantics for Versione

[jira] [Resolved] (KAFKA-14617) Replicas with stale broker epoch should not be allowed to join the ISR

ker epoch should not be allowed to join the ISR > -- > > Key: KAFKA-14617 > URL: https://issues.apache.org/jira/browse/KAFKA-14617 > Project: Kafka > Is

[jira] [Created] (KAFKA-14862) Outer stream-stream join does not output all results with multiple input partitions

Bruno Cadonna created KAFKA-14862: - Summary: Outer stream-stream join does not output all results with multiple input partitions Key: KAFKA-14862 URL: https://issues.apache.org/jira/browse/KAFKA-14862

[jira] [Created] (KAFKA-14834) Improved stream-table and table-table join semantics for versioned stores

Victoria Xia created KAFKA-14834: Summary: Improved stream-table and table-table join semantics for versioned stores Key: KAFKA-14834 URL: https://issues.apache.org/jira/browse/KAFKA-14834 Project

Re: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

> >> wrote: > >>> > >>> Hi all, > >>> > >>> I'd like to start a vote on KIP-914 for updating the Kafka Streams join > >>> processors to use proper timestamp-based semantics in applications with > >>> versioned stores:

Re: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

Streams join processors to use proper timestamp-based semantics in applications with versioned stores: https://cwiki.apache.org/confluence/display/KAFKA/KIP-914%3A+Join+Processor+Semantics+for+Versioned+Stores To avoid compatibility concerns, I'd like to include the changes from this KIP together

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

eems to be no special impact, but it > > should be called out, too. The lookup itself does not go into the history > > of the table so no change here (as we don't have the "query older than > > history case") > > > > Yup, we're on the same page. Using a vers

Re: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

+1 (binding) On 3/20/23 9:05 AM, Guozhang Wang wrote: +1, thank you Victoria! On Sat, Mar 18, 2023 at 8:27 AM Victoria Xia wrote: Hi all, I'd like to start a vote on KIP-914 for updating the Kafka Streams join processors to use proper timestamp-based semantics in applications

Re: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

+1, thank you Victoria! On Sat, Mar 18, 2023 at 8:27 AM Victoria Xia wrote: > > Hi all, > > I'd like to start a vote on KIP-914 for updating the Kafka Streams join > processors to use proper timestamp-based semantics in applications with > versioned stores: > https://cwiki.

[VOTE] KIP-914 Join Processor Semantics for Versioned Stores

Hi all, I'd like to start a vote on KIP-914 for updating the Kafka Streams join processors to use proper timestamp-based semantics in applications with versioned stores: https://cwiki.apache.org/confluence/display/KAFKA/KIP-914%3A+Join+Processor+Semantics+for+Versioned+Stores To avoid

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

, but it > should be called out, too. The lookup itself does not go into the history > of the table so no change here (as we don't have the "query older than > history case") > > Yup, we're on the same page. Using a versioned store for table-table joins > results

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

up, we're on the same page. Using a versioned store for table-table joins > results in the semantic change that the join result will include the > latest-by-timestamp record rather than the latest-by-offset record, but no > timestamped lookups (i.e., `get(key, ts)` calls) are used in the process

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

able-table joins results in the semantic change that the join result will include the latest-by-timestamp record rather than the latest-by-offset record, but no timestamped lookups (i.e., `get(key, ts)` calls) are used in the process so there is no concern about history retention having elapsed and affect

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

I had some questions/concerns, but you addressed them in the Rejected Alternatives section. Thanks for the thorough proposal! -John On Thu, Mar 9, 2023, at 18:59, Victoria Xia wrote: Hi everyone, I have a proposal for updating Kafka Streams's stream-table join and table-table join semantics for t

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

> > > > > I had some questions/concerns, but you addressed them in the Rejected > > Alternatives section. Thanks for the thorough proposal! > > > > > > -John > > > > > > On Thu, Mar 9, 2023, at 18:59, Victoria Xia wrote: > > > > Hi ev

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

ks for the KIP, Victoria! > > > > I had some questions/concerns, but you addressed them in the Rejected > Alternatives section. Thanks for the thorough proposal! > > > > -John > > > > On Thu, Mar 9, 2023, at 18:59, Victoria Xia wrote: > > > Hi everyone, &g

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

eryone, > > > > I have a proposal for updating Kafka Streams's stream-table join and > > table-table join semantics for the new versioned key-value state stores > > introduced in KIP-889 > > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-889%3A+Versioned+S

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

eam-table join and > table-table join semantics for the new versioned key-value state stores > introduced in KIP-889 > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-889%3A+Versioned+State+Stores>. > Would love to hear your thoughts and suggestions. > > https://cwiki.ap

[DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

Hi everyone, I have a proposal for updating Kafka Streams's stream-table join and table-table join semantics for the new versioned key-value state stores introduced in KIP-889 <https://cwiki.apache.org/confluence/display/KAFKA/KIP-889%3A+Versioned+State+Stores>. Would love to hear your th

Re: [VOTE] KIP-903: Replicas with stale broker epoch should not be allowed to join the ISR

The KIP is accepted with 3 binding votes (David, Jun, Jason) and 1 non-binding vote (Alexandre). Thanks! On Tue, Feb 28, 2023 at 3:06 PM Jason Gustafson wrote: > Thanks Calvin, +1 from me. > > On Mon, Feb 27, 2023 at 9:41 AM Calvin Liu > wrote: > > > Hi Jason, > > Updated the fields

Re: [VOTE] KIP-903: Replicas with stale broker epoch should not be allowed to join the ISR

Thanks Calvin, +1 from me. On Mon, Feb 27, 2023 at 9:41 AM Calvin Liu wrote: > Hi Jason, > Updated the fields accordingly. Also, rename the BrokerState to > ReplicaState. > Thanks. > > On Wed, Feb 22, 2023 at 4:38 PM Jason Gustafson > > wrote: > > > Hi Calvin, > > > > The `BrokerState` struct

Re: [VOTE] KIP-903: Replicas with stale broker epoch should not be allowed to join the ISR

Hi Jason, Updated the fields accordingly. Also, rename the BrokerState to ReplicaState. Thanks. On Wed, Feb 22, 2023 at 4:38 PM Jason Gustafson wrote: > Hi Calvin, > > The `BrokerState` struct I suggested would replace the `BrokerId` field in > older versions. > > { "name": "ReplicaId",

[jira] [Created] (KAFKA-14748) Relax non-null FK left-join requirement

Matthias J. Sax created KAFKA-14748: --- Summary: Relax non-null FK left-join requirement Key: KAFKA-14748 URL: https://issues.apache.org/jira/browse/KAFKA-14748 Project: Kafka Issue Type

[jira] [Created] (KAFKA-14747) FK join should record discarded subscription responses

Matthias J. Sax created KAFKA-14747: --- Summary: FK join should record discarded subscription responses Key: KAFKA-14747 URL: https://issues.apache.org/jira/browse/KAFKA-14747 Project: Kafka

Re: [VOTE] KIP-903: Replicas with stale broker epoch should not be allowed to join the ISR

Hi Calvin, The `BrokerState` struct I suggested would replace the `BrokerId` field in older versions. { "name": "ReplicaId", "type": "int32", "versions": "0-13", "entityType": "brokerId", "about": "The broker ID of the follower, of -1 if this request is from a consumer." }, {

Re: [VOTE] KIP-903: Replicas with stale broker epoch should not be allowed to join the ISR

To Jose: 1. Actually I have a second thoughts about the naming ReplicaEpoch. The BrokerEpoch only applies to the replication protocol between the brokers. For others like the KRaft controller, this field can be ignored. So can we change the name to ReplicaEpoch when we really use it in other

Re: [VOTE] KIP-903: Replicas with stale broker epoch should not be allowed to join the ISR

To Jason: 1. Related to the Fetch Request fields change, previously you suggested deprecating the ReplicaId and moving it into a BrokerState field. How about we just make the BrokerEpoch a tag field? - The ReplicaId is currently in use and is filled every time. So that we can keep the way simple.

  1   2   3   4   5   6   >