...
To solve this problem, we propose introducing a new idempotence mode in 1.0.0, ie. enable.idempotence=requested
. The other modes would be enable.idempotence=off
and enable.idempotence=required.
In the safe
requested
mode, idempotence would be best effort, ie. you get it if the broker supports it, otherwise no error is raised. In required
mode, requests would fail if the broker did not support idempotence. In off
mode, there is no idempotence (similar to the false
value today).
The new enable.idempotence=requested
mode would be introduced in the 1.0.0 release. In addition, the 1.0.0 broker will automatically downgrade messages sent in 'requested' mode from the 0.11.0 message format if the topic being written to is configured to use an older message format versionclient will disable idempotence if the message format of the destination topic doesn't support it.. In required mode, the broker would client will raise an error if it detects an incompatible message format.
This means we would need to upgrade the ProduceRequest
version the TopicMetadata
in the MetadataResponse version to include the idempotent producer mode.. One potential downside here is the extra work to convert messages when the format of the client and broker is mismatchedversion of the message format for the topic in question.
Additionally, if a 1.0.0 client with enable.idempotence=requested
is writing to an 0.11.0 broker, idempotence will be disabled.
...