[jira] [Created] (FLINK-6790) Flink Kafka Consumer Cannot Round Robin Fetch Records

[xingHu (JIRA)]

xingHu created FLINK-6790:
-

 Summary: Flink Kafka Consumer Cannot Round Robin Fetch Records
 Key: FLINK-6790
 URL: https://issues.apache.org/jira/browse/FLINK-6790
 Project: Flink
  Issue Type: Bug
  Components: DataStream API
Affects Versions: 1.2.1
Reporter: xingHu


The Java consumer fails consume messages in a round robin fashion. This can 
lead to an unbalance consumption.
In our use case we have a set of consumer that can take a significant amount of 
time consuming messages off a topic. For this reason, we are using the 
pause/poll/resume pattern to ensure the consumer session is not timeout. The 
topic that is being consumed has been preloaded with message. That means there 
is a significant message lag when the consumer is first started. To limit how 
many messages are consumed at a time, the consumer has been configured with 
max.poll.records=1.
The first initial observation is that the client receive a large batch of 
messages for the first partition it decides to consume from and will consume 
all those messages before moving on, rather than returning a message from a 
different partition for each call to poll.
We solved this issue by configuring max.partition.fetch.bytes to be small 
enough that only a single message will be returned by the broker on each fetch, 
although this would not be feasible if message size were highly variable.
The behavior of the consumer after this change is to largely consume from a 
small number of partitions, usually just two, iterating between them, until it 
exhausts them, before moving to another partition. This behavior is problematic 
if the messages have some rough time semantics and need to be process roughly 
time ordered across all partitions.
It would be useful if source has a pluggable API that allowed custom logic to 
select which partition to consume from next, thus enabling the creation of a 
round robin partition consumer.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Willing to contribute to Flink!

[Jin Chul Kim]

Hello all,

I am very interesting in Flink framework, especially development. Since I
joined a new company below, I have been fallen into OSS. I haven't taken a
chance to contribute to OSS, but I am happy if I would take an opportunity
to be a developer for Flicker.

I read "How to contribute" section and here is my question.

- May I take a "starter" issue? I found some unassigned issues on JIRA.
AFAIK, I don't have a privilege to take it. If I interest in an issue, I
just leave a comment on JIRA, taking a look at and push a commit on my
forked repository. Please correct me if my understanding is wrong.

Please read below if you are interested in my background.

Currently I am working at SK telecom in Republic of Korea. In this company,
I am a member of developers to build up real-time analyzing system for
telco and 3rd party data. We are currently using Flink for the real-time
processing.

Before joining the company, I had been worked SAP Labs Korea for about ten
years and I was one of core developers for SAP HANA in-memory data
platform. In SAP, I contributed SQL/SQLScript compiler(i.e. parser to build
AST, semantic checker, design of intermediate representation(IR), code
generator for executable code), SQL plan cache, SQL query optimizer using
cost-based/rule-based, query plan distribution on multi nodes and so on. I
was struggling to resolve complexity problems such as finding performance
bottleneck on distributed landscape, lots of major customers issues/bugs.

Thanks!

Best regards,
Jinchul

[jira] [Created] (FLINK-6789) Remove duplicated test utility reducer in optimizer

[Chesnay Schepler (JIRA)]

Chesnay Schepler created FLINK-6789:
---

 Summary: Remove duplicated test utility reducer in optimizer
 Key: FLINK-6789
 URL: https://issues.apache.org/jira/browse/FLINK-6789
 Project: Flink
  Issue Type: Improvement
  Components: Optimizer, Tests
Affects Versions: 1.4.0
Reporter: Chesnay Schepler


The {{DummyReducer}} and {{SelectOneReducer}} in 
{{org.apache.flink.optimizer.testfunctions}} are identical; we could remove one 
of them.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (FLINK-6788) Remove unused GenericFlatTypePostPass/AbstractSchema class

[Chesnay Schepler (JIRA)]

Chesnay Schepler created FLINK-6788:
---

 Summary: Remove unused GenericFlatTypePostPass/AbstractSchema class
 Key: FLINK-6788
 URL: https://issues.apache.org/jira/browse/FLINK-6788
 Project: Flink
  Issue Type: Improvement
  Components: Optimizer
Affects Versions: 1.4.0
Reporter: Chesnay Schepler
Priority: Trivial


The {{AbstractSchema}} and {{GenericFlatTypePostPass}} classes in 
{{org.apache.flink.optimizer.postpass}} are unused and could maybe be removed.

[~fhueske] your thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (FLINK-6787) Job-/StoppableException should extend FlinkException

[Chesnay Schepler (JIRA)]

Chesnay Schepler created FLINK-6787:
---

 Summary: Job-/StoppableException should extend FlinkException
 Key: FLINK-6787
 URL: https://issues.apache.org/jira/browse/FLINK-6787
 Project: Flink
  Issue Type: Improvement
  Components: Local Runtime
Affects Versions: 1.4.0
Reporter: Chesnay Schepler
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Timo Walther]

What do you think about waiting with the release announcement for Flink 
1.3.1 until next week.


IMHO the documentation is not in a good shape for a release annoucement 
right now anyway.


Most of the new features of the Table API are not documented. Docs for 
other features are missing as well or exist in open PR [1].


Regards,
Timo

[1] https://issues.apache.org/jira/browse/FLINK-6674


Am 31.05.17 um 15:03 schrieb Aljoscha Krettek:

Yes, FLINK-6783 might even have been a release blocker…. It’s a new feature 
that simply doesn’t work in most cases.


On 31. May 2017, at 14:51, Timo Walther  wrote:

We should also include FLINK-6783. It seems that WindowedStream::aggregate is 
broken right now.


Am 31.05.17 um 14:31 schrieb Timo Walther:

I merged all Table API related PRs.

I'm also fine with a 1.3.1 release this or next week.


Am 31.05.17 um 14:08 schrieb Till Rohrmann:

I would be ok to quickly release 1.3.1 once the the respective PRs have
been merged.

Just for your information, I'm not yet through with the testing of the type
serializer upgrade feature, though.

Cheers,
Till

On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
s.rich...@data-artisans.com> wrote:


