You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "John Roesler (JIRA)" <ji...@apache.org> on 2018/10/02 17:03:00 UTC

[jira] [Commented] (KAFKA-7393) Consider making suppression node names independent of topologically numbered names.

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

John Roesler commented on KAFKA-7393:
-------------------------------------

Note that for suppression in particular, the behavior is solely driven by config, so if we had a way to serialize the configuration to a string, we could uniquely identify a suppression node by its parent + its config. The downside is that if you change the suppression config, you'd need an application reset.

Another alternative is to allow naming the suppression operator via Suppressed#withName like Grouped and Materialized.

> Consider making suppression node names independent of topologically numbered names.
> -----------------------------------------------------------------------------------
>
>                 Key: KAFKA-7393
>                 URL: https://issues.apache.org/jira/browse/KAFKA-7393
>             Project: Kafka
>          Issue Type: Improvement
>          Components: streams
>            Reporter: John Roesler
>            Priority: Major
>
> See [https://github.com/apache/kafka/pull/5567#discussion_r214188984] (please keep the discussion on this Jira ticket).
> There is an opportunity to use a slightly different naming strategy for suppression nodes so that they can be moved around the topology without upsetting other nodes' names.
> The main downside is that it might be confusing to have a separate naming strategy for just this one kind of node.
> Then again, this could create important opportunities for topology-compatible optimizations.
>  
> At a higher design/implementation cost, but a lower ongoing complexity, we could consider this naming approach for all node types.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)