[jira] [Created] (FLINK-23521) flinksql
didiaode18 created FLINK-23521: -- Summary: flinksql Key: FLINK-23521 URL: https://issues.apache.org/jira/browse/FLINK-23521 Project: Flink Issue Type: Improvement Components: API / Scala Affects Versions: 1.11.2 Reporter: didiaode18 When I look at Webui, I find that the code table related part of my program does exist with the status of finished.How can I handle it to get checkpoint back to normal? please. thanx the same as [https://stackoverflow.com/questions/68004194/flink-sql-is-not-in-state-running-but-finished-instead-aborting-checkpoint] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23520) Improve StateFun <-> DataStream Interop
Seth Wiesman created FLINK-23520: Summary: Improve StateFun <-> DataStream Interop Key: FLINK-23520 URL: https://issues.apache.org/jira/browse/FLINK-23520 Project: Flink Issue Type: Improvement Components: Stateful Functions Reporter: Seth Wiesman Assignee: Seth Wiesman Improve Stateful Functions <-> DataStream interop to improve usable with remote functions. In particular: * Automatic type conversion between JVM primitives and remote type system * Plugable types for use with complex class * Hide internal classes like TypedValue * Support all endpoint configuration including wildcards and URL path templating -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Unable to read state Witten by Beam application with Flink runner using Flink's State Processor API
Hi Sandeep, In general I'd say it will be tricky to read Beam state this way as it doesn't use Flink primitives, but it's writing state in custom binary format (it can be de-serialized, but it's not easy to put all of the pieces together). Can you please share an example code of how you're reading the state? Also can please you try this with latest Beam / Flink versions (the ones you're using are no longer supported)? Best, D. On Tue, Jul 27, 2021 at 5:46 PM Kathula, Sandeep wrote: > Hi, > We have a simple Beam application like a work count running with > Flink runner (Beam 2.26 and Flink 1.9). We are using Beam’s value state. I > am trying to read the state from savepoint using Flink's State Processor > API but getting a NullPointerException. Converted the whole code into Pure > Flink application, created a savepoint and tried to read the state where we > are able to read the state successfully. > > Exception Stack trace: > > Exception in thread "main" > org.apache.flink.runtime.client.JobExecutionException: Job execution failed. > at > org.apache.flink.runtime.jobmaster.JobResult.toJobExecutionResult(JobResult.java:147) > at > org.apache.flink.runtime.minicluster.MiniCluster.executeJobBlocking(MiniCluster.java:631) > at > org.apache.flink.client.LocalExecutor.executePlan(LocalExecutor.java:222) > at > org.apache.flink.api.java.LocalEnvironment.execute(LocalEnvironment.java:91) > at > org.apache.flink.api.java.ExecutionEnvironment.execute(ExecutionEnvironment.java:820) > at > org.apache.flink.api.java.DataSet.count(DataSet.java:398) > at > com.intuit.spp.example.StateReader.main(StateReader.java:34) > Caused by: java.io.IOException: Failed to restore state backend > at > org.apache.flink.state.api.input.KeyedStateInputFormat.getStreamOperatorStateContext(KeyedStateInputFormat.java:231) > at > org.apache.flink.state.api.input.KeyedStateInputFormat.open(KeyedStateInputFormat.java:177) > at > org.apache.flink.state.api.input.KeyedStateInputFormat.open(KeyedStateInputFormat.java:79) > at > org.apache.flink.runtime.operators.DataSourceTask.invoke(DataSourceTask.java:173) > at > org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:705) > at > org.apache.flink.runtime.taskmanager.Task.run(Task.java:530) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.Exception: Exception while creating > StreamOperatorStateContext. > at > org.apache.flink.streaming.api.operators.StreamTaskStateInitializerImpl.streamOperatorStateContext(StreamTaskStateInitializerImpl.java:195) > at > org.apache.flink.state.api.input.KeyedStateInputFormat.getStreamOperatorStateContext(KeyedStateInputFormat.java:223) > ... 6 more > Caused by: org.apache.flink.util.FlinkException: Could not restore keyed > state backend for > f25cb861abbd020d3595d47c5d53d3fd_f25cb861abbd020d3595d47c5d53d3fd_(1/1) > from any of the 1 provided restore options. > at > org.apache.flink.streaming.api.operators.BackendRestorerProcedure.createAndRestore(BackendRestorerProcedure.java:135) > at > org.apache.flink.streaming.api.operators.StreamTaskStateInitializerImpl.keyedStatedBackend(StreamTaskStateInitializerImpl.java:307) > at > org.apache.flink.streaming.api.operators.StreamTaskStateInitializerImpl.streamOperatorStateContext(StreamTaskStateInitializerImpl.java:135) > ... 7 more > Caused by: org.apache.flink.runtime.state.BackendBuildingException: Failed > when trying to restore heap backend > at > org.apache.flink.runtime.state.heap.HeapKeyedStateBackendBuilder.build(HeapKeyedStateBackendBuilder.java:116) > at > org.apache.flink.runtime.state.memory.MemoryStateBackend.createKeyedStateBackend(MemoryStateBackend.java:347) > at > org.apache.flink.streaming.api.operators.StreamTaskStateInitializerImpl.lambda$keyedStatedBackend$1(StreamTaskStateInitializerImpl.java:291) > at > org.apache.flink.streaming.api.operators.BackendRestorerProcedure.attemptCreateAndRestore(BackendRestorerProcedure.java:142) > at > org.apache.flink.streaming.api.operators.BackendRestorerProcedure.createAndRestore(BackendRestorerProcedure.java:121) > ... 9 more > Caused by: java.lang.NullPointerException > at > org.apache.flink.runtime.state.heap.HeapRestoreOperation.readKeyGroupStateData(HeapRestoreOperation.java:280) > at > org.apache.flink.runtime.state.heap.HeapRestoreOperation.readStateHandleStateData(HeapRestoreOperation.java:254) > at > org.apache.flink.runtime.state.heap.HeapRestoreOperation.restore(HeapRestoreOperation.java:154) > at >
[jira] [Created] (FLINK-23519) Aggregate State Backend Latency by State Level
Mason Chen created FLINK-23519: -- Summary: Aggregate State Backend Latency by State Level Key: FLINK-23519 URL: https://issues.apache.org/jira/browse/FLINK-23519 Project: Flink Issue Type: Improvement Components: Runtime / Metrics, Runtime / State Backends Affects Versions: 1.13.0 Reporter: Mason Chen To make metrics aggregation easier, there should be a config to expose something like `state.backend.rocksdb.metrics.column-family-as-variable` that rocksdb provides to do aggregation across column families ([https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/deployment/config/#state-backend-rocksdb-metrics-column-family-as-variable]). In this case of state backend latency, the variable exposed would be state level instead column family. This makes it easier to aggregate by the various state levels that are reported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Unable to read state Witten by Beam application with Flink runner using Flink's State Processor API
Hi, We have a simple Beam application like a work count running with Flink runner (Beam 2.26 and Flink 1.9). We are using Beam’s value state. I am trying to read the state from savepoint using Flink's State Processor API but getting a NullPointerException. Converted the whole code into Pure Flink application, created a savepoint and tried to read the state where we are able to read the state successfully. Exception Stack trace: Exception in thread "main" org.apache.flink.runtime.client.JobExecutionException: Job execution failed. at org.apache.flink.runtime.jobmaster.JobResult.toJobExecutionResult(JobResult.java:147) at org.apache.flink.runtime.minicluster.MiniCluster.executeJobBlocking(MiniCluster.java:631) at org.apache.flink.client.LocalExecutor.executePlan(LocalExecutor.java:222) at org.apache.flink.api.java.LocalEnvironment.execute(LocalEnvironment.java:91) at org.apache.flink.api.java.ExecutionEnvironment.execute(ExecutionEnvironment.java:820) at org.apache.flink.api.java.DataSet.count(DataSet.java:398) at com.intuit.spp.example.StateReader.main(StateReader.java:34) Caused by: java.io.IOException: Failed to restore state backend at org.apache.flink.state.api.input.KeyedStateInputFormat.getStreamOperatorStateContext(KeyedStateInputFormat.java:231) at org.apache.flink.state.api.input.KeyedStateInputFormat.open(KeyedStateInputFormat.java:177) at org.apache.flink.state.api.input.KeyedStateInputFormat.open(KeyedStateInputFormat.java:79) at org.apache.flink.runtime.operators.DataSourceTask.invoke(DataSourceTask.java:173) at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:705) at org.apache.flink.runtime.taskmanager.Task.run(Task.java:530) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.Exception: Exception while creating StreamOperatorStateContext. at org.apache.flink.streaming.api.operators.StreamTaskStateInitializerImpl.streamOperatorStateContext(StreamTaskStateInitializerImpl.java:195) at org.apache.flink.state.api.input.KeyedStateInputFormat.getStreamOperatorStateContext(KeyedStateInputFormat.java:223) ... 6 more Caused by: org.apache.flink.util.FlinkException: Could not restore keyed state backend for f25cb861abbd020d3595d47c5d53d3fd_f25cb861abbd020d3595d47c5d53d3fd_(1/1) from any of the 1 provided restore options. at org.apache.flink.streaming.api.operators.BackendRestorerProcedure.createAndRestore(BackendRestorerProcedure.java:135) at org.apache.flink.streaming.api.operators.StreamTaskStateInitializerImpl.keyedStatedBackend(StreamTaskStateInitializerImpl.java:307) at org.apache.flink.streaming.api.operators.StreamTaskStateInitializerImpl.streamOperatorStateContext(StreamTaskStateInitializerImpl.java:135) ... 7 more Caused by: org.apache.flink.runtime.state.BackendBuildingException: Failed when trying to restore heap backend at org.apache.flink.runtime.state.heap.HeapKeyedStateBackendBuilder.build(HeapKeyedStateBackendBuilder.java:116) at org.apache.flink.runtime.state.memory.MemoryStateBackend.createKeyedStateBackend(MemoryStateBackend.java:347) at org.apache.flink.streaming.api.operators.StreamTaskStateInitializerImpl.lambda$keyedStatedBackend$1(StreamTaskStateInitializerImpl.java:291) at org.apache.flink.streaming.api.operators.BackendRestorerProcedure.attemptCreateAndRestore(BackendRestorerProcedure.java:142) at org.apache.flink.streaming.api.operators.BackendRestorerProcedure.createAndRestore(BackendRestorerProcedure.java:121) ... 9 more Caused by: java.lang.NullPointerException at org.apache.flink.runtime.state.heap.HeapRestoreOperation.readKeyGroupStateData(HeapRestoreOperation.java:280) at org.apache.flink.runtime.state.heap.HeapRestoreOperation.readStateHandleStateData(HeapRestoreOperation.java:254) at org.apache.flink.runtime.state.heap.HeapRestoreOperation.restore(HeapRestoreOperation.java:154) at org.apache.flink.runtime.state.heap.HeapKeyedStateBackendBuilder.build(HeapKeyedStateBackendBuilder.java:114) ... 13 more When I debugged, it is showing that it is throwing NullPointerException at https://github.com/apache/flink/blob/release-1.9/flink-runtime/src/main/java/org/apache/flink/runtime/state/heap/HeapRestoreOperation.java#L280 metaInfoSnapshot is null. I then checked what all kvStateId values we are getting at https://github.com/apache/flink/blob/release-1.9/flink-runtime/src/main/java/org/apache/flink/runtime/state/heap/HeapRestoreOperation.java#L277. I also did stateMetaInfoSnapshot.getName()
[jira] [Created] (FLINK-23518) ZooKeeperLeaderElectionConnectionHandlingTest hangs on Azure
Dawid Wysakowicz created FLINK-23518:
Summary: ZooKeeperLeaderElectionConnectionHandlingTest hangs on
Azure
Key: FLINK-23518
URL: https://issues.apache.org/jira/browse/FLINK-23518
Project: Flink
Issue Type: Bug
Components: Runtime / Coordination
Affects Versions: 1.14.0
Reporter: Dawid Wysakowicz
https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=20964=logs=0da23115-68bb-5dcd-192c-bd4c8adebde1=24c3384f-1bcb-57b3-224f-51bf973bbee8=9511
{code}
Jul 26 11:05:26 "main" #1 prio=5 os_prio=0 tid=0x7efd7000b800 nid=0x1769
waiting on condition [0x7efd771ea000]
Jul 26 11:05:26java.lang.Thread.State: WAITING (parking)
Jul 26 11:05:26 at sun.misc.Unsafe.park(Native Method)
Jul 26 11:05:26 - parking to wait for <0x86681f00> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
Jul 26 11:05:26 at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
Jul 26 11:05:26 at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
Jul 26 11:05:26 at
java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:403)
Jul 26 11:05:26 at
org.apache.flink.runtime.leaderelection.ZooKeeperLeaderElectionConnectionHandlingTest$QueueLeaderElectionListener.next(ZooKeeperLeaderElectionConnectionHandlingTest.java:324)
Jul 26 11:05:26 at
org.apache.flink.runtime.leaderelection.ZooKeeperLeaderElectionConnectionHandlingTest$QueueLeaderElectionListener.next(ZooKeeperLeaderElectionConnectionHandlingTest.java:318)
Jul 26 11:05:26 at
org.apache.flink.runtime.leaderelection.ZooKeeperLeaderElectionConnectionHandlingTest.testConnectionSuspendedHandlingDuringInitialization(ZooKeeperLeaderElectionConnectionHandlingTest.java:114)
Jul 26 11:05:26 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
Jul 26 11:05:26 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
Jul 26 11:05:26 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Jul 26 11:05:26 at java.lang.reflect.Method.invoke(Method.java:498)
Jul 26 11:05:26 at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
Jul 26 11:05:26 at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
Jul 26 11:05:26 at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
Jul 26 11:05:26 at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
Jul 26 11:05:26 at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
Jul 26 11:05:26 at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
Jul 26 11:05:26 at
org.apache.flink.util.TestNameProvider$1.evaluate(TestNameProvider.java:45)
Jul 26 11:05:26 at
org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
Jul 26 11:05:26 at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
Jul 26 11:05:26 at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
Jul 26 11:05:26 at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
Jul 26 11:05:26 at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
Jul 26 11:05:26 at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
Jul 26 11:05:26 at
org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
Jul 26 11:05:26 at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
Jul 26 11:05:26 at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
Jul 26 11:05:26 at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
Jul 26 11:05:26 at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
Jul 26 11:05:26 at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
Jul 26 11:05:26 at
org.junit.runners.ParentRunner.run(ParentRunner.java:413)
Jul 26 11:05:26 at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
Jul 26 11:05:26 at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
Jul 26 11:05:26 at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
Jul 26 11:05:26 at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Jul 26 11:05:26 at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
Jul 26 11:05:26 at
Re: [DISCUSS] Change Default Jira Priority from "Major" to "Minor"
Hi, I would introduce a new priority between Major and Minor. I think there's still value for having a Minor priority, especially for tickets where something is being reported but there's a workable workaround available. With regards to Yun's comment, I think that's a follow-up question on what to do with tickets that are already in the system that are registered as "Major". There are currently 4 Blockers, 29 Critical, 938 Major, 2340 Minor and 0 Not a Priority open tickets. I don't think there's a bulk rule that can be applied to, for example, move all Major to a Normal state. I do think this will balance itself out over time if you would introduce "Normal" as a new default priority and the ones who can change Jira tickets also check if the right priority is set whenever they work on a ticket. Best regards, Martijn On Tue, 27 Jul 2021 at 12:40, Yun Tang wrote: > Hi Konstantin, > > How about rename "Major" to "Normal"? We already have higher critical and > blocker priorities, and I personally usually treat current "major" as > "normal" priority. > > Best, > Yun Tang > > From: Konstantin Knauf > Sent: Tuesday, July 27, 2021 18:03 > To: dev > Subject: Re: [DISCUSS] Change Default Jira Priority from "Major" to "Minor" > > Quick Question to Martijn, Jingsong: do you propose to rename "Minor" to > "Normal" or would you like to introduce a new priority between Major and > Minor? > > On Tue, Jul 27, 2021 at 11:44 AM Jingsong Li > wrote: > > > I agree with Martijn. > > > > My problem is just minor, which will make me a little disappointed. > > > > Best, > > Jingsong > > > > > > On Tue, Jul 27, 2021 at 5:32 PM Martijn Visser > > wrote: > > > > > Hi, > > > > > > I personally would prefer to use "Normal" as a default priority > because I > > > think a lot of people's first reaction is that their reported problem > is > > > bigger than a minor loss of function [1], resulting in them choosing > the > > > next priority which is currently "Major". > > > > > > Best regards, > > > > > > Martijn > > > > > > [1] > > > > > > > > > https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels > > > > > > On Mon, 26 Jul 2021 at 11:54, Caizhi Weng > wrote: > > > > > > > Hi Konstantin! > > > > > > > > Thanks for raising this up. From my point of view it is a reasonable > > > > change. But I think it would be better to handle different types of > > > tickets > > > > respectively. For example, for bugs a default major seems to be > better, > > > > while for others the default shall be minor. > > > > > > > > Konstantin Knauf 于2021年7月26日周一 下午3:35写道： > > > > > > > > > Hi everyone, > > > > > > > > > > In [1] I proposed to change the default priority of our Jira > project > > to > > > > > "Minor". Most tickets are opened with the default priority. > Arguably > > > the > > > > > majority of these tickets fall into the "Minor" category instead of > > > > "Major" > > > > > according to the definition in [3] (and the implementation of the > > Jira > > > > bot > > > > > [2]). Specifically, tickets in "Minor" stay untouched by the Jira > bot > > > > much > > > > > longer than tickets in "Major". > > > > > > > > > > Since this is affecting every new ticket, I would like to collect a > > bit > > > > > more feedback. So, what do you think? > > > > > > > > > > Thanks, > > > > > > > > > > Konstantin > > > > > > > > > > [1] > https://lists.apache.org/x/list.html?dev@flink.apache.org:lte=1M > > : > > > > > [2] https://github.com/apache/flink-jira-bot > > > > > [3] > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process#FlinkJiraProcess-TicketsPriorities > > > > > > > > > > -- > > > > > > > > > > Konstantin Knauf > > > > > > > > > > https://twitter.com/snntrable > > > > > > > > > > https://github.com/knaufk > > > > > > > > > > > > > > > > > > -- > > Best, Jingsong Lee > > > > > -- > > Konstantin Knauf > > https://twitter.com/snntrable > > https://github.com/knaufk >
Re: [DISCUSS] Change Default Jira Priority from "Major" to "Minor"
Hi Konstantin, How about rename "Major" to "Normal"? We already have higher critical and blocker priorities, and I personally usually treat current "major" as "normal" priority. Best, Yun Tang From: Konstantin Knauf Sent: Tuesday, July 27, 2021 18:03 To: dev Subject: Re: [DISCUSS] Change Default Jira Priority from "Major" to "Minor" Quick Question to Martijn, Jingsong: do you propose to rename "Minor" to "Normal" or would you like to introduce a new priority between Major and Minor? On Tue, Jul 27, 2021 at 11:44 AM Jingsong Li wrote: > I agree with Martijn. > > My problem is just minor, which will make me a little disappointed. > > Best, > Jingsong > > > On Tue, Jul 27, 2021 at 5:32 PM Martijn Visser > wrote: > > > Hi, > > > > I personally would prefer to use "Normal" as a default priority because I > > think a lot of people's first reaction is that their reported problem is > > bigger than a minor loss of function [1], resulting in them choosing the > > next priority which is currently "Major". > > > > Best regards, > > > > Martijn > > > > [1] > > > > > https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels > > > > On Mon, 26 Jul 2021 at 11:54, Caizhi Weng wrote: > > > > > Hi Konstantin! > > > > > > Thanks for raising this up. From my point of view it is a reasonable > > > change. But I think it would be better to handle different types of > > tickets > > > respectively. For example, for bugs a default major seems to be better, > > > while for others the default shall be minor. > > > > > > Konstantin Knauf 于2021年7月26日周一 下午3:35写道： > > > > > > > Hi everyone, > > > > > > > > In [1] I proposed to change the default priority of our Jira project > to > > > > "Minor". Most tickets are opened with the default priority. Arguably > > the > > > > majority of these tickets fall into the "Minor" category instead of > > > "Major" > > > > according to the definition in [3] (and the implementation of the > Jira > > > bot > > > > [2]). Specifically, tickets in "Minor" stay untouched by the Jira bot > > > much > > > > longer than tickets in "Major". > > > > > > > > Since this is affecting every new ticket, I would like to collect a > bit > > > > more feedback. So, what do you think? > > > > > > > > Thanks, > > > > > > > > Konstantin > > > > > > > > [1] https://lists.apache.org/x/list.html?dev@flink.apache.org:lte=1M > : > > > > [2] https://github.com/apache/flink-jira-bot > > > > [3] > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process#FlinkJiraProcess-TicketsPriorities > > > > > > > > -- > > > > > > > > Konstantin Knauf > > > > > > > > https://twitter.com/snntrable > > > > > > > > https://github.com/knaufk > > > > > > > > > > > > -- > Best, Jingsong Lee > -- Konstantin Knauf https://twitter.com/snntrable https://github.com/knaufk
Re: [DISCUSS] Change Default Jira Priority from "Major" to "Minor"
Quick Question to Martijn, Jingsong: do you propose to rename "Minor" to "Normal" or would you like to introduce a new priority between Major and Minor? On Tue, Jul 27, 2021 at 11:44 AM Jingsong Li wrote: > I agree with Martijn. > > My problem is just minor, which will make me a little disappointed. > > Best, > Jingsong > > > On Tue, Jul 27, 2021 at 5:32 PM Martijn Visser > wrote: > > > Hi, > > > > I personally would prefer to use "Normal" as a default priority because I > > think a lot of people's first reaction is that their reported problem is > > bigger than a minor loss of function [1], resulting in them choosing the > > next priority which is currently "Major". > > > > Best regards, > > > > Martijn > > > > [1] > > > > > https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels > > > > On Mon, 26 Jul 2021 at 11:54, Caizhi Weng wrote: > > > > > Hi Konstantin! > > > > > > Thanks for raising this up. From my point of view it is a reasonable > > > change. But I think it would be better to handle different types of > > tickets > > > respectively. For example, for bugs a default major seems to be better, > > > while for others the default shall be minor. > > > > > > Konstantin Knauf 于2021年7月26日周一 下午3:35写道： > > > > > > > Hi everyone, > > > > > > > > In [1] I proposed to change the default priority of our Jira project > to > > > > "Minor". Most tickets are opened with the default priority. Arguably > > the > > > > majority of these tickets fall into the "Minor" category instead of > > > "Major" > > > > according to the definition in [3] (and the implementation of the > Jira > > > bot > > > > [2]). Specifically, tickets in "Minor" stay untouched by the Jira bot > > > much > > > > longer than tickets in "Major". > > > > > > > > Since this is affecting every new ticket, I would like to collect a > bit > > > > more feedback. So, what do you think? > > > > > > > > Thanks, > > > > > > > > Konstantin > > > > > > > > [1] https://lists.apache.org/x/list.html?dev@flink.apache.org:lte=1M > : > > > > [2] https://github.com/apache/flink-jira-bot > > > > [3] > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process#FlinkJiraProcess-TicketsPriorities > > > > > > > > -- > > > > > > > > Konstantin Knauf > > > > > > > > https://twitter.com/snntrable > > > > > > > > https://github.com/knaufk > > > > > > > > > > > > -- > Best, Jingsong Lee > -- Konstantin Knauf https://twitter.com/snntrable https://github.com/knaufk
[jira] [Created] (FLINK-23517) Add messages to bannedDependencies enforcer rules
Chesnay Schepler created FLINK-23517: Summary: Add messages to bannedDependencies enforcer rules Key: FLINK-23517 URL: https://issues.apache.org/jira/browse/FLINK-23517 Project: Flink Issue Type: Improvement Components: Build System Reporter: Chesnay Schepler Assignee: Chesnay Schepler Fix For: 1.14.0 Add messages to all bannedDependencies rules to properly inform developers about the problem and ways to mitigate it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Change Default Jira Priority from "Major" to "Minor"
I agree with Martijn. My problem is just minor, which will make me a little disappointed. Best, Jingsong On Tue, Jul 27, 2021 at 5:32 PM Martijn Visser wrote: > Hi, > > I personally would prefer to use "Normal" as a default priority because I > think a lot of people's first reaction is that their reported problem is > bigger than a minor loss of function [1], resulting in them choosing the > next priority which is currently "Major". > > Best regards, > > Martijn > > [1] > > https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels > > On Mon, 26 Jul 2021 at 11:54, Caizhi Weng wrote: > > > Hi Konstantin! > > > > Thanks for raising this up. From my point of view it is a reasonable > > change. But I think it would be better to handle different types of > tickets > > respectively. For example, for bugs a default major seems to be better, > > while for others the default shall be minor. > > > > Konstantin Knauf 于2021年7月26日周一 下午3:35写道： > > > > > Hi everyone, > > > > > > In [1] I proposed to change the default priority of our Jira project to > > > "Minor". Most tickets are opened with the default priority. Arguably > the > > > majority of these tickets fall into the "Minor" category instead of > > "Major" > > > according to the definition in [3] (and the implementation of the Jira > > bot > > > [2]). Specifically, tickets in "Minor" stay untouched by the Jira bot > > much > > > longer than tickets in "Major". > > > > > > Since this is affecting every new ticket, I would like to collect a bit > > > more feedback. So, what do you think? > > > > > > Thanks, > > > > > > Konstantin > > > > > > [1] https://lists.apache.org/x/list.html?dev@flink.apache.org:lte=1M: > > > [2] https://github.com/apache/flink-jira-bot > > > [3] > > > > > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process#FlinkJiraProcess-TicketsPriorities > > > > > > -- > > > > > > Konstantin Knauf > > > > > > https://twitter.com/snntrable > > > > > > https://github.com/knaufk > > > > > > -- Best, Jingsong Lee
Re: [DISCUSS] Change Default Jira Priority from "Major" to "Minor"
Hi, I personally would prefer to use "Normal" as a default priority because I think a lot of people's first reaction is that their reported problem is bigger than a minor loss of function [1], resulting in them choosing the next priority which is currently "Major". Best regards, Martijn [1] https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels On Mon, 26 Jul 2021 at 11:54, Caizhi Weng wrote: > Hi Konstantin! > > Thanks for raising this up. From my point of view it is a reasonable > change. But I think it would be better to handle different types of tickets > respectively. For example, for bugs a default major seems to be better, > while for others the default shall be minor. > > Konstantin Knauf 于2021年7月26日周一 下午3:35写道： > > > Hi everyone, > > > > In [1] I proposed to change the default priority of our Jira project to > > "Minor". Most tickets are opened with the default priority. Arguably the > > majority of these tickets fall into the "Minor" category instead of > "Major" > > according to the definition in [3] (and the implementation of the Jira > bot > > [2]). Specifically, tickets in "Minor" stay untouched by the Jira bot > much > > longer than tickets in "Major". > > > > Since this is affecting every new ticket, I would like to collect a bit > > more feedback. So, what do you think? > > > > Thanks, > > > > Konstantin > > > > [1] https://lists.apache.org/x/list.html?dev@flink.apache.org:lte=1M: > > [2] https://github.com/apache/flink-jira-bot > > [3] > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process#FlinkJiraProcess-TicketsPriorities > > > > -- > > > > Konstantin Knauf > > > > https://twitter.com/snntrable > > > > https://github.com/knaufk > > >
[jira] [Created] (FLINK-23516) I try to specify savepoint dir in my app. However, the startup task reports an error, java.lang.unsupported operationexception: the configuration is unmodifiable; its co
李伟高 created FLINK-23516:
---
Summary: I try to specify savepoint dir in my app. However, the
startup task reports an error, java.lang.unsupported operationexception: the
configuration is unmodifiable; its contents cannot be changed.
Key: FLINK-23516
URL: https://issues.apache.org/jira/browse/FLINK-23516
Project: Flink
Issue Type: Bug
Components: API / State Processor
Affects Versions: 1.13.1
Environment: Flink Version :1.13.1
Standalone Cluster
Reporter: 李伟高
The directory where savepoint is configured in my application
{code:java}
String savepointDir;
if (Strings.isNotBlank(savepointDir =
parameterTool.get("system.savepoint.dir"))) {
env.setDefaultSavepointDirectory(savepointDir);
}
{code}
Where `system.savepoint.dir` is not empty.
When I submit an application to my standalone cluster, an error is prompted:
{code:java}
2021-07-27 16:26:34.029 [travel_spilt -> (Sink: sink_es_insert, Sink:
sink_es_update) (1/1)#31] WARN org.apache.flink.runtime.taskmanager.Task -
travel_spilt -> (Sink: sink_es_insert, Sink: sink_es_update) (1/1)#31
(1f33925046e04307ba6beb3959d2cad5) switched from DEPLOYING to FAILED with
failure cause: java.lang.UnsupportedOperationException: The configuration is
unmodifiable; its contents cannot be changed.2021-07-27 16:26:34.029
[travel_spilt -> (Sink: sink_es_insert, Sink: sink_es_update) (1/1)#31] WARN
org.apache.flink.runtime.taskmanager.Task - travel_spilt -> (Sink:
sink_es_insert, Sink: sink_es_update) (1/1)#31
(1f33925046e04307ba6beb3959d2cad5) switched from DEPLOYING to FAILED with
failure cause: java.lang.UnsupportedOperationException: The configuration is
unmodifiable; its contents cannot be changed. at
org.apache.flink.configuration.UnmodifiableConfiguration.error(UnmodifiableConfiguration.java:73)
at
org.apache.flink.configuration.UnmodifiableConfiguration.setValueInternal(UnmodifiableConfiguration.java:63)
at org.apache.flink.configuration.Configuration.set(Configuration.java:709) at
org.apache.flink.runtime.state.CheckpointStorageLoader.load(CheckpointStorageLoader.java:174)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.createCheckpointStorage(StreamTask.java:1231)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:337)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:308)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:281)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:273)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:263)
at
org.apache.flink.streaming.runtime.tasks.OneInputStreamTask.(OneInputStreamTask.java:65)
at sun.reflect.GeneratedConstructorAccessor339.newInstance(Unknown Source) at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at
org.apache.flink.runtime.taskmanager.Task.loadAndInstantiateInvokable(Task.java:1524)
at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:730) at
org.apache.flink.runtime.taskmanager.Task.run(Task.java:566) at
java.lang.Thread.run(Thread.java:748)
{code}
Every stateful operator has this error.What do I need to do? I looked at other
versions and didn't find the method Unmodifiable configuration#setvalueinternal
(string key, t value).
Looking forward to your reply, thank you.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-23515) I try to specify savepoint dir in my app. However, the startup task reports an error, java.lang.unsupported operationexception: the configuration is unmodifiable; its co
李伟高 created FLINK-23515:
---
Summary: I try to specify savepoint dir in my app. However, the
startup task reports an error, java.lang.unsupported operationexception: the
configuration is unmodifiable; its contents cannot be changed.
Key: FLINK-23515
URL: https://issues.apache.org/jira/browse/FLINK-23515
Project: Flink
Issue Type: Bug
Components: API / State Processor
Affects Versions: 1.13.1
Environment: Flink Version :1.13.1
Standalone Cluster
Reporter: 李伟高
The directory where savepoint is configured in my application
{code:java}
String savepointDir;
if (Strings.isNotBlank(savepointDir =
parameterTool.get("system.savepoint.dir"))) {
env.setDefaultSavepointDirectory(savepointDir);
}
{code}
Where `system.savepoint.dir` is not empty.
When I submit an application to my standalone cluster, an error is prompted:
{code:java}
2021-07-27 16:26:34.029 [travel_spilt -> (Sink: sink_es_insert, Sink:
sink_es_update) (1/1)#31] WARN org.apache.flink.runtime.taskmanager.Task -
travel_spilt -> (Sink: sink_es_insert, Sink: sink_es_update) (1/1)#31
(1f33925046e04307ba6beb3959d2cad5) switched from DEPLOYING to FAILED with
failure cause: java.lang.UnsupportedOperationException: The configuration is
unmodifiable; its contents cannot be changed.2021-07-27 16:26:34.029
[travel_spilt -> (Sink: sink_es_insert, Sink: sink_es_update) (1/1)#31] WARN
org.apache.flink.runtime.taskmanager.Task - travel_spilt -> (Sink:
sink_es_insert, Sink: sink_es_update) (1/1)#31
(1f33925046e04307ba6beb3959d2cad5) switched from DEPLOYING to FAILED with
failure cause: java.lang.UnsupportedOperationException: The configuration is
unmodifiable; its contents cannot be changed. at
org.apache.flink.configuration.UnmodifiableConfiguration.error(UnmodifiableConfiguration.java:73)
at
org.apache.flink.configuration.UnmodifiableConfiguration.setValueInternal(UnmodifiableConfiguration.java:63)
at org.apache.flink.configuration.Configuration.set(Configuration.java:709) at
org.apache.flink.runtime.state.CheckpointStorageLoader.load(CheckpointStorageLoader.java:174)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.createCheckpointStorage(StreamTask.java:1231)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:337)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:308)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:281)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:273)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.(StreamTask.java:263)
at
org.apache.flink.streaming.runtime.tasks.OneInputStreamTask.(OneInputStreamTask.java:65)
at sun.reflect.GeneratedConstructorAccessor339.newInstance(Unknown Source) at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at
org.apache.flink.runtime.taskmanager.Task.loadAndInstantiateInvokable(Task.java:1524)
at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:730) at
org.apache.flink.runtime.taskmanager.Task.run(Task.java:566) at
java.lang.Thread.run(Thread.java:748)
{code}
Every stateful operator has this error.What do I need to do? I looked at other
versions and didn't find the method Unmodifiable configuration#setvalueinternal
(string key, t value).
Looking forward to your reply, thank you.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-23514) foreach exec SQL
ighack created FLINK-23514:
--
Summary: foreach exec SQL
Key: FLINK-23514
URL: https://issues.apache.org/jira/browse/FLINK-23514
Project: Flink
Issue Type: Improvement
Components: Table SQL / API
Affects Versions: 1.13.1
Reporter: ighack
tableEnv.executeSql(sql(0))
tableEnv.executeSql(sql(1))
tableEnv.executeSql(sql(2))
tableEnv.executeSql(sql(3))
tableEnv.executeSql(sql(4))
tableEnv.executeSql(sql(5))
tableEnv.executeSql(sql(6))
tableEnv.executeSql(sql(7)).print()
that is OK
but I hope
sql.foreach(s=>{
tableEnv.executeSql(s)
})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-23513) Remove old connectors and formats
Ingo Bürk created FLINK-23513: - Summary: Remove old connectors and formats Key: FLINK-23513 URL: https://issues.apache.org/jira/browse/FLINK-23513 Project: Flink Issue Type: Sub-task Reporter: Ingo Bürk Assignee: Ingo Bürk -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23512) Check for illegal modifications of JobGraph with partially finished operators
Yun Gao created FLINK-23512: --- Summary: Check for illegal modifications of JobGraph with partially finished operators Key: FLINK-23512 URL: https://issues.apache.org/jira/browse/FLINK-23512 Project: Flink Issue Type: Sub-task Components: Runtime / Checkpointing Affects Versions: 1.14.0 Reporter: Yun Gao Besides the fully finished operators, we also would like to disable inserting new operators before the partially finished operators: # If keyed state is used and discarded after the tasks get finished in the first run, then if we received new records target at these keys, the result would be not right. # Similarly, for normal operator subtasks, if new records are emitted and they relies on the discarded states, the result would also be confused. Thus we would first disable such cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23511) Fix the location error in metric page.
zoucao created FLINK-23511: -- Summary: Fix the location error in metric page. Key: FLINK-23511 URL: https://issues.apache.org/jira/browse/FLINK-23511 Project: Flink Issue Type: Improvement Components: Documentation Reporter: zoucao Attachments: image-2021-07-27-15-17-57-654.png This error exist in [master|https://ci.apache.org/projects/flink/flink-docs-master/docs/ops/metrics/#default-shuffle-service] and [1.13|https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/ops/metrics/] The affected metrics are : * 'inputFloatingBuffersUsage' * 'inputExclusiveBuffersUsage' * 'maxQueueLen' * 'avgQueueLen' * 'backPressuredTimeMsPerSecond' * 'busyTimeMsPerSecond' !image-2021-07-27-15-17-57-654.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23510) add a new metric to show the max usage of inputExclusiveBuffer for each inputChannel
zoucao created FLINK-23510: -- Summary: add a new metric to show the max usage of inputExclusiveBuffer for each inputChannel Key: FLINK-23510 URL: https://issues.apache.org/jira/browse/FLINK-23510 Project: Flink Issue Type: Improvement Components: Runtime / Metrics Reporter: zoucao Now, the 'inPoolUsage' and 'inputExclusiveBuffersUsage' describe the overall situation of a task's network usage. Sometimes, when the back pressure was present, I found the value of 'inPoolUsage' or 'inputExclusiveBuffersUsage' were very low, beacuse they were averaged by the input channel whose buffer usage is low. I propose to add a new metric for each task to record the maximum buffer usage of all input channels belonged to this task. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23509) FlinkKafkaInternalProducer overrides static final ProducerIdAndEpoch#NONE during transaction recovery (fails)
Matthias Schwalbe created FLINK-23509:
-
Summary: FlinkKafkaInternalProducer overrides static final
ProducerIdAndEpoch#NONE during transaction recovery (fails)
Key: FLINK-23509
URL: https://issues.apache.org/jira/browse/FLINK-23509
Project: Flink
Issue Type: Bug
Affects Versions: 1.13.0
Reporter: Matthias Schwalbe
When recovering Kafka transactions from a snapshot, FlinkKafkaInternalProducer
overrides static final ProducerIdAndEpoch#NONE here:
[FlinkKafkaInternalProducer#resumeTransaction|https://github.com/apache/flink/blob/f06faf13930f2e8acccf1e04e2c250b85bdbf48e/flink-connectors/flink-connector-kafka/src/main/java/org/apache/flink/streaming/connectors/kafka/internals/FlinkKafkaInternalProducer.java#L229]
and consequently TransactionManager initializes transactions as new
transactions instead of recovered ones. Here:
[TransactionManager#initializeTransactions|https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/producer/internals/TransactionManager.java#L332]
TransactionManager log (edited for readability):
{{[Sink: trxRollupKafkaSink (1/1)#3|#3] INFO
org.apache.kafka.clients.producer.KafkaProducer - [Producer
clientId=producer-Sink: trxRollupKafkaSink-...8b6-2, transactionalId=Sink:
trxRollupKafkaSink-...8b6-2] Overriding the default enable.idempotence to true
since transactional.id is specified.
[Sink: trxRollupKafkaSink (1/1)#3|#3] INFO
org.apache.kafka.clients.producer.KafkaProducer - [Producer
clientId=producer-Sink: trxRollupKafkaSink-...8b6-2, transactionalId=Sink:
trxRollupKafkaSink-...8b6-2] Instantiated a transactional producer.
[Sink: trxRollupKafkaSink (1/1)#3|#3] INFO
org.apache.kafka.clients.producer.KafkaProducer - [Producer
clientId=producer-Sink: trxRollupKafkaSink-...8b6-2, transactionalId=Sink:
trxRollupKafkaSink-...8b6-2] Overriding the default retries config to the
recommended value of 2147483647 since the idempotent producer is enabled.
[Sink: trxRollupKafkaSink (1/1)#3|#3] INFO
org.apache.kafka.clients.producer.KafkaProducer - [Producer
clientId=producer-Sink: trxRollupKafkaSink-...8b6-2, transactionalId=Sink:
trxRollupKafkaSink-...8b6-2] Overriding the default acks to all since
idempotence is enabled.
[Sink: trxRollupKafkaSink (1/1)#3|#3] DEBUG
org.apache.kafka.clients.producer.internals.TransactionManager - [Producer
clientId=producer-Sink: trxRollupKafkaSink-...8b6-2, transactionalId=Sink:
trxRollupKafkaSink-...8b6-2] Transition from state UNINITIALIZED to INITIALIZING
[Sink: trxRollupKafkaSink (1/1)#3|#3] INFO
org.apache.kafka.clients.producer.internals.TransactionManager - [Producer
clientId=producer-Sink: trxRollupKafkaSink-...8b6-2, transactionalId=Sink:
trxRollupKafkaSink-...8b6-2] Invoking InitProducerId for the first time in
order to acquire a producer ID
[Sink: trxRollupKafkaSink (1/1)#3|#3] DEBUG
org.apache.kafka.clients.producer.internals.TransactionManager - [Producer
clientId=producer-Sink: trxRollupKafkaSink-...8b6-2, transactionalId=Sink:
trxRollupKafkaSink-...8b6-2] Enqueuing transactional request
InitProducerIdRequestData(transactionalId='Sink: trxRollupKafkaSink-...8b6-2',
transactionTimeoutMs=6, producerId=1545118, producerEpoch=17)
[kafka-producer-network-thread | producer-Sink: trxRollupKafkaSink-...8b6-2]
TRACE org.apache.kafka.clients.producer.internals.TransactionManager -
[Producer clientId=producer-Sink: trxRollupKafkaSink-...8b6-2,
transactionalId=Sink: trxRollupKafkaSink-...8b6-2] Request
InitProducerIdRequestData(transactionalId='Sink: trxRollupKafkaSink-...8b6-2',
transactionTimeoutMs=6, producerId=1545118, producerEpoch=17) dequeued for
sending
[kafka-producer-network-thread | producer-Sink: trxRollupKafkaSink-...8b6-2]
DEBUG org.apache.kafka.clients.producer.internals.TransactionManager -
[Producer clientId=producer-Sink: trxRollupKafkaSink-...8b6-2,
transactionalId=Sink: trxRollupKafkaSink-...8b6-2] Enqueuing transactional
request FindCoordinatorRequestData(key='Sink: trxRollupKafkaSink-...8b6-2',
keyType=1)
[kafka-producer-network-thread | producer-Sink: trxRollupKafkaSink-...8b6-2]
DEBUG org.apache.kafka.clients.producer.internals.TransactionManager -
[Producer clientId=producer-Sink: trxRollupKafkaSink-...8b6-2,
transactionalId=Sink: trxRollupKafkaSink-...8b6-2] Enqueuing transactional
request InitProducerIdRequestData(transactionalId='Sink:
trxRollupKafkaSink-...8b6-2', transactionTimeoutMs=6, producerId=1545118,
producerEpoch=17)
[kafka-producer-network-thread | producer-Sink: trxRollupKafkaSink-...8b6-2]
TRACE org.apache.kafka.clients.producer.internals.TransactionManager -
[Producer clientId=producer-Sink: trxRollupKafkaSink-...8b6-2,
transactionalId=Sink: trxRollupKafkaSink-...8b6-2] Request
FindCoordinatorRequestData(key='Sink: trxRollupKafkaSink-...8b6-2', keyType=1)
dequeued for sending
[jira] [Created] (FLINK-23508) HA mode cannot coexist with history server
john created FLINK-23508: Summary: HA mode cannot coexist with history server Key: FLINK-23508 URL: https://issues.apache.org/jira/browse/FLINK-23508 Project: Flink Issue Type: Bug Reporter: john When I submit a Flink job using HA mode, the default job ID generated each time is . At this time, I cannot use the history server because the history server uses the job ID to write the job archive. But the job ID is the same every time, so I cannot track the status of the job. what do I do? -- This message was sent by Atlassian Jira (v8.3.4#803005)
