Important Warning

Update July 2016: This Tech Preview documentation from March 2016 is outdated and deprecated. Please use the latest Confluent Platform documentation instead.

FAQ

Attention

Kafka Streams is a new library and isn’t ready for use in production workloads yet. We are looking for feedback on APIs, operators, documentation, and really anything that will make the end user experience better. Feel free to provide your feedback via email to dev@kafka.apache.org.

General

When will Kafka Streams be released officially?

The upcoming Apache Kafka 0.10 release will include Kafka Streams. The 0.10 release is, at the time of this writing, scheduled for April 2016.

Is Kafka Streams a project separate from Apache Kafka?

No, it is not. Kafka Streams is a new component of the Apache Kafka open source project, and thus included in Apache Kafka 0.10+ releases.

Is Kafka Streams a proprietary library of Confluent?

No, it is not. Kafka Streams is a new component of the Apache Kafka open source project.

What are the system dependencies of Kafka Streams?

Kafka Streams has no external dependencies on systems other than Apache Kafka.

Note

ZooKeeper dependency (Tech Preview): The Kafka Streams implementation included in the Tech Preview has an additional dependency on Apache ZooKeeper. This explains why you are currently required to configure the zookeeper.connect setting in your application (see Configuring a Kafka Streams application in the Developer Guide). This dependency on ZooKeeper is only temporary though and will be removed once KIP-4 is included in Apache Kafka, and the decision was made to not duplicate parts of the KIP-4 efforts just for the sake of Kafka Streams. In the meantime, this additional system dependency should not matter much in practice because ZooKeeper is required for running Apache Kafka anyways.

Troubleshooting and debugging

Get more meaningful Java stacktraces?

When you write Kafka Streams applications, you often create chains of method calls such as the following:

// Code all on one line.  Unfortunately, this is bad practice when it comes to stacktraces.
myStream.map(...).filter(...).countByKey(...);

Now if your code happens to trigger a runtime error, the Java stacktrace may not be very helpful because the JVM provides only line-number information about where an error occurred (“NullPointerException at line 123”). So, to pick the example above, you may deduce that some operation in the map/filter/countByKey chain failed, but the stacktrace will not tell you where exactly in the affected line.

A simple trick is to split your method chains across multiple lines, so that the row number returned by the stacktrace will more easily identify the actual culprit:

// Split the same code across multiple lines to benefit from more actionable stacktraces.
myStream
  .map(...)
  .filter(...)
  .countByKey(...);