blob: df25aa532b315458ff48d91e6cb16d3376c28299 [file] [log] [blame]
<table class="configuration table table-bordered">
<thead>
<tr>
<th class="text-left" style="width: 20%">Key</th>
<th class="text-left" style="width: 15%">Default</th>
<th class="text-left" style="width: 10%">Type</th>
<th class="text-left" style="width: 55%">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><h5>cluster.evenly-spread-out-slots</h5></td>
<td style="word-wrap: break-word;">false</td>
<td>Boolean</td>
<td>Enable the slot spread out allocation strategy. This strategy tries to spread out the slots evenly across all available <code class="highlighter-rouge">TaskExecutors</code>.</td>
</tr>
<tr>
<td><h5>cluster.intercept-user-system-exit</h5></td>
<td style="word-wrap: break-word;">DISABLED</td>
<td><p>Enum</p></td>
<td>Flag to check user code exiting system by terminating JVM (e.g., System.exit()). Note that this configuration option can interfere with <code class="highlighter-rouge">cluster.processes.halt-on-fatal-error</code>: In intercepted user-code, a call to System.exit() will not cause the JVM to halt, when <code class="highlighter-rouge">THROW</code> is configured.<br /><br />Possible values:<ul><li>"DISABLED": Flink is not monitoring or intercepting calls to System.exit()</li><li>"LOG": Log exit attempt with stack trace but still allowing exit to be performed</li><li>"THROW": Throw exception when exit is attempted disallowing JVM termination</li></ul></td>
</tr>
<tr>
<td><h5>cluster.io-pool.size</h5></td>
<td style="word-wrap: break-word;">(none)</td>
<td>Integer</td>
<td>The size of the IO executor pool used by the cluster to execute blocking IO operations (Master as well as TaskManager processes). By default it will use 4 * the number of CPU cores (hardware contexts) that the cluster process has access to. Increasing the pool size allows to run more IO operations concurrently.</td>
</tr>
<tr>
<td><h5>cluster.processes.halt-on-fatal-error</h5></td>
<td style="word-wrap: break-word;">false</td>
<td>Boolean</td>
<td>Whether processes should halt on fatal errors instead of performing a graceful shutdown. In some environments (e.g. Java 8 with the G1 garbage collector), a regular graceful shutdown can lead to a JVM deadlock. See <a href="https://issues.apache.org/jira/browse/FLINK-16510">FLINK-16510</a> for details.</td>
</tr>
<tr>
<td><h5>cluster.registration.error-delay</h5></td>
<td style="word-wrap: break-word;">10000</td>
<td>Long</td>
<td>The pause made after an registration attempt caused an exception (other than timeout) in milliseconds.</td>
</tr>
<tr>
<td><h5>cluster.registration.initial-timeout</h5></td>
<td style="word-wrap: break-word;">100</td>
<td>Long</td>
<td>Initial registration timeout between cluster components in milliseconds.</td>
</tr>
<tr>
<td><h5>cluster.registration.max-timeout</h5></td>
<td style="word-wrap: break-word;">30000</td>
<td>Long</td>
<td>Maximum registration timeout between cluster components in milliseconds.</td>
</tr>
<tr>
<td><h5>cluster.registration.refused-registration-delay</h5></td>
<td style="word-wrap: break-word;">30000</td>
<td>Long</td>
<td>The pause made after the registration attempt was refused in milliseconds.</td>
</tr>
<tr>
<td><h5>cluster.services.shutdown-timeout</h5></td>
<td style="word-wrap: break-word;">30000</td>
<td>Long</td>
<td>The shutdown timeout for cluster services like executors in milliseconds.</td>
</tr>
<tr>
<td><h5>cluster.uncaught-exception-handling</h5></td>
<td style="word-wrap: break-word;">LOG</td>
<td><p>Enum</p></td>
<td>Defines whether cluster will handle any uncaught exceptions by just logging them (LOG mode), or by failing job (FAIL mode)<br /><br />Possible values:<ul><li>"LOG"</li><li>"FAIL"</li></ul></td>
</tr>
</tbody>
</table>