[
https://issues.apache.org/jira/browse/FLINK-9295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477855#comment-16477855
]
ASF GitHub Bot commented on FLINK-9295:
---------------------------------------
Github user StephanEwen commented on a diff in the pull request:
https://github.com/apache/flink/pull/5977#discussion_r188725700
--- Diff:
flink-core/src/main/java/org/apache/flink/api/common/functions/RuntimeContext.java
---
@@ -71,6 +71,17 @@
@PublicEvolving
MetricGroup getMetricGroup();
+ /**
+ * Returned value is guaranteed to be unique between operators within
the same job and to be
+ * stable and the same across job submissions.
+ *
+ * <p>This operation is currently only supported in Streaming
(DataStream) contexts.
+ *
+ * @return String representation of the operator's unique id.
+ */
+ @PublicEvolving
+ String getOperatorUniqueID();
--- End diff --
I am still much in favor of not exposing this in the RuntimeContext:
- Having the state accesses in the RuntimeContext was a necessity of that
moment, because there was no `initializeState()` and it is crucial to be
exposed to users.
- This operatorID is not crucial to be exposed to users, hence a very
different case to me.
- It is super easy to expose it later, it is much harder (even if marked
as PublicEvolving) to hide it later. For a quick move, not exposing an addition
publicly should always be the default choice, also beyond this specific case
here.
> FlinkKafkaProducer011 sometimes throws ProducerFencedExceptions when in
> EXACTLY_ONCE mode
> -----------------------------------------------------------------------------------------
>
> Key: FLINK-9295
> URL: https://issues.apache.org/jira/browse/FLINK-9295
> Project: Flink
> Issue Type: Bug
> Components: Kafka Connector
> Affects Versions: 1.4.2
> Reporter: Christopher Ng
> Assignee: Piotr Nowojski
> Priority: Major
> Fix For: 1.5.0
>
>
> {{FlinkKafkaProducer011}} can throw {{ProducerFencedExceptions}} if multiple
> sinks are used within the same sub-task. This can happen when
> operator-chaining results in two different sinks in the same topology being
> chained into a task, and thus into each of its sub-tasks.
> The problem is that {{TransactionIdsGenerator}} only takes into account the
> task name, the subtask index, the number of subtasks, and a couple of other
> things. All the attributes are the same between different
> {{FlinkKafkaProducer011s}} within the same sub-task, so they get the same
> transaction ids and one of them ends up failing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
