Failed: apache/flink#41524 (master - 7600e8b)

[Flink CI <fl...@foxmail.com>]

|  [

apache

/

flink

](https://travis-ci.org/apache/flink)  
---  
  
![branch icon](https://s3.amazonaws.com/travis-email-
assets/branch.png)[master](https://github.com/apache/flink/tree/master)  
  
|

![build hasfailed](https://s3.amazonaws.com/travis-email-assets/status-
failed.png)

[Build #41524 failed](https://travis-ci.org/apache/flink/builds/624197612)

![arrow to build time](https://s3.amazonaws.com/travis-email-assets/failure-
arrow.png)

![clock icon](https://s3.amazonaws.com/travis-email-assets/time.png)7 mins, 49
secs  
  
---  
  
![Zhijiang
avatar](https://secure.gravatar.com/avatar/92a244cca512354365c41d947baeb69e.jpg)Zhijiang

[7600e8b CHANGESET
->](https://github.com/apache/flink/compare/7bc79a172419...7600e8b9d4cb)  
  
[FLINK-14952][network] Solve the issue of exceeding memory limits when using
mmap blocking partition  
  
As reported by users in mail list, the container would be killed by yarn
because of exceeding physical memory limits. It is mainly because  
the memory usage of mmap in BoundedBlockingSubpartition is not capped and not
accounted by configured memory limits, but yarn would track  
this memory usage and kill the container once exceeding some threshold.  
  
To solve this issue, we adjust the default option of
"taskmanager.network.bounded-blocking-subpartition-type" from `auto` to `file`
for safety usage.  
And users can still enable mmap way via configuration if they make a proper
adjustment in yarn configuration to avoid container killing.  
  
In order to make this option consistent with existing compression option, we
also rename it to "taskmanager.network.blocking-shuffle.type".