Status
Current state: Under discussion
Discussion thread: here
JIRA: here
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
In order for state stores to provide stronger consistency in the future (e.g., RYW consistency) they need to be able to collect record metadata (e.g., offset information).
Today, we already make record metadata available in the ProcessContext (::recordMetadata()), and it is present in the abstract class that implements both ProcessorContext and StateStoreContext, but the method is not currently exposed through the StateStoreContext interface, so it is not available in the state stores.
Public Interfaces
In this KIP we propose to expose recordMetada via the StateStoreContext. The following interface will change:
- org.apache.kafka.stream.processor.StateStoreContext - adding method recordMetadata()
Proposed Changes
The code segment below shows the actual code change together with the corresponding JavaDoc:
public interface StateStoreContext { ... /** * Return the metadata of the current topic/partition/offset if available. * This metadata in a StateStore is defined as the metadata of the last record * that is currently been processed by the StreamTask that holds the store. * <p> * Note that the metadata is not defined during all store interactions, for * example, while the StreamTask is running a punctuation. */ Optional<RecordMetadata> recordMetadata(); ... }
Note that recordMetadata() returns an Optional to account for the fact that there might not be any recordMetadata available if no records have been processed.
Compatibility, Deprecation, and Migration Plan
The change of the StateStoreContext interface does not require any changes to any of the implementations of the interface, it merely exposes (recordMetadata) a method that is already implemented in AbstractProcessorContext. Therefore we do not expect any compatibility issues. Moreover, recordMetadata returns an object of type RecordMetadata which is exclusively read-only, thus, protecting Kafka-internal from being tampered by applications.
Rejected Alternatives
None.