THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The main addition of this KIP is a new variant of the current initTransactions API which provides the set of partitions that were assigned in the latest rebalancegives us access to the consumer group states, such as member.id and generation.id.
| Code Block |
|---|
interface Producer {
/**
* InitializeThis transactionalAPI stateshall forbe thecalled producer with the partitions assigned
* in the for consumer group rebalance.aware This call ensures that any transactions
* involving committed offsets from the set of input partitions must be completed
* before this call returns. transactional producers.
*/
* Unlike the no-arg initTransactions() API, this can be called multiple timesvoid initTransactions(Consumer<byte[], byte[]> consumer);
/**
* onNo thelonger sameneed instance.to Typicallypass itin shouldthe beconsumer calledgroup immediatelyid afterin receiving
a case where *we aalready newget partitionaccess assignmentto from the groupconsumer coordinatorstate.
*/
void initTransactionssendOffsetsToTransaction(KafkaConsumer<byte[]Map<TopicPartition, byte[]> consumer);
}
public interface GroupAssignment {
int generationId();OffsetAndMetadata> offsets);
} |
Here we introduced an intermediate data structure `GroupAssignment` just to make the evolvement easier in case we need to add more identification info during transaction init stage. There are two main differences in the behavior of this API and the pre-existing `initTransactions`:
...