You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Ryan Worsley (JIRA)" <ji...@apache.org> on 2017/09/02 16:56:00 UTC
[jira] [Created] (KAFKA-5825) Streams not processing when exactly
once is set
Ryan Worsley created KAFKA-5825:
-----------------------------------
Summary: Streams not processing when exactly once is set
Key: KAFKA-5825
URL: https://issues.apache.org/jira/browse/KAFKA-5825
Project: Kafka
Issue Type: Bug
Components: streams
Affects Versions: 0.11.0.0
Environment: EmbeddedKafka running on Windows. Relevant files attached.
Reporter: Ryan Worsley
Attachments: build.sbt, log4j.properties, Tests.scala
+Set-up+
I'm using [EmbeddedKafka https://github.com/manub/scalatest-embedded-kafka/] for ScalaTest.
This spins up a single broker internally on a random port.
I've written two tests - the first without transactions, the second with. They're nearly identical apart from the config and the transactional semantics. I've written the transactional version based on Neha's [blog https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/] which is the closest thing I could find to instructions.
The tests wait until a single message is processed by the streams topology, they use this message to complete a promise that the test is waiting on. Once the promise completes the test verifies the value of the promise as being the expected value of the message.
+Observed behaviour+
The first test passes fine, the second test times out, the streams processor never seems to read the transactional message.
+Notes+
I've attached my build.sbt, log4j.properties and my Tests.scala file in order to make it as easy as possible for someone to re-create. I'm running on Windows and using Scala as this reflects my workplace. I completely expect there to be some configuration issue that's causing this, but am unable to proceed at this time.
Related information: https://github.com/manub/scalatest-embedded-kafka/issues/82
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)