François,
thanks for starting this initiative. Personally, I don't think it's
necessarily harmful for the project to add such a new page, however, I
share the same concerns others raised already.
I understand your motivation that people had issues finding commercial
support, but I am not
`KGroupedStream` is just an "intermediate representation" to get a
better flow in the DSL. It's not a "top level" abstraction like
KStream/KTable.
For `KTable` there is `transformValue()` -- there is no `transform()`
because keying must be preserved -- if you want to change the keying you
Hey Jeroen,
Thanks for looking into the collision theory!
> There are no offset collisions as the offset-syncs albeit being stored on
> the same cluster, offsets from A->B are stored
> in mm2-offset-syncs.b.internal whereas offsets from B->A are stored
> in mm2-offset-syncs.a.internal.
The
Ryanne,
> > b.a.replicate-me-0
> That's actually impossible with MM2.
Thanks, I see the isCycle check in MirrorSourceConnector. That makes
me even more curious how the renameTopicPartition method triggers
without a change such as the one that Jeroen has prototyped, since the
only thing that
Hello
Is there any way in Kafka Streams API to define processors for KTable
and KGroupedStream like KStream#transform? How to provide a custom
processor for KTable or KGroupedStream which could for instance provide
way to not downstream selected events?
--
Igor Maznitsa
email:
Hey Greg,
There are no offset collisions as the offset-syncs albeit being stored on
the same cluster, offsets from A->B are stored
in mm2-offset-syncs.b.internal whereas offsets from B->A are stored
in mm2-offset-syncs.a.internal.
What's curious though is the B->A checkpoint connector (which has
