Kafka 4.3.1 fixes a Kafka Streams RocksDB native memory leak

Apache Kafka released 4.3.1 on June 25, with a Kafka Streams RocksDB native memory leak singled out among its critical fixes. The announcement links the complete change list and version-specific upgrade guidance.

The relevant runtime is the Streams application

The highlighted defect is in Kafka Streams’ use of RocksDB. Our analysis is that teams should begin by finding applications that package the affected Streams runtime, rather than treating a broker version check as the whole response.

Memory observation should also cover the process, not only the managed heap. A stable heap chart can coexist with growth elsewhere in a process, so an acceptance test focused on garbage collection would be incomplete for a native-memory fix.

Build a sustained replay using a representative stateful topology and record memory over time, input volume and state-store size. Those measurements help distinguish a leak-shaped trend from legitimate growth as the application learns more keys.

Verify recovery after updating the dependency

The patch is an opportunity to test the operational path used when a worker stops. Restart a test instance, observe state restoration and confirm that application outputs remain correct through the transition.

Do not claim success from a short idle run. Include enough updates and state activity to exercise the workload that matters, and compare it with the same scenario on the prior build if that can be done safely.

The immediate action is to identify the deployed Streams dependency and produce an updated application artifact. Record its runtime version with a before-and-after memory trace, then use the project’s upgrade notes to plan the release rather than assuming that all Kafka components share one deployment boundary.