Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Of course the producer may fail to receive the response from the InitProducerId call, so we need to make this API safe for retries. In the worst case, a retry may span coordinator failover, so we need to record in the transaction log whether the bump was the result of a new producer instance or not. We propose to add a new field to the transaction state message for the last epoch that was assigned to a producer instance. We also need to handle retries of a request that triggered the generation of a new producerId due to epoch exhaustion, so we propose to add a new field to the transaction state message for the previous producerId associated with the transaction. When the coordinator receives a new InitProducerId request, we will use the following logic to update the epoch:

  1. No If no producerId/epoch is provided, the producer is initializing for the first time. We need to bump the epoch, which could mean overflow.
    1. No overflow: Bump the epoch and return the current producerId with the bumped epoch
    will be bumped and the last
    1. . The last producerId/epoch will be set to empty.
    2. Overflow: Initialize a new producerId with epoch=0 and return it. The last producerId/epoch will be set to
    -1
    1. empty.
  2. Epoch and producerId are If producerId/epoch is provided, and the provided producerId matches the current producerId or the provided producerId matches the previous producerId and the provided epoch is exhausted:then the producer is re-initializing after a failure. There are three cases:
    1. The provided producerId/epoch matches the existing producerId/epoch, so we need to bump the epoch. As above, we may need to generate a new producer if there would be overflow bumping the epoch.
      1. No overflow: bump the epoch and return the current producerId with the bumped epoch. The last producerId/
    2. Provided epoch matches current epoch: the last
      1. epoch will be set to the
      current epoch, and the current epoch will be bumped .
      1. previous producerId/epoch.
      2. Overflow: generate a new producerId with epoch=0. The last producerId/epoch will be set to the old producerId/epoch.
    3. The provided producerId/epoch matches the last producerId/epoch. The current producerId/Provided epoch matches last epoch: the current epoch will be returned.
    4. Else : return INVALID_PRODUCER_EPOCH
    Otherwise,
    1. return INVALID_PRODUCER_EPOCH

Another case we want to handle is InvalidProducerIdMapping. This error occurs following expiration of the producerId. It's possible that another producerId has been installed in its place following expiration (if another producer instance has become active), or the mapping is empty. We can safely retry the InitProducerId with the logic in this KIP in order to detect which case it is:

...