mjsax commented on a change in pull request #8864:
URL: https://github.com/apache/kafka/pull/8864#discussion_r458266432
##########
File path:
connect/runtime/src/main/java/org/apache/kafka/connect/storage/KafkaStatusBackingStore.java
##########
@@ -148,6 +148,7 @@ public KafkaStatusBackingStore(Time time, Converter
converter) {
this.statusTopic = statusTopic;
}
+ @SuppressWarnings("deprecation")
Review comment:
Btw: @hachikuji raise a concern about this issue, too:
https://github.com/apache/kafka/pull/8864#pullrequestreview-443424531
> I just had one question about the proposal. Using retries=0 in the
producer allows the user to have "at-most-once" delivery. This allows the
application to implement its own retry logic for example. Do we still have a
way to do this once this configuration is gone?
So maybe we need to do some follow up work in the `Producer` to make it work
for Connect. But I would defer this to the follow up work.
My original though was, that setting `max.deliver.timeout.ms := request
.timeout.ms` might prevent internal retries. But we need to verify this. It was
also brought to my attention, that this might not work if the network
disconnects -- only `retries=0` would prevent to re-open the connection but a
low timeout would not prevent retries.
In KIP-572, we proposed for Kafka Streams itself, to treat `task.timeout.ms
= 0` as "no retries" -- maybe we can do a similar thing for the producer?
There is also `max.block.ms` that we should consider. Unfortunately, I am
not an expert on the `Producer`. But I would like to move forward with KIP-572
for now and are happy to help to resolve those questions.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
