You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Status

Current state: Under Discussion

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

JIRA: Unable to render Jira issues macro, execution error.

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

Motivation

KIP-479, implemented in Kafka 2.4.0, added `StreamJoined` to Kafka Streams as a way to extend features of `Materialized` to stream-stream joins. During the KIP discussion, adding options to disable caching and logging were discussed but not implemented through KIP-479. Adding these features allows users more flexibility over their store and fits with the original goal of extending `Materialized` features to stream-stream joins.

Public Interfaces

This KIP will add the following four methods as well as `loggingEnabled` and `cachingEnabled` variables.

Methods Added to StreamJoined
public StreamJoined<K, V1, V2> withLoggingEnabled(final WindowBytesStoreSupplier otherStoreSupplier) {}

public StreamJoined<K, V1, V2> withLoggingDisabled(final WindowBytesStoreSupplier otherStoreSupplier) {}

public StreamJoined<K, V1, V2> withCachingEnabled(final WindowBytesStoreSupplier otherStoreSupplier) {}

public StreamJoined<K, V1, V2> withCachingDisabled(final WindowBytesStoreSupplier otherStoreSupplier) {}

Proposed Changes

We will add four new methods to `StreamJoined` to allow users to determine whether they want logging and caching for their stores. These configs set the caching and logging decision for both stores, meaning that if logging is disabled for `thisWindowStore`, it will also be disabled for `otherWindowStore`. The default value for both `loggingEnabled` and `cachingEnabled` will be `true`, enabling caching and logging for both stores if the user does not set the values manually.

Compatibility, Deprecation, and Migration Plan

As this is not deprecating or changing default behavior there should be no compatibility issues

Rejected Alternatives

  • Including `withRetentionPeriod()` → skipped as there is no reason for a user to configure a certain retention time for joins
  • No labels