gt; and buffers records from the second so that it can emit the record from the
> first branch first would do the trick. >
>
> Thanks,>
> John>
>
> On Tue, Dec 3, 2019, at 06:32, Vasily Sulatskov wrote:>
> > Hello,>
> > >
> > I wonder if ordering of the messages is preserved by kafka streams when >
> > the messa
case
I know that there's no repartitioning etc, and messages basically appear on the
same "tick", so it feels like there should be a way to do this. Can I keep
ordering if I replace my transformers with processors and manually connect them
to the same sink?
--
Best regards,
Vasily Sulatskov
gg1 = nVSI + aVL
> println(agg1.toString)
> serialise(agg1)
> }
> )(Materialized.`with`(Serdes.String, Serdes.ByteArray))
> .mapValues(v => { val s = deserialise[Long](v).toString; println(s); s})
> .toStream
> .to(outputTopic)
>
>
> ___
ust add 4 to the earlier 2 so it
> is agg 6?
>
> I have no interest in mapping to different keys. That's kind of making this
> exercise more complex.
>
> Also one of the confusing points is why in older versions of Kafka did you
> not need a subtractor? Only in 2.0 am
ormal" aggregation working and I don't see
> why I need a subtractor. Other than of course I need to make the program
> compile.
>
> I'm using Kafka Streams DSL 2.0
--
Best regards,
Vasily Sulatskov
nt and maybe pick it up by yourself :)
>
>
> -Matthias
>
> On 7/17/18 3:01 PM, Vasily Sulatskov wrote:
> > Hi,
> >
> > I do understand that in a general case it's not possible to guarantee
> > that newValue and oldValue parts of a Change message arrive
hat the overall KTable state is sharded. Updating a single
> upstream shard, might required to update two different downstream shards.
>
>
> -Matthias
>
> On 7/16/18 2:50 PM, Vasily Sulatskov wrote:
> > Hi,
> >
> > It seems that it wouldn't be that difficul
Sax wrote:
>
> Vasily,
>
> yes, it can happen. As you noticed, both messages might be processed on
> different machines. Thus, Kafka Streams provides 'eventual consistency'
> guarantees.
>
>
> -Matthias
>
> On 7/16/18 6:51 AM, Vasily Sulatskov wrote:
> > Hi J
gt; Also, I've created https://issues.apache.org/jira/browse/KAFKA-7161 and
> https://github.com/apache/kafka/pull/5366 . Do you mind taking a look and
> leaving any feedback you have?
>
> Thanks,
> -John
>
> On Fri, Jul 13, 2018 at 12:00 PM Vasily Sulatskov
> wrote:
&g
dr: Supposing you reset the app when the topology changes, I think that
> you should be able to rely on non-null aggregates being passed in to *both*
> the adder and subtractor in a reduce.
>
> I would be in favor, as you suggested, of adding an explicit check and
> throwing an excepti
ut a reset.
>
>
> I can't say right now whether those wacky behaviors are bugs or the result
> of changing the topology without a reset. Or if they are correct but
> surprising behavior somehow. I'll look into it tomorrow. Do feel free to
> open a Jira ticket if you think y
ge shed some light on these issues?
--
Best regards,
Vasily Sulatskov
12 matches
Mail list logo
