Yun Tang created FLINK-14495:
Summary: Add documentation for memory control of RocksDB state
backend with writebuffer manager
Key: FLINK-14495
URL: https://issues.apache.org/jira/browse/FLINK-14495
Projec
Dawid Wysakowicz created FLINK-14494:
Summary: Update documentation generator
Key: FLINK-14494
URL: https://issues.apache.org/jira/browse/FLINK-14494
Project: Flink
Issue Type: Sub-task
Dawid Wysakowicz created FLINK-14493:
Summary: Introduce data types to ConfigOptions
Key: FLINK-14493
URL: https://issues.apache.org/jira/browse/FLINK-14493
Project: Flink
Issue Type: Sub
Yu Li created FLINK-14492:
-
Summary: Modify state backend to report reserved memory to
MemoryManager
Key: FLINK-14492
URL: https://issues.apache.org/jira/browse/FLINK-14492
Project: Flink
Issue Type
Dawid Wysakowicz created FLINK-14491:
Summary: Introduce ConfigOptions with Data Types
Key: FLINK-14491
URL: https://issues.apache.org/jira/browse/FLINK-14491
Project: Flink
Issue Type: I
Dawid Wysakowicz created FLINK-14490:
Summary: Add methods for interacting with temporary objects
Key: FLINK-14490
URL: https://issues.apache.org/jira/browse/FLINK-14490
Project: Flink
Is
Yu Li created FLINK-14489:
-
Summary: Check and make sure state backend fits into TaskExecutor
memory configuration
Key: FLINK-14489
URL: https://issues.apache.org/jira/browse/FLINK-14489
Project: Flink
Dawid Wysakowicz created FLINK-14488:
Summary: Update python table API with temporary objects methods
Key: FLINK-14488
URL: https://issues.apache.org/jira/browse/FLINK-14488
Project: Flink
Dawid Wysakowicz created FLINK-14487:
Summary: Update chinese documentation regarding Temporary Objects
Key: FLINK-14487
URL: https://issues.apache.org/jira/browse/FLINK-14487
Project: Flink
Dawid Wysakowicz created FLINK-14486:
Summary: Update documentation
Key: FLINK-14486
URL: https://issues.apache.org/jira/browse/FLINK-14486
Project: Flink
Issue Type: Sub-task
C
Dawid Wysakowicz created FLINK-14485:
Summary: Support for Temporary Objects in Table module
Key: FLINK-14485
URL: https://issues.apache.org/jira/browse/FLINK-14485
Project: Flink
Issue T
Yun Tang created FLINK-14484:
Summary: Modify RocksDB backend to allow setting
WriteBufferManager via options
Key: FLINK-14484
URL: https://issues.apache.org/jira/browse/FLINK-14484
Project: Flink
Yun Tang created FLINK-14483:
Summary: Build and supply frocksdb version to support
WriteBufferManager
Key: FLINK-14483
URL: https://issues.apache.org/jira/browse/FLINK-14483
Project: Flink
Issu
Yun Tang created FLINK-14482:
Summary: Bump up rocksdb version to support WriteBufferManager
Key: FLINK-14482
URL: https://issues.apache.org/jira/browse/FLINK-14482
Project: Flink
Issue Type: Sub
Thank you all for the votes.
We got
* four +1(binding) votes (Kurt, Aljoscha, Jark, Timo) and one
non-binding (Tison)
* No -1 votes
Therefore, I'm glad to announce that FLIP-77 is approved to be adopted
by Apache Flink.
Best,
Dawid
On 16/10/2019 13:23, Zili Chen wrote:
> +1
>
> Best,
>
ming li created FLINK-14481:
---
Summary: Modify the Flink valid socket port check to 0 to 65535.
Key: FLINK-14481
URL: https://issues.apache.org/jira/browse/FLINK-14481
Project: Flink
Issue Type: Imp
Hi Thomas,
Thanks for sharing your thoughts. I think improve and solve the limitations
of the Beam artifact staging is good topic(For beam).
As I understand it as follows:
For Beam(data):
Stage1: BeamClient --> JobService (data will be upload to DFS).
Stage2: JobService(FlinkClient)
+1 (non-binding)
Thanks,
Biao /'bɪ.aʊ/
On Tue, 22 Oct 2019 at 10:26, Jark Wu wrote:
> +1 (non-binding)
>
> Best,
> Jark
>
> On Tue, 22 Oct 2019 at 09:38, Hequn Cheng wrote:
>
> > +1 (non-binding)
> >
> > Best, Hequn
> >
> > On Tue, Oct 22, 2019 at 9:21 AM Dian Fu wrote:
> >
> > > +1 (non-bi
+1 (non-binding)
Best,
Jark
On Tue, 22 Oct 2019 at 09:38, Hequn Cheng wrote:
> +1 (non-binding)
>
> Best, Hequn
>
> On Tue, Oct 22, 2019 at 9:21 AM Dian Fu wrote:
>
> > +1 (non-binding)
> >
> > Regards,
> > Dian
> >
> > > 在 2019年10月22日，上午9:10，Kurt Young 写道：
> > >
> > > +1 (binding)
> > >
> >
“OPAQUE” seems a little strange to me.
+ 1 for ‘RAW’.
Best,
Terry Wang
> 2019年10月22日 09:19，Kurt Young 写道：
>
> +1 to RAW, if there's no better candidate comes up.
>
> Best,
> Kurt
>
>
> On Mon, Oct 21, 2019 at 9:25 PM Timo Walther wrote:
>
>> I would also avoid `UNKNOWN` because of the me
+1 (non-binding)
Best, Hequn
On Tue, Oct 22, 2019 at 9:21 AM Dian Fu wrote:
> +1 (non-binding)
>
> Regards,
> Dian
>
> > 在 2019年10月22日，上午9:10，Kurt Young 写道：
> >
> > +1 (binding)
> >
> > Best,
> > Kurt
> >
> >
> > On Tue, Oct 22, 2019 at 12:56 AM Fabian Hueske
> wrote:
> >
> >> +1 (binding)
>
+1 (non-binding)
Regards,
Dian
> 在 2019年10月22日，上午9:10，Kurt Young 写道：
>
> +1 (binding)
>
> Best,
> Kurt
>
>
> On Tue, Oct 22, 2019 at 12:56 AM Fabian Hueske wrote:
>
>> +1 (binding)
>>
>> Am Mo., 21. Okt. 2019 um 16:18 Uhr schrieb Thomas Weise :
>>
>>> +1 (binding)
>>>
>>>
>>> On Mon, O
+1 to RAW, if there's no better candidate comes up.
Best,
Kurt
On Mon, Oct 21, 2019 at 9:25 PM Timo Walther wrote:
> I would also avoid `UNKNOWN` because of the mentioned reasons.
>
> I'm fine with `RAW`. I will wait another day or two until I conclude the
> discussion.
>
> Thanks,
> Timo
>
>
+1 (binding)
Best,
Kurt
On Tue, Oct 22, 2019 at 12:56 AM Fabian Hueske wrote:
> +1 (binding)
>
> Am Mo., 21. Okt. 2019 um 16:18 Uhr schrieb Thomas Weise :
>
> > +1 (binding)
> >
> >
> > On Mon, Oct 21, 2019 at 7:10 AM Timo Walther wrote:
> >
> > > +1 (binding)
> > >
> > > Thanks,
> > > Timo
>
+1 (binding)
Am Mo., 21. Okt. 2019 um 16:18 Uhr schrieb Thomas Weise :
> +1 (binding)
>
>
> On Mon, Oct 21, 2019 at 7:10 AM Timo Walther wrote:
>
> > +1 (binding)
> >
> > Thanks,
> > Timo
> >
> >
> > On 21.10.19 15:59, Till Rohrmann wrote:
> > > +1 (binding)
> > >
> > > Cheers,
> > > Till
> > >
+1 (binding)
On Mon, Oct 21, 2019 at 5:53 PM Zili Chen wrote:
> +1 (non-binding)
>
> Best,
> tison.
>
>
> Kostas Kloudas 于2019年10月21日周一 下午11:49写道：
>
> > +1 (binding)
> >
> > On Mon, Oct 21, 2019 at 5:18 PM Aljoscha Krettek
> > wrote:
> > >
> > > +1 (binding)
> > >
> > > Aljoscha
> > >
> > > >
+1 (non-binding)
Best,
tison.
Kostas Kloudas 于2019年10月21日周一 下午11:49写道：
> +1 (binding)
>
> On Mon, Oct 21, 2019 at 5:18 PM Aljoscha Krettek
> wrote:
> >
> > +1 (binding)
> >
> > Aljoscha
> >
> > > On 21. Oct 2019, at 16:18, Thomas Weise wrote:
> > >
> > > +1 (binding)
> > >
> > >
> > > On Mon
+1 (binding)
On Mon, Oct 21, 2019 at 5:18 PM Aljoscha Krettek wrote:
>
> +1 (binding)
>
> Aljoscha
>
> > On 21. Oct 2019, at 16:18, Thomas Weise wrote:
> >
> > +1 (binding)
> >
> >
> > On Mon, Oct 21, 2019 at 7:10 AM Timo Walther wrote:
> >
> >> +1 (binding)
> >>
> >> Thanks,
> >> Timo
> >>
> >
Hi all,
As part of FLIP-73 (the Executors effort), we would like to introduce
some new configuration options. These are needed in order to be able
to map all the options that the user can specify either
programmatically or through the CLI into configuration options.
The bylaws specify that every
+1 (binding)
Thanks Timo for driving this.
--
Rong
On Mon, Oct 21, 2019 at 8:19 AM wrote:
> +1 (binding)
>
> Best,
> Xingcan
>
> -Original Message-
> From: jincheng sun
> Sent: Monday, October 21, 2019 5:04
> To: dev
> Subject: Re: [VOTE] FLIP-65: New type inference for Table API UDF
+1 (binding)
Best,
Xingcan
-Original Message-
From: jincheng sun
Sent: Monday, October 21, 2019 5:04
To: dev
Subject: Re: [VOTE] FLIP-65: New type inference for Table API UDFs
+1(binding)
Best,
Jincheng
Jark Wu 于2019年10月21日周一 下午4:55写道：
> +1 (binding)
>
> Best,
> Jark
>
> > 在 2019年
+1 (binding)
Aljoscha
> On 21. Oct 2019, at 16:18, Thomas Weise wrote:
>
> +1 (binding)
>
>
> On Mon, Oct 21, 2019 at 7:10 AM Timo Walther wrote:
>
>> +1 (binding)
>>
>> Thanks,
>> Timo
>>
>>
>> On 21.10.19 15:59, Till Rohrmann wrote:
>>> +1 (binding)
>>>
>>> Cheers,
>>> Till
>>>
>>> O
Beam artifact staging currently relies on shared file system and there are
limitations, for example when running locally with Docker and local FS. It
sounds like a distributed cache based implementation might be a good
(better?) option for artifact staging even for the Beam Flink runner?
If so, ca
+1 (binding)
On Mon, Oct 21, 2019 at 7:10 AM Timo Walther wrote:
> +1 (binding)
>
> Thanks,
> Timo
>
>
> On 21.10.19 15:59, Till Rohrmann wrote:
> > +1 (binding)
> >
> > Cheers,
> > Till
> >
> > On Mon, Oct 21, 2019 at 12:13 PM Robert Metzger
> wrote:
> >
> >> +1 (binding)
> >>
> >> On Mon, Oc
+1 (binding)
Thanks,
Timo
On 21.10.19 15:59, Till Rohrmann wrote:
+1 (binding)
Cheers,
Till
On Mon, Oct 21, 2019 at 12:13 PM Robert Metzger wrote:
+1 (binding)
On Mon, Oct 21, 2019 at 12:06 PM Stephan Ewen wrote:
This is the official vote whether to accept the Stateful Functions code
Arvid Heise created FLINK-14480:
---
Summary: Sort out exception supression during snapshotting for
non-running tasks.
Key: FLINK-14480
URL: https://issues.apache.org/jira/browse/FLINK-14480
Project: Flink
Hi Jark,
thanks for the proposal. This is a great effort to finalize the new API
design.
I'm wondering if we could simply use the SQL parser like
`org.apache.calcite.sql.parser.SqlParser#parseExpression(..)` to parse
an expression that contain only literals. This would avoid any
discussion
+1 (binding)
Cheers,
Till
On Mon, Oct 21, 2019 at 12:13 PM Robert Metzger wrote:
> +1 (binding)
>
> On Mon, Oct 21, 2019 at 12:06 PM Stephan Ewen wrote:
>
> > This is the official vote whether to accept the Stateful Functions code
> > contribution to Apache Flink.
> >
> > The current Stateful
sunjincheng created FLINK-14479:
---
Summary: Strange exceptions found in log file after executing
`test_udf.py`
Key: FLINK-14479
URL: https://issues.apache.org/jira/browse/FLINK-14479
Project: Flink
sunjincheng created FLINK-14478:
---
Summary: The python test on travis consumes too much time
Key: FLINK-14478
URL: https://issues.apache.org/jira/browse/FLINK-14478
Project: Flink
Issue Type: Im
Chesnay Schepler created FLINK-14477:
Summary: Extend partition tracking and safety net on TaskExecutor
Key: FLINK-14477
URL: https://issues.apache.org/jira/browse/FLINK-14477
Project: Flink
Chesnay Schepler created FLINK-14476:
Summary: Extend PartitionTracker to support partition promotions
Key: FLINK-14476
URL: https://issues.apache.org/jira/browse/FLINK-14476
Project: Flink
Chesnay Schepler created FLINK-14475:
Summary: Adjust TaskExecutor interface to support partition
promotions
Key: FLINK-14475
URL: https://issues.apache.org/jira/browse/FLINK-14475
Project: Flink
Chesnay Schepler created FLINK-14474:
Summary: FLIP-67 Cluster partitions
Key: FLINK-14474
URL: https://issues.apache.org/jira/browse/FLINK-14474
Project: Flink
Issue Type: New Feature
The voting time has elapsed.
There were 4 +1 votes, 3 of which are binding:
- Till (binding)
- Zhijiang (binding)
- Zhuzhu (non-binding)
- Chesnay (binding)
There were no disapproving votes.
Thus, FLIP-67 has been accepted.
On 21/10/2019 15:26, Chesnay Schepler wrote:
+1
On 21/10/2019 04:24,
+1
On 21/10/2019 04:24, Zhu Zhu wrote:
Thanks Chesnay for proposing this improvement!
It's meaningful for interactive query and the design looks good.
+1 (non-binding)
Thanks,
Zhu Zhu
Till Rohrmann 于2019年10月17日周四 下午8:48写道：
Thanks for creating this FLIP and starting the VOTE for it.
+1 (bi
I would also avoid `UNKNOWN` because of the mentioned reasons.
I'm fine with `RAW`. I will wait another day or two until I conclude the
discussion.
Thanks,
Timo
On 21.10.19 12:23, Jark Wu wrote:
I also think `UNKNOWN` is not suitable here.
Because we already have `UNKNOWN` value in SQL, i.e
I also think `UNKNOWN` is not suitable here.
Because we already have `UNKNOWN` value in SQL, i.e. the three-valued logic
(TRUE, FALSE, UNKNOWN) of BOOLEAN type.
It will confuse users here, what's the relationship between them.
Best,
Jark
On Mon, 21 Oct 2019 at 17:53, Paul Lam wrote:
> Hi,
>
> I
+1 (binding)
On Mon, Oct 21, 2019 at 12:06 PM Stephan Ewen wrote:
> This is the official vote whether to accept the Stateful Functions code
> contribution to Apache Flink.
>
> The current Stateful Functions code, documentation, and website can be
> found here:
> https://statefun.io/
> https://gi
This is the official vote whether to accept the Stateful Functions code
contribution to Apache Flink.
The current Stateful Functions code, documentation, and website can be
found here:
https://statefun.io/
https://github.com/ververica/stateful-functions
This vote should capture whether the Apache
Hi,
IMHO, `UNKNOWN` does not fully reflects the situation here, because the types
are
actually “known” to users, and users just want to leave them out of Flink type
system.
+1 for `RAW`, for it's more intuitive than `OPAQUE`.
Best,
Paul Lam
> 在 2019年10月21日，16:43，Kurt Young 写道：
>
> OPAQUE s
That's what i really need!Thank you so much!
Yours
Xuyangzhong
在2019-10-21 17:07:21,Till Rohrmann写道：
> Hi Xuyangzhong,
>
> the reason why both split consumers share the same slot is that per default
> slot sharing is activated. You can define separate slot sharing groups via
> `.slotSharingGroup(
Hi Max,
Sorry for the late reply. Regarding the issue you mentioned above, I'm glad
to share my thoughts:
> For process-based execution we use Flink's cache distribution instead of
Beam's artifact staging.
In current design, we use Flink's cache distribution to upload users' files
from client to
Hi Tison,
I'm not sure whether I fully understand your distinction between
customizable and pluggable. Maybe you could clarify your ideas a bit
because you seem to favour support for pluggable implementations.
Maybe let me try to answer some other questions you raised. With the
HighAvailabilitySe
Hi Xuyangzhong,
the reason why both split consumers share the same slot is that per default
slot sharing is activated. You can define separate slot sharing groups via
`.slotSharingGroup("new_slot_sharing_group")` for the two consumers. This
will tell Flink to deploy both consumers in different slo
+1 (binding)
Best, Hequn
On Mon, Oct 21, 2019 at 4:55 PM Jark Wu wrote:
> +1 (binding)
>
> Best,
> Jark
>
> > 在 2019年10月21日，16:52，Aljoscha Krettek 写道：
> >
> > +1 (binding)
> >
> > Aljoscha
> >
> >> On 21. Oct 2019, at 10:50, Timo Walther wrote:
> >>
> >> Hi everyone,
> >>
> >> I would like to
+1(binding)
Best,
Jincheng
Jark Wu 于2019年10月21日周一 下午4:55写道：
> +1 (binding)
>
> Best,
> Jark
>
> > 在 2019年10月21日，16:52，Aljoscha Krettek 写道：
> >
> > +1 (binding)
> >
> > Aljoscha
> >
> >> On 21. Oct 2019, at 10:50, Timo Walther wrote:
> >>
> >> Hi everyone,
> >>
> >> I would like to start a vot
+1 (binding)
Best,
Jark
> 在 2019年10月21日，16:52，Aljoscha Krettek 写道：
>
> +1 (binding)
>
> Aljoscha
>
>> On 21. Oct 2019, at 10:50, Timo Walther wrote:
>>
>> Hi everyone,
>>
>> I would like to start a vote on FLIP-65. The discussion seems to have
>> reached an agreement.
>>
>> Please vote fo
+1 (binding)
Aljoscha
> On 21. Oct 2019, at 10:50, Timo Walther wrote:
>
> Hi everyone,
>
> I would like to start a vote on FLIP-65. The discussion seems to have
> reached an agreement.
>
> Please vote for the following design document:
>
> https://cwiki.apache.org/confluence/display/FLINK/F
OPAQUE seems to be a little bit advanced to a lot non-english
speakers (including me). I think Xuefu raised a good alternative:
UNKNOWN. What do you think about it?
Best,
Kurt
On Mon, Oct 21, 2019 at 3:49 PM Aljoscha Krettek
wrote:
> I prefer OPAQUE compared to ANY because any is often the roo
Hi everyone,
I would like to start a vote on FLIP-65. The discussion seems to have
reached an agreement.
Please vote for the following design document:
https://cwiki.apache.org/confluence/display/FLINK/FLIP-65%3A+New+type+inference+for+Table+API+UDFs
The discussion can be found at:
https://l
Hi Hequn,
yes we should target this feature for the 1.10 release. It will enable
not only a function DDL but also UDFs in the unified `TableEnvironment`
for the Blink planner. It will also make the Hive UDF implementation
cleaner.
Regards,
Timo
On 18.10.19 05:33, Hequn Cheng wrote:
+1 to s
Hello:
I am a graduate student from ustc. I have a little doubt about flink
programming recently. I hope to get your reply, thank you.
I use the split operator to split a stream into two streams. However, I found
that the parallelism of the two streams can only be set separately, so that
each of
+1 to rename ANY.
I don't have strong opinion on the new name. I think "OPAQUE" is fine,
because it is introduced in IBM Informix and Oracle.
In Informix, it says [1]:
"An opaque data type is fully encapsulated; the database server does not
know about the internal format of an opaque data type.
T
According to my test, the Travis ARM CI is not ready. For example:
1. Java8 support is missing.
https://travis-ci.community/t/about-the-arm-cpu-architecture-category/5336/4
2. Cache function is not supported.
https://travis-ci.community/t/no-cache-support-on-arm64/5416
The compile job ran timeout
I prefer OPAQUE compared to ANY because any is often the root object in an
object hierarchy and would indicate to users the wrong thing.
Aljoscha
> On 18. Oct 2019, at 18:41, Xuefu Z wrote:
>
> Thanks to Timo for bringing up an interesting topic.
>
> Personally, "OPAQUE" doesn't seem very int
Jark Wu created FLINK-14473:
---
Summary: Support nested field as the rowtime attribute
Key: FLINK-14473
URL: https://issues.apache.org/jira/browse/FLINK-14473
Project: Flink
Issue Type: Sub-task
zhijiang created FLINK-14472:
Summary: Implement back-pressure monitor with non-blocking outputs
Key: FLINK-14472
URL: https://issues.apache.org/jira/browse/FLINK-14472
Project: Flink
Issue Type:
68 matches
Mail list logo
