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 as 5000 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.

Job Execution Strategy

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 following strategies from the Job execution strategies drop-down list.

• No backpressure (default)—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.

  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.

  

• Non-blocking backpressure with limited jobs—delays the execution of jobs based on the available nodes.

  With the Non-blocking backpressure with limited jobs job execution strategy, jobs are executed based on the number of 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 which you type the maximum number of jobs allowed to run on a single node. For example, if you have a three-node cluster and set the Desired Job Count Per Node to 5, you can execute 5 jobs on each node, with a total of 15 jobs across all the three nodes at any given point in time.

  

Note: Changing the JOb execution strategy needs no Release server restart.

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, if one user is editing a task and another user makes changes and tries to save them, the task will fail, and an error message will appear.

When the Enable concurrent Task edit checking in API is selected and you try to update a task that has been modified, 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.

Task Execution Log Settings

The log truncation and debugging mechanism helps you manage live log entries that you see in the Task Drawer's Activity tab during task execution.

Log truncation lets you set a maximum size limit for live logs. Once enabled, the system automatically trims logs when they reach the set limit, preventing the accumulation of too many log files on the system.

1. Select the Enable execution log truncating to set a maximum size limit for logs generated during tasks.
2. Type the maximum log size, in MB, in the Max execution logs size box.

Note: The system will automatically truncate logs when they reach the defined size limit, preventing the accumulation of excessive log files on the file system. Actual logs size can exceed this limit if there is huge amount of logs being produced

Debugging Mechanism for Live Logging

The debugging mechanism for live logging improves how logs are collected and displayed by controlling how often updates happen:

• Logs are updated every 5 seconds or after collecting 1MB of logs, whichever comes first.

• This prevents system overload from scripts that generate logs rapidly, such as those with infinite loops.