[jira] [Created] (FLINK-11405) rest api can see exception by start end time filter
lining created FLINK-11405: -- Summary: rest api can see exception by start end time filter Key: FLINK-11405 URL: https://issues.apache.org/jira/browse/FLINK-11405 Project: Flink Issue Type: Sub-task Reporter: lining Assignee: lining -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FLINK-11404) web ui add see page and can filter by time
lining created FLINK-11404: -- Summary: web ui add see page and can filter by time Key: FLINK-11404 URL: https://issues.apache.org/jira/browse/FLINK-11404 Project: Flink Issue Type: Sub-task Reporter: lining Assignee: lining -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [ANNOUNCE] Contributing Alibaba's Blink
Great news Stephan! Why not make the code available by having a fork of Flink on Alibaba's Github account. This will allow us to do easy diff's in the Github UI and create PR's of cherry-picked commits if needed. I can imagine that the Blink codebase has a lot of branches by itself, so just pushing a couple of branches to the main Flink repo is not ideal. Looking forward to it! Cheers, Fokko Op di 22 jan. 2019 om 03:48 schreef Shaoxuan Wang : > big +1 to contribute Blink codebase directly into the Apache Flink project. > Looking forward to the new journey. > > Regards, > Shaoxuan > > On Tue, Jan 22, 2019 at 3:52 AM Xiaowei Jiang wrote: > > > Thanks Stephan! We are hoping to make the process as non-disruptive as > > possible to the Flink community. Making the Blink codebase public is the > > first step that hopefully facilitates further discussions. > > Xiaowei > > > > On Monday, January 21, 2019, 11:46:28 AM PST, Stephan Ewen < > > se...@apache.org> wrote: > > > > Dear Flink Community! > > > > Some of you may have heard it already from announcements or from a Flink > > Forward talk: > > Alibaba has decided to open source its in-house improvements to Flink, > > called Blink! > > First of all, big thanks to team that developed these improvements and > made > > this > > contribution possible! > > > > Blink has some very exciting enhancements, most prominently on the Table > > API/SQL side > > and the unified execution of these programs. For batch (bounded) data, > the > > SQL execution > > has full TPC-DS coverage (which is a big deal), and the execution is more > > than 10x faster > > than the current SQL runtime in Flink. Blink has also added support for > > catalogs, > > improved the failover speed of batch queries and the resource management. > > It also > > makes some good steps in the direction of more deeply unifying the batch > > and streaming > > execution. > > > > The proposal is to merge Blink's enhancements into Flink, to give Flink's > > SQL/Table API and > > execution a big boost in usability and performance. > > > > Just to avoid any confusion: This is not a suggested change of focus to > > batch processing, > > nor would this break with any of the streaming architecture and vision of > > Flink. > > This contribution follows very much the principle of "batch is a special > > case of streaming". > > As a special case, batch makes special optimizations possible. In its > > current state, > > Flink does not exploit many of these optimizations. This contribution > adds > > exactly these > > optimizations and makes the streaming model of Flink applicable to harder > > batch use cases. > > > > Assuming that the community is excited about this as well, and in favor > of > > these enhancements > > to Flink's capabilities, below are some thoughts on how this contribution > > and integration > > could work. > > > > --- Making the code available --- > > > > At the moment, the Blink code is in the form of a big Flink fork (rather > > than isolated > > patches on top of Flink), so the integration is unfortunately not as easy > > as merging a > > few patches or pull requests. > > > > To support a non-disruptive merge of such a big contribution, I believe > it > > make sense to make > > the code of the fork available in the Flink project first. > > From there on, we can start to work on the details for merging the > > enhancements, including > > the refactoring of the necessary parts in the Flink master and the Blink > > code to make a > > merge possible without repeatedly breaking compatibility. > > > > The first question is where do we put the code of the Blink fork during > the > > merging procedure? > > My first thought was to temporarily add a repository (like > > "flink-blink-staging"), but we could > > also put it into a special branch in the main Flink repository. > > > > > > I will start a separate thread about discussing a possible strategy to > > handle and merge > > such a big contribution. > > > > Best, > > Stephan > > >
[jira] [Created] (FLINK-11403) Remove ResultPartitionConsumableNotifier from ResultPartition
zhijiang created FLINK-11403:
Summary: Remove ResultPartitionConsumableNotifier from
ResultPartition
Key: FLINK-11403
URL: https://issues.apache.org/jira/browse/FLINK-11403
Project: Flink
Issue Type: Sub-task
Components: Network
Reporter: zhijiang
Assignee: zhijiang
Fix For: 1.8.0
This is the precondition for introducing pluggable {{ShuffleService}} on TM
side.
In current process of creating {{ResultPartition}}, the
{{ResultPartitionConsumableNotifier}} regarded as TM level component has to be
passed into the constructor. In order to create {{ResultPartition}} easily from
{{ShuffleService}}, the required information should be covered by
{{ResultPartitionDeploymentDescriptor}} as much as possible, then we could
remove this notifier from the constructor. And it is also reasonable for
notifying consumable partition via {{TaskActions}} which is already covered in
{{ResultPartition}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Apply for Flink contributor permission
Hi Guys, Could anyone give me the contributor permission ? My Jira ID is hongtao12310 Regards, Hongtao
Re: [ANNOUNCE] Contributing Alibaba's Blink
big +1 to contribute Blink codebase directly into the Apache Flink project. Looking forward to the new journey. Regards, Shaoxuan On Tue, Jan 22, 2019 at 3:52 AM Xiaowei Jiang wrote: > Thanks Stephan! We are hoping to make the process as non-disruptive as > possible to the Flink community. Making the Blink codebase public is the > first step that hopefully facilitates further discussions. > Xiaowei > > On Monday, January 21, 2019, 11:46:28 AM PST, Stephan Ewen < > se...@apache.org> wrote: > > Dear Flink Community! > > Some of you may have heard it already from announcements or from a Flink > Forward talk: > Alibaba has decided to open source its in-house improvements to Flink, > called Blink! > First of all, big thanks to team that developed these improvements and made > this > contribution possible! > > Blink has some very exciting enhancements, most prominently on the Table > API/SQL side > and the unified execution of these programs. For batch (bounded) data, the > SQL execution > has full TPC-DS coverage (which is a big deal), and the execution is more > than 10x faster > than the current SQL runtime in Flink. Blink has also added support for > catalogs, > improved the failover speed of batch queries and the resource management. > It also > makes some good steps in the direction of more deeply unifying the batch > and streaming > execution. > > The proposal is to merge Blink's enhancements into Flink, to give Flink's > SQL/Table API and > execution a big boost in usability and performance. > > Just to avoid any confusion: This is not a suggested change of focus to > batch processing, > nor would this break with any of the streaming architecture and vision of > Flink. > This contribution follows very much the principle of "batch is a special > case of streaming". > As a special case, batch makes special optimizations possible. In its > current state, > Flink does not exploit many of these optimizations. This contribution adds > exactly these > optimizations and makes the streaming model of Flink applicable to harder > batch use cases. > > Assuming that the community is excited about this as well, and in favor of > these enhancements > to Flink's capabilities, below are some thoughts on how this contribution > and integration > could work. > > --- Making the code available --- > > At the moment, the Blink code is in the form of a big Flink fork (rather > than isolated > patches on top of Flink), so the integration is unfortunately not as easy > as merging a > few patches or pull requests. > > To support a non-disruptive merge of such a big contribution, I believe it > make sense to make > the code of the fork available in the Flink project first. > From there on, we can start to work on the details for merging the > enhancements, including > the refactoring of the necessary parts in the Flink master and the Blink > code to make a > merge possible without repeatedly breaking compatibility. > > The first question is where do we put the code of the Blink fork during the > merging procedure? > My first thought was to temporarily add a repository (like > "flink-blink-staging"), but we could > also put it into a special branch in the main Flink repository. > > > I will start a separate thread about discussing a possible strategy to > handle and merge > such a big contribution. > > Best, > Stephan >
Re: [DISCUSS] Towards a leaner flink-dist
Thanks Chesnay for raising this discussion thread. I think there are 3 major use scenarios for flink binary distribution. 1. Use it to set up standalone cluster 2. Use it to experience features of flink, such as via scala-shell, sql-client 3. Downstream project use it to integrate with their system I did a size estimation of flink dist folder, lib folder take around 100M and opt folder take around 200M. Overall I agree to make a thin flink dist. So the next problem is which components to drop. I check the opt folder, and I think the filesystem components and metrics components could be moved out. Because they are pluggable components and is only used in scenario 1 I think (setting up standalone cluster). Other components like flink-table, flink-ml, flnk-gellay, we should still keep them IMHO, because new user may still use it to try the features of flink. For me, scala-shell is the first option to try new features of flink. Fabian Hueske 于2019年1月18日周五 下午7:34写道： > Hi Chesnay, > > Thank you for the proposal. > I think this is a good idea. > We follow a similar approach already for Hadoop dependencies and > connectors (although in application space). > > +1 > > Fabian > > Am Fr., 18. Jan. 2019 um 10:59 Uhr schrieb Chesnay Schepler < > ches...@apache.org>: > >> Hello, >> >> the binary distribution that we release by now contains quite a lot of >> optional components, including various filesystems, metric reporters and >> libraries. Most users will only use a fraction of these, and as such >> pretty much only increase the size of flink-dist. >> >> With Flink growing more and more in scope I don't believe it to be >> feasible to ship everything we have with every distribution, and instead >> suggest more of a "pick-what-you-need" model, where flink-dist is rather >> lean and additional components are downloaded separately and added by >> the user. >> >> This would primarily affect the /opt directory, but could also be >> extended to cover flink-dist. For example, the yarn and mesos code could >> be spliced out into separate jars that could be added to lib manually. >> >> Let me know what you think. >> >> Regards, >> >> Chesnay >> >> -- Best Regards Jeff Zhang
[jira] [Created] (FLINK-11402) User code can fail with an UnsatisfiedLinkError in the presence of multiple classloaders
Ufuk Celebi created FLINK-11402:
---
Summary: User code can fail with an UnsatisfiedLinkError in the
presence of multiple classloaders
Key: FLINK-11402
URL: https://issues.apache.org/jira/browse/FLINK-11402
Project: Flink
Issue Type: Bug
Components: Distributed Coordination
Affects Versions: 1.7.0
Reporter: Ufuk Celebi
Attachments: hello-snappy-1.0-SNAPSHOT.jar, hello-snappy.tgz
As reported on the user mailing list thread "[`env.java.opts` not persisting
after job canceled or failed and then
restarted|https://lists.apache.org/thread.html/37cc1b628e16ca6c0bacced5e825de8057f88a8d601b90a355b6a291@%3Cuser.flink.apache.org%3E];,
there can be issues with using native libraries and user code class loading.
h2. Steps to reproduce
I was able to reproduce the issue reported on the mailing list using
[snappy-java|https://github.com/xerial/snappy-java] in a user program. Running
the attached user program works fine on initial submission, but results in a
failure when re-executed.
I'm using Flink 1.7.0 using a standalone cluster started via
{{bin/start-cluster.sh}}.
0. Unpack attached Maven project and build using {{mvn clean package}} *or*
directly use attached {{hello-snappy-1.0-SNAPSHOT.jar}}
1. Download
[snappy-java-1.1.7.2.jar|http://central.maven.org/maven2/org/xerial/snappy/snappy-java/1.1.7.2/snappy-java-1.1.7.2.jar]
and unpack libsnappyjava for your system:
{code}
jar tf snappy-java-1.1.7.2.jar | grep libsnappy
...
org/xerial/snappy/native/Linux/x86_64/libsnappyjava.so
...
org/xerial/snappy/native/Mac/x86_64/libsnappyjava.jnilib
...
{code}
2. Configure system library path to {{libsnappyjava}} in {{flink-conf.yaml}}
(path needs to be adjusted for your system):
{code}
env.java.opts: -Djava.library.path=/.../org/xerial/snappy/native/Mac/x86_64
{code}
3. Run attached {{hello-snappy-1.0-SNAPSHOT.jar}}
{code}
bin/flink run hello-snappy-1.0-SNAPSHOT.jar
Starting execution of program
Program execution finished
Job with JobID ae815b918dd7bc64ac8959e4e224f2b4 has finished.
Job Runtime: 359 ms
{code}
4. Rerun attached {{hello-snappy-1.0-SNAPSHOT.jar}}
{code}
bin/flink run hello-snappy-1.0-SNAPSHOT.jar
Starting execution of program
The program finished with the following exception:
org.apache.flink.client.program.ProgramInvocationException: Job failed. (JobID:
7d69baca58f33180cb9251449ddcd396)
at
org.apache.flink.client.program.rest.RestClusterClient.submitJob(RestClusterClient.java:268)
at org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:487)
at
org.apache.flink.streaming.api.environment.StreamContextEnvironment.execute(StreamContextEnvironment.java:66)
at com.github.uce.HelloSnappy.main(HelloSnappy.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.flink.client.program.PackagedProgram.callMainMethod(PackagedProgram.java:529)
at
org.apache.flink.client.program.PackagedProgram.invokeInteractiveModeForExecution(PackagedProgram.java:421)
at org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:427)
at
org.apache.flink.client.cli.CliFrontend.executeProgram(CliFrontend.java:813)
at org.apache.flink.client.cli.CliFrontend.runProgram(CliFrontend.java:287)
at org.apache.flink.client.cli.CliFrontend.run(CliFrontend.java:213)
at
org.apache.flink.client.cli.CliFrontend.parseParameters(CliFrontend.java:1050)
at
org.apache.flink.client.cli.CliFrontend.lambda$main$11(CliFrontend.java:1126)
at
org.apache.flink.runtime.security.NoOpSecurityContext.runSecured(NoOpSecurityContext.java:30)
at org.apache.flink.client.cli.CliFrontend.main(CliFrontend.java:1126)
Caused by: org.apache.flink.runtime.client.JobExecutionException: Job execution
failed.
at
org.apache.flink.runtime.jobmaster.JobResult.toJobExecutionResult(JobResult.java:146)
at
org.apache.flink.client.program.rest.RestClusterClient.submitJob(RestClusterClient.java:265)
... 17 more
Caused by: java.lang.UnsatisfiedLinkError: Native Library
/.../org/xerial/snappy/native/Mac/x86_64/libsnappyjava.jnilib already loaded in
another classloader
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1907)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1861)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:182)
at org.xerial.snappy.SnappyLoader.loadSnappyApi(SnappyLoader.java:154)
at org.xerial.snappy.Snappy.(Snappy.java:47)
at
[jira] [Created] (FLINK-11401) Allow compression on ParquetBulkWriter
Fokko Driesprong created FLINK-11401: Summary: Allow compression on ParquetBulkWriter Key: FLINK-11401 URL: https://issues.apache.org/jira/browse/FLINK-11401 Project: Flink Issue Type: Improvement Affects Versions: 1.7.1 Reporter: Fokko Driesprong Assignee: Fokko Driesprong Fix For: 1.8.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [ANNOUNCE] Contributing Alibaba's Blink
Thanks Stephan! We are hoping to make the process as non-disruptive as possible to the Flink community. Making the Blink codebase public is the first step that hopefully facilitates further discussions. Xiaowei On Monday, January 21, 2019, 11:46:28 AM PST, Stephan Ewen wrote: Dear Flink Community! Some of you may have heard it already from announcements or from a Flink Forward talk: Alibaba has decided to open source its in-house improvements to Flink, called Blink! First of all, big thanks to team that developed these improvements and made this contribution possible! Blink has some very exciting enhancements, most prominently on the Table API/SQL side and the unified execution of these programs. For batch (bounded) data, the SQL execution has full TPC-DS coverage (which is a big deal), and the execution is more than 10x faster than the current SQL runtime in Flink. Blink has also added support for catalogs, improved the failover speed of batch queries and the resource management. It also makes some good steps in the direction of more deeply unifying the batch and streaming execution. The proposal is to merge Blink's enhancements into Flink, to give Flink's SQL/Table API and execution a big boost in usability and performance. Just to avoid any confusion: This is not a suggested change of focus to batch processing, nor would this break with any of the streaming architecture and vision of Flink. This contribution follows very much the principle of "batch is a special case of streaming". As a special case, batch makes special optimizations possible. In its current state, Flink does not exploit many of these optimizations. This contribution adds exactly these optimizations and makes the streaming model of Flink applicable to harder batch use cases. Assuming that the community is excited about this as well, and in favor of these enhancements to Flink's capabilities, below are some thoughts on how this contribution and integration could work. --- Making the code available --- At the moment, the Blink code is in the form of a big Flink fork (rather than isolated patches on top of Flink), so the integration is unfortunately not as easy as merging a few patches or pull requests. To support a non-disruptive merge of such a big contribution, I believe it make sense to make the code of the fork available in the Flink project first. >From there on, we can start to work on the details for merging the enhancements, including the refactoring of the necessary parts in the Flink master and the Blink code to make a merge possible without repeatedly breaking compatibility. The first question is where do we put the code of the Blink fork during the merging procedure? My first thought was to temporarily add a repository (like "flink-blink-staging"), but we could also put it into a special branch in the main Flink repository. I will start a separate thread about discussing a possible strategy to handle and merge such a big contribution. Best, Stephan
[ANNOUNCE] Contributing Alibaba's Blink
Dear Flink Community! Some of you may have heard it already from announcements or from a Flink Forward talk: Alibaba has decided to open source its in-house improvements to Flink, called Blink! First of all, big thanks to team that developed these improvements and made this contribution possible! Blink has some very exciting enhancements, most prominently on the Table API/SQL side and the unified execution of these programs. For batch (bounded) data, the SQL execution has full TPC-DS coverage (which is a big deal), and the execution is more than 10x faster than the current SQL runtime in Flink. Blink has also added support for catalogs, improved the failover speed of batch queries and the resource management. It also makes some good steps in the direction of more deeply unifying the batch and streaming execution. The proposal is to merge Blink's enhancements into Flink, to give Flink's SQL/Table API and execution a big boost in usability and performance. Just to avoid any confusion: This is not a suggested change of focus to batch processing, nor would this break with any of the streaming architecture and vision of Flink. This contribution follows very much the principle of "batch is a special case of streaming". As a special case, batch makes special optimizations possible. In its current state, Flink does not exploit many of these optimizations. This contribution adds exactly these optimizations and makes the streaming model of Flink applicable to harder batch use cases. Assuming that the community is excited about this as well, and in favor of these enhancements to Flink's capabilities, below are some thoughts on how this contribution and integration could work. --- Making the code available --- At the moment, the Blink code is in the form of a big Flink fork (rather than isolated patches on top of Flink), so the integration is unfortunately not as easy as merging a few patches or pull requests. To support a non-disruptive merge of such a big contribution, I believe it make sense to make the code of the fork available in the Flink project first. >From there on, we can start to work on the details for merging the enhancements, including the refactoring of the necessary parts in the Flink master and the Blink code to make a merge possible without repeatedly breaking compatibility. The first question is where do we put the code of the Blink fork during the merging procedure? My first thought was to temporarily add a repository (like "flink-blink-staging"), but we could also put it into a special branch in the main Flink repository. I will start a separate thread about discussing a possible strategy to handle and merge such a big contribution. Best, Stephan
issue in the MetricReporterRegistry
Hi
I don't have the jira permission but If you grant me the permission I could
contribute to fix the following issue:
When using java 11, "metrics.reporters" configuration has to be provided
for reporters to be taken into account.
The desired behavior:
The MetricRegistryConfiguration looks for a conf like "metrics.reporters =
foo,bar", if not found: all reporters that could be found in the
configuration will be started.
In the code is it done by
Set includedReporters =
reporterListPattern.splitAsStream(includedReportersString).collect(Collectors.toSet());
https://github.com/apache/flink/blob/master/flink-runtime/src/main/java/org/apache/flink/runtime/metrics/MetricRegistryConfiguration.java#L134
Definition of splitAsStream: If this pattern does not match any subsequence
of the input then the resulting stream has just one element, namely the
input sequence in string form.
It means reporterListPattern.splitAsStream("") should return "" and so
includedReporters should have size 1 with "" as unique element
However there is a misbehavior in some version of java 8, it does return
empty stream.
But working with java 11, the further code does not work: if
(includedReporters.isEmpty() || includedReporters.contains(reporterName))
https://github.com/apache/flink/blob/master/flink-runtime/src/main/java/org/apache/flink/runtime/metrics/MetricRegistryConfiguration.java#L145
I would suggest to filter empty string:
Set includedReporters =
reporterListPattern.splitAsStream(includedReportersString).*filter(s ->
!s.isEmpty())*.collect(Collectors.toSet());
Regards
Matthieu Bonneviot
--
Matthieu Bonneviot
Senior Engineer, DataDome
M +33 7 68 29 79 34 <+33+7+68+29+79+34>
E matthieu.bonnev...@datadome.co
W www.datadome.co
DataDome
ranked 'Strong Performer' in latest Forrester Bot management report
[jira] [Created] (FLINK-11400) JobManagerRunner does not wait for suspension of JobMaster
Till Rohrmann created FLINK-11400:
-
Summary: JobManagerRunner does not wait for suspension of JobMaster
Key: FLINK-11400
URL: https://issues.apache.org/jira/browse/FLINK-11400
Project: Flink
Issue Type: Bug
Components: Distributed Coordination
Affects Versions: 1.7.1, 1.6.3, 1.8.0
Reporter: Till Rohrmann
Assignee: Till Rohrmann
Fix For: 1.8.0
The {{JobManagerRunner}} does not wait for the suspension of the {{JobMaster}}
to finish before granting leadership again. This can lead to a state where the
{{JobMaster}} tries to start the {{ExecutionGraph}} but the {{SlotPool}} is
still stopped.
I suggest to linearize the leadership operations (granting and revoking
leadership) similarly to the {{Dispatcher}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FLINK-11399) Parsing nested ROW()s in SQL
Benoît Paris created FLINK-11399:
Summary: Parsing nested ROW()s in SQL
Key: FLINK-11399
URL: https://issues.apache.org/jira/browse/FLINK-11399
Project: Flink
Issue Type: Bug
Components: Table API SQL
Affects Versions: 1.7.1
Reporter: Benoît Paris
Hi!
I'm trying to build a nested structure in SQL (mapping to json with
flink-json). This works fine:
{code:java}
INSERT INTO outputTable
SELECT ROW(col1, col2)
FROM (
SELECT
col1,
ROW(col1, col1) as col2
FROM inputTable
) tbl2
{code}
(and I use it as a workaround), but it fails in the simpler version:
{code:java}
INSERT INTO outputTable
SELECT ROW(col1, ROW(col1, col1))
FROM inputTable
{code}
, yielding the following stacktrace:
{noformat}
Exception in thread "main" org.apache.flink.table.api.SqlParserException: SQL
parse failed. Encountered ", ROW" at line 1, column 40.
Was expecting one of:
")" ...
"," ...
"," ...
"," ...
"," ...
"," ...
at
org.apache.flink.table.calcite.FlinkPlannerImpl.parse(FlinkPlannerImpl.scala:94)
at
org.apache.flink.table.api.TableEnvironment.sqlUpdate(TableEnvironment.scala:803)
at
org.apache.flink.table.api.TableEnvironment.sqlUpdate(TableEnvironment.scala:777)
at TestBug.main(TestBug.java:32)
Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered ", ROW"
at line 1, column 40.
Was expecting one of:
")" ...
"," ...
"," ...
"," ...
"," ...
"," ...
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:347)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:128)
at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:137)
at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:162)
at
org.apache.flink.table.calcite.FlinkPlannerImpl.parse(FlinkPlannerImpl.scala:90)
... 3 more
Caused by: org.apache.calcite.sql.parser.impl.ParseException: Encountered ",
ROW" at line 1, column 40.
Was expecting one of:
")" ...
"," ...
"," ...
"," ...
"," ...
"," ...
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.generateParseException(SqlParserImpl.java:23019)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_consume_token(SqlParserImpl.java:22836)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.ParenthesizedSimpleIdentifierList(SqlParserImpl.java:4466)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.Expression3(SqlParserImpl.java:3328)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.Expression2b(SqlParserImpl.java:3066)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.Expression2(SqlParserImpl.java:3092)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.Expression(SqlParserImpl.java:3045)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SelectExpression(SqlParserImpl.java:1525)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SelectItem(SqlParserImpl.java:1500)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SelectList(SqlParserImpl.java:1477)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlSelect(SqlParserImpl.java:912)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.LeafQuery(SqlParserImpl.java:552)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.LeafQueryOrExpr(SqlParserImpl.java:3030)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.QueryOrExpr(SqlParserImpl.java:2949)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.OrderedQueryOrExpr(SqlParserImpl.java:463)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlInsert(SqlParserImpl.java:1212)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlStmt(SqlParserImpl.java:847)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlStmtEof(SqlParserImpl.java:869)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.parseSqlStmtEof(SqlParserImpl.java:184)
at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:130)
... 5 more{noformat}
I was thinking it could be a naming/referencing issue; or I was not using ROW()
properly, in the json-idiomatic way I want to push on it.
Anyway this is very minor, thanks for all the good work on Flink!
Cheers,
Ben
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FLINK-11398) Add a dedicated phase to materialize time indicators for nodes produce updates
Hequn Cheng created FLINK-11398: --- Summary: Add a dedicated phase to materialize time indicators for nodes produce updates Key: FLINK-11398 URL: https://issues.apache.org/jira/browse/FLINK-11398 Project: Flink Issue Type: Improvement Components: Table API SQL Reporter: Hequn Cheng Assignee: Hequn Cheng As discussed [here|https://github.com/apache/flink/pull/6787#discussion_r249056249], we need a dedicated phase to materialize time indicators for nodes produce updates. Details: Currently, we materialize time indicators in `RelTimeInidicatorConverter`. We need to introduce another materialize phase that materializes all time attributes on nodes that produce updates. We can not do it inside `RelTimeInidicatorConverter`, because only later, after physical optimization phase, we know whether it is a non-window outer join which will produce updates There are a few other things we need to consider. - Whether we can unify the two converter phase. - Take window with early fire into consideration(not been implemented yet). In this case, we don't need to materialize time indicators even it produces updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Apply for flink contributor permission
Hi ildglh, Welcome as well! Done. Best, Fabian Am Mo., 21. Jan. 2019 um 11:54 Uhr schrieb ildglh : > Hi, guys > > Could anyone kindly give me the contributor permission? > My JIRA id is ildglh. > > Best regards, > ildglh > > > > -- > Sent from: http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/ >
Re: Apply for flink contributor permission
Hi Kezhu Wang, Welcome to the Flink community. I gave you contributor permissions. Best, Fabian Am So., 20. Jan. 2019 um 21:00 Uhr schrieb Kezhu Wang : > Hi guys: > > Could someone give me contributor permission? > > My JIRA username is kezhuw > > Thanks, > Kezhu Wang >
Apply for flink contributor permission
Hi, guys Could anyone kindly give me the contributor permission? My JIRA id is ildglh. Best regards, ildglh -- Sent from: http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/
[jira] [Created] (FLINK-11397) Speed up initialization of AbstractStreamOperatorTestHarness
TisonKun created FLINK-11397:
Summary: Speed up initialization of
AbstractStreamOperatorTestHarness
Key: FLINK-11397
URL: https://issues.apache.org/jira/browse/FLINK-11397
Project: Flink
Issue Type: Improvement
Components: Tests
Affects Versions: 1.8.0
Reporter: TisonKun
Currently Kafka connector tests are unbearably slow, which is tracked by
FLINK-10603. With investigation, the construction and initialization of
{{AbstractStreamOperatorTestHarness}} is quite slow.
When walk down the code, it amazed me that {{mockTask =
mock(StreamTask.class);}} cost a few of second to finish. If we can introduce a
test class instead of mock framework, the situation might be loosen.
cc [~Zentol] [~pnowojski]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
