I think it's not a nice solution to check for the type of the returned
execution environment to determine whether it is a local or a remote
execution environment.
Wouldn't it be better to add a method isLocal() to ExecutionEnvironment?
Cheers, Fabian
2015-10-14 19:14 GMT+02:00 Flavio Pompermaier
of course,I tried to configure the task slot during a debug test and I
forgot to remove it..
Just for curiosity, is there any good reason why you've changed the default
parallellelism that way?and moreover, is it the only unexpected changed
behaviour wrt the previous API version?
On 14 Oct 2015 18:
Hi Flavio!
ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment()
by default picks up the number of cores as the parallelism, while the
manual environments do not do that.
You can still set it manually set the parallelism
"env.setParallelism(Runtime.getRuntime().availableProcess
Hi Fabian and Stephan, back to work :)
I finally managed to find the problem of the parallelism encountered by my
colleague!
Basically that was introduced by this API change. Before I was using
env.setConfiguration() to merge the default params with some custom ones.
Now, after the API change I wa
That makes sense: what can be configured should be differentiated between
local and remote envs (obviously this is a minor issue/improvement)
Thanks again,
Flavio
On Tue, Oct 6, 2015 at 11:25 AM, Stephan Ewen wrote:
> We can think about that, but I think it may be quite confusing. The
> configu
We can think about that, but I think it may be quite confusing. The
configurations actually mean something different for local and remote
environments:
- For the local environment, the config basically describes the entire
Flink cluster setup (for the local execution cluster in the background)
However it could be a good idea to overload also
the getExecutionEnvironment() to be able to pass a custom
configuration..what do you think?
Otherwise I have to know a priori if I'm working in a local deployment or
in a remote one, or check if getExecutionEnvironment() returned an instance
of Local
Yes Stephan!
I usually work with the master version, at least in development ;)
Thanks for the quick support!
Best,
Flavio
On Tue, Oct 6, 2015 at 10:48 AM, Stephan Ewen wrote:
> Hi!
>
> Are you on the SNAPSHOT master version?
>
> You can pass the configuration to the constructor of the executio
Hi!
Are you on the SNAPSHOT master version?
You can pass the configuration to the constructor of the execution
environment, or create one via
ExecutionEnvironment.createLocalEnvironment(config) or via
createRemoteEnvironment(host, port, configuration, jarFiles);
The change of the signature was p
