[
https://issues.apache.org/jira/browse/FLINK-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949204#comment-15949204
]
ASF GitHub Bot commented on FLINK-6188:
---------------------------------------
Github user kl0u commented on a diff in the pull request:
https://github.com/apache/flink/pull/3616#discussion_r108944527
--- Diff:
flink-streaming-java/src/main/java/org/apache/flink/streaming/api/transformations/StreamTransformation.java
---
@@ -221,10 +232,19 @@ public int getMaxParallelism() {
* @param maxParallelism Maximum parallelism for this stream
transformation.
*/
public void setMaxParallelism(int maxParallelism) {
- Preconditions.checkArgument(maxParallelism > 0
- && maxParallelism <=
StreamGraphGenerator.UPPER_BOUND_MAX_PARALLELISM,
- "Maximum parallelism must be between 1 and " +
StreamGraphGenerator.UPPER_BOUND_MAX_PARALLELISM
- + ". Found: " + maxParallelism);
+ checkArgument(
+ parallelism !=
ExecutionConfig.PARALLELISM_DEFAULT,
+ "A maximum parallelism can only be specified
with an explicitly specified " +
+ "parallelism.");
--- End diff --
This means that we always have to specify a `parallelism` before being able
to specify a `maxParallelism`. This seems a bit counter-intuitive to me, as the
only constraint seems to be that `parallelism <= maxParalleliem`.
> Some setParallelism() methods can't cope with default parallelism
> -----------------------------------------------------------------
>
> Key: FLINK-6188
> URL: https://issues.apache.org/jira/browse/FLINK-6188
> Project: Flink
> Issue Type: Bug
> Components: DataStream API
> Affects Versions: 1.2.1
> Reporter: Aljoscha Krettek
> Assignee: Aljoscha Krettek
> Priority: Blocker
> Fix For: 1.2.1
>
>
> Recent changes done for FLINK-5808 move default parallelism manifestation
> from eager to lazy, that is, the parallelism of operations that don't have an
> explicit parallelism is only set when generating the JobGraph. Some
> {{setParallelism()}} calls, such as
> {{SingleOutputStreamOperator.setParallelism()}} cannot deal with the fact
> that the parallelism of an operation might be {{-1}} (which indicates that it
> should take the default parallelism when generating the JobGraph).
> We should either revert the changes that fixed another user-facing bug for
> version 1.2.1 or fix the methods.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