+1 for releasing now and providing a 1.3.1 release soon.


Am 31.05.2017 um 11:02 schrieb Gyula Fóra :

Hi All,

I also lean towards getting the release out as soon as possible given

that

it had been delayed quite a bit and there is no major issue without a
straightforward workaround (agreeing with Nico and Kostas). I am sure

once

people will start using the new features we will see more issues that
should be fixed asap in 1.3.1.

Regarding the critical bug Till had found, we could add a line about it

to

the release notes so that people don't get blocked by it as there is a
workaround possible.

Regards,
Gyula


Kostas Kloudas  ezt írta (időpont: 2017.

máj.

31., Sze, 10:53):


Hi all,

I also tend to agree with the argument that says a release should be out
as soon as possible, given that 1) it improves usability/functionality

and

2) at a minimum, it does not include new known bugs. The arguments are
more or less aligned with Nico’s response on the matter.

Focusing on the bug that spiked the current discussion, I agree with

Till

that this is alarming, as it passed all previous testing efforts, but I
have to
add that if nobody so far encountered it, we could release 1.3 now and

fix

it in the upcoming 1.3.1.

Kostas


On May 31, 2017, at 10:20 AM, Nico Kruber 

wrote:

IMHO, any release that improves things and does not break anything is

worth

releasing and should not be blocked on bugs that it did not cause.
There will always be a next (minor/major) release that may fix this at

a

later

time, given that the time between releases is not too high.

Consider someone waiting for a bugfix/feature that made it into 1.3.0

who--if

delayed--would have to wait even longer for "his" bugfix/feature. Any

new

bugfixes (and there will always be more) can wait a few more days or

even a few

weeks and may be fixed in 1.3.1 or so.


Nico

On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:

- Not sure whether it's a good argument to defer fixing major bugs

because

they have not been introduced with 1.3.0. It's actually alarming that

these

things have not been found earlier given that we test our releases
thoroughly.

Re: flink-table sql overlaps time.scala

[Timo Walther]

Hi Stefano,

I implemented the overlap according to Calcite's implementation. Maybe 
they changed the behavior in the mean time. I agree we should try to 
stay in sync with Calcite. What do other DB vendors do? Feel free to 
open an issue about this.


Regards,
Timo


Am 30.05.17 um 14:24 schrieb Stefano Bortoli:

Hi all,

I am playing around with the table API, and I have a doubt about temporal 
operator overlaps. In particular, a test in the 
scalarFunctionsTest.testOverlaps checks for false the following intervals:
testAllApis(
   temporalOverlaps("2011-03-10 05:02:02".toTimestamp, 0.second,
 "2011-03-10 05:02:02".toTimestamp, "2011-03-10 05:02:01".toTimestamp),
   "temporalOverlaps(toTimestamp('2011-03-10 05:02:02'), 0.second, " +
 "'2011-03-10 05:02:02'.toTimestamp, '2011-03-10 
05:02:01'.toTimestamp)",
   "(TIMESTAMP '2011-03-10 05:02:02', INTERVAL '0' SECOND) OVERLAPS " +
 "(TIMESTAMP '2011-03-10 05:02:02', TIMESTAMP '2011-03-10 05:02:01')",
   "false")

