This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: Under DiscussionAdopted

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread] 

JIRA:

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Over time, certain exceptions and methods within the Kafka Streams exception handling interfaces have been deprecated are unused in favor of newer, more comprehensive alternatives. Retaining these deprecated elements can lead to confusion, and complicates future development and maintenance. This KIP proposes the deprecation and removal of these specific deprecated exceptions and methods to streamline the API BrokerNotFoundException and improve code clarity.

Public Interfaces

Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.

A public interface is any change to the following:

• Binary log format

• The network protocol and api behavior

• Any class in the public packages under clientsConfiguration, especially client configuration

  • org/apache/kafka/common/serialization

  • org/apache/kafka/common

  • org/apache/kafka/common/errors

  • org/apache/kafka/clients/producer

  • org/apache/kafka/clients/consumer (eventually, once stable)

• Monitoring

• Command line tools and arguments

• Anything else that will likely break existing users in some way when they upgrade

Proposed Changes

...

The removal will affect the public exceptions of Kafka Streams. Users who are still using the BrokerNotFoundException  class will encounter compilation errors.

Proposed Changes

This KIP proposes to remove BrokerNotFoundException which is unused since Kafka Streams 2.8.

This change goes in two steps

Step1: mark unused BrokerNotFoundException as deprecated in 4.2 release

Step2: remove the deprecated exception in the next major release which can be 5.0

Unused Exception for Deprecation and Removal:

• org.apache.kafka.streams.errors.BrokerNotFoundException

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
• If we are changing behavior how will we phase out the older behavior?
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Test Plan

Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

• Compatibility: This change is not backward compatible at the source code level for users who are still using the BrokerNotFoundException class.
• Deprecation: The BrokerNotFoundException was unused since Kafka Streams version 2.8. 
  • Given that BrokerNotFoundException is unused, we can mark it deprecated in 4.2, making their removal appropriate in 5.0 as sufficient deprecation period will be passed.
• Migration Plan:
  • Users should remove any handling of BrokerNotFoundException as it is no longer relevant.

Test Plan

This is a code cleanup. Existing test suite should catch any failures. Will add or update new unit tests as needed.

Rejected Alternatives

Since BrokerNotFoundException is not used for a very long time, we can remove it directly. But, the protocol we follow is to deprecate them first and then remove them in the next major release.

We will have an unused class lying around for another release. Other than that, there is no damage if we follow the regular process. Hence, the two step processIf there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.