Jark Wu created FLINK-7509:
--
Summary: Refactorings to AggregateCodeGenerator
Key: FLINK-7509
URL: https://issues.apache.org/jira/browse/FLINK-7509
Project: Flink
Issue Type: Improvement
Bowen Li created FLINK-7508:
---
Summary: switch FlinkKinesisProducer to use KPL's ThreadingMode to
ThreadedPool mode rather than Per_Request mode
Key: FLINK-7508
URL: https://issues.apache.org/jira/browse/FLINK-7508
Till Rohrmann created FLINK-7507:
Summary: Fence Dispatcher
Key: FLINK-7507
URL: https://issues.apache.org/jira/browse/FLINK-7507
Project: Flink
Issue Type: Sub-task
Components:
Till Rohrmann created FLINK-7506:
Summary: Fence JobMaster
Key: FLINK-7506
URL: https://issues.apache.org/jira/browse/FLINK-7506
Project: Flink
Issue Type: Sub-task
Components:
Stefan Richter created FLINK-7505:
-
Summary: Use lambdas in suppressed exception idiom
Key: FLINK-7505
URL: https://issues.apache.org/jira/browse/FLINK-7505
Project: Flink
Issue Type:
Till Rohrmann created FLINK-7504:
Summary: Fence ResourceManager
Key: FLINK-7504
URL: https://issues.apache.org/jira/browse/FLINK-7504
Project: Flink
Issue Type: Sub-task
Hi,
Since we switched to Java 8, I would like to start a discussion about a
deprecating usage of @Nullable parameters and return values in Flink and
enforcing strict ban on nulls in those places. I just think that having a very
explicit way, enforced by a static type checking mechanism of
Felix Dreissig created FLINK-7503:
-
Summary: Config options taskmanager.log.path and
jobmanager.web.log.path are misleading, if not broken
Key: FLINK-7503
URL: https://issues.apache.org/jira/browse/FLINK-7503
Maximilian Bode created FLINK-7502:
--
Summary: PrometheusReporter improvements
Key: FLINK-7502
URL: https://issues.apache.org/jira/browse/FLINK-7502
Project: Flink
Issue Type: Improvement
Till Rohrmann created FLINK-7501:
Summary: Generalize leader id of RegisteredRpcConnection
Key: FLINK-7501
URL: https://issues.apache.org/jira/browse/FLINK-7501
Project: Flink
Issue Type:
I think it may not work in scenario where Hadoop security is enabled and each
HCFS setup is configured differently, unless if there is a way to isolate the
Hadoop configurations used in this case?
Regards,
Vijay
Sent from my iPhone
> On Aug 24, 2017, at 2:51 AM, Stephan Ewen
Till Rohrmann created FLINK-7500:
Summary: Set JobMaster leader session id in main thread
Key: FLINK-7500
URL: https://issues.apache.org/jira/browse/FLINK-7500
Project: Flink
Issue Type:
Nico Kruber created FLINK-7499:
--
Summary: double buffer release in SpillableSubpartitionView
Key: FLINK-7499
URL: https://issues.apache.org/jira/browse/FLINK-7499
Project: Flink
Issue Type: Bug
Hi!
I think it can work if you fully qualify the URIs.
For the checkpoint configuration, specify one namenode (in the
flink-config.yml or in the constructor of the state backend).
Example: statebackend.fs.checkpoint.dir:
hdfs://dfsOneNamenode:port/flink/checkpoints
For the result (for example
Hi,
I don’t think that this is currently supported. If you see a use case for this
(over creating different root directories for checkpoint data and result data)
then I suggest that you open a JIRA issue with a new feature request.
Best,
Stefan
> Am 23.08.2017 um 20:17 schrieb Vijay
Piotr Nowojski created FLINK-7498:
-
Summary: Bind together state fields of TwoPhaseCommitSinkFunction
Key: FLINK-7498
URL: https://issues.apache.org/jira/browse/FLINK-7498
Project: Flink
Piotr Nowojski created FLINK-7497:
-
Summary: Allow users to add custom user context stored in state in
TwoPhaseCommitSinkFunction
Key: FLINK-7497
URL: https://issues.apache.org/jira/browse/FLINK-7497
Dian Fu created FLINK-7496:
--
Summary: Support greedy quantifier followed by an optional pattern
Key: FLINK-7496
URL: https://issues.apache.org/jira/browse/FLINK-7496
Project: Flink
Issue Type: Bug
18 matches
Mail list logo
