[
https://issues.apache.org/jira/browse/KAFKA-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311995#comment-17311995
]
Guozhang Wang commented on KAFKA-12574:
---------------------------------------
Yeah I think in 3.0 we would not remove the old eos implementations, it's just
about how we want to deprecate the old configs in 3.0 to encourage people to
move to the new eos protocol. So far we have several options:
1. Just deprecate `eos`, and encourage people to go with `eos-beta`. Eventually
we would only have `eos-beta`
2. Similar to 1): we deprecate `eos` and `eos-beta`, and introduce a `eos-v2`
which is the same as `eos-beta`, and encourage people to go with `eos-v2`.
Eventually we would only have `eos-v2`. It is slightly better than 1) since
people usually do not like to stick with "beta" but rather "v2".
3. Similar to 2), except that we would rename `eos-v2` to `eos` after we remove
the old `eos`. It has cleaner name for first-time users but may confuse
existing users.
4. Very different to 1/2/3: we deprecate `eos-beta`, and introduce a
`eos-alpha`, and tell users if they upgrade to 3.0 and do not want to use the
new `eos`, switch to `eos-alpha`. We would later (3.1?) deprecate `eos-alpha`
and eventually only have `eos`. It has cleaner name but require a one-liner
code change for people who want to stay as-is when upgrading.
Personally I'm a bit leaning towards 4), since besides it would eventually end
up with just `eos`, with `eos-alpha` I personally feel it is probably even more
"persuasive" to let people move away from it than naming the new one as shiny
"v2" to let people move to it; its downsides, on the other side, the one-liner
change is indeed concerning, but I feel it is not a huge burden.
> Deprecate eos-alpha
> -------------------
>
> Key: KAFKA-12574
> URL: https://issues.apache.org/jira/browse/KAFKA-12574
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: A. Sophie Blee-Goldman
> Priority: Blocker
> Labels: needs-kip
> Fix For: 3.0.0
>
>
> In KIP-447 we introduced a new thread-producer which is capable of
> exactly-once semantics across multiple tasks. The new mode of EOS, called
> eos-beta, is intended to eventually be the preferred processing mode for EOS
> as it improves the performance and scaling of partitions/tasks. The only
> downside is that it requires brokers to be on version 2.5+ in order to
> understand the latest APIs that are necessary for this thread-producer.
> We should consider deprecating the eos-alpha config, ie
> StreamsConfig.EXACTLY_ONCE, to encourage new. & existing EOS users to migrate
> to the new-and-improved processing mode, and upgrade their brokers if
> necessary.
> Eventually we would like to be able to remove the eos-alpha code paths from
> Streams as this will help to simplify the logic and reduce the processing
> mode branching. But since this will break client-broker compatibility, and
> 2.5 is still a relatively recent version, we probably can't actually remove
> eos-alpha in the near future
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
