Sounds reasonable.
Note that a `GlobalKTable` is designed to read data from an topic only
without further processing. That's why you don't get any "output
stream". For fault-tolerance, the input topic is used, and hence, there
is also no "changelog topic".
I agree that option (1) is not ideal wit
Hello,
We have all of spark, flink, storm, kafka installed.
For realtime streaming calculation, which one is the best above?
Like other big players, the logs in our stack are huge.
Thanks.
Thanks guys. I knew that re-processing messages was a possibility with
at_least_once processing, but I guess I hadn't considered the potential
impact on the state stores as far as aggregations are concerned. So with
exactly_once, it must roll-back commit(s) to the state store in a failure
scenari
Hi Alex,
what you describe about failing before offsets are committed is one
reason why records are processed multiple times under the
at-least-once processing guarantee. That is reality of life as you
stated. Kafka Streams in exactly-once mode guarantees that this
duplicate state updates do not h
#listTopic() is not related to your subscription/assignment as indicated
by its JavaDocs:
> Get metadata about partitions for all topics that the user is authorized to
> view. This method will issue a
> remote call to the server.
-Matthias
On 8/19/19 7:02 AM, Kamal Chandraprakash wrote:
> You
Hi all,
Noticing some of the consumer fetch timing out (2-10 sec), even though
there is a steady rate of ingestion that is being seen on the topic.
Any leads on how to triage such an issue?
I asked an essentially similar question a week or two ago. The answer was "this
is expected behaviour unless you switch on exactly-once processing".
(In my case it was solved by changing the topology, which I had to do for
other, unconnected, reasons (the requirements for the application changed
