Increase HTTP Client Max Connections Per Route


We need to increase the “setMaxConnPerRoute” of the “http-connector” Camunda connector. We have read through the “HTTP Connector”, “Extending Connect”, and “Camunda Connector Reference” documents as well as examining the Camunda connect code on Github.

We cannot figure out how you actually use the custom configurator such that when processes are executing and more than five (5) of them are connected to the same route (URL) the processes don’t lock up. This “condition” renders the Camunda server unusable until the underlying JVM is restarted.

We have tried putting the custom configurator jar file into a process deployment war file We have tried putting the jar down in the WildFly modules directories.

We need step-by-step instructions on how this is done for a SHARED Camunda engine, please.

We are using Camunda 7.6.2-ee and WildFly 10.1.

Thank you.


UPDATE: We may have figured this out (accidentally).

We grabbed the camunda-connect 1.0.3 code from Github and placed the custom configurator jar file in org.camunda.connect.http-client.impl and META-INF/services file within that project. We then built the jar and replaced the existing camunda-connect-http-client-1.0.3.jar files within the WildFly distribution. We bounced WildFly, ran processes with debug level logging on, and saw that the number of connections per route increased to the values we had set.

We have not confirmed that this did not break something else. We don’t know if this is even the proper way to do this, so any confirmation would be appreciated.



Hi Michael,

I can confirm that your approach works. A way that does not require rebuilding connect would be:

  1. Build a connector configurator JAR as outlined in the connect documentation in
  2. Deploy it as a module to wildfly
  3. Edit ${WILDFLY_HOME}/modules/org/camunda/bpm/camunda-engine-plugin-connect/main/module.xml. Declare a dependency on the new JAR module and make sure to set the attribute services="import".



I’ve doubtless done something wrong, but the technique suggested above does not work. I placed the configurator jar file in this directory:


I then created a module.xml file with the following content:

<module xmlns="urn:jboss:module:1.0" name="com.att.gcs.bizops.cop.connector.GcsBpoCustomHttpConnectorConfigurator">
    <resource-root path="GcsBpoCustomHttpConnectorConfigurator-0.0.1.jar" />


I then modified the both copies of the camunda-engine-plugin-connect module.xml file and added the following entry:

<module name="com.att.gcs.bizops.cop.connector.GcsBpoCustomHttpConnectorConfigurator" services="import" />

I restarted WildFly, ran a process, then checked the WildFly DEBUG level output for threads allocated, and it did not change from the default.

I have had very little luck getting WildFly to load modules, despite hours of trying for different modules. I’m not sure if this is a dependency issue that I needed to account for in the configurator module.xml file or not.

In any event, both methods involve modifying the base Camunda/WildFly distribution, so I suppose there’s little difference in terms of long-term maintenance.



Hi Michael,

If both ways are equally good for you, then I recommend to stick with the way that works. If you would like to continue with the option I proposed, I’d like to ask you to share your configurator on github, so that I can build and test it locally.



We just discovered that you can change this value very easily through a system property. Add the following to standalone.xml (or domain.xml) just before the section:

You can also do this through the WildFly GUI by selecting Configuration -> System.Properties -> View and then adding a key of “http.maxConnections” and an integer value of the maximum connections. This will set the maximum number of connections per “route” to that value The maximum number of connections in the entire pool is set to twice whatever value you enter. I suspect that other attributes for the Apache HTTP client can be set in this manner.

This is the easiest way of all.


That is a great solution. All the available system properties are documented here: