Differences

This shows you the differences between two versions of the page.

--- rdms:webapp:processes [2025/03/18 10:10] – [Delayed Rules] some text jelte
+++ rdms:webapp:processes [2025/03/24 08:46] (current) – giulio
@@ Line 1: / Line 1: @@
-====== Processes/Jobs ======
+====== Processes and Jobs ======
 {{indexmenu_n>5}}
-The RDMS web interface allows you to observe certain processes/jobs that you do via the web interface. For that, the //Processes/jobs// view on the left-side menu can be used. Moreover, this view allows you to observe the status of your //Delayed Rules//, a concept that will be explained in this section as well.
+The RDMS web interface allows you to observe the status of the processes/jobs that you started via the web interface. For that, you can use the //Processes/jobs// view on the left-side menu. Moreover, this view allows you to observe the status of your //delayed rules//, a concept that will be explained in this section as well.
-{{ :rdms:webapp:rdms_procces_0.png?direct&800 |}}
+{{ :rdms:webapp:rdms_procces_0.png?direct&600 |}}
 ===== Processes/Jobs in the Web Interface =====
@@ Line 17: / Line 17: @@
 By clicking on a listed process, you can get more details about it.
-{{ :rdms:webapp:rdms_procces_2.png?direct&800 |}}
+{{ :rdms:webapp:rdms_procces_4.png?direct&600 |}}
-This shows you, for example, the kind of process and the data on which it was executed. Moreover, every process gets a process number as well as a ID. The ID can be used to correlated the job to a Delayed Rule (see below) if applicable.
+This shows you, for example, the kind of process and the data on which it was executed. Moreover, every process gets a process number as well as an ID. You can use the ID to correlate the job to a delayed rule (see below), if applicable.
-**Note:** Not all jobs are executed as Delayed Rules as will described below. For example the upload operation, is not a delayed rule, but it has a Delayed Rule associated with it that is executed in the background (computation of data checksum).
+**Note:** Not all jobs are executed as delayed rules, as will described below. For example the upload operation will not be triggered as a delayed rule, but the computation of data checksum following the upload will be executed as a delayed rule in the background.
 ===== Delayed Rules =====
-The RDMS is built on top of the data management software [[rdms:rdmsproject:irods|iRODS]]. The iRODS system has the in-built capability to execute certain task when a certain event is registered in the system. This automated tasks are called //rules// and they can be delayed, meaning being queued and executed in the background even if the user is not logged in anymore.
-We use rules at several places in the RDMS, often as delayed rules. Important example of delayed rules are:
+The RDMS is built on top of the data management software [[rdms:rdmsproject:irods|iRODS]]. The iRODS system has the in-built capability to execute certain tasks when a certain event is registered in the system. This automated tasks are called //rules// and they can be delayed, meaning being queued and executed in the background even if the user is not logged in anymore.
-  * **Automated checksum calculations of your data**: If you upload files to the RDMS, a automated checksum calculation for your files with be executed as a delayed rules. This guarantees that all your files have a checksum registered which gives you/us the capability to check the [[rdms:data:integrity|integrity of your data]].
+We use rules in several places in the RDMS, often as delayed rules. Important example of delayed rules are:
-  * **Bundling/Unbundling via the web interface**:
+  * **Automated checksum calculations of your data**: If you upload files to the RDMS, an automated checksum calculation for your files with be executed as a delayed rule. This guarantees that all your files have a checksum registered which gives you/us the capability to check the [[rdms:data:integrity|integrity of your data]].
+  * **Bundling/Unbundling via the web interface**: If you use the function to compress a folder to a tar archive or to decompress a tar archive, it will also be executed as a delayed rule.
+You can observe the status of your rules via the second tab in the processes/jobs view.
+{{ :rdms:webapp:rdms_procces_5.png?direct&800 |}}
+The RDMS process ID is visible for every delayed rule, which allows you to correlate a job with its respective delayed rule. For example, in the screenshots above, you can see that the process ID is the same for both the delayed rule and for the related job presented in the section above.
+Moreover, you can see displayed here as an example what the delayed rule for the creation of a tar archive looks like. You will notice that below the first line (//ID://), a **//Priority//** of 9 is assigned to this rule. The RDMS assigns **priority 9** to all the delayed rules that **should be executed first**, **priority 5** to delayed rules that have **medium priority**, and finally **priority 1** to all the rules that should be **queued last** (i.e. checksum calculations).
+{{ :rdms:webapp:rdms_procces_8.png?direct&600 |}}
+The priorities are set such that critical tasks, tasks initiated manually by the user, and tasks that are part of a workflow are allowed to jump the queue and be executed before tasks that are not essential to the functioning of the system, numerous, common, and automatically scheduled. For example, it is important that the checksum of a file is calculated after the file is uploaded, but this calculation should not stop the archiving workflow from moving to the next step. Even if the file was uploaded way before the workflow started, the calculation of the checksum is given minimal priority, so that it may happen when the system is mostly idle.
+You can also check the status of delayed rules via the CLI tool [[rdms:access:linux:icommands|iCommands]] using the `iqstat` command, which shows the user's delayed rules that await execution.
+{{ :rdms:webapp:rdms_procces_9.png?direct&600 |}}