Limit number of concurrently running processes


I would like to revisit this topic:!topic/camunda-bpm-users/I_w15c0Vg64
After many years have passed.

I did see this thread:

but the answers seem a bit hackish, and I’m not sure I want to go that route…

I was wondering if there is any Camunda-native way to do this now in the latest version of Camunda.
I get asked a lot about this capability from people modeling process definitions…


@Galen_Hollins I wrote the original way you mentioned in your above post. The more I think about this, not sure it’s exactly “hacky”. Say we did a listener or some other server side Java delegate running; the Java code would basically be doing the same logic.

It of course be cleaned up! What about creating a delegate that does the same logic check and you can call it as a standalone delegate on a start event? This way it’s reusable and less code in the bpmn file.


Perhaps you could think about this using this model -

You can limit actual executing process instances via limiting the size of the thread pool etc.
You could consider the database as a kind of ‘message queue’. In other words if a new instance is started, its queued in the DB until the job executor picks it up (assuming async behaviour).

Thus by default, the size of the ‘message queue’ is bounded by the size of the database.

Hence the question - are you wanting to limit the size of the ‘message queue’? (Id love to know the use case…) If thats the case, you could use numerous mechanisms in the DB, but there is no native Camunda capability to do this that Im aware of…



@Webcyberrob would this not result in lots of rework or duplicate code?:

Thinking: to have anything close to feature parity to the power of the ability to query the Camunda engine with its API to determine if there are duplicate instances, you would be building lots of extra query code around the “message queue”.

If there was a cleaner way to return a JSON response (error message or just a json payload as a object in the standard response) to the client on a error throw (or some built in function) I feel like we would not have any issues with the previous solution. Because this:

is not a clean response, not parseable (easily at least), and not nice to work with.

Hi Stephen,

Don’t get me wrong, I’m not suggesting interposing the engine with a message queue, my intent was to help unpack the use-case by describing the two concepts - buffering versus actual execution…

Im curious to understand the use case. It could be some sort of rate limiting and if thats the case, I wonder if it should be limited by another layer, eg API gateway…

Now that we can return process variables on a process start, I think we could have a much cleaner response. For example, we could use a variable called DISPOSITION. Its value could be ACCEPTED or REJECTED. Thus in the process logic have a decision gate which either accepts the process instance or routes to an end event if there are too many instances. Then a client need only look for the DISPOSITION variable in the response to know what happened. No exception or REST exception required…



Good point! :slight_smile:

Created a Feature request for better error object responses.

Are you aware that you can create a custom JAX-RS application that embeds the REST API classes and then add a custom ExceptionMapper that maps a Java exception to any response you want it to be?

I don’t see the need for the REST API to support such a use case on top of this.

:wink: was hoping that we could control this type of functionality without having to deploying additional apps or custom java code.

Even just being able to append a additional object or key to the existing api response would be good enough; does not need to be a re-write capability of the api response.

I’m not really happy with this proposal as we start to rebuild JAX-RS features that are not the focus of Camunda or the REST API.

@thorben is there an alternative to deploying a jax-rs app? Something that can be done within the BPMN file?

@StephenOTT I don’t think so

Could be something that would bubble the throw error as an object rather than a concatenated string in the message?

Right now when you throw the error to stop a process from instantiating you get:
a object, but the Message has the thrown error. When a error is thrown could we not add the actual error message as a different Key in the object?

Edit: Or possibly allow us to throw a object and that object can have more control over the output of the error message? Like if you were to expose a generic Camunda API error message function/object that we can append data into.

1 Like