Hi Shi,
Naiad/Timely Dataflow and other projects use global coordination which is very
convenient for asynchronous progress tracking in general but it has some
downsides in a production systems that count on in-flight transactional control
mechanisms and rollback recovery guarantees. This is
Hi, Fouad
Thank you for the explanation. Now the centralized method seems correct to
me.
The passing of StatusUpdate events will lead to synchronous iterations and
we are using the information in each iterations to terminate the
computation.
Actually, i prefer the centralized method because in
Hi Zhenhao,
does this happen reproducibly? What happens after the failure? Will it
retry restoring and then succeed?
I have a suspicion that Yarn could be cleaning up some files that RocksDB
expects to be there while restoring.
Cheers,
Aljoscha
On Thu, 10 Nov 2016 at 14:24
I have a question about type info, it looks like one in calcite mail you showed
in jira,
but I catch CodeGenException when checking predefined table field types with
output types from source
Flink cannot generate conversion because of row arity. We cannot reduce number
of table fields,
but we
Kostas Kloudas created FLINK-5056:
-
Summary: BucketingSink deletes valid data when checkpoint
notification is slow.
Key: FLINK-5056
URL: https://issues.apache.org/jira/browse/FLINK-5056
Project:
Flink security context gets initialized during the application start phase.
As part of the initialization, the UserGroupInformation (UGI) instance is
bootstrapped using the Hadoop configuration files (read: HADOOP_CONF_DIR or
YARN_CONF_DIR environment variable is set). If the hadoop configuration
Till Rohrmann created FLINK-5055:
Summary: Security feature crashes JM for certain Hadoop versions
even though using no Kerberos
Key: FLINK-5055
URL: https://issues.apache.org/jira/browse/FLINK-5055
Hi Naveen,
I could reproduce your problem with the given Hadoop version
(2.7.0-mapr-1607). It seems to me as if this version always tries to use
Kerberos even though I selected the AuthenticationMethod.SIMPLE (no
Kerberos activated). I've also tested it with vanilla Hadoop 2.7.3 and
there it
Kostas Kloudas created FLINK-5054:
-
Summary: Make the BucketingSink rescalable.
Key: FLINK-5054
URL: https://issues.apache.org/jira/browse/FLINK-5054
Project: Flink
Issue Type: Improvement
Hi Shi,
It seems that you are referring to the centralized algorithm which is no longer
the proposed version.
In the decentralized version (check last doc) there is no master node or global
coordination involved.
Let us keep this discussion to the decentralized one if possible.
To answer your
Stefan Richter created FLINK-5053:
-
Summary: Incremental / lightweight snapshots for checkpoints
Key: FLINK-5053
URL: https://issues.apache.org/jira/browse/FLINK-5053
Project: Flink
Issue
Stefan Richter created FLINK-5052:
-
Summary: Changing the maximum parallelism (number of key groups)
of a job
Key: FLINK-5052
URL: https://issues.apache.org/jira/browse/FLINK-5052
Project: Flink
Stefan Richter created FLINK-5051:
-
Summary: Backwards compatibility for serializers in backend state
Key: FLINK-5051
URL: https://issues.apache.org/jira/browse/FLINK-5051
Project: Flink
Yes, I would like to continue my work with this issue. It is already assigned
to me. I will follow the approach that you suggested.
Thanks,
Alexander
> -Original Message-
> From: Fabian Hueske [mailto:fhue...@gmail.com]
> Sent: Friday, November 11, 2016 11:49 AM
> To:
Dear Flink community,
Please vote on releasing the following candidate as Apache Flink version 1.1.4.
The commit to be voted on:
3c1024a (http://git-wip-us.apache.org/repos/asf/flink/commit/3c1024a)
Branch:
release-1.1.4-rc1
Hi Alexander,
I had a look at the logical plan generated by Calcite for NOT IN again and
noticed that the CROSS JOIN is only used to join a single record (the
result of a global aggregation) to all records of the other table.
IMO, this is a special case, that we can easily support and efficiently
Hi Fabian,
Should we close this issue then? Or I could just leave the comment why we can't
repair NOT IN at the moment. So no one else will do the same research again.
Perhaps the Calcite team will change a logical plan for NOT IN and we will be
back to this issue.
Regards,
Alexander
17 matches
Mail list logo