[ 
https://issues.apache.org/jira/browse/KAFKA-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313484#comment-17313484
 ] 

Matthias J. Sax commented on KAFKA-12574:
-----------------------------------------

I agree that "hot swapping" might be too aggressive.

About the naming question: it might be good to move off the "-beta" name sooner 
than later. Thus I would propose the following:
 * Deprecate `eos` and `eos-beta` in 3.0 and add `eos-v2` (as new name for 
"beta) – this should ensure that people understand that the new EOS is better
 * remove `eos` (config and impl) and `eos-beta` config (we know only have 
eos-v2 config)
 * Add `eos` back an 4.x and deprecate `eos-v2`
 * Remove `eos-v2` in 5.0

{quote}Regarding the eos-alpha to eos-beta upgrade path, I agree we should well 
document the upgrade path 
{quote}
This is well documented in 
[https://kafka.apache.org/27/documentation/streams/upgrade-guide]
{noformat}
Starting in Kafka Streams 2.6.x, a new processing mode "exactly_once_beta" 
(configurable via parameter processing.guarantee) is available. To use this new 
feature, your brokers must be on version 2.5.x or newer. A switch from 
"exactly_once" to "exactly_once_beta" (or the other way around) is only 
possible if the application is on version 2.6.x. If you want to upgrade your 
application from an older version and enable this feature, you first need to 
upgrade your application to version 2.6.x, staying on "exactly_once", and then 
do second round of rolling bounces to switch to "exactly_once_beta". For a 
downgrade, do the reverse: first switch the config from "exactly_once_beta" to 
"exactly_once" to disable the feature in your 2.6.x application. Afterward, you 
can downgrade your application to a pre-2.6.x version.
{noformat}
{quote}Besides, when checking on the upgrade test paths, I think our system 
tests do not have a case to cover the eos -> eos-beta upgrade path 
{quote}
Correct. Because we test this with `EosBetaUpgradeIntegrationTest` – we don't 
need a system test because the upgrade from alpha to beta happens in the same 
version.

 

> 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)

Reply via email to