---
schema_version: "1"
id: 4dd74bb9020d5b2e9edb87b770402d6904f57df76398b58667a964aacab02113
title: Back-Pressure and MaxConcurrency
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.3/tuning-backpressure-maxconcurrency.md
canonical_url: https://docs.mulesoft.com/mule-runtime/4.3/tuning-backpressure-maxconcurrency
source_site: docs.mulesoft.com
content_type: documentation
content_hash: bd1901f5d3bf69141e2a898e8557f89400bc81d4a0a0ba1ca62c0cb8c77f58a8
description: MuleSoft Documentation Site
release: "4.3"
latest: false
---
---
product: Mule Runtime
version: 4.3
---

# Back-Pressure and MaxConcurrency

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Under heavy load, Mule runtime engine (Mule) might not immediately have the resources available to
process a specific event. This issue might occur because all threads are busy and the current flow’s
concurrency is exceeded. When this occurs, Mule logs the following message:
`Flow 'flowName' is unable to accept new events at this time`  
This message is known as back-pressure. Mule back-pressure actions are specific to each connector’s
source.

When a producer component outputs information at a higher rate than a consumer component can process
it, you can use the `maxConcurrency` parameter to set the maximum number of concurrent messages that
a flow can process at any given time, whether the components are internal or external, flows or
sources, and so on.

Although Mule applies back-pressure on its own, the `maxConcurrency` parameter helps to control the
flow performance, especially when a backend server may affect when having high concurrency. See how
to set the parameter in the following example:

```xml
<flow name="perf-test-flow" maxConcurrency="${flow.max.concurrency}">
```

Similarly, you can limit the number of records that can be processed in a batch job by setting the
`maxConcurrency` parameter as in the following example:

```xml
<batch:job jobName="test-batch" maxConcurrency="${batch.max.concurrency}">
```

By default, the Flow and Async scopes do not set a `maxConcurrency` limit, but the Batch Job
component limits concurrency to twice the number of available cores. The capacity of your system
also limits concurrency.

## Components with Max Concurrency Settings

The following [components](https://docs.mulesoft.com/mule-runtime/4.3/about-components) provide a max concurrency setting:

- Flow scope

- Scatter-Gather router

- Async scope

- Batch Job scope

- Parallel For Each scope

## Recommendation

Unless a lower concurrency is required to artificially trigger a back-pressure event, use the
default settings, and do not change the max concurrency value.

## See also

- [Execution Engine Threads and Concurrency](https://docs.mulesoft.com/mule-runtime/4.3/intro-engine)