[
https://issues.apache.org/jira/browse/FLINK-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949389#comment-15949389
]
ASF GitHub Bot commented on FLINK-6188:
---------------------------------------
Github user aljoscha commented on a diff in the pull request:
https://github.com/apache/flink/pull/3616#discussion_r108977967
--- 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 --
Yes, it is but the problem is that the treatment of the "default
parallelism" is a bit strange. (The default parallelism is the parallelism that
is set from the flink config or by the user on the command line using the `-p`
parameter. Maybe we have to rework that before we can fix this.
I'm starting to think that we should maybe revert the
parallelism/max-parallelism changes on the release-1.2 branch and rework the
whole thing properly.
> 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)
