?
Thanks
Adam
On Sun, Sep 30, 2018 at 10:23 AM Adam Bellemare
wrote:
> Hi Jan
>
> With the Stores.windowStoreBuilder and Stores.persistentWindowStore, you
> actually only need to specify the amount of segments you want and how large
> they are. To the best of my understanding,
I think this question is much too broad to be answered in this way. This will
require you to do your own work on understanding the code.
Alternately, start by looking through the Kafka documentation and Confluent
blogs to get an understanding of Kafka usage patterns in Event driven
microservice
Hi All
I would like to call a vote on
https://cwiki.apache.org/confluence/display/KAFKA/KIP-213+Support+non-key+joining+in+KTable.
This allows a Kafka Streams DSL user to perform KTable to KTable
foreign-key joins on their data. I have been using this in production for
some time and I have compose
As expected :) But still, thanks none-the-less!
On Fri, Nov 2, 2018 at 3:36 AM Jan Filipiak
wrote:
> reminder
>
> On 30.10.2018 15:47, Adam Bellemare wrote:
> > Hi All
> >
> > I would like to call a vote on
> >
> https://cwiki.apache.org/confluence/display/K
Bumping this thread, as per convention - 1
On Fri, Nov 2, 2018 at 8:22 AM Adam Bellemare
wrote:
> As expected :) But still, thanks none-the-less!
>
> On Fri, Nov 2, 2018 at 3:36 AM Jan Filipiak
> wrote:
>
>> reminder
>>
>> On 30.10.2018 15:47, Adam Bellema
d
> it over again. Would it be discouraging if I wound up responding to your
> discussion thread?
>
> Thanks,
> -John
>
> On Wed, Nov 7, 2018 at 3:25 PM Adam Bellemare
> wrote:
>
>> Bumping this thread, as per convention - 1
>>
>> On Fri, Nov 2, 2018 at
Hello Matthias
I am curious as to the status of this KIP. TTL and expiry of records will
be extremely useful for several of our business use-cases, as well as
another KIP I had been working on.
Thanks
On Mon, Aug 13, 2018 at 10:29 AM Eno Thereska
wrote:
> Hi Matthias,
>
> Good stuff. Could y
> upgrade path with some colleagues and I am prototyping this atm. Hope to
> update the KIP accordingly soon.
>
> -Matthias
>
> On 11/10/18 7:41 AM, Adam Bellemare wrote:
> > Hello Matthias
> >
> > I am curious as to the status of this KIP. TTL and expiry of recor
gt; > ?
> > This would leave the original store intact and allow a migration of the
> > timestamps without touching the other data.
> >
> > So I am very interested in your PR :-)
> >
> > best regards
> >
> > Patrik
> >
> > On Tue, 20 Nov 201
yed:
> > A: [1, 3]
> > B: [2]
> >
> > Then, the rhs part of the join would only need a regular single-key
> > lookup. Of course we have to deal with the problem of large values, as
> > there's no bound on the number of lhs records that can reference rhs
> &g
proposed to scatter a KTable, and then do things like
> join, re-group, etc from there... I'm not sure; I haven't thought through
> all the consequences yet.
>
> This is all just my opinion after thinking over the discussion so far...
> -John
>
> On Mon, Dec 3, 2018 at
s coded as-is. Alternate option is possible, but will
require for implementation details to be made in the API and some exposure
of new data structures into the API (ie: CombinedKey).
I appreciate any insight into this.
Thanks.
On Tue, Dec 4, 2018 at 2:59 PM Adam Bellemare
wrote:
> Hi John
>
this step simpler than the current proposal. In fact,
> > we
> > > can just keep a single final-result store with timestamps and reject
> > values
> > > that have a smaller timestamp, is that right?
> >
> > Which is the correct output should at least be dec
+1 (non-binding) from me. Looks like a pretty clear-cut case.
On Tue, Dec 11, 2018 at 1:11 AM Shawn Nguyen
wrote:
> Thanks for the feedback Guozhang! I updated the KIP.
>
> In the meantime, could I ask for additional binding votes/approval on this
> KIP proposal?
>
> Shawn
>
> On Thu, Dec 6, 2
be clear to future readers which parts of the document are
> > enduring, and which parts are a snapshot of our implementation thinking
> at
> > the time.
> >
> > I'm suggesting this because I suspect that the others haven't made time
> to
> > rev
> traffic. I think this is actually a reasonable assumption, which we can
> > discuss more if you're suspicious.
> > * we only need one copy of the data (the left and right tables need to be
> > materialized) and one extra copy of the PK:FK pairs in the Materialized
> >
ec 17, 2018 at 7:06 PM Adam Bellemare
wrote:
> Hi John and Guozhang
>
> Ah yes, I lost that in the mix! Thanks for the convergent solutions - I do
> think that the attachment that John included makes for a better design. It
> should also help with overall performance as very high-cardina
; You know my opinion on this. For me its dead, I just leave you the
> message here as an opportunity to reconsider the choices that were made.
>
> Whish y'll a happy new year :)
>
>
>
>
>
>
> On 27.12.2018 17:22, Adam Bellemare wrote:
> > Hi All
> >
> >
Hi Nick
Is this change only for the basic consumer? How would this affect anything with
Kafka Streams?
Thanks
> On Jan 5, 2019, at 10:52 PM, n...@afshartous.com wrote:
>
> Bumping again for more votes.
> --
> Nick
>
>
>> On Dec 26, 2018, at 12:36 PM, n...@afshartous.com wrote:
>>
>>
helped put it into a much better state. I would appreciate any
feedback or votes.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-213+Support+non-key+joining+in+KTable
Thank you
Adam Bellemare
Looks good to me then!
+1 non-binding
> On Jan 10, 2019, at 1:22 PM, Afshartous, Nick wrote:
>
>
> Hi Adam,
>
>
> This change is only intended for the basic consumer API.
>
>
> Cheers,
>
> --
>
>Nick
>
>
>
> some examples. Or perhaps we should consider some kind of API to do
> pluggable buffering on the client side.
>
> In any case, this needs more discussion. We need to be clear and definite
> about what use cases we want to solve, and the tradeoffs we're making to
> solve
g) from me as well.
> > >
> > > Thanks for sticking with this, Adam!
> > > -John
> > >
> > > On Wed, Jan 9, 2019 at 6:22 PM Guozhang Wang
> wrote:
> > >
> > > > Hello Adam,
> > > >
> > > > I'm +1 on the c
hs ago and am very excited
> > about it. It would be a huge help on the project I'm working on.
> >
> > On Fri, Jan 11, 2019 at 9:05 AM Adam Bellemare >
> > wrote:
> >
> >> Thanks all -
> >>
> >> So far that's +2 Binding, +2 no
not promise. Even if
> we make the voting deadline, it might also be tight to review the PR, as
> it seems to be big and complicated.
>
> I'll try my very best to get it into 2.2...
>
>
> -Matthias
>
>> On 1/15/19 3:27 AM, Adam Bellemare wrote:
>> If I c
Hello
As per:
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
I request access to be able to create a KIP for
https://issues.apache.org/jira/browse/KAFKA-4628.
Wiki username: adam.bellemare
Thanks,
Adam
Hello
Sending a second request to get access to make a KIP.
As per: https://cwiki.apache.org/confluence/display/KAFKA/
Kafka+Improvement+Proposals
I request access to be able to create a KIP for https://issues.apache.org/
jira/browse/KAFKA-4628.
Wiki username: adam.bellemare
Thanks,
Adam
wrote:
> Your request was already granted.
>
> Same day when you sent the first email.
>
> Did you not see my reply on the dev list? (cc'ed you this time to make
> sure you get the email).
>
>
> -Matthias
>
> On 6/8/18 5:05 AM, Adam Bellemare wrote:
> > H
alter the way that GlobalKTables
can be used in relation to KTables. I believe that this would be a very
useful change but I need some eyes on the technical aspects to validate or
refute the strategy.
Thanks
Adam Bellemare
ng+in+KTable
>
> It suggest to add non-key joins and a lot of issues how to implement
> this were discussed already. As a KTable-GloblKTable join is a non-key
> join, too, it seems that those discussion apply to your KIP too.
>
> Hope this helps to make the next steps.
>
>
KTable-KTable join, we have inner / left / outer, while for
> KStream-KTable / GlobalKTable join we only have inner / left, and the
> reason is that for stream-table joins outer join makes less sense; should
> we consider outer for KTable-GlobalKTable join as well?
>
>
> Guoz
t; Please see my comments inline.
>
> On Thu, Jun 21, 2018 at 8:14 AM, Adam Bellemare
> wrote:
>
> > Hi Guozhang
> >
> > *Re: Questions*
> > *1)* I do not yet have a solution to this, but I also did not look that
> > closely at it when I begun this KIP.
Hey all
I recently took a crack at implementing my own version of KIP-213 based on code
written by the previous committee, Jan. I currently have it dev ready, but I
want to restart some of the discussion based on some design decisions that I
made, and I need some feedback on a few particular ch
Hi Folks
I have a quick question about a scenario that I would appreciate some
insight on. This is related to a KIP I am working on, but I wanted to break
this out into its own scenario to reach a wider audience. In this scenario,
I am using builder.internalTopologyBuilder to create the following
some clearer
integration tests (I did a lot of testing using a non-Kafka Streams
framework) and clean up the code a bit more before putting it in a PR
against trunk (I can do so later this week likely).
Please take a look,
Thanks
Adam Bellemare
esire, but first I was hoping to just
tackle some of the fundamental design proposals.
Thanks,
Adam
On Mon, Jul 23, 2018 at 10:05 AM, Adam Bellemare
wrote:
> Here is the new discussion thread for KIP-213. I picked back up on the KIP
> as this is something that we too at Flipp are now runni
t-once".
>
> 3) Finally, when exactly-once is enabled, if there is any crashes, the
> changelog topic / state store will be "rewinded" (I omit the implementation
> details here, but just assume that logically, we can rewind them) to the
> previously successful commit, so `
data in streams.
Adam
On Fri, Jul 27, 2018 at 1:45 AM, Guozhang Wang wrote:
> Hello Adam,
>
> Thanks for rebooting the discussion of this KIP ! Let me finish my pass on
> the wiki and get back to you soon. Sorry for the delays..
>
> Guozhang
>
> On Tue, Jul 24, 2018 at
switching the KIP-213 to use the RecordHeaders in Kafka Streams
instead of the PropagationWrapper, but conceptually it should be the same.
Again, any feedback is welcomed...
On Mon, Jul 30, 2018 at 9:38 AM, Adam Bellemare
wrote:
> Hi Guozhang et al
>
> I was just reading the 2.0 release
Hi Cédric
I do not know how the topology names are chosen, but provided that you
didn't change any of the topology then new topics will not be created or
require alteration.
If you modify the topology then the naming can indeed change, but it would
then create a new internal topic and there would
ybe what happened to you.
> >
> > We have been discussing various mechanisms by which we could support
> > modifying the topology in place. Typically, this would involve giving
> each
> > operator a semantic name so that the internal names would be related to
&g
ore.
>
> If there is anything unclear with all the text that has been written, feel
> free to just directly cc me so I don't miss it on
> the mailing list.
>
> Best Jan
>
>
>
>
>
> On 08.08.2018 15:26, Adam Bellemare wrote:
>
>> More followup, and +de
CC Jan
On Mon, Aug 13, 2018 at 12:16 PM, Adam Bellemare
wrote:
> Hi Jan
>
> If you do not use headers or other metadata, how do you ensure that
> changes to the foreign-key value are not resolved out-of-order?
> ie: If an event has FK = A, but you change it to FK = B, you need
oing on. The Idea
> > of hiding this behind metadata and handle it in the DSL is from my POV
> > unideal.
> >
> > To write into your example:
> >
> > key + A, null)
> > (key +B, )
> >
> > is what my output would look like.
> >
> >
> >
gher
> streams version, I don't really have a steak here and initially I didn't
> feel like actually sending it. But maybe you can pull
> something good from it.
>
> Best jan
>
>
>
> On 15.08.2018 04:44, Adam Bellemare wrote:
>
>> @Jan
>> Than
While I am not sure if I can or can’t vote, my question re: Jan’s comment is,
“should we be implementing it as Samza does?”
I am not familiar with the drawbacks of the current approach vs how samza does
it.
> On Aug 18, 2018, at 5:06 PM, n...@afshartous.com wrote:
>
>
> I only saw one vote
018 at 9:48 AM Jan Filipiak
> wrote:
>
> > Still havent completly grabbed it.
> > sorry will read more
> >
> > On 17.08.2018 21:23, Jan Filipiak wrote:
> > > Cool stuff.
> > >
> > > I made some random remarks. Did not touch the cor
Hi All
I am looking for performance metrics related to Kafka Streams and KSQL. I
have been scouring various blogs, including the confluent one, looking for
any current performance metrics or benchmarks, official or otherwise, on
both Kafka Streams and KSQL for Kafka 2.x +. Unfortunately, almost
ev
Blog post in question:
https://www.confluent.io/blog/ksql-february-release-streaming-sql-for-apache-kafka/
On Wed, Aug 22, 2018 at 10:01 AM, Adam Bellemare
wrote:
> Hi All
>
> I am looking for performance metrics related to Kafka Streams and KSQL. I
> have been scouring various blog
0Available%22)%
> 20AND%20component%20%3D%20%22streams%22%20%20AND%
> 20labels%20%3D%20performance%20%20
>
>
> Guozhang
>
> On Wed, Aug 22, 2018 at 7:02 AM, Adam Bellemare
> wrote:
>
> > Blog post in question:
> > https://www.confluent.io/blog/ksql-february-re
ix the header to be safe, while keeping the additional cost
> (note the header field is per-record, so any additional byte is per-record
> as well) low.
>
>
> Guozhang
>
> On Tue, Aug 21, 2018 at 11:58 AM, Adam Bellemare >
> wrote:
>
> > Hi John
> >
>
Hi Matt
I posted in the PR about some of the commenting changes. Overall I think
the whole thing looks good, so I would give it a:
+1 non-binding
Adam
On Tue, Aug 28, 2018 at 5:13 PM, Matt Farmer wrote:
> Given that voting and discussion have stalled out it seems like this is a
> thing that f
y for reviews?
>
>
> Guozhang
>
> On Tue, Aug 28, 2018 at 5:00 AM, Adam Bellemare
> wrote:
>
>> Okay, I will implement John's suggestion of namespacing the external
>> headers prior to processing, and then removing the namespacing prior to
>> emitting. A
th the review and further KIP discussion. I can
>> understand this can be painful, but that may be the best option we can do
>> to avoid as much work to be wasted as possible.
>>
>>
>> Guozhang
>>
>>
>> On Wed, Aug 29, 2018 at 10:06 AM, Adam Bellema
s are appreciated. I will revisit it again when I have a
bit more time.
Thanks
On Mon, Sep 3, 2018 at 4:55 PM, Adam Bellemare
wrote:
> Hi Jan
>
> Thank you for taking the time to look into my PR. I have updated it
> accordingly along with the suggestions from John. Please note
+1 (non binding) - would really like to see this one.
On Mon, Sep 3, 2018 at 12:18 PM, Mickael Maison
wrote:
> +1 (non binding)
> On Mon, Sep 3, 2018 at 3:14 PM Manikumar
> wrote:
> >
> > bump up! waiting for 2 more binding votes!
> >
> > On Tue, Aug 28, 2018 at 7:36 AM Satish Duggana >
> >
in effect is the same as the design I have now,
just with the two tables merged together.
I will keep looking at this but I am not seeing a great simplification.
Advice and comments are welcomed as always.
On Tue, Sep 4, 2018 at 9:38 AM, Adam Bellemare
wrote:
>
> As I was looking mor
disregarded. The decision about the forward
> > depends on the size of the aggregated map.
> > Only 1 element long maps would be unpacked and forwarded. 0 element maps
> > would be published as delete. Any other count
> > of map entries is in "waiting for correct delete
afterwards is really common.
>
>
>
>
>
>
> On 05.09.2018 13:49, Adam Bellemare wrote:
>
>> Hi Matthias
>>
>> Thank you for your feedback, I do appreciate it!
>>
>> While name spacing would be possible, it would require to deserialize
>>> us
s? Is there somewhere
>> I can see the original requirement or proposal?
>>
>> On Sep 7, 2018, at 8:13 AM, Jan Filipiak
>>> wrote:
>>>
>>>
>>> On 05.09.2018 22:17, Adam Bellemare wrote:
>>>
>>>> I'm currently testing u
and ruined all your charts.
> > Hopefully i can get it done today
> >
> > On 08.09.2018 16:00, Adam Bellemare wrote:
> > > Hi Jan
> > >
> > > I have included a diagram of what I attempted on the KIP.
> > >
> > https://cwiki.apache.org/conf
Hi Yui Yoi
Preface: I am not familiar with the spring framework.
"Earliest" when it comes to consuming from Kafka means, "Start reading from
the first message in the topic, *if there is no offset stored for that
consumer group*". It sounds like you are expecting it to re-read each
message wheneve
tion
> stuck on an invalid message? and not consuming any further messages?
>
> Thanks again
>
> On Wed, Sep 12, 2018 at 2:35 PM Adam Bellemare
> wrote:
>
> > Hi Yui Yoi
> >
> > Preface: I am not familiar with the spring framework.
> >
> > "Ear
> only, but for windowed KTables we do not really have a good support for
> > their joins anyways (https://issues.apache.org/jira/browse/KAFKA-7107) I
> > think we can just consider non-windowed KTable-KTable non-key joins for
> > now. In which case, KIP-258 should hel
Hi Jan
Check for " highwaterMat " in the PR. I only changed the state store, not
the ProcessorSupplier.
Thanks,
Adam
On Mon, Sep 24, 2018 at 2:47 PM, Jan Filipiak
wrote:
>
>
> On 24.09.2018 16:26, Adam Bellemare wrote:
>
>> @Guozhang
>>
>> Thanks for t
>
> I just hope the window-store doesn't check stream-time under the hoods
> that would be a questionable interface.
>
> If it does: did you see my comment on checking all the windows earlier?
> that would be needed to actually give reasonable time gurantees.
>
> Best
Bumping this vote because I don't want it to languish. It is very unlikely
to go into 2.2 at this point, but I would like to avoid resurrecting a dead
thread in 30 days time.
On Tue, Jan 15, 2019 at 5:07 PM Adam Bellemare
wrote:
> All good Matthias. If it doesn’t get in for 2.2 I’ll ju
As the question indicates.
Should this not be default false? I think this is a bit nefarious to
someone launching their application into production without testing it
extensively around failure modes. I can see a scenario where a consumer
polls for events, processes them, produces to output topic,
mit the previous
> batch.
> > In your example, the app might come back and have to re-execute all
> > the records in the uncommitted batch but it will never skip over
> > unprocessed records.
> >
> > -Original Message-
> > From: Adam Bellemare [mailto:adam.
-down without requiring any pauses
for rebuilding state. I am interested in kicking this off as a KIP if so,
but would appreciate any JIRAs or related KIPs to read up on prior to
digging into this.
Thanks
Adam Bellemare
Hi Harsha
Agreed with Eno: "However I'd argue that this KIP is about strengthening
the role of Kafka as a long-term storage service"
- Put the focus on the single source of truth being from Kafka, with
clients not needing to source from multiple data sources.
Also, clarify if the segment is ev
Bump - hoping someone has some insight. Alternately, redirection to a more
suitable forum.
Thanks
On Sun, Feb 3, 2019 at 10:25 AM Adam Bellemare
wrote:
> Hey Folks
>
> I have a few questions around the operations of stateful processing while
> scaling nodes up/down, and a pos
Great work Bill! Well deserved!
> On Feb 14, 2019, at 3:55 AM, Edoardo Comar wrote:
>
> Well done Bill!
> --
>
> Edoardo Comar
>
> IBM Event Streams
> IBM UK Ltd, Hursley Park, SO21 2JN
>
>
>
>
> From: Rajini Sivaram
> To: dev
> Date
Hi all
Since Bill is now a committer, the vote is changed to 3 binding and 3
non-binding (unless I am somehow mistaken - please let me know!). In this case,
I believe the vote passes.
Thanks
Adam
> On Jan 24, 2019, at 7:28 PM, Adam Bellemare wrote:
>
> Bumping this vote becaus
think, he needs to re-cast his vote.
>
> -Matthias
>
>> On 2/15/19 5:49 AM, Adam Bellemare wrote:
>> Hi all
>>
>> Since Bill is now a committer, the vote is changed to 3 binding and 3
>> non-binding (unless I am somehow mistaken - please let me kno
on is complete.
Thanks for your help - I appreciate you taking the time to reply.
Adam
On Wed, Feb 20, 2019 at 8:38 PM Guozhang Wang wrote:
> Hello Adam,
>
> Sorry for being late replying on this thread, I've put my comments inlined
> below.
>
> On Sun, Feb 3, 2019 at 7:3
Downloaded, compiled and passed all tests successfully.
Ran quickstart (https://kafka.apache.org/quickstart) up to step 6 without
issue.
(+1 non-binding).
Adam
On Mon, Feb 25, 2019 at 9:19 PM Matthias J. Sax
wrote:
> @Stephane
>
> Thanks! You are right (I copied the list from an older draft
Hi Matthias
Thank you for the feedback! I appreciate your well thought-out questions. I
have tried to answer and comment on everything that I know below.
*> Q) For the materialized combined-key store, why do we need to disable>
caching? And why do we need to flush the store?*
This is an artifac
Ah yes, I recall it all now. That answers that question as to why I had
caching disabled. I can certainly re-enable it since I believe the main
concern was simply about reconciling those two iterators. A lack of
knowledge there on my part.
Thank you John for weighing in - we certainly both do app
sent back from the right hand side does not match with the left hand
> side any more, i.e. we will only send:
>
> (k1, (f-k1, v2-v3))
>
> to down streams once.
>
> WDYT?
>
>
> Guozhang
>
>
> On Wed, Mar 6, 2019 at 7:58 AM Adam Bellemare
> wrote:
>
> &g
bug). I take this as "evidence" that we're better off
> > eliminating those duplicates from the start. Guozhang's proposal seems
> like
> > a lightweight solution to the problem, so FWIW, I'm in favor.
> >
> > Thanks,
> > -John
>
gt; >> Would this pose some sort of verbosity problem in the internal topics,
> >> especially if we have to rebuild state off of them?
>
> I don't see an issue atm. Can you elaborate how this relates to rebuild
> state?
>
>
> -Matthias
>
> On 3/10/19 1
For the sake of expediency, I updated the KIP with what I believe we have
discussed.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-213+Support+non-key+joining+in+KTable#KIP-213Supportnon-keyjoininginKTable-Tombstones&ForeignKeyChanges
On Mon, Mar 11, 2019 at 8:20 AM Adam Belle
on
> > topics because Streams aggressively deletes messages from the reparation
> > topics once it knows they are handled. Thus, we don't need to try and
> cater
> > to the log compactor.
> >
> > Thanks,
> > -John
> >
> > On Mon, Mar 11, 2019
gt; +1 (binding)
>
>
>
> -Matthias
>
>> On 2/15/19 11:27 AM, Adam Bellemare wrote:
>> Hi Bill
>>
>> Now that you are a committer, does your vote add a +1 to binding? Can you
>> recast it if you believe this is a sound decision? I am eager
ding the parent page) with the newest
> status as well? Thanks.
>
>
> Guozhang
>
> On Mon, Mar 11, 2019 at 6:12 PM Adam Bellemare
> wrote:
>
> > Thanks to everyone, including John, Guozhang, Matthias and Jan for all
> the
> > help!
> >
> >
Hi Valeria
Thanks for the KIP. I admit my knowledge on Kafka Connect transforms is a
bit rusty, however - Is there any other way to currently achieve this same
functionality outlined in your KIP using existing transforms?
Thanks
On Thu, Mar 14, 2019 at 12:05 PM Valeria Vasylieva <
valeri
re more effort, so it is better to do
> it as separate issue.
>
> Kind Regards,
> Valeria
>
> пт, 15 мар. 2019 г. в 17:35, Adam Bellemare :
>
> > Hi Valeria
> >
> > Thanks for the KIP. I admit my knowledge on Kafka Connect transforms is a
> > bit ru
Hey folks
I have been implementing the KIP as outlined in
https://cwiki.apache.org/confluence/display/KAFKA/KIP-213+Support+non-key+joining+in+KTable,
and I have run into a few points to consider that we did not include in the
original.
*1) Do all input topics need to have the same partitions or
; >
> > 3) I am not an expert on hashing, but 128-bit murmur3 sounds reasonable
> > to me
> >
> >
> >
> > Btw: I think we can have this discussion on the PR -- no need to concern
> > the mailing list (it's a lot of people that are subscribed).
&g
One more thing to note:
You are looking at regular, base NATS. On its own, it is not a direct 1-1
comparison to Kafka because it lacks things like data retention, clustering
and replication. Instead, you would want to compare it to NATS-Streaming, (
https://github.com/nats-io/nats-streaming-server
Hi John
What is the status of this KIP?
My teammates and I are running into the "UNKNOWN_PRODUCER_ID" error on
2.1.1 for a multitude of our internal topics, and I suspect that a proper
fix is needed.
Adam
On Mon, Jan 7, 2019 at 7:42 PM Guozhang Wang wrote:
> Thanks Jason. The proposed solutio
Ach - Sorry. I meant Jason. I had just read a John Roesler email.
On Mon, Mar 25, 2019 at 5:21 PM Adam Bellemare
wrote:
> Hi John
>
> What is the status of this KIP?
>
> My teammates and I are running into the "UNKNOWN_PRODUCER_ID" error on
> 2.1.1 for a multitude o
Thanks for the hard work Colin, and everyone else who helped get this out!
On Mon, Jun 24, 2019 at 1:38 PM Colin McCabe wrote:
> Hi all,
>
> This vote passes with 6 +1 votes (3 of which are binding) and no 0 or -1
> votes. Thanks to everyone who voted.
>
> +1 votes
> PMC Members:
> * Ismael Jum
Thanks John.
I'm looking forward to any feedback on this. In the meantime I will work on
the unit tests to ensure that we have well-defined and readable coverage.
At the moment I cannot see a way around emitting (k,null) whenever we emit
an event that lacks a matching foreign key on the RHS, exce
gt; tombstones: their payload is small, and they are trivial to handle
> downstream. If users want to, they can materialize the join result to
> suppress any extra tombstones, so there's a way out.
>
> Thanks for the awesome idea. It's better than what I was thinking.
> -joh
2019 at 3:37 PM Adam Bellemare
wrote:
> >Maybe just call it as (k, leftval, null) or (k, null, rightval)?
> Done.
>
> > if you update the KIP, you might want to send a new "diff link" to this
> thread
> Here it is:
>
> > Looking closely at the proposal
e fine to say you have
> to upgrade completely to 2.4 before deploying a FK join.
>
> Just want to make sure we anticipate these issues in case it affects
> the design at all.
>
> Thanks,
> -John
>
> On Wed, Jun 26, 2019 at 2:38 PM Adam Bellemare
> wrote:
> >
>
normal keys are like "key" and null-keys are like
> "null(identity)". Then given a query like
> "KTable.rightJoin(KTable)", and
> inputs like:
> LHS:
> "a": 1
> "b": 2
>
> RHS:
> 1: true
> 3: false
>
> a full
olean takes
> > anyway), so it seems like an Enum in Java-land and a byte on the wire
> > is a good choice.
> >
> > Agreed on the right and full outer joins, it doesn't seem necessary
> > right now, although I am happy to see the left join "join" the par
1 - 100 of 161 matches
Mail list logo
