Robert Metzger created FLINK-1929:
-
Summary: Add code to cleanly stop a running streaming topology
Key: FLINK-1929
URL: https://issues.apache.org/jira/browse/FLINK-1929
Project: Flink
Issue
Till Rohrmann created FLINK-1931:
Summary: Add ADMM to optimization framework
Key: FLINK-1931
URL: https://issues.apache.org/jira/browse/FLINK-1931
Project: Flink
Issue Type: New Feature
Till Rohrmann created FLINK-1932:
Summary: Add L-BFGS to the optimization framework
Key: FLINK-1932
URL: https://issues.apache.org/jira/browse/FLINK-1932
Project: Flink
Issue Type: New
I think Stephan meant Meteor, an old API when Flink was Stratosphere. This
was never part of the code that made it to Apache.
Not sure if we want to remove the common API, as it provides a dataflow
abstraction that is higher level than the JobGraph. Admittedly, I don't
have a better argument
Vasia Kalavri created FLINK-1930:
Summary: NullPointerException in vertex-centric iteration
Key: FLINK-1930
URL: https://issues.apache.org/jira/browse/FLINK-1930
Project: Flink
Issue Type:
Many thanks Stephan.
I followed your instructions and it was working fine when I had the
required flink projects in the build path,
later when I substituted it by adding respective dependencies with the
snapshots in pom, I am getting the below exception at
OptimizedPlan opPlan =
Chiwan Park created FLINK-1933:
--
Summary: Add distance measure interface and basic implementation
to machine learning library
Key: FLINK-1933
URL: https://issues.apache.org/jira/browse/FLINK-1933
I think the main difference to the Java API is right now that the JavaAPI
is fluent and the common API is compositional. Otherwise there is not much
in the common API any more.
Not sure whether this warrants an extra API...
On Wed, Apr 22, 2015 at 3:52 PM, Kostas Tzoumas ktzou...@apache.org
Hi Stephan,
thanks for your answer! I thought about this, too, but I am not sure if
this solves to problem.
I think it works if there is only a temporary failure an the job can be
restartet with the same dop.
But it does not work if one node is permanently lost and the dop needs to
be adjusted.
If
Robert Metzger created FLINK-1923:
-
Summary: Replace asynchronous logging in JobManager with regular
slf4j logging
Key: FLINK-1923
URL: https://issues.apache.org/jira/browse/FLINK-1923
Project: Flink
Till Rohrmann created FLINK-1925:
Summary: Split SubmitTask method up into two phases: Receive TDD
and instantiation of TDD
Key: FLINK-1925
URL: https://issues.apache.org/jira/browse/FLINK-1925
Chesnay Schepler created FLINK-1926:
---
Summary: [Py] Sync Python API with otehr API's
Key: FLINK-1926
URL: https://issues.apache.org/jira/browse/FLINK-1926
Project: Flink
Issue Type:
Chesnay Schepler created FLINK-1927:
---
Summary: [Py] Rework operator distribution
Key: FLINK-1927
URL: https://issues.apache.org/jira/browse/FLINK-1927
Project: Flink
Issue Type:
Robert Metzger created FLINK-1928:
-
Summary: BlobManager can be a bottleneck on large deployments
Key: FLINK-1928
URL: https://issues.apache.org/jira/browse/FLINK-1928
Project: Flink
Issue
I think it should circumvent many of the problems. If you re-submit the
program from the client with
a lower DOP, all intermediae state (saved by you in files) will be
re-partitioned, because no
assumptions about prior properties are made.
I may not be getting the whole picture here, so sorry, if
Robert Metzger created FLINK-1920:
-
Summary: Passing -D akka.ask.timeout=5 min to yarn client does not
work
Key: FLINK-1920
URL: https://issues.apache.org/jira/browse/FLINK-1920
Project: Flink
16 matches
Mail list logo
