[jira] [Created] (FLINK-23720) Migrate ModuleFactory to the new factory stack
Ingo Bürk created FLINK-23720: - Summary: Migrate ModuleFactory to the new factory stack Key: FLINK-23720 URL: https://issues.apache.org/jira/browse/FLINK-23720 Project: Flink Issue Type: Improvement Components: Table SQL / API Reporter: Ingo Bürk Assignee: Ingo Bürk -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] FLIP-173: Support DAG of algorithms (Flink ML)
Hi Zhipeng, It looks like there are three different but potentially related things here. 1. How to describe multiple output of a node in the DAG. 2. How to construct / describe the DAG. 3. Do we need an encapsulation class of a DAG, e.g. the Graph class in option 1? It is much easier to discuss them if we agree on the fundamental issue I mentioned above. So the following discussion assumes that we follow the one-set-of-API approach. Regarding 1, there are two independent suggestions. Timo suggested named outputs, and you suggested distinguishing main output from side outputs. Even with the main output / side outputs, named output may still be useful because there might be multiple side outputs. If we only look at the node itself, distinguishing main output from side outputs introduces another concept, but only avoids the index on the main output. So merely from the multiple output description perspective, this doesn't seem very useful. The main benefit of doing this is because it seems to make the DAG construction / description easier, which brings us to the second point. Regarding 2, the way proposed in option 1 to describe a DAG is indeed a little verbose, partly due to its generalized multiple output API. So if introducing the side outputs helps make it simpler, it looks like a good improvement to me. Regarding 3, first of all, users can still write programs by calling fit(), transform() or compute() by themselves even without the encapsulation class of DAG. It is just like users can just call Estimator.fit() and Transformer.transform() without using the Pipeline. However, if users want to reuse the DAG and potentially connect the DAG to another bigger DAG as an Estimator or transformer, encapsulation is necessary. In this case, the DAG description API mentioned in (2) needs to work well with the encapsulation as well. To sum up, I think distinguishing main output and side outputs, which enables link / linkFrom, can help reduce the verbosity when describing the DAG. So I am open to this option. However, what's unclear to me is how link/linkFrom would work with the encapsulation case in (3). Do you have some ideas for that? Thanks, Jiangjie (Becket) Qin On Wed, Aug 11, 2021 at 10:04 AM Zhipeng Zhang wrote: > Hi Timo, Becket, > > Thanks for the feedback. > > I agree that having named table can help the code more readable. No matter > there is one output table or multiple output tables, users have to access > an output table by a magic index (For the case that there is only one > output table, we need to use index zero.), which is somehow hard to read. > > My point is that can we adopt the idea in Option-2 that we distinguish the > main-output and side-output by getOutputTable() and getSideOutputs() in > AlgoOperator API? > As an Alink developer (Alibaba's machine learning library on Flink, > https://github.com/alibaba/Alink), we do find that many machine learning > algorithms have only one output table, and getOutputTable() is more > frequently used by accessing other output tables. > > > ``` > Table output = >transformer7.transform( >transformer6.transform( >transformer5.transform( >transformer4.transform( >tranformers3.transform( > transformer2.transform(input2)[0], transformer1.transform(input1)[0] >)[0])[0])[0])[0])[0])[0]; > ``` > > For example, the above case in getOutputTable() and getSideOutputs() API > will be written as: > >Table output1 = op1.compute(intput1).getOutputTable(); >Table output2 = op2.compute(input2).getOutputTable(); >Table output3 = op3.compute(output1, output2).getOutputTable(); >Table output4 = op4.compute(input3).getOutputTable(); >Table output5 = op5.compute(input4).getOutputTable(); >Table output6 = op6.compute(input5).getOutputTable(); >Table output = op7.compute(input6).getOutputTable(); > > BTW, in Option-2, we proposed AlgoOperator::linkFrom() and > AlgoOperator::link() to users to better support building machine learning > DAGs. In AlgoOperator case, the above code can be simply written as: > > AlgoOperator output = stage3 > > .linkFrom(input1.link(stage1), input2.link(stage2)) > > .link(stage4) > > .link(stage5) > > .link(stage6) > > .link(stage7); > > Table outputTable = output.getOutputTable(); > > Note: > (1) linkFrom() encapsulates the computation logic of this AlgoOperator. > Only the first output table of each input will be used in the computation. > (2) A.link(B) equals to B.linkFrom(A) > > > > Becket Qin 于2021年8月11日周三 上午8:49写道： > > > Thanks for the feedback, Mingliang. > > > > Dong, I think what Mingliang meant by option-2 is the second way > mentioned > > in my email, i.e. having a Graph encapsulation. It does not mean the > option > > 2 in the FLIP. So he actually meant option 1 of the FLIP. Mingliang can > > correct me if I misunderstood. > > > > Hi Timo, > > > > Thanks for taking a look at the FLIP and giving the feedback. > > > > Having named output tables could
[jira] [Created] (FLINK-23721) Flink SQL state TTL has no effect when using non-incremental RocksDBStateBackend
Q Kang created FLINK-23721:
--
Summary: Flink SQL state TTL has no effect when using
non-incremental RocksDBStateBackend
Key: FLINK-23721
URL: https://issues.apache.org/jira/browse/FLINK-23721
Project: Flink
Issue Type: Bug
Components: Runtime / State Backends, Table SQL / Runtime
Affects Versions: 1.13.0
Reporter: Q Kang
Take the following deduplication SQL program as an example:
{code:java}
SET table.exec.state.ttl=30s;
INSERT INTO tmp.blackhole_order_done_log
SELECT t.* FROM (
SELECT *,ROW_NUMBER() OVER(PARTITION BY suborderid ORDER BY procTime ASC) AS
rn
FROM rtdw_ods.kafka_order_done_log
) AS t WHERE rn = 1;
{code}
When using RocksDBStateBackend with incremental checkpoint enabled, the size of
deduplication state seems OK.
FlinkCompactionFilter is also working, regarding to logs below:
{code:java}
21-08-11 17:21:42 DEBUG org.rocksdb.FlinkCompactionFilter
[] - RocksDB filter native code log: Call FlinkCompactionFilter::FilterV2
- Key: , Data: 017B3481026D01, Value type: 0, State type: 1, TTL: 3
ms, timestamp_offset: 0
21-08-11 17:21:42 DEBUG org.rocksdb.FlinkCompactionFilter
[] - RocksDB filter native code log: Last access timestamp: 1628673475181
ms, ttlWithoutOverflow: 3 ms, Current timestamp: 1628673701905 ms
21-08-11 17:21:42 DEBUG org.rocksdb.FlinkCompactionFilter
[] - RocksDB filter native code log: Decision: 1
21-08-11 17:21:42 DEBUG org.rocksdb.FlinkCompactionFilter
[] - RocksDB filter native code log: Call FlinkCompactionFilter::FilterV2
- Key: , Data: 017B3484064901, Value type: 0, State type: 1, TTL: 3
ms, timestamp_offset: 0
21-08-11 17:21:42 DEBUG org.rocksdb.FlinkCompactionFilter
[] - RocksDB filter native code log: Last access timestamp: 1628673672777
ms, ttlWithoutOverflow: 3 ms, Current timestamp: 1628673701905 ms
21-08-11 17:21:42 DEBUG org.rocksdb.FlinkCompactionFilter
[] - RocksDB filter native code log: Decision: 0
21-08-11 17:21:42 DEBUG org.rocksdb.FlinkCompactionFilter
[] - RocksDB filter native code log: Call FlinkCompactionFilter::FilterV2
- Key: , Data: 017B3483341D01, Value type: 0, State type: 1, TTL: 3
ms, timestamp_offset: 0
21-08-11 17:21:42 DEBUG org.rocksdb.FlinkCompactionFilter
[] - RocksDB filter native code log: Last access timestamp: 1628673618973
ms, ttlWithoutOverflow: 3 ms, Current timestamp: 1628673701905 ms
21-08-11 17:21:42 DEBUG org.rocksdb.FlinkCompactionFilter
[] - RocksDB filter native code log: Decision: 1
{code}
However, after turning off incremental checkpoint, the state TTL seems not
effective at all: FlinkCompactionFilter logs are not printed, and the size of
deduplication state grows steadily up to several GBs (Kafka traffic is somewhat
heavy, at about 1K records per sec).
In contrast, FsStateBackend always works well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-23722) S3 Tests fail on AZP: Unable to find a region via the region provider chain. Must provide an explicit region in the builder or setup environment to supply a region.
Arvid Heise created FLINK-23722:
---
Summary: S3 Tests fail on AZP: Unable to find a region via the
region provider chain. Must provide an explicit region in the builder or setup
environment to supply a region.
Key: FLINK-23722
URL: https://issues.apache.org/jira/browse/FLINK-23722
Project: Flink
Issue Type: Improvement
Components: Connectors / FileSystem
Affects Versions: 1.14.0
Reporter: Arvid Heise
Assignee: Arvid Heise
E2E and integration tests fail with
{noformat}
Aug 11 09:11:32 Caused by: com.amazonaws.SdkClientException: Unable to find a
region via the region provider chain. Must provide an explicit region in the
builder or setup environment to supply a region.
Aug 11 09:11:32 at
com.amazonaws.client.builder.AwsClientBuilder.setRegion(AwsClientBuilder.java:462)
Aug 11 09:11:32 at
com.amazonaws.client.builder.AwsClientBuilder.configureMutableProperties(AwsClientBuilder.java:424)
Aug 11 09:11:32 at
com.amazonaws.client.builder.AwsSyncClientBuilder.build(AwsSyncClientBuilder.java:46)
Aug 11 09:11:32 at
org.apache.hadoop.fs.s3a.DefaultS3ClientFactory.buildAmazonS3Client(DefaultS3ClientFactory.java:144)
Aug 11 09:11:32 at
org.apache.hadoop.fs.s3a.DefaultS3ClientFactory.createS3Client(DefaultS3ClientFactory.java:96)
Aug 11 09:11:32 at
org.apache.hadoop.fs.s3a.S3AFileSystem.bindAWSClient(S3AFileSystem.java:753)
Aug 11 09:11:32 at
org.apache.hadoop.fs.s3a.S3AFileSystem.initialize(S3AFileSystem.java:446)
Aug 11 09:11:32 ... 44 more
{noformat}
https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=21884&view=logs&j=d44f43ce-542c-597d-bf94-b0718c71e5e8&t=ed165f3f-d0f6-524b-5279-86f8ee7d0e2d
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-23723) Look up join support PROCTIME() function
silence created FLINK-23723:
---
Summary: Look up join support PROCTIME() function
Key: FLINK-23723
URL: https://issues.apache.org/jira/browse/FLINK-23723
Project: Flink
Issue Type: Improvement
Components: Table SQL / API
Reporter: silence
Now,when we what to use look up join we must declare procetime attribute on
source table.
this is relatively troublesome, and in some complex scenarios(eg. Top-N) , look
up join cannot be performed because of the loss of processtime attribute.
Moreover, in the process of look up join, the processing time is of no
practical use. can we support specifying `PROCTIME()` directly in the join
without declaring it in the source table,
like:
{code:sql}
SELECT o.order_id, o.total, c.country, c.zip
FROM Orders AS o
JOIN Customers FOR SYSTEM_TIME AS OF PROCTIME() AS c
ON o.customer_id = c.id;
{code}
Now it throws an exception
{code:java}
Caused by: java.lang.AssertionError: Temporal table can only be used in
temporal join and only supports 'FOR SYSTEM_TIME AS OF' left table's time
attribute field.
Querying a temporal table using 'FOR SYSTEM TIME AS OF' syntax with an
expression call 'PROCTIME()' is not supported yet.
at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
at
org.apache.flink.table.planner.plan.nodes.logical.FlinkLogicalSnapshot.isValid(FlinkLogicalSnapshot.scala:60)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re:Re: [ANNOUNCE] RocksDB Version Upgrade and Performance
Hi, Nico and yun: Thanks for your great work and detail description on rocksdb version upgrade and performance. About 800 jobs are using rocksdb state backend in our production environment, and we plan to upgrade more aim to solve the gc problems caused by large states.Because of non-restrict memory control on rocksdb, we have to spend a lot of time to solve the problem of memory usage beyond the physical memory.With the support of strict block cache, things will become much easier. Also, delete range api is useful for us too, so we prefer to upgrade the rocksdb to the new release version and +1(non-binding). best, zlzhang0122 At 2021-08-05 01:50:07, "Yun Tang" wrote: >Hi Yuval, > >Upgrading RocksDB version is a long story since Flink-1.10. >When we first plan to introduce write buffer manager to help control the >memory usage of RocksDB, we actually wanted to bump up to RocksDB-5.18 from >current RocksDB-5.17. However, we found performance regression in our micro >benchmark on state operations [1] if bumped to RocksDB-5.18. We did not figure >the root cause at that time and decide to cherry pick the commits of write >buffer manager to our own FRocksDB [2]. And we finally released our own >frocksdbjni-5.17.2-artisans-2.0 at that time. > >As time goes no, more and more bugs or missed features have been reported in >the old RocksDB version. Such as: > > 1. Cannot support ARM platform [3] > 2. Dose not have stable deleteRange API, which is useful for Flink scale > out [4] > 3. Cannot support strict block cache [5] > 4. Checkpoint might stuck if using UNIVERSVAL compaction strategy [6] > 5. Uncontrolled log size make us disabled the RocksDB internal LOG [7] > 6. RocksDB's optimizeForPointLookup option might cause data lost [8] > 7. Current dummy entry used for memory control in RocksDB-5.17 is too > large, leading performance problem [9] > 8. Cannot support alpine-based images. > 9. ... > >Some of the bugs are walked around, and some are still open. > >And we decide to make some changes from Flink-1.12. First of all, we reported >the performance regression problem compared with RocksDB-5.18 and RocksDB-5.17 >to RocksDB community [10]. However, as RocksDB-5.x versions are a bit older >for the community, and RocksJava usage might not be the core part for facebook >guys, we did not get useful replies. Thus, we decide to figure out the root >cause of performance regression by ourself. >Fortunately, we find the cause via binary search the commits among >RocksDB-5.18 and RocksDB-5.17, and updated in the original thread [10]. To be >short, the performance regression is due to different implementation of >`__thread` and `thread_local` in gcc and would have more impact on dynamic >loading [11], which is also what current RocksJava jar package does. With my >patch [12], the performance regression would disappear if comparing >RocksDB-5.18 with RocksDB-5.17. > >Unfortunately, RocksDB-5.18 still has many bugs and we want to bump to >RocksDB-6.x. However, another performance regression appeared even with my >patch [12]. With previous knowledge, we know that we must verify the built .so >files with our java-based benchmark instead of using RocksDB built-in >db-bench. I started to search the 1340+ commits from RocksDB-5.18 to >RocksDB-6.11 to find the performance problem. However, I did not figure out >the root cause after spending several weeks this time. The performance behaves >up and down in those commits and I cannot get the commit which lead the >performance regression. Take this commit of integrating block cache tracer in >block-based table reader [13] for example, I noticed that this commit would >cause a bit performance regression and that might be the useless usage >accounting in operations, however, the problematic code was changed in later >commits. Thus, after several weeks digging, I have to give up for the endless >searching in the thousand commits temporarily. As RocksDB community seems not >make the project management system public, unlike Apache's open JIRA systems, >we do not know what benchmark they actually run before releasing each version >to guarantee the performance. > >With my patch [10] on latest RocksDB-6.20.3, we could get the results on >nexmark in the original thread sent by Stephan, and we can see the performance >behaves closely in many real-world cases. And we also hope new features, such >as direct buffer supporting [14] in RocksJava could help improve RocksDB's >performance in the future. > >Hope this could explain what we already did. > > >[1] https://github.com/apache/flink-benchmarks >[2] https://github.com/ververica/frocksdb/tree/FRocksDB-5.17.2 >[3] https://issues.apache.org/jira/browse/FLINK-13598 >[4] https://issues.apache.org/jira/browse/FLINK-21321 >[5] https://github.com/facebook/rocksdb/issues/6247 >[6] https://issues.apache.org/jira/browse/FLINK-21726 >[7] https://issues.apache.org/jira/browse/FLINK-
[jira] [Created] (FLINK-23724) Network buffer leak when ResultPartition is released (failover)
Yingjie Cao created FLINK-23724: --- Summary: Network buffer leak when ResultPartition is released (failover) Key: FLINK-23724 URL: https://issues.apache.org/jira/browse/FLINK-23724 Project: Flink Issue Type: Bug Components: Runtime / Network Affects Versions: 1.14.0 Reporter: Yingjie Cao Fix For: 1.14.0 The BufferBuilders in BufferWritingResultPartition are not properly released when ResultPartition is released. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23725) HadoopFsCommitter， Prompt for file rename failure
todd created FLINK-23725:
Summary: HadoopFsCommitter， Prompt for file rename failure
Key: FLINK-23725
URL: https://issues.apache.org/jira/browse/FLINK-23725
Project: Flink
Issue Type: Bug
Components: Connectors / FileSystem, Connectors / Hadoop Compatibility
Affects Versions: 1.12.1, 1.11.1
Reporter: todd
When the HDFS file is written, if the part file exists, only false will be
returned if the duplicate name fails.Whether to throw an exception that already
exists in the part, or print related logs.
```
org.apache.flink.runtime.fs.hdfs.HadoopRecoverableFsDataOutputStream.HadoopFsCommitter#commit
public void commit() throws IOException {
final Path src = recoverable.tempFile();
final Path dest = recoverable.targetFile();
final long expectedLength = recoverable.offset();
final FileStatus srcStatus;
try {
srcStatus = fs.getFileStatus(src);
} catch (IOException e) {
throw new IOException("Cannot clean commit: Staging file does not exist.");
}
if (srcStatus.getLen() != expectedLength) {
// something was done to this file since the committer was created.
// this is not the "clean" case
throw new IOException("Cannot clean commit: File has trailing junk data.");
}
try {
// return false or ture
fs.rename(src, dest);
} catch (IOException e) {
throw new IOException(
"Committing file by rename failed: " + src + " to " + dest, e);
}
}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-23726) Buffer debloat configuration is taken from the wrong configuration
Anton Kalashnikov created FLINK-23726: - Summary: Buffer debloat configuration is taken from the wrong configuration Key: FLINK-23726 URL: https://issues.apache.org/jira/browse/FLINK-23726 Project: Flink Issue Type: Bug Components: Runtime / Task Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Right now, StreamTask receives the buffer debloat configuration from the taskConfiguration which is wrong. The right place for the debloat configuration is taskManagerConfiguration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23727) Skip null values in SimpleStringSchema
Paul Lin created FLINK-23727: Summary: Skip null values in SimpleStringSchema Key: FLINK-23727 URL: https://issues.apache.org/jira/browse/FLINK-23727 Project: Flink Issue Type: Bug Components: Connectors / Common Affects Versions: 1.13.2 Reporter: Paul Lin In Kafka user cases, it's valid to send a message with a key and a null payload as a tombstone. But SimpleStringSchema, which is frequently used as a message value deserializer, throws NPE when the input value is null. We should tolerate null values in SimpleStringSchema (simply return null to skip the records), otherwise users need to implement a custom one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23728) Support new state backend factory stack in State Processor API
Seth Wiesman created FLINK-23728: Summary: Support new state backend factory stack in State Processor API Key: FLINK-23728 URL: https://issues.apache.org/jira/browse/FLINK-23728 Project: Flink Issue Type: Improvement Components: API / State Processor Reporter: Seth Wiesman Assignee: Seth Wiesman -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23729) sql-client.sh fails on Git Bash for Windows, MinGW & MSYS2
Derek Moore created FLINK-23729: --- Summary: sql-client.sh fails on Git Bash for Windows, MinGW & MSYS2 Key: FLINK-23729 URL: https://issues.apache.org/jira/browse/FLINK-23729 Project: Flink Issue Type: Bug Components: Command Line Client Affects Versions: 1.12.5 Reporter: Derek Moore sql-client.sh uses manglePath() and manglePathList() from config.sh. These helper functions only recognize "CYGWIN" and not "msys". Adding awareness of "msys" allows sql-client.sh to mostly work on Windows. The log4j-cli.properties file location is also incorrectly constructed on Windows machines, but this doesn't fail sql-client.sh from loading. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23730) Source from hive sink hbase lost data
Carl created FLINK-23730: Summary: Source from hive sink hbase lost data Key: FLINK-23730 URL: https://issues.apache.org/jira/browse/FLINK-23730 Project: Flink Issue Type: Bug Components: Connectors / HBase, Connectors / Hive Affects Versions: 1.12.1 Reporter: Carl Our use case is as follows, # hive source: create hive table which meta data is in HMS # create hbase use hbase shell # flink sql ddl: create hbase flink table # use hive catalog: use flink sql insert into hbase flink table if i set the tableconfig: table.exec.hive.infer-source-parallelism = false The program will run as one parallelism，and the number of records of results is correct. but if i set the tableconfig: table.exec.hive.infer-source-parallelism = true The program will run as twenty parallelism that express source parallelism is inferred according to splits number，and the number of records of results is not correct. The test was repeated many times and there was no exception occurred. So I guess it has something to do with high concurrency. Does it lose data because of high concurrency? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23731) Streaming File Sink s3 end-to-end test fail due to timeout
Xintong Song created FLINK-23731:
Summary: Streaming File Sink s3 end-to-end test fail due to timeout
Key: FLINK-23731
URL: https://issues.apache.org/jira/browse/FLINK-23731
Project: Flink
Issue Type: Bug
Components: API / DataStream
Affects Versions: 1.14.0
Reporter: Xintong Song
Fix For: 1.14.0
https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=21894&view=logs&j=c88eea3b-64a0-564d-0031-9fdcd7b8abee&t=070ff179-953e-5bda-71fa-d6599415701c&l=11509
{code}
Aug 11 12:29:12 Job (d53520e1f7c1126d6761cb2d6c8cd97a) is running.
Aug 11 12:29:12 Waiting for job (d53520e1f7c1126d6761cb2d6c8cd97a) to have at
least 3 completed checkpoints ...
Aug 11 12:39:17 A timeout occurred waiting for job
(d53520e1f7c1126d6761cb2d6c8cd97a) to have at least 3 completed checkpoints .
Aug 11 12:39:17 Stopping job timeout watchdog (with pid=419743)
rm: cannot remove
'/home/vsts/work/1/s/flink-dist/target/flink-1.14-SNAPSHOT-bin/flink-1.14-SNAPSHOT/lib/flink-shaded-netty-tcnative-static-*.jar':
No such file or directory
Aug 11 12:39:21 f5a7931f78c5994b37179fe2dc62d8e5fe80b603f25026698e4230d15bbc4960
Aug 11 12:39:21 f5a7931f78c5994b37179fe2dc62d8e5fe80b603f25026698e4230d15bbc4960
Aug 11 12:39:21 [FAIL] Test script contains errors.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-23732) StatefulJobSavepointMigrationITCase.testRestoreSavepoint fails due to LoggerInitializationException
Xintong Song created FLINK-23732:
Summary: StatefulJobSavepointMigrationITCase.testRestoreSavepoint
fails due to LoggerInitializationException
Key: FLINK-23732
URL: https://issues.apache.org/jira/browse/FLINK-23732
Project: Flink
Issue Type: Bug
Components: Runtime / Coordination
Affects Versions: 1.14.0
Reporter: Xintong Song
Fix For: 1.14.0
https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=21905&view=logs&j=a57e0635-3fad-5b08-57c7-a4142d7d6fa9&t=2ef0effc-1da1-50e5-c2bd-aab434b1c5b7&l=10229
{code}
Aug 11 13:18:49 [ERROR] Tests run: 40, Failures: 0, Errors: 1, Skipped: 20,
Time elapsed: 105.47 s <<< FAILURE! - in
org.apache.flink.api.scala.migration.StatefulJobSavepointMigrationITCase
Aug 11 13:18:49 [ERROR] testRestoreSavepoint[Migrate Savepoint / Backend:
{1.13,rocksdb}] Time elapsed: 43.482 s <<< ERROR!
Aug 11 13:18:49 java.lang.Exception: Could not create actor system
Aug 11 13:18:49 at
org.apache.flink.runtime.rpc.akka.AkkaBootstrapTools.startLocalActorSystem(AkkaBootstrapTools.java:238)
Aug 11 13:18:49 at
org.apache.flink.runtime.rpc.akka.AkkaRpcServiceUtils$AkkaRpcServiceBuilder.createAndStart(AkkaRpcServiceUtils.java:349)
Aug 11 13:18:49 at
org.apache.flink.runtime.rpc.akka.AkkaRpcServiceUtils$AkkaRpcServiceBuilder.createAndStart(AkkaRpcServiceUtils.java:327)
Aug 11 13:18:49 at
org.apache.flink.runtime.rpc.akka.AkkaRpcServiceUtils$AkkaRpcServiceBuilder.createAndStart(AkkaRpcServiceUtils.java:247)
Aug 11 13:18:49 at
org.apache.flink.runtime.minicluster.MiniCluster.createLocalRpcService(MiniCluster.java:986)
Aug 11 13:18:49 at
org.apache.flink.runtime.minicluster.MiniCluster.start(MiniCluster.java:297)
Aug 11 13:18:49 at
org.apache.flink.runtime.testutils.MiniClusterResource.startMiniCluster(MiniClusterResource.java:203)
Aug 11 13:18:49 at
org.apache.flink.runtime.testutils.MiniClusterResource.before(MiniClusterResource.java:91)
Aug 11 13:18:49 at
org.apache.flink.test.util.MiniClusterWithClientResource.before(MiniClusterWithClientResource.java:64)
Aug 11 13:18:49 at
org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
Aug 11 13:18:49 at
org.apache.flink.util.TestNameProvider$1.evaluate(TestNameProvider.java:45)
Aug 11 13:18:49 at
org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
Aug 11 13:18:49 at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
Aug 11 13:18:49 at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
Aug 11 13:18:49 at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner.run(ParentRunner.java:413)
Aug 11 13:18:49 at org.junit.runners.Suite.runChild(Suite.java:128)
Aug 11 13:18:49 at org.junit.runners.Suite.runChild(Suite.java:27)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
Aug 11 13:18:49 at
org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
Aug 11 13:18:49 at org.junit.rules.RunRules.evaluate(RunRules.java:20)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
Aug 11 13:18:49 at
org.junit.runners.ParentRunner.run(ParentRunner.java:413)
Aug 11 13:18:49 at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
Aug 11 13:18:49 at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
Aug 11 13:18:49 at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
Aug 11 13:18:49 at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
Aug 11 13:18:49 at
java.util.stream.ReferencePipeline$3$1.a
[jira] [Created] (FLINK-23733) sdsd
kaohaonan created FLINK-23733: - Summary: sdsd Key: FLINK-23733 URL: https://issues.apache.org/jira/browse/FLINK-23733 Project: Flink Issue Type: Improvement Affects Versions: 1.14.0 Reporter: kaohaonan Fix For: 1.15.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-23734) Migrate ComponentFactory to the new Factory stack
Ingo Bürk created FLINK-23734: - Summary: Migrate ComponentFactory to the new Factory stack Key: FLINK-23734 URL: https://issues.apache.org/jira/browse/FLINK-23734 Project: Flink Issue Type: Improvement Components: Table SQL / API Reporter: Ingo Bürk Assignee: Ingo Bürk -- This message was sent by Atlassian Jira (v8.3.4#803005)
