How to Set the Maximum Number of Web Connections in WildFly

In WildFly and JBoss EAP, managing concurrent request limits is essential for optimizing application server performance, controlling resource usage, and preventing resource exhaustion[cite: 14]. This tutorial covers how to configure maximum web connection limits at three distinct levels: Listener level, Server level, and Application level[cite: 14]. The core connection-limiting mechanisms remain fully consistent across recent WildFly releases, including WildFly 41[cite: 14].

To prevent overload errors such as "The maximum number of web connections has been reached", you can fine-tune concurrency limits depending on your architectural scope[cite: 14]:

• Server listener level: Controls the maximum number of concurrent TCP connections accepted by an Undertow listener (e.g., HTTP or HTTPS)[cite: 14].
• Server level: Enforces a maximum concurrent request ceiling across an Undertow virtual host using the request-limit filter[cite: 14].
• Application level: Applies request limits to specific web applications or URI endpoints using Undertow predicate filters[cite: 14].

1. Configuring Maximum Connections at Listener Level

Undertow processes inbound network traffic through protocol listeners[cite: 14]. The max-connections attribute sets the maximum number of concurrent active connections processed by an Undertow listener[cite: 14].

For example, to set the maximum number of connections to 300 for the default HTTP connector via the JBoss CLI, execute[cite: 14]:

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-connections,value=300)

This updates the XML configuration within the undertow subsystem[cite: 14]:

<server name="default-server">
    <http-listener name="default" max-connections="300" socket-binding="http" redirect-socket="https" enable-http2="true"/>
</server>

Similarly, if your server utilizes secure HTTP listeners, you can configure max-connections for the https-listener:

/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=max-connections,value=500)

Deprecation of the AJP Protocol in WildFly 41

If your legacy deployment relies on the AJP (Apache JServ Protocol) listener (ajp-listener), note that AJP support has been officially deprecated starting in WildFly 41. Including an ajp-listener in your server configuration will now trigger a WARN message in the log at startup.

2. Configuring Maximum Connections at Server Level

To limit the number of concurrent requests processed across an Undertow virtual server (regardless of listener type), use the request-limit filter[cite: 14]. This filter caps active concurrent requests and queues incoming connections[cite: 14].

For example, to limit concurrent requests to 500 with a queue size of 10[cite: 14]:

# Define the request-limit filter
/subsystem=undertow/configuration=filter/request-limit=connlimit:add(max-concurrent-requests=500, queue-size=10)

# Attach the filter to the default virtual host
/subsystem=undertow/server=default-server/host=default-host/filter-ref=connlimit:add()

3. Configuring Maximum Connections at Application Level

To restrict connection limits to a specific application context or URL path, attach an Undertow predicate to the filter-ref[cite: 14].

To apply the request-limit filter only to requests matching the /mywebapp/ URI prefix[cite: 14]:

/subsystem=undertow/server=default-server/host=default-host/filter-ref=connlimit:write-attribute(name=predicate,value="path-prefix('/mywebapp/')")

You can also target specific Servlet resource mappings using regular expression predicates[cite: 14]. For instance, to limit endpoints ending with -limited[cite: 14]:

/subsystem=undertow/server=default-server/host=default-host/filter-ref=connlimit:write-attribute(name=predicate,value="regex('/mywebapp/(.*)-limited')")

4. Logging and Monitoring Connection Limit Events

When connection limits are reached or exceeded, Undertow logs diagnostic messages through XNIO[cite: 14]:

• Reaching High-Water Limit:[cite: 14]

  DEBUG [org.xnio.nio.tcp.server] (default Accept) Total open connections reach high water limit (10) by this new accepting request java.nio.channels.SocketChannel[connected local=/127.0.0.1:8080 remote=/127.0.0.1:40008]

• Exceeding Limit (Closing Connection):[cite: 14]

  DEBUG [org.xnio.nio.tcp.server] (default Accept) Exceeding connection high water limit (10). Closing this new accepting request java.nio.channels.SocketChannel[connected local=/127.0.0.1:8080 remote=/127.0.0.1:40010]

To enable these diagnostic log entries, enable DEBUG logging for the org.xnio.nio.tcp.server logger[cite: 14]:

/subsystem=logging/logger=org.xnio.nio.tcp.server:add(level=DEBUG)

Conclusion

Setting maximum connection limits in WildFly and JBoss EAP prevents server failure under heavy web traffic[cite: 14]. While listener-level and server-level connection filtering remain fully supported in modern releases, administrators running WildFly 41 and newer should actively migrate away from legacy AJP listeners in favor of secure HTTP/HTTPS reverse proxying.