Basically, the compared intervals overlap just by one of the extreme. The 
interpretation of the time.scala implementation is
AND(
 >=(DATETIME_PLUS(CAST('2011-03-10 
05:02:02'):TIMESTAMP(3) NOT NULL, 0), CAST('2011-03-10 05:02:02'):TIMESTAMP(3) NOT 
NULL),
 >=(CAST('2011-03-10 05:02:01'):TIMESTAMP(3) NOT NULL, 
CAST('2011-03-10 05:02:02'):TIMESTAMP(3) NOT NULL)
),

Where the result is false as the second clause is not satisfied.

However, latest calcite master compiles the overlaps as follows:
[AND
 (
 >=(  CASE(
 <=(2011-03-10 05:02:02, 
DATETIME_PLUS(2011-03-10 05:02:02, 0)), DATETIME_PLUS(2011-03-10 05:02:02, 0), 
2011-03-10 05:02:02
 ),
 CASE(
 <=(2011-03-10 05:02:02, 
2011-03-10 05:02:01), 2011-03-10 05:02:02, 2011-03-10 05:02:01
 )
 ),
 >=(  CASE(
 <=(2011-03-10 05:02:02, 
2011-03-10 05:02:01), 2011-03-10 05:02:01, 2011-03-10 05:02:02
 ),
 CASE(
 <=(2011-03-10 05:02:02, 
DATETIME_PLUS(2011-03-10 05:02:02, 0)), 2011-03-10 05:02:02, 
DATETIME_PLUS(2011-03-10 05:02:02, 0)
 )
 )
 )
]

Where the result is true.

I believe the issue is about interpreting the extremes as part of the 
overlapping intervals or not. Flink does not consider the intervals as 
overlapping (as the test shows), whereas Calcite implements the test including 
them.

Which one should be preserved?

I think that calcite implementation is correct, and overlapping extremes should 
be considered. What do you think?

Best,
Stefano

[jira] [Created] (FLINK-6786) Remove duplicate QueryScopeInfoTest

[Chesnay Schepler (JIRA)]

Chesnay Schepler created FLINK-6786:
---

 Summary: Remove duplicate QueryScopeInfoTest
 Key: FLINK-6786
 URL: https://issues.apache.org/jira/browse/FLINK-6786
 Project: Flink
  Issue Type: Improvement
  Components: Metrics, Tests
Affects Versions: 1.4.0
Reporter: Chesnay Schepler
Assignee: Chesnay Schepler
 Fix For: 1.4.0


The {{QueryScopeInfoTest}} exists twice in {{runtime/metrics}}, under 
{{groups/}} and {{dump/}}.

These should be merged together.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (FLINK-6785) Ineffective checks in MetricRegistryTest

[Chesnay Schepler (JIRA)]

Chesnay Schepler created FLINK-6785:
---

 Summary: Ineffective checks in MetricRegistryTest
 Key: FLINK-6785
 URL: https://issues.apache.org/jira/browse/FLINK-6785
 Project: Flink
  Issue Type: Bug
  Components: Metrics, Tests
Affects Versions: 1.4.0
Reporter: Chesnay Schepler
Assignee: Chesnay Schepler


Several tests in {{MetricRegistryTest}} have reporters doing assertions. By 
design exceptions from reporters are however catched and logged, and thus can't 
fail the test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (FLINK-6784) Add some notes about externalized checkpoints and the difference to savepoints

[Nico Kruber (JIRA)]

Nico Kruber created FLINK-6784:
--

 Summary: Add some notes about externalized checkpoints and the 
difference to savepoints
 Key: FLINK-6784
 URL: https://issues.apache.org/jira/browse/FLINK-6784
 Project: Flink
  Issue Type: Sub-task
  Components: Documentation, State Backends, Checkpointing
Affects Versions: 1.3.0
Reporter: Nico Kruber
Assignee: Nico Kruber


while externalized checkpoints are described somehow, there does not seem to be 
any paragraph explaining the difference to savepoints, also there are two 
checkpointing docs which could at least be linked somehow



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[DISCUSS] NOTICE

[Greg Hogan]

In several locations we have copied code from external projects, for
example
flink-scala-shell/src/main/java/org/apache/flink/api/java/JarHelper.java
links to the file from org.apache.xmlbeans/xmlbeans/2.4.0. We also have
copied from Apache's Calcite, Spark, and Hadoop.

None of these projects are referenced in Flink's NOTICE or LICENSE. Is this
unnecessary because all Apache project code is is copyright the ASF (or
public domain)?

Also, lodash is cited in Flink's NOTICE but there is no lodash NOTICE at
https://github.com/lodash/lodash. We do properly cite the project in the
MIT License section of Flink's LICENSE.

Greg

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Aljoscha Krettek]

Yes, FLINK-6783 might even have been a release blocker…. It’s a new feature 
that simply doesn’t work in most cases.

> On 31. May 2017, at 14:51, Timo Walther  wrote:
> 
> We should also include FLINK-6783. It seems that WindowedStream::aggregate is 
> broken right now.
> 
> 
> Am 31.05.17 um 14:31 schrieb Timo Walther:
>> I merged all Table API related PRs.
>> 
>> I'm also fine with a 1.3.1 release this or next week.
>> 
>> 
>> Am 31.05.17 um 14:08 schrieb Till Rohrmann:
>>> I would be ok to quickly release 1.3.1 once the the respective PRs have
>>> been merged.
>>> 
>>> Just for your information, I'm not yet through with the testing of the type
>>> serializer upgrade feature, though.
>>> 
>>> Cheers,
>>> Till
>>> 
>>> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
>>> s.rich...@data-artisans.com> wrote:
>>> 
 +1 for releasing now and providing a 1.3.1 release soon.
 
> Am 31.05.2017 um 11:02 schrieb Gyula Fóra :
> 
> Hi All,
> 
> I also lean towards getting the release out as soon as possible given
 that
> it had been delayed quite a bit and there is no major issue without a
> straightforward workaround (agreeing with Nico and Kostas). I am sure
 once
> people will start using the new features we will see more issues that
> should be fixed asap in 1.3.1.
> 
> Regarding the critical bug Till had found, we could add a line about it
 to
> the release notes so that people don't get blocked by it as there is a
> workaround possible.
> 
> Regards,
> Gyula
> 
> 
> Kostas Kloudas  ezt írta (időpont: 2017.
 máj.
> 31., Sze, 10:53):
> 
>> Hi all,
>> 
>> I also tend to agree with the argument that says a release should be out
>> as soon as possible, given that 1) it improves usability/functionality
 and
>> 2) at a minimum, it does not include new known bugs. The arguments are
>> more or less aligned with Nico’s response on the matter.
>> 
>> Focusing on the bug that spiked the current discussion, I agree with
 Till
>> that this is alarming, as it passed all previous testing efforts, but I
>> have to
>> add that if nobody so far encountered it, we could release 1.3 now and
 fix
>> it in the upcoming 1.3.1.
>> 
>> Kostas
>> 
>>> On May 31, 2017, at 10:20 AM, Nico Kruber 
>> wrote:
>>> IMHO, any release that improves things and does not break anything is
>> worth
>>> releasing and should not be blocked on bugs that it did not cause.
>>> There will always be a next (minor/major) release that may fix this at
 a
>> later
>>> time, given that the time between releases is not too high.
>>> 
>>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
>> who--if
>>> delayed--would have to wait even longer for "his" bugfix/feature. Any
 new
>>> bugfixes (and there will always be more) can wait a few more days or
>> even a few
>>> weeks and may be fixed in 1.3.1 or so.
>>> 
>>> 
>>> Nico
>>> 
>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
 - Not sure whether it's a good argument to defer fixing major bugs
>> because
 they have not been introduced with 1.3.0. It's actually alarming that
>> these
 things have not been found earlier given that we test our releases
 thoroughly.
>> 
 
> 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Timo Walther]

We should also include FLINK-6783. It seems that 
WindowedStream::aggregate is broken right now.



Am 31.05.17 um 14:31 schrieb Timo Walther:

I merged all Table API related PRs.

I'm also fine with a 1.3.1 release this or next week.


Am 31.05.17 um 14:08 schrieb Till Rohrmann:

I would be ok to quickly release 1.3.1 once the the respective PRs have
been merged.

Just for your information, I'm not yet through with the testing of 
the type

serializer upgrade feature, though.

Cheers,
Till

On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
s.rich...@data-artisans.com> wrote:


+1 for releasing now and providing a 1.3.1 release soon.


Am 31.05.2017 um 11:02 schrieb Gyula Fóra :

Hi All,

I also lean towards getting the release out as soon as possible given

that

it had been delayed quite a bit and there is no major issue without a
straightforward workaround (agreeing with Nico and Kostas). I am sure

once

people will start using the new features we will see more issues that
should be fixed asap in 1.3.1.

Regarding the critical bug Till had found, we could add a line 
about it

to

the release notes so that people don't get blocked by it as there is a
workaround possible.

Regards,
Gyula


