Running 3.3
We are running graphs using the API, and performance problems occur when we have many graphs running concurrently. I've tried changing the property "executor.max_running_concurrently" in the hopes that graphs would be queued up in the Server in the "Ready" state, but this just throws a TooManyConcurrentExecutionsException.
Also (for a complete picture), the graph I'm running then uses the RUN_GRAPH component to launch sub-graphs.
Is there some property I'm missing or another config setting to get graphs to be queued?
We are running graphs using the API, and performance problems occur when we have many graphs running concurrently. I've tried changing the property "executor.max_running_concurrently" in the hopes that graphs would be queued up in the Server in the "Ready" state, but this just throws a TooManyConcurrentExecutionsException.
Also (for a complete picture), the graph I'm running then uses the RUN_GRAPH component to launch sub-graphs.
Is there some property I'm missing or another config setting to get graphs to be queued?
-
Hello,
If you set property "max_running_concurrently", you should specify how to cope with graphs, which are running over this limit.
For example if you set "max_running_concurrently" to 10 and 10 graphs are running concurrently, what to do with the next started graph.
You can specify this behavior by property "enqueue_executions". If this property is set to true, executions above "max_running_concurrently" are enqueued, if it is false executions above "max_running_concurrently" fail. Default value is false, so it is obviously the reason of your issues.
You can set this property per graph via web GUI section "Sandboxes". Select graph file and go to tab "Config properties".
For more details please see the documentation: http://doc.cloveretl.com/documentation/ ... rties.html
Please sign in to leave a comment.
Comments 1