Status

Current state: Under Discussion

Discussion thread: (not yet set)

JIRA: KAFKA-4462

Motivation

Currently, we have a “one-way” backwards compatibility policy.  New brokers support older clients, but new clients do not support older broker versions.  This policy makes it difficult for users to upgrade Kafka clients.  Essentially, they must upgrade to the corresponding broker version before rolling out a new client version.

...

Currently, users are incentivized to use the oldest client they can put up with.  Old clients can talk to both new and old brokers, whereas new clients can only talk to new brokers.  Users may miss out on important security, performance, and functionality upgrades because of these perverse incentives.  The limited compatibility policy makes deploying and using Kafka more difficult for system administrators.

Proposed Changes

This KIP suggests revising the Kafka Java client compatibility policy so that it is two-way, rather than one-way.  Not only should older brokers support newer clients, but newer clients should support older brokers.

...

In some cases, older brokers will be unable to perform a feature supported by newer clients.  For example, retrieving message offsets from a message timestamp (KIP-79) is not supported in versions before 0.10.1.  In these cases, the new client will throw an ObsoleteBrokerVersion exception when attempting to perform the operation.  This will let clients know that the reason why the operation cannot be performed is because the broker version in use does not support it.  At the same time, clients which do not attempt to use the new operations will proceed as before.

Implementation

KIP-35 added the ApiVersionRequest call.  When it starts up, the client makes this RPC to learn what versions of each RPC the server supports.

...

This policy ensures that old software which uses old features will continue to work, while allowing new software to use new features when they become available on the broker.

New or Changed Public Interfaces

No public RPCs will be changed or created.  No new public methods will be added to clients.  A new public exception, ObsoleteVersionException, will be created.

Migration Plan and Compatibility

Because we require the ApiVersionRequest RPC to be present, only broker versions beginning with 0.10 will be supported by new clients.  However, going forward, new clients will support broker versions after that.

If the burden of backwards compatibility becomes too large, at some point we may need to break it.  This is a familiar pattern-- for example, Hadoop maintains backwards compatibility within a single major release, but makes no guarantees across major releases.  This decision should be made by the community based on the situation at the time.  In general, backwards compatibility is highly useful to users, so this decision should not be made lightly.

Test Plan

The current compatibility tests are:

...

 We should add a new test which demonstrates that new clients can use older brokers.  It should be able to test against multiple older broker versions.  In cases where a feature is missing from an older broker, it should check that we receive ObsoleteBrokerVersion as expected.  In other cases, things should work as expected.

Rejected Alternatives

We considered adding a new RPC to the broker for retrieving “feature flags.”  This would return a set of features which the broker supported.  The client could then make use of this list of features.

...

If there are changes that don’t make sense in the context of existing RPCs, the ApiVersionRequest mechanism allows us to add a brand new RPC.  In fact, if we ever decide that feature flags are desirable, we can add them this way.

Potential Future Work

In the future, we might consider adding an API whereby clients can specify which features that they needed when connecting to the broker.  This would allow clients to know which features they were getting up-front, rather than learning later.  For example, a client could specify that it needs ListOffsetRequestV1 support in order to start up.  Or the client could specify that it needs exactly-once semantics in order to start up.