Kostas Kloudas  ezt írta (időpont: 2017.

máj.

31., Sze, 10:53):


Hi all,

I also tend to agree with the argument that says a release should 
be out
as soon as possible, given that 1) it improves 
usability/functionality

and
2) at a minimum, it does not include new known bugs. The arguments 
are

more or less aligned with Nico’s response on the matter.

Focusing on the bug that spiked the current discussion, I agree with

Till
that this is alarming, as it passed all previous testing efforts, 
but I

have to
add that if nobody so far encountered it, we could release 1.3 now 
and

fix

it in the upcoming 1.3.1.

Kostas


On May 31, 2017, at 10:20 AM, Nico Kruber 

wrote:
IMHO, any release that improves things and does not break 
anything is

worth

releasing and should not be blocked on bugs that it did not cause.
There will always be a next (minor/major) release that may fix 
this at

a

later

time, given that the time between releases is not too high.

Consider someone waiting for a bugfix/feature that made it into 
1.3.0

who--if
delayed--would have to wait even longer for "his" bugfix/feature. 
Any

new

bugfixes (and there will always be more) can wait a few more days or

even a few

weeks and may be fixed in 1.3.1 or so.


Nico

On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:

- Not sure whether it's a good argument to defer fixing major bugs

because
they have not been introduced with 1.3.0. It's actually alarming 
that

these

things have not been found earlier given that we test our releases
thoroughly.

[jira] [Created] (FLINK-6783) Wrongly extracted TypeInformations for WindowedStream::aggregate

[Dawid Wysakowicz (JIRA)]

Dawid Wysakowicz created FLINK-6783:
---

 Summary: Wrongly extracted TypeInformations for 
WindowedStream::aggregate
 Key: FLINK-6783
 URL: https://issues.apache.org/jira/browse/FLINK-6783
 Project: Flink
  Issue Type: Bug
  Components: DataStream API, Type Serialization System
Affects Versions: 1.3.0
Reporter: Dawid Wysakowicz
Assignee: Dawid Wysakowicz


The following test fails because of wrongly acquired output type for 
{{AggregateFunction}}:

{code}
@Test
public void testAggregateWithWindowFunctionDifferentResultTypes() throws 
Exception {
StreamExecutionEnvironment env = 
StreamExecutionEnvironment.getExecutionEnvironment();

DataStream> source = 
env.fromElements(Tuple2.of("hello", 1), Tuple2.of("hello", 2));

DataStream> window = source
.keyBy(new TupleKeySelector())
.window(TumblingEventTimeWindows.of(Time.of(1, 
TimeUnit.SECONDS)))
.aggregate(new AggregateFunction, 
Tuple2, String>() {
@Override
public Tuple2 createAccumulator() {
return Tuple2.of("", 0);
}

@Override
public void add(
Tuple2 value, Tuple2 accumulator) {

}

@Override
public String getResult(Tuple2 
accumulator) {
return accumulator.f0;
}

@Override
public Tuple2 merge(
Tuple2 a, Tuple2 b) {
return Tuple2.of("", 0);
}
}, new WindowFunction, 
String, TimeWindow>() {
@Override
public void apply(
String s,
TimeWindow window,
Iterable input,
Collector> out) 
throws Exception {
out.collect(Tuple3.of("", "", 0));
}
});

OneInputTransformation, Tuple3> transform =
(OneInputTransformation, Tuple3>) window.getTransformation();

OneInputStreamOperator, Tuple3> operator = transform.getOperator();

Assert.assertTrue(operator instanceof WindowOperator);
WindowOperator, ?, ?, ?> winOperator =
(WindowOperator, ?, ?, ?>) 
operator;

Assert.assertTrue(winOperator.getTrigger() instanceof EventTimeTrigger);
Assert.assertTrue(winOperator.getWindowAssigner() instanceof 
TumblingEventTimeWindows);
Assert.assertTrue(winOperator.getStateDescriptor() instanceof 
AggregatingStateDescriptor);

processElementAndEnsureOutput(
operator, winOperator.getKeySelector(), 
BasicTypeInfo.STRING_TYPE_INFO, new Tuple2<>("hello", 1));
}
{code}

The test results in 
{code}
org.apache.flink.api.common.functions.InvalidTypesException: Input mismatch: 
Tuple type expected.

at 
org.apache.flink.api.java.typeutils.TypeExtractor.validateInputType(TypeExtractor.java:1157)
at 
org.apache.flink.api.java.typeutils.TypeExtractor.getUnaryOperatorReturnType(TypeExtractor.java:451)
at 
org.apache.flink.streaming.api.datastream.WindowedStream.aggregate(WindowedStream.java:855)
at 
org.apache.flink.streaming.runtime.operators.windowing.WindowTranslationTest.testAggregateWithWindowFunctionDifferentResultTypes(WindowTranslationTest.java:702)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Timo Walther]

I merged all Table API related PRs.

I'm also fine with a 1.3.1 release this or next week.


Am 31.05.17 um 14:08 schrieb Till Rohrmann:

I would be ok to quickly release 1.3.1 once the the respective PRs have
been merged.

Just for your information, I'm not yet through with the testing of the type
serializer upgrade feature, though.

Cheers,
Till

On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
s.rich...@data-artisans.com> wrote:


+1 for releasing now and providing a 1.3.1 release soon.


Am 31.05.2017 um 11:02 schrieb Gyula Fóra :

Hi All,

I also lean towards getting the release out as soon as possible given

that

it had been delayed quite a bit and there is no major issue without a
straightforward workaround (agreeing with Nico and Kostas). I am sure

once

people will start using the new features we will see more issues that
should be fixed asap in 1.3.1.

Regarding the critical bug Till had found, we could add a line about it

to

the release notes so that people don't get blocked by it as there is a
workaround possible.

Regards,
Gyula


Kostas Kloudas  ezt írta (időpont: 2017.

máj.

31., Sze, 10:53):


Hi all,

I also tend to agree with the argument that says a release should be out
as soon as possible, given that 1) it improves usability/functionality

and

2) at a minimum, it does not include new known bugs. The arguments are
more or less aligned with Nico’s response on the matter.

