If your producer is using transactions, it's possible that the producer was killed in the middle of a transaction, in which case any un-committed records would be logged on the broker but skipped by downstream consumers.
Otherwise, it's likely that the leader for the partition crashed before the record was replicated to the 2 other brokers. In either case, downstream consumers would ignore the record as if it never existed. re why the join didn't work: the consumers processing the partition would ignore the uncommitted record, and Streams would never see it. This is by design. Ryanne On Fri, Mar 15, 2019 at 10:36 AM Федор Чернилин <investorme...@gmail.com> wrote: > Thanks, I understand how consumer works. The main question is related to > why the join did not work and how it happened that only one message > remained uncommitted. > > пт, 15 мар. 2019 г. в 16:29, Ryanne Dolan <ryannedo...@gmail.com>: > > > Hello! When using exactly-once semantics, uncommitted or aborted records > > are skipped by the consumer as if they don't exist. > > > > When inspecting the topic manually, use isolation.level=read_committed to > > get the same behavior. > > > > Ryanne > > > > On Fri, Mar 15, 2019, 6:08 AM Федор Чернилин <investorme...@gmail.com> > > wrote: > > > > > I also noticed another important thing now. Message which used for join > > is > > > uncommitted. I understood it with the help of consumer's setting > > isolation > > > level - read_committed. The message got into the topic using the same > > > stream app. Remind that stream app has processing guarantee > > > = exactly_once. How could this happen? > > > > > >
