[jira] [Created] (FLINK-9225) Minor code comments fix in RuntimeContext
binlijin created FLINK-9225:
---
Summary: Minor code comments fix in RuntimeContext
Key: FLINK-9225
URL: https://issues.apache.org/jira/browse/FLINK-9225
Project: Flink
Issue Type: Bug
Reporter: binlijin
* {@code
* DataStream stream = ...;
* KeyedStream keyedStream = stream.keyBy("id");
*
* keyedStream.map(new RichMapFunction>() {
*
* private ValueState count;
*
* public void open(Configuration cfg) {
* state = getRuntimeContext().getState(
* new ValueStateDescriptor("count",
LongSerializer.INSTANCE, 0L));
* }
*
* public Tuple2 map(MyType value) {
* long count = state.value() + 1;
* state.update(value);
* return new Tuple2<>(value, count);
* }
* });
* }
"private ValueState count;" should be "private ValueState state;"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FLINK-9224) Add Bucketing e2e test script to run-pre-commit-tests.sh
mingleizhang created FLINK-9224:
---
Summary: Add Bucketing e2e test script to run-pre-commit-tests.sh
Key: FLINK-9224
URL: https://issues.apache.org/jira/browse/FLINK-9224
Project: Flink
Issue Type: Improvement
Reporter: mingleizhang
Assignee: mingleizhang
The {{test_streaming_bucketing.sh}} does not add to {{run-pre-commit-tests.sh}}
now, the latter will be executed by Travis that would verify e2e test whether
correct or incorrect. So, we should add it and make Travis execute it for every
git commits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: TaskManager deadlock on NetworkBufferPool
Please use this link. https://gist.github.com/imamitjain/5ab84c2d9eaf06615ad912506a08f7e2 On Thu, Apr 19, 2018 at 10:37 PM, Ted Yu wrote: > Amit: > Execution plan attachment didn't come through. > > Please consider using third party website for storing the plan. > > FYI > > On Thu, Apr 19, 2018 at 10:04 AM, Amit Jain wrote: > > > @Ufuk Please find execution plan in the attachment. > > > > @Nico Job is not making progress at all. This issue is happening > > randomly. Few of our jobs are working with only few MB of data and still, > > they are getting stuck even TM have 22G with 2 slots per TM. > > > > I've started using 1.5 and facing few issues which I'm communicating with > > community these days. However, this issue seems to be solved there :-) Do > > you guys have a timeline for 1.5 release? > > > > -- > > Thanks, > > Amit > > > > > > > > > > > > On Fri, Apr 6, 2018 at 10:40 PM, Ufuk Celebi wrote: > > > >> Hey Amit! > >> > >> Thanks for posting this here. I don't think it's an issue of the > >> buffer pool per se. Instead I think there are two potential causes > >> here: > >> > >> 1. The generated flow doesn't use blocking intermediate results for a > >> branching-joining flow. > >> => I think we can check it if you run and post the output of > >> `StreamExecutionEnvironment#getExecutionPlan()` here. Can you please > >> post the result of this here? > >> > >> 2. The blocking intermediate result is used but there is an issue with > >> the implementation of them. > >> => Depending on the output of 1, we can investigate this option. > >> > >> As Fabian mentioned, running this with a newer version of Flink will > >> be very helpful. If the problem still persists, it will also make it > >> more likely that the issue will be fixed faster. ;-) > >> > >> – Ufuk > >> > >> > >> On Fri, Apr 6, 2018 at 5:43 AM, Nico Kruber > >> wrote: > >> > I'm not aware of any changes regarding the blocking buffer pools > though. > >> > > >> > Is it really stuck or just making progress slowly? (You can check with > >> > the number or records sent/received in the Web UI) > >> > > >> > Anyway, this may also simply mean that the task is back-pressured > >> > depending on how the operators are wired together. In that case, all > >> > available buffers for that ResultPartition have been used (records > were > >> > serialized into them) and are now waiting on Netty to send or a > >> > SpillingSubpartition to spill data to disk. > >> > Please also check for warnings or errors in the affected TaskManager's > >> > log files. > >> > > >> > If you can reproduce the problem, could you try reducing your program > to > >> > a minimal working example and provide it here for further debugging? > >> > > >> > > >> > Thanks > >> > Nico > >> > > >> > On 04/04/18 23:00, Fabian Hueske wrote: > >> >> Hi Amit, > >> >> > >> >> The network stack has been redesigned for the upcoming Flink 1.5 > >> release. > >> >> The issue might have been fixed by that. > >> >> > >> >> There's already a first release candidate for Flink 1.5.0 available > >> [1]. > >> >> It would be great if you would have the chance to check if the bug is > >> still > >> >> present. > >> >> > >> >> Best, Fabian > >> >> > >> >> [1] > >> >> https://lists.apache.org/thread.html/a6b6fb1a42a975608fa8641 > >> c86df30b47f022985ade845f1f1ec542a@%3Cdev.flink.apache.org%3E > >> >> > >> >> 2018-04-04 20:23 GMT+02:00 Ted Yu : > >> >> > >> >>> I searched for 0x0005e28fe218 in the two files you attached > >> >>> to FLINK-2685 but didn't find any hit. > >> >>> > >> >>> Was this the same instance as the attachment to FLINK-2685 ? > >> >>> > >> >>> Thanks > >> >>> > >> >>> On Wed, Apr 4, 2018 at 10:21 AM, Amit Jain > >> wrote: > >> >>> > >> +u...@flink.apache.org > >> > >> On Wed, Apr 4, 2018 at 11:33 AM, Amit Jain > >> wrote: > >> > Hi, > >> > > >> > We are hitting TaskManager deadlock on NetworkBufferPool bug in > >> Flink > >> 1.3.2. > >> > We have set of ETL's merge jobs for a number of tables and stuck > >> with > >> above > >> > issue randomly daily. > >> > > >> > I'm attaching the thread dump of JobManager and one of the Task > >> Manager > >> (T1) > >> > running stuck job. > >> > We also observed, sometimes new job scheduled on T1 progresses > even > >> another > >> > job is stuck there. > >> > > >> > "CHAIN DataSource (at createInput(ExecutionEnvironment.java:553) > >> > (org.apache.flink.api.java.hadoop.mapreduce.HadoopInputFormat)) > -> > >> Map > >> (Map > >> > at main(MergeTableSecond.java:175)) -> Map (Key Extractor) (6/9)" > >> >>> #1501 > >> > daemon prio=5 os_prio=0 tid=0x7f9ea84d2fb0 nid=0x22fe in > >> Object.wait() > >> > [0x7f9ebf102000] > >> >java.lang.Thread.State: TIMED_WAITING (on object monitor) > >> > at java.lang.Object.wait(Native Method) > >> > at > >> > org.apache.flink.runtime.io.network.buffer. > >> LocalBufferPool.reques
Re: TaskManager deadlock on NetworkBufferPool
Amit: Execution plan attachment didn't come through. Please consider using third party website for storing the plan. FYI On Thu, Apr 19, 2018 at 10:04 AM, Amit Jain wrote: > @Ufuk Please find execution plan in the attachment. > > @Nico Job is not making progress at all. This issue is happening > randomly. Few of our jobs are working with only few MB of data and still, > they are getting stuck even TM have 22G with 2 slots per TM. > > I've started using 1.5 and facing few issues which I'm communicating with > community these days. However, this issue seems to be solved there :-) Do > you guys have a timeline for 1.5 release? > > -- > Thanks, > Amit > > > > > > On Fri, Apr 6, 2018 at 10:40 PM, Ufuk Celebi wrote: > >> Hey Amit! >> >> Thanks for posting this here. I don't think it's an issue of the >> buffer pool per se. Instead I think there are two potential causes >> here: >> >> 1. The generated flow doesn't use blocking intermediate results for a >> branching-joining flow. >> => I think we can check it if you run and post the output of >> `StreamExecutionEnvironment#getExecutionPlan()` here. Can you please >> post the result of this here? >> >> 2. The blocking intermediate result is used but there is an issue with >> the implementation of them. >> => Depending on the output of 1, we can investigate this option. >> >> As Fabian mentioned, running this with a newer version of Flink will >> be very helpful. If the problem still persists, it will also make it >> more likely that the issue will be fixed faster. ;-) >> >> – Ufuk >> >> >> On Fri, Apr 6, 2018 at 5:43 AM, Nico Kruber >> wrote: >> > I'm not aware of any changes regarding the blocking buffer pools though. >> > >> > Is it really stuck or just making progress slowly? (You can check with >> > the number or records sent/received in the Web UI) >> > >> > Anyway, this may also simply mean that the task is back-pressured >> > depending on how the operators are wired together. In that case, all >> > available buffers for that ResultPartition have been used (records were >> > serialized into them) and are now waiting on Netty to send or a >> > SpillingSubpartition to spill data to disk. >> > Please also check for warnings or errors in the affected TaskManager's >> > log files. >> > >> > If you can reproduce the problem, could you try reducing your program to >> > a minimal working example and provide it here for further debugging? >> > >> > >> > Thanks >> > Nico >> > >> > On 04/04/18 23:00, Fabian Hueske wrote: >> >> Hi Amit, >> >> >> >> The network stack has been redesigned for the upcoming Flink 1.5 >> release. >> >> The issue might have been fixed by that. >> >> >> >> There's already a first release candidate for Flink 1.5.0 available >> [1]. >> >> It would be great if you would have the chance to check if the bug is >> still >> >> present. >> >> >> >> Best, Fabian >> >> >> >> [1] >> >> https://lists.apache.org/thread.html/a6b6fb1a42a975608fa8641 >> c86df30b47f022985ade845f1f1ec542a@%3Cdev.flink.apache.org%3E >> >> >> >> 2018-04-04 20:23 GMT+02:00 Ted Yu : >> >> >> >>> I searched for 0x0005e28fe218 in the two files you attached >> >>> to FLINK-2685 but didn't find any hit. >> >>> >> >>> Was this the same instance as the attachment to FLINK-2685 ? >> >>> >> >>> Thanks >> >>> >> >>> On Wed, Apr 4, 2018 at 10:21 AM, Amit Jain >> wrote: >> >>> >> +u...@flink.apache.org >> >> On Wed, Apr 4, 2018 at 11:33 AM, Amit Jain >> wrote: >> > Hi, >> > >> > We are hitting TaskManager deadlock on NetworkBufferPool bug in >> Flink >> 1.3.2. >> > We have set of ETL's merge jobs for a number of tables and stuck >> with >> above >> > issue randomly daily. >> > >> > I'm attaching the thread dump of JobManager and one of the Task >> Manager >> (T1) >> > running stuck job. >> > We also observed, sometimes new job scheduled on T1 progresses even >> another >> > job is stuck there. >> > >> > "CHAIN DataSource (at createInput(ExecutionEnvironment.java:553) >> > (org.apache.flink.api.java.hadoop.mapreduce.HadoopInputFormat)) -> >> Map >> (Map >> > at main(MergeTableSecond.java:175)) -> Map (Key Extractor) (6/9)" >> >>> #1501 >> > daemon prio=5 os_prio=0 tid=0x7f9ea84d2fb0 nid=0x22fe in >> Object.wait() >> > [0x7f9ebf102000] >> >java.lang.Thread.State: TIMED_WAITING (on object monitor) >> > at java.lang.Object.wait(Native Method) >> > at >> > org.apache.flink.runtime.io.network.buffer. >> LocalBufferPool.requestBuffer(LocalBufferPool.java:224) >> > - locked <0x0005e28fe218> (a java.util.ArrayDeque) >> > at >> > org.apache.flink.runtime.io.network.buffer.LocalBufferPool. >> requestBufferBlocking(LocalBufferPool.java:193) >> > at >> > org.apache.flink.runtime.io.network.api.writer. >> RecordWriter.sendToTarget(RecordWriter.java:132) >> > - locked <0x0005e29125f0> (a >> > org.apache.flink.r
Re: TaskManager deadlock on NetworkBufferPool
@Ufuk Please find execution plan in the attachment. @Nico Job is not making progress at all. This issue is happening randomly. Few of our jobs are working with only few MB of data and still, they are getting stuck even TM have 22G with 2 slots per TM. I've started using 1.5 and facing few issues which I'm communicating with community these days. However, this issue seems to be solved there :-) Do you guys have a timeline for 1.5 release? -- Thanks, Amit On Fri, Apr 6, 2018 at 10:40 PM, Ufuk Celebi wrote: > Hey Amit! > > Thanks for posting this here. I don't think it's an issue of the > buffer pool per se. Instead I think there are two potential causes > here: > > 1. The generated flow doesn't use blocking intermediate results for a > branching-joining flow. > => I think we can check it if you run and post the output of > `StreamExecutionEnvironment#getExecutionPlan()` here. Can you please > post the result of this here? > > 2. The blocking intermediate result is used but there is an issue with > the implementation of them. > => Depending on the output of 1, we can investigate this option. > > As Fabian mentioned, running this with a newer version of Flink will > be very helpful. If the problem still persists, it will also make it > more likely that the issue will be fixed faster. ;-) > > – Ufuk > > > On Fri, Apr 6, 2018 at 5:43 AM, Nico Kruber > wrote: > > I'm not aware of any changes regarding the blocking buffer pools though. > > > > Is it really stuck or just making progress slowly? (You can check with > > the number or records sent/received in the Web UI) > > > > Anyway, this may also simply mean that the task is back-pressured > > depending on how the operators are wired together. In that case, all > > available buffers for that ResultPartition have been used (records were > > serialized into them) and are now waiting on Netty to send or a > > SpillingSubpartition to spill data to disk. > > Please also check for warnings or errors in the affected TaskManager's > > log files. > > > > If you can reproduce the problem, could you try reducing your program to > > a minimal working example and provide it here for further debugging? > > > > > > Thanks > > Nico > > > > On 04/04/18 23:00, Fabian Hueske wrote: > >> Hi Amit, > >> > >> The network stack has been redesigned for the upcoming Flink 1.5 > release. > >> The issue might have been fixed by that. > >> > >> There's already a first release candidate for Flink 1.5.0 available [1]. > >> It would be great if you would have the chance to check if the bug is > still > >> present. > >> > >> Best, Fabian > >> > >> [1] > >> https://lists.apache.org/thread.html/a6b6fb1a42a975608fa8641c86df30 > b47f022985ade845f1f1ec542a@%3Cdev.flink.apache.org%3E > >> > >> 2018-04-04 20:23 GMT+02:00 Ted Yu : > >> > >>> I searched for 0x0005e28fe218 in the two files you attached > >>> to FLINK-2685 but didn't find any hit. > >>> > >>> Was this the same instance as the attachment to FLINK-2685 ? > >>> > >>> Thanks > >>> > >>> On Wed, Apr 4, 2018 at 10:21 AM, Amit Jain wrote: > >>> > +u...@flink.apache.org > > On Wed, Apr 4, 2018 at 11:33 AM, Amit Jain > wrote: > > Hi, > > > > We are hitting TaskManager deadlock on NetworkBufferPool bug in Flink > 1.3.2. > > We have set of ETL's merge jobs for a number of tables and stuck with > above > > issue randomly daily. > > > > I'm attaching the thread dump of JobManager and one of the Task > Manager > (T1) > > running stuck job. > > We also observed, sometimes new job scheduled on T1 progresses even > another > > job is stuck there. > > > > "CHAIN DataSource (at createInput(ExecutionEnvironment.java:553) > > (org.apache.flink.api.java.hadoop.mapreduce.HadoopInputFormat)) -> > Map > (Map > > at main(MergeTableSecond.java:175)) -> Map (Key Extractor) (6/9)" > >>> #1501 > > daemon prio=5 os_prio=0 tid=0x7f9ea84d2fb0 nid=0x22fe in > Object.wait() > > [0x7f9ebf102000] > >java.lang.Thread.State: TIMED_WAITING (on object monitor) > > at java.lang.Object.wait(Native Method) > > at > > org.apache.flink.runtime.io.network.buffer. > LocalBufferPool.requestBuffer(LocalBufferPool.java:224) > > - locked <0x0005e28fe218> (a java.util.ArrayDeque) > > at > > org.apache.flink.runtime.io.network.buffer.LocalBufferPool. > requestBufferBlocking(LocalBufferPool.java:193) > > at > > org.apache.flink.runtime.io.network.api.writer. > RecordWriter.sendToTarget(RecordWriter.java:132) > > - locked <0x0005e29125f0> (a > > org.apache.flink.runtime.io.network.api.serialization. > SpanningRecordSerializer) > > at > > org.apache.flink.runtime.io.network.api.writer.RecordWriter.emit( > RecordWriter.java:89) > > at > > org.apache.flink.runtime.operators.shipping.OutputCollector.collect( > OutputCollector.java:65) > > at > > org.apache.fli
[jira] [Created] (FLINK-9223) bufferConsumers should be closed in SpillableSubpartitionTest#testConsumeSpilledPartitionSpilledBeforeAdd
Ted Yu created FLINK-9223:
-
Summary: bufferConsumers should be closed in
SpillableSubpartitionTest#testConsumeSpilledPartitionSpilledBeforeAdd
Key: FLINK-9223
URL: https://issues.apache.org/jira/browse/FLINK-9223
Project: Flink
Issue Type: Test
Reporter: Ted Yu
{code}
BufferConsumer[] bufferConsumers = Arrays.stream(bufferBuilders).map(
BufferBuilder::createBufferConsumer
).toArray(BufferConsumer[]::new);
{code}
After operation on bufferConsumers is done, the BufferConsumer's in the array
should be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FLINK-9222) Add a Gradle Quickstart
Nico Kruber created FLINK-9222: -- Summary: Add a Gradle Quickstart Key: FLINK-9222 URL: https://issues.apache.org/jira/browse/FLINK-9222 Project: Flink Issue Type: Improvement Components: Quickstarts Reporter: Nico Kruber Having a proper project template helps a lot in getting dependencies right. For example, setting the core dependencies to "provided", the connector / library dependencies to "compile", etc. The Maven quickstarts are in good shape by now, but I observed SBT and Gradle users to get this wrong quite often. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FLINK-9221) Add method SinkFunction[A]#contramap[B](f: B => A): SinkFunction[B]
Josh Lemer created FLINK-9221:
-
Summary: Add method SinkFunction[A]#contramap[B](f: B => A):
SinkFunction[B]
Key: FLINK-9221
URL: https://issues.apache.org/jira/browse/FLINK-9221
Project: Flink
Issue Type: Task
Reporter: Josh Lemer
Just like it is very useful to use `DataStream[T]` as a sort of Functor or
Monad with `map`/`flatMap`/`filter` methods, it would be extremely handy to
have a `SinkFunction[A]#contramap[B](f: B => A): SinkFunction[B]` on
`SinkFunctions`, so that you can reuse existing complex sink functions, but
with a different input type. For example:
{code}
val bucketingStringSink: SinkFunction[String] =
new BucketingSink[String]("...")
.setBucketr(new DateTimeBucketer("-MM-dd-HHmm")
val bucketingIntListSink: SinkFunction[List[Int]] =
bucketingStringSink.contramap[List[Int]](_.mkString(","))
{code}
For some more formal motivation behind this,
https://typelevel.org/cats/typeclasses/contravariant.html is definitely a great
place to start!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FLINK-9220) Table program cannot be compiled
Saurabh Garg created FLINK-9220: --- Summary: Table program cannot be compiled Key: FLINK-9220 URL: https://issues.apache.org/jira/browse/FLINK-9220 Project: Flink Issue Type: Bug Reporter: Saurabh Garg Flink job gets failed with scalar UDF. I am using Flink 1.4 Below is the error logs: org.apache.flink.api.common.InvalidProgramException: Table program cannot be compiled. This is a bug. Please file an issue. at org.apache.flink.table.codegen.Compiler$class.compile(Compiler.scala:36) at org.apache.flink.table.runtime.CRowProcessRunner.compile(CRowProcessRunner.scala:35) at org.apache.flink.table.runtime.CRowProcessRunner.open(CRowProcessRunner.scala:49) at org.apache.flink.api.common.functions.util.FunctionUtils.openFunction(FunctionUtils.java:36) at org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator.open(AbstractUdfStreamOperator.java:102) at org.apache.flink.streaming.api.operators.ProcessOperator.open(ProcessOperator.java:56) at org.apache.flink.streaming.runtime.tasks.StreamTask.openAllOperators(StreamTask.java:393) at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:254) at org.apache.flink.runtime.taskmanager.Task.run(Task.java:718) at java.lang.Thread.run(Thread.java:748) Caused by: org.codehaus.commons.compiler.CompileException: Line 6, Column 18: Cannot determine simple type name "com" at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:11672) at org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6416) at org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6177) at org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6190) at org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6190) at org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6190) at org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6190) at org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6156) at org.codehaus.janino.UnitCompiler.access$13300(UnitCompiler.java:212) at org.codehaus.janino.UnitCompiler$18$1.visitReferenceType(UnitCompiler.java:6064) at org.codehaus.janino.UnitCompiler$18$1.visitReferenceType(UnitCompiler.java:6059) at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3754) at org.codehaus.janino.UnitCompiler$18.visitType(UnitCompiler.java:6059) at org.codehaus.janino.UnitCompiler$18.visitType(UnitCompiler.java:6052) at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3753) at org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6052) at org.codehaus.janino.UnitCompiler.access$1200(UnitCompiler.java:212) at org.codehaus.janino.UnitCompiler$21.getType(UnitCompiler.java:7844) at org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6456) at org.codehaus.janino.UnitCompiler.access$13800(UnitCompiler.java:212) at org.codehaus.janino.UnitCompiler$18$2$1.visitFieldAccess(UnitCompiler.java:6082) at org.codehaus.janino.UnitCompiler$18$2$1.visitFieldAccess(UnitCompiler.java:6077) at org.codehaus.janino.Java$FieldAccess.accept(Java.java:4136) at org.codehaus.janino.UnitCompiler$18$2.visitLvalue(UnitCompiler.java:6077) at org.codehaus.janino.UnitCompiler$18$2.visitLvalue(UnitCompiler.java:6073) at org.codehaus.janino.Java$Lvalue.accept(Java.java:3974) at org.codehaus.janino.UnitCompiler$18.visitRvalue(UnitCompiler.java:6073) at org.codehaus.janino.UnitCompiler$18.visitRvalue(UnitCompiler.java:6052) at org.codehaus.janino.Java$Rvalue.accept(Java.java:3942) at org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6052) at org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6438) at org.codehaus.janino.UnitCompiler.access$13600(UnitCompiler.java:212) at org.codehaus.janino.UnitCompiler$18$2$1.visitAmbiguousName(UnitCompiler.java:6080) at org.codehaus.janino.UnitCompiler$18$2$1.visitAmbiguousName(UnitCompiler.java:6077) at org.codehaus.janino.Java$AmbiguousName.accept(Java.java:4050) at org.codehaus.janino.UnitCompiler$18$2.visitLvalue(UnitCompiler.java:6077) at org.codehaus.janino.UnitCompiler$18$2.visitLvalue(UnitCompiler.java:6073) at org.codehaus.janino.Java$Lvalue.accept(Java.java:3974) at org.codehaus.janino.UnitCompiler$18.visitRvalue(UnitCompiler.java:6073) at org.codehaus.janino.UnitCompiler$18.visitRvalue(UnitCompiler.java:6052) at org.codehaus.janino.Java$Rvalue.accept(Java.java:3942) at org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6052) at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8591) at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4708) at org.codehaus.janino.UnitCompiler.access$8200(UnitCompiler.java:212) at org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(UnitCompiler.java:4071) at org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(UnitCompiler.java:4044) at org.
[jira] [Created] (FLINK-9219) Add support for OpenGIS features in Table & SQL API
Timo Walther created FLINK-9219:
---
Summary: Add support for OpenGIS features in Table & SQL API
Key: FLINK-9219
URL: https://issues.apache.org/jira/browse/FLINK-9219
Project: Flink
Issue Type: New Feature
Components: Table API & SQL
Reporter: Timo Walther
CALCITE-1968 added core functionality for handling
spatial/geographical/geometry data. It should not be too hard to expose these
features also in Flink's Table & SQL API. We would need a new {{GEOMETRY}} data
type and connect the function APIs.
Right now the following functions are supported by Calcite:
{code}
ST_AsText, ST_AsWKT, ST_Boundary, ST_Buffer, ST_Contains, ST_ContainsProperly,
ST_Crosses, ST_Disjoint, ST_Distance, ST_DWithin, ST_Envelope,
ST_EnvelopesIntersect, ST_Equals, ST_GeometryType, ST_GeometryTypeCode,
ST_GeomFromText, ST_Intersects, ST_Is3D, ST_LineFromText, ST_MakeLine,
ST_MakePoint, ST_MLineFromText, ST_MPointFromText, ST_MPolyFromText,
ST_Overlaps, ST_Point, ST_PointFromText, ST_PolyFromText, ST_SetSRID,
ST_Touches, ST_Transform, ST_Union, ST_Within, ST_Z
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FLINK-9218) Docs for old versions aren't building successfully
Chesnay Schepler created FLINK-9218: --- Summary: Docs for old versions aren't building successfully Key: FLINK-9218 URL: https://issues.apache.org/jira/browse/FLINK-9218 Project: Flink Issue Type: Bug Components: Documentation, Project Website Affects Versions: 1.2.1, 1.1.4, 1.0.3 Reporter: Chesnay Schepler The [1.0|https://ci.apache.org/builders/flink-docs-release-1.0], [1.1|https://ci.apache.org/builders/flink-docs-release-1.1] and [1.2|https://ci.apache.org/builders/flink-docs-release-1.2] aren't currently building. My guess is this has to do with the dependency changes we recently made. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