Focusing on the bug that spiked the current discussion, I agree with

Till

that this is alarming, as it passed all previous testing efforts, but I
have to
add that if nobody so far encountered it, we could release 1.3 now and

fix

it in the upcoming 1.3.1.

Kostas


On May 31, 2017, at 10:20 AM, Nico Kruber 

wrote:

IMHO, any release that improves things and does not break anything is

worth

releasing and should not be blocked on bugs that it did not cause.
There will always be a next (minor/major) release that may fix this at

a

later

time, given that the time between releases is not too high.

Consider someone waiting for a bugfix/feature that made it into 1.3.0

who--if

delayed--would have to wait even longer for "his" bugfix/feature. Any

new

bugfixes (and there will always be more) can wait a few more days or

even a few

weeks and may be fixed in 1.3.1 or so.


Nico

On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:

- Not sure whether it's a good argument to defer fixing major bugs

because

they have not been introduced with 1.3.0. It's actually alarming that

these

things have not been found earlier given that we test our releases
thoroughly.

[RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

[Robert Metzger]

Thanks a lot for all your responses on the point Till raised.
It seems that we have an agreement to release this RC as Flink 1.3.0.
I'll include a note into the release announcement regarding the state
descriptor issue.


Thanks also for all the release testing and the votes.

+1 votes:
- Chesnay
- Robert (binding)
- jincheng sun
- Aljoscha (binding)
- Gordon
- Greg (binding)

That's 6 votes, out of which 3 are binding.
Therefore, I'll release RC3 as Flink 1.3.0!



On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann  wrote:

> I would be ok to quickly release 1.3.1 once the the respective PRs have
> been merged.
>
> Just for your information, I'm not yet through with the testing of the type
> serializer upgrade feature, though.
>
> Cheers,
> Till
>
> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
> s.rich...@data-artisans.com> wrote:
>
> > +1 for releasing now and providing a 1.3.1 release soon.
> >
> > > Am 31.05.2017 um 11:02 schrieb Gyula Fóra :
> > >
> > > Hi All,
> > >
> > > I also lean towards getting the release out as soon as possible given
> > that
> > > it had been delayed quite a bit and there is no major issue without a
> > > straightforward workaround (agreeing with Nico and Kostas). I am sure
> > once
> > > people will start using the new features we will see more issues that
> > > should be fixed asap in 1.3.1.
> > >
> > > Regarding the critical bug Till had found, we could add a line about it
> > to
> > > the release notes so that people don't get blocked by it as there is a
> > > workaround possible.
> > >
> > > Regards,
> > > Gyula
> > >
> > >
> > > Kostas Kloudas  ezt írta (időpont: 2017.
> > máj.
> > > 31., Sze, 10:53):
> > >
> > >> Hi all,
> > >>
> > >> I also tend to agree with the argument that says a release should be
> out
> > >> as soon as possible, given that 1) it improves usability/functionality
> > and
> > >> 2) at a minimum, it does not include new known bugs. The arguments are
> > >> more or less aligned with Nico’s response on the matter.
> > >>
> > >> Focusing on the bug that spiked the current discussion, I agree with
> > Till
> > >> that this is alarming, as it passed all previous testing efforts, but
> I
> > >> have to
> > >> add that if nobody so far encountered it, we could release 1.3 now and
> > fix
> > >> it in the upcoming 1.3.1.
> > >>
> > >> Kostas
> > >>
> > >>> On May 31, 2017, at 10:20 AM, Nico Kruber 
> > >> wrote:
> > >>>
> > >>> IMHO, any release that improves things and does not break anything is
> > >> worth
> > >>> releasing and should not be blocked on bugs that it did not cause.
> > >>> There will always be a next (minor/major) release that may fix this
> at
> > a
> > >> later
> > >>> time, given that the time between releases is not too high.
> > >>>
> > >>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
> > >> who--if
> > >>> delayed--would have to wait even longer for "his" bugfix/feature. Any
> > new
> > >>> bugfixes (and there will always be more) can wait a few more days or
> > >> even a few
> > >>> weeks and may be fixed in 1.3.1 or so.
> > >>>
> > >>>
> > >>> Nico
> > >>>
> > >>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
> >  - Not sure whether it's a good argument to defer fixing major bugs
> > >> because
> >  they have not been introduced with 1.3.0. It's actually alarming
> that
> > >> these
> >  things have not been found earlier given that we test our releases
> >  thoroughly.
> > >>>
> > >>
> > >>
> >
> >
>

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Till Rohrmann]

I would be ok to quickly release 1.3.1 once the the respective PRs have
been merged.

Just for your information, I'm not yet through with the testing of the type
serializer upgrade feature, though.

Cheers,
Till

On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
s.rich...@data-artisans.com> wrote:

> +1 for releasing now and providing a 1.3.1 release soon.
>
> > Am 31.05.2017 um 11:02 schrieb Gyula Fóra :
> >
> > Hi All,
> >
> > I also lean towards getting the release out as soon as possible given
> that
> > it had been delayed quite a bit and there is no major issue without a
> > straightforward workaround (agreeing with Nico and Kostas). I am sure
> once
> > people will start using the new features we will see more issues that
> > should be fixed asap in 1.3.1.
> >
> > Regarding the critical bug Till had found, we could add a line about it
> to
> > the release notes so that people don't get blocked by it as there is a
> > workaround possible.
> >
> > Regards,
> > Gyula
> >
> >
> > Kostas Kloudas  ezt írta (időpont: 2017.
> máj.
> > 31., Sze, 10:53):
> >
> >> Hi all,
> >>
> >> I also tend to agree with the argument that says a release should be out
> >> as soon as possible, given that 1) it improves usability/functionality
> and
> >> 2) at a minimum, it does not include new known bugs. The arguments are
> >> more or less aligned with Nico’s response on the matter.
> >>
> >> Focusing on the bug that spiked the current discussion, I agree with
> Till
> >> that this is alarming, as it passed all previous testing efforts, but I
> >> have to
> >> add that if nobody so far encountered it, we could release 1.3 now and
> fix
> >> it in the upcoming 1.3.1.
> >>
> >> Kostas
> >>
> >>> On May 31, 2017, at 10:20 AM, Nico Kruber 
> >> wrote:
> >>>
> >>> IMHO, any release that improves things and does not break anything is
> >> worth
> >>> releasing and should not be blocked on bugs that it did not cause.
> >>> There will always be a next (minor/major) release that may fix this at
> a
> >> later
> >>> time, given that the time between releases is not too high.
> >>>
> >>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
> >> who--if
> >>> delayed--would have to wait even longer for "his" bugfix/feature. Any
> new
> >>> bugfixes (and there will always be more) can wait a few more days or
> >> even a few
> >>> weeks and may be fixed in 1.3.1 or so.
> >>>
> >>>
> >>> Nico
> >>>
> >>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>  - Not sure whether it's a good argument to defer fixing major bugs
> >> because
>  they have not been introduced with 1.3.0. It's actually alarming that
> >> these
>  things have not been found earlier given that we test our releases
>  thoroughly.
> >>>
> >>
> >>
>
>

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Stefan Richter]

