Experimental Settings
In this topic, you will learn how to configure some experimental settings.
Note: The System Settings screen is reorganized to make the navigation more user-friendly. The settings are now grouped by theme, to easily locate and access the features.
Navigate to the upper-right corner of the screen, click > System Settings > Experimental.
Important
- The settings on this screen can be updated or removed without prior notice. Contact Digital.ai Support to understand and use these settings.
- The Experimental settings page is available only for Administrators, who have the Admin global permission.
Database Query Logging
Use this setting to log any database statements. But now, you can select the Enable long SQL query logging checkbox to log the SQL statements. You can enable this to query the statements that are taking more time than defined in the Query execution duration longer than field.
- Select the Enable long SQL query logging checkbox to log the SQL statements. Selecting this checkbox enables the Query execution duration longer than field and the Enable SQL query parameters logging checkbox.
- In the Query execution duration longer than field, specify a value in milliseconds to log SQL queries that takes more time than the specified value. The default value is
2000
ms. For example, if you set the value as5000
ms, then only SQL statements which have crossed 5000 ms are logged. - Select the Enable SQL query parameters logging checkbox to log the SQL statements with the parameter values. Clear this checkbox to log them without the parameter values.
Strategy to Execute Jobs
Job execution strategy is an algorithm that is used in Release to determine whether certain jobs should be delayed or executed immediately.
You can select a strategy on how the jobs can be scheduled for execution.
Select one of the strategy from the Job execution strategies drop-down list.
- No backpressure—does not delay the execution of jobs in case the Release server is overloaded.
- Blocking backpressure—delays the execution of jobs in case the Release server is overloaded.
- Non-blocking backpressure—delays the execution of jobs in case the Release server is overloaded for a specific period of time.
- Non-blocking backpressure with limited jobs—delays the execution of jobs based on the available nodes.
When you select the Non-blocking backpressure strategy from the drop-down list, a new field called Delay is enabled and you must set a value in milliseconds. This value defines the no of milliseconds that Release must wait to re-run the jobs.
Also, you can change to any of the three options without any restart to your Release server.
A new job execution strategy, called Non-blocking backpressure with limited jobs, introduces a method where the execution of jobs is restricted based on available nodes. Choosing the Non-blocking backpressure with limited jobs option from the job execution strategies drop-down list enables the Desired Job Count Per Node drop-down list. In this list, you can choose or input the number of jobs allowed to run on a single node. For instance, if you have a 3-node cluster and set the value in this drop-down to 5, you can execute 5 jobs on each node, with a total of 15 jobs across the 3 nodes.
Optimized Permission Checker
The new permission checker implementation improves the performance by making the API calls faster.
- By default, the Enable Permission caching (performance tuning) checkbox is selected. This feature improves the performance by enabling the internal caching feature in Release while multiple permission are enabled in the background.
- If you don't want to enable this feature, clear the checkbox.
Concurrent Task Editing Settings
Note: When you enable the Enable concurrent Task edit checking in User Interface checkbox, it stops the changes from being saved to a task if it has been updated in the meantime. Enabling this checkbox prevents two users who are simultaneously updating the same task from overriding each other's changes. When enabled, and if you try to save changes on an outdated version of a task, the update will fail, and a notification message will appear in the UI. This does not include updates to to Comments, Attachments, Attributes, Lock/Unlock, Assignees, and Watchers.
To modify this setting, go to System settings > Experimental > Task editing settings section. By default, the Enable concurrent Task edit checking in User Interface and Enable concurrent Task edit checking in API checkboxes are cleared.
Note that the settings for Enable concurrent Task edit checking in API will only take effect when the Enable concurrent Task edit checking in User Interface checkbox is selected.
When the Enable concurrent Task edit checking in User Interface checkbox is selected, and if one user is editing a task and another user makes changes and tries to save them, the update will fail, and an error message will appear.
When the Enable concurrent Task edit checking in API checkbox is selected, and if you try to update a task that has been modified recently using Jython or REST API, it will fail with an error code of 409 - Conflict
.
Note: The settings on this screen can be updated or removed without prior notice.
Reload Jython Modules
Select the Enable reload of Jython modules without system restart checkbox to enable the reload of jython modules when a plugin is installed. It means that you can install the Jython plugins without a server restart.
Important: Do not use this feature in production environments.
Note: You must restart the server for JAR-type plugin uploads.
Script Engine Options
Select the Enable reload of Jython and Groovy engines checkbox to control the lifecycle of the script engine. In the Reload interval field, you can specify the duration, in minutes, to recycle the script engine on all nodes to remove the references to cached script classes and class loaders. The default value is set to 60
minutes.
Release Load Options
- Unlike Release 22.3 and earlier with which task dependencies were loaded one-by-one, you can now batch-load task dependencies with Release 23.1 and later.
- To optimize the number of select statements that are processed, you can batch-load task dependencies along with the Release.
- This means that the dependencies can be loaded simultaneously with the Release, resulting in more efficient processing.
- Enable this feature by selecting the Enable batch load for Gate task Dependencies (performance tuning) checkbox.
- By default, this checkbox is selected.
Whenever, you update a setting on this screen, the Save button is enabled.
- Click Save to save the changes.
- Click Reset to return to the default setting of the screen.