Heavy operations like global searches, batch creations, batch updates or complex reports can consume a lot of precious server resources. Executing too many heavy operations at the same time in an uncontrolled manner may even result in a server crash. To avoid that, openBIS provides a mechanism to control a number of concurrent operations. The mechanism is highly configurable. It allows to set different limits for different sets of operations. For instance, we could limit a number of concurrent global searches to 2, concurrent creations to 5 and reports to 7. All of this is done via application server service.properties file. Apart from the limits we can also specify timeouts. Using "concurrent-operation-limiter.timout" property we can control a time after which an operation will quit waiting for its turn if the server is too busy. If that happens an exception is thrown with an information for a user that the server is currently under a heavy load. To control a timeout of asynchronous operations (e.g. operations executed via V3 API executeOperations method with AsynchronousOperationExecutionOptions) one can use "concurrent-operation-limiter.timout-async" property. Normally, the asynchronous timeout should be set to a much higher value than the regular timeout. Asynchronous operations are executed in the background and are expected to be potentially long-running. This is not the case with regular synchronous operations that put the whole execution flow on hold.
WARNING: The mechanism works for all V3 API operations + for global search, experiment/sample/dataset/material searches (no matter where they are executed from, i.e. V1, core UI etc.)
Controls a time after which an operation will quit waiting for its turn if the server is too busy. If that happens an exception is thrown with an information for a user that the server is currently under a heavy load.
|30000 milliseconds (i.e. 30 seconds)|
|concurrent-operation-limiter.timeout-async||Same as "concurrent-operation-limiter.timeout" but for asynchronous operations (e.g. operations executed via V3 API executeOperations method with AsynchronousOperationExecutionOptions).||86400000 milliseconds (i.e. 1 day)|
|concurrent-operation-limiter.limits||A comma-separated list of limit names. The first matching limit is used. If no limits match then an operation is executed normally.||empty list|
A regexp that defines what operations the limit should be applied to. For instance, "Search.*" value means that the limit should be used for all operations which name starts with "Search" prefix. Names of operations are the names of V3 operations classes (i.e. classes that implement V3 IOperation interface). For instance, global search operation name is "SearchGloballyOperation", experiment search operation name is "SearchExperimentsOperation" etc. Therefore, "Search.*" value would make the limit match any kind of search. That, together with the "limit" parameter value e.g. set to 5, would mean one can execute only 5 searches (of any kind) at the same time.
A number of concurrent operations that can be executed at the same time. Any operation execution above that limit will be waiting idle either until a timeout or until some of the already executing operations is finished.
|-1 (i.e. no limit)|