+1 for releasing now and providing a 1.3.1 release soon.

> Am 31.05.2017 um 11:02 schrieb Gyula Fóra :
> 
> Hi All,
> 
> I also lean towards getting the release out as soon as possible given that
> it had been delayed quite a bit and there is no major issue without a
> straightforward workaround (agreeing with Nico and Kostas). I am sure once
> people will start using the new features we will see more issues that
> should be fixed asap in 1.3.1.
> 
> Regarding the critical bug Till had found, we could add a line about it to
> the release notes so that people don't get blocked by it as there is a
> workaround possible.
> 
> Regards,
> Gyula
> 
> 
> Kostas Kloudas  ezt írta (időpont: 2017. máj.
> 31., Sze, 10:53):
> 
>> Hi all,
>> 
>> I also tend to agree with the argument that says a release should be out
>> as soon as possible, given that 1) it improves usability/functionality and
>> 2) at a minimum, it does not include new known bugs. The arguments are
>> more or less aligned with Nico’s response on the matter.
>> 
>> Focusing on the bug that spiked the current discussion, I agree with Till
>> that this is alarming, as it passed all previous testing efforts, but I
>> have to
>> add that if nobody so far encountered it, we could release 1.3 now and fix
>> it in the upcoming 1.3.1.
>> 
>> Kostas
>> 
>>> On May 31, 2017, at 10:20 AM, Nico Kruber 
>> wrote:
>>> 
>>> IMHO, any release that improves things and does not break anything is
>> worth
>>> releasing and should not be blocked on bugs that it did not cause.
>>> There will always be a next (minor/major) release that may fix this at a
>> later
>>> time, given that the time between releases is not too high.
>>> 
>>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
>> who--if
>>> delayed--would have to wait even longer for "his" bugfix/feature. Any new
>>> bugfixes (and there will always be more) can wait a few more days or
>> even a few
>>> weeks and may be fixed in 1.3.1 or so.
>>> 
>>> 
>>> Nico
>>> 
>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
 - Not sure whether it's a good argument to defer fixing major bugs
>> because
 they have not been introduced with 1.3.0. It's actually alarming that
>> these
 things have not been found earlier given that we test our releases
 thoroughly.
>>> 
>> 
>> 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Gyula Fóra]

Hi All,

I also lean towards getting the release out as soon as possible given that
it had been delayed quite a bit and there is no major issue without a
straightforward workaround (agreeing with Nico and Kostas). I am sure once
people will start using the new features we will see more issues that
should be fixed asap in 1.3.1.

Regarding the critical bug Till had found, we could add a line about it to
the release notes so that people don't get blocked by it as there is a
workaround possible.

Regards,
Gyula


Kostas Kloudas  ezt írta (időpont: 2017. máj.
31., Sze, 10:53):

> Hi all,
>
> I also tend to agree with the argument that says a release should be out
> as soon as possible, given that 1) it improves usability/functionality and
> 2) at a minimum, it does not include new known bugs. The arguments are
> more or less aligned with Nico’s response on the matter.
>
> Focusing on the bug that spiked the current discussion, I agree with Till
> that this is alarming, as it passed all previous testing efforts, but I
> have to
> add that if nobody so far encountered it, we could release 1.3 now and fix
> it in the upcoming 1.3.1.
>
> Kostas
>
> > On May 31, 2017, at 10:20 AM, Nico Kruber 
> wrote:
> >
> > IMHO, any release that improves things and does not break anything is
> worth
> > releasing and should not be blocked on bugs that it did not cause.
> > There will always be a next (minor/major) release that may fix this at a
> later
> > time, given that the time between releases is not too high.
> >
> > Consider someone waiting for a bugfix/feature that made it into 1.3.0
> who--if
> > delayed--would have to wait even longer for "his" bugfix/feature. Any new
> > bugfixes (and there will always be more) can wait a few more days or
> even a few
> > weeks and may be fixed in 1.3.1 or so.
> >
> >
> > Nico
> >
> > On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
> >> - Not sure whether it's a good argument to defer fixing major bugs
> because
> >> they have not been introduced with 1.3.0. It's actually alarming that
> these
> >> things have not been found earlier given that we test our releases
> >> thoroughly.
> >
>
>

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Kostas Kloudas]

Hi all,

I also tend to agree with the argument that says a release should be out
as soon as possible, given that 1) it improves usability/functionality and 
2) at a minimum, it does not include new known bugs. The arguments are 
more or less aligned with Nico’s response on the matter.

Focusing on the bug that spiked the current discussion, I agree with Till
that this is alarming, as it passed all previous testing efforts, but I have to 
add that if nobody so far encountered it, we could release 1.3 now and fix
it in the upcoming 1.3.1.

Kostas

> On May 31, 2017, at 10:20 AM, Nico Kruber  wrote:
> 
> IMHO, any release that improves things and does not break anything is worth 
> releasing and should not be blocked on bugs that it did not cause.
> There will always be a next (minor/major) release that may fix this at a 
> later 
> time, given that the time between releases is not too high.
> 
> Consider someone waiting for a bugfix/feature that made it into 1.3.0 who--if 
> delayed--would have to wait even longer for "his" bugfix/feature. Any new 
> bugfixes (and there will always be more) can wait a few more days or even a 
> few 
> weeks and may be fixed in 1.3.1 or so.
> 
> 
> Nico
> 
> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>> - Not sure whether it's a good argument to defer fixing major bugs because
>> they have not been introduced with 1.3.0. It's actually alarming that these
>> things have not been found earlier given that we test our releases
>> thoroughly.
> 

[jira] [Created] (FLINK-6782) Update savepoint documentation

[Nico Kruber (JIRA)]

Nico Kruber created FLINK-6782:
--

 Summary: Update savepoint documentation
 Key: FLINK-6782
 URL: https://issues.apache.org/jira/browse/FLINK-6782
 Project: Flink
  Issue Type: Sub-task
  Components: Documentation, State Backends, Checkpointing
Affects Versions: 1.3.0
Reporter: Nico Kruber
Assignee: Nico Kruber


Savepoint documentation is a bit outdated regarding full data being stored in 
the savepoint path, not just a metadata file



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Ufuk Celebi]

I agree with Robert that this could be fixed in a bugfix release, but
I really don't like immediately starting a new 1.3.1 vote a day after
the 1.3.0 vote ends. I think it potentially gives a bad/sloppy
impression to our users.

Therefore, I lean towards cancelling this RC and creating a new one
with the fixes included. If there are no objections, I would reduce
the voting time to 48 hours (Fri assuming that a new RC is created
today) instead of 72 -or- keeping it at 72 and counting the weekend.

Best,

Ufuk



On Wed, May 31, 2017 at 10:20 AM, Nico Kruber  wrote:
> IMHO, any release that improves things and does not break anything is worth
> releasing and should not be blocked on bugs that it did not cause.
> There will always be a next (minor/major) release that may fix this at a later
> time, given that the time between releases is not too high.
>
> Consider someone waiting for a bugfix/feature that made it into 1.3.0 who--if
> delayed--would have to wait even longer for "his" bugfix/feature. Any new
> bugfixes (and there will always be more) can wait a few more days or even a 
> few
> weeks and may be fixed in 1.3.1 or so.
>
>
> Nico
>
> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>> - Not sure whether it's a good argument to defer fixing major bugs because
>> they have not been introduced with 1.3.0. It's actually alarming that these
>> things have not been found earlier given that we test our releases
>> thoroughly.
>

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Nico Kruber]

IMHO, any release that improves things and does not break anything is worth 
releasing and should not be blocked on bugs that it did not cause.
There will always be a next (minor/major) release that may fix this at a later 
time, given that the time between releases is not too high.

Consider someone waiting for a bugfix/feature that made it into 1.3.0 who--if 
delayed--would have to wait even longer for "his" bugfix/feature. Any new 
bugfixes (and there will always be more) can wait a few more days or even a few 
weeks and may be fixed in 1.3.1 or so.


Nico

On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
> - Not sure whether it's a good argument to defer fixing major bugs because
> they have not been introduced with 1.3.0. It's actually alarming that these
> things have not been found earlier given that we test our releases
> thoroughly.



signature.asc
Description: This is a digitally signed message part.

[jira] [Created] (FLINK-6781) Make fetch size configurable in JDBCInputFormat

[Maximilian Bode (JIRA)]

Maximilian Bode created FLINK-6781:
--

 Summary: Make fetch size configurable in JDBCInputFormat
 Key: FLINK-6781
 URL: https://issues.apache.org/jira/browse/FLINK-6781
 Project: Flink
  Issue Type: New Feature
  Components: Batch Connectors and Input/Output Formats
Affects Versions: 1.2.1
Reporter: Maximilian Bode
Assignee: Maximilian Bode
Priority: Minor


For batch jobs that read from large tables, it is useful to be able to 
configure the SQL statement's fetch size. In particular, for Oracle's JDBC 
driver the default fetch size is 10.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Fabian Hueske]

Moreover it looks to me as if FLINK-6780 can be fixed without touching the
API, i.e., it can be fixed in 1.3.1.
Haohui, do you think that's correct?

Thanks, Fabian



2017-05-31 8:56 GMT+02:00 Timo Walther :

> I don't think that FLINK-6780 is a blocker, because the Table API is still
> a new feature. FLINK-6736 was also a hard bug. However, if there will be a
> RC4, a fix should be included.
>
> Regards,
> Timo
>
>
> Am 31.05.17 um 02:55 schrieb Haohui Mai:
>
> Hi,
>>
>> We have discovered https://issues.apache.org/jira/browse/FLINK-6780 which
>> effectively makes external catalogs in the table API very difficult to
>> use.
>>
>> It may not be a show stopper but in my opinion it is worth a fix before
>> the
>> release.
>>
>> Regards,
>> Haohui
>>
>> On Tue, May 30, 2017 at 11:22 AM Till Rohrmann 
>> wrote:
>>
>> Just some thoughts concerning the cons for cancelling RC3:
>>>
>>> - Technically, the release is already delayed since the official release
>>> date was the 26th of May
>>> - Not sure whether it's a good argument to defer fixing major bugs
>>> because
>>> they have not been introduced with 1.3.0. It's actually alarming that
>>> these
>>> things have not been found earlier given that we test our releases
>>> thoroughly.
>>> - The shared serializer surfaced in the form of a cryptic
>>> ArrayIndexOutOfBoundsException. Only if you realize that this is
>>> related to
>>> a shared StateDescriptor you can look for a workaround. It took me 2h to
>>> realize that.
>>>
>>> Cheers,
>>> Till
>>>
>>> On Tue, May 30, 2017 at 7:02 PM, Robert Metzger 
>>> wrote:
>>>
>>> The vote time is over, but I'll keep it open for a bit longer until we've
 decided regarding Till's issue.

 On Tue, May 30, 2017 at 6:10 PM, Robert Metzger 
 wrote:

 Hi Till,
> good catch! That is definitively a severe issue. Probably it didn't
> surface yet, because
> a) the code example in the documentation is using a new instance for
>
 each
>>>
 state descriptor
> b) people are using stateless serializers?
> c) don't have the same state descriptor on the same machine
>
> I see two options how to handle the situation
> 1) Cancel RC3 and do another vote (potentially with a 24 hrs vote time)
> 2) Release RC3 as 1.3.0 and start the vote for 1.3.1 right afterwards.
>
>
> + Pros and - cons for cancelling RC3
> - The release would be delayed (not sure who's expecting the 1.3.0 to
>
 be
>>>
 available on time)
> - The bug has been there since many releases, probably no user is
>
 affected

> and it was not introduced during the rel 1.3.0 cycle.
> - There is a workaround for the issue
> + We would have a better feeling for the 1.3.0 release because there
>
 are
>>>
 no known critical issues.
>
> + pro and - cons for releasing RC3:
> + there are some other "minor" issues that showed up during the 1.3.0
> testing that could go into 1.3.1 (FLINK-6763
> , FLINK-6764
> ) without too much
> time-pressure (I'm happy to manage the 1.3.1 release and start it
>
 tomorrow)

>
> I'm undecided between both options and more than happy to hear your
> opinion.
>
>
>
> On Tue, May 30, 2017 at 4:18 PM, Till Rohrmann 
> wrote:
>
> I might have found a blocking issue [1]. The problem is that a
>> StateDescriptor cannot be shared by multiple subtasks because they
>>
> don't
>>>
 duplicate their serializer. As a consequence, things break if you
>>
> have a
>>>
 stateful serializer. The problem exists since 1.0. However, given that
>> this
>> issue is really hard to debug for the user and one can easily fall
>>
> into
>>>
 this trap, I would like to fix it for the release.
>>
>> [1] https://issues.apache.org/jira/browse/FLINK-6775
>>
>> Cheers,
>> Till
>>
>> On Tue, May 30, 2017 at 4:01 PM, Greg Hogan 
>>
> wrote:
>>>
 +1 (binding)
>>>
>>> - verified source and binary signatures
>>> - verified source and binary checksums
>>> - verified LICENSEs
>>> - verified NOTICEs
>>> - built from source
>>>
>>> Greg
>>>
>>>
>>> On May 26, 2017, at 12:58 PM, Robert Metzger >> wrote:
>>>
 Hi all,

 this is the second VOTEing release candidate for Flink 1.3.0

 The commit to be voted on:
 760eea8a >> repos/asf/flink/commit/760eea8

> a>
>>
>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Timo Walther]

I don't think that FLINK-6780 is a blocker, because the Table API is 
still a new feature. FLINK-6736 was also a hard bug. However, if there 
will be a RC4, a fix should be included.


Regards,
Timo


Am 31.05.17 um 02:55 schrieb Haohui Mai:

Hi,

We have discovered https://issues.apache.org/jira/browse/FLINK-6780 which
effectively makes external catalogs in the table API very difficult to use.

It may not be a show stopper but in my opinion it is worth a fix before the
release.

Regards,
Haohui

On Tue, May 30, 2017 at 11:22 AM Till Rohrmann  wrote:


Just some thoughts concerning the cons for cancelling RC3:

- Technically, the release is already delayed since the official release
date was the 26th of May
- Not sure whether it's a good argument to defer fixing major bugs because
they have not been introduced with 1.3.0. It's actually alarming that these
things have not been found earlier given that we test our releases
thoroughly.
- The shared serializer surfaced in the form of a cryptic
ArrayIndexOutOfBoundsException. Only if you realize that this is related to
a shared StateDescriptor you can look for a workaround. It took me 2h to
realize that.

Cheers,
Till

On Tue, May 30, 2017 at 7:02 PM, Robert Metzger 
wrote:


The vote time is over, but I'll keep it open for a bit longer until we've
decided regarding Till's issue.

On Tue, May 30, 2017 at 6:10 PM, Robert Metzger 
wrote:


Hi Till,
good catch! That is definitively a severe issue. Probably it didn't
surface yet, because
a) the code example in the documentation is using a new instance for

each

state descriptor
b) people are using stateless serializers?
c) don't have the same state descriptor on the same machine

I see two options how to handle the situation
1) Cancel RC3 and do another vote (potentially with a 24 hrs vote time)
2) Release RC3 as 1.3.0 and start the vote for 1.3.1 right afterwards.


+ Pros and - cons for cancelling RC3
- The release would be delayed (not sure who's expecting the 1.3.0 to

be

available on time)
- The bug has been there since many releases, probably no user is

affected

and it was not introduced during the rel 1.3.0 cycle.
- There is a workaround for the issue
+ We would have a better feeling for the 1.3.0 release because there

are

no known critical issues.

+ pro and - cons for releasing RC3:
+ there are some other "minor" issues that showed up during the 1.3.0
testing that could go into 1.3.1 (FLINK-6763
, FLINK-6764
) without too much
time-pressure (I'm happy to manage the 1.3.1 release and start it

tomorrow)


I'm undecided between both options and more than happy to hear your
opinion.



On Tue, May 30, 2017 at 4:18 PM, Till Rohrmann 
wrote:


I might have found a blocking issue [1]. The problem is that a
StateDescriptor cannot be shared by multiple subtasks because they

don't

duplicate their serializer. As a consequence, things break if you

have a

stateful serializer. The problem exists since 1.0. However, given that
this
issue is really hard to debug for the user and one can easily fall

into

this trap, I would like to fix it for the release.

[1] https://issues.apache.org/jira/browse/FLINK-6775

Cheers,
Till

On Tue, May 30, 2017 at 4:01 PM, Greg Hogan 

wrote:

+1 (binding)

- verified source and binary signatures
- verified source and binary checksums
- verified LICENSEs
- verified NOTICEs
- built from source

Greg



On May 26, 2017, at 12:58 PM, Robert Metzger 

(*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
*)

Branch:
release-1.3.0-rc3

The release artifacts to be voted on can be found at:
http://people.apache.org/~rmetzger/flink-1.3.0-rc3


The release artifacts are signed with the key with fingerprint

D9839159:

http://www.apache.org/dist/flink/KEYS

The staging repository for this release can be found at:
*https://repository.apache.org/content/repositories/orgapach

eflink-1122