Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
rdms:webapp:processes [2025/08/13 11:38] – periodic edit giuliordms:webapp:processes [2025/09/23 13:47] (current) – some small text changes jelte
Line 2: Line 2:
 {{indexmenu_n>5}} {{indexmenu_n>5}}
  
-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 bar. 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 bar. 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&850 |}} {{ :rdms:webapp:rdms_procces_0.png?direct&850 |}}
Line 10: Line 10:
  
 Currently, the following operations are visible as processes: Currently, the following operations are visible as processes:
-  - Uploading of data via the web interface, +  - Uploading of data via the web interface. 
-  - Bundling operations (compress to tar or decompress), +  - Bundling operations (compress to tar or decompress). 
-  - Extraction of metadata,+  - Extraction of metadata.
   - Different steps of the [[rdms:workflows:archiving|Archiving Workflow]].   - Different steps of the [[rdms:workflows:archiving|Archiving Workflow]].
  
Line 26: Line 26:
 ===== Delayed Rules ===== ===== Delayed Rules =====
  
-The RDMS is built on top of the data management software [[rdms:rdmsproject:irods|iRODS]]. The iRODS system has the built-in 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.  +The RDMS is built on top of the data management software [[https://irods.org/|iRODS]]. The iRODS system has the built-in capability to execute certain tasks when a certain event is registered in the system. These 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 in several places in the RDMS, often as delayed rules. Important example of delayed rules are:+We use rules in several places in the RDMS, often as delayed rules. Important examples of delayed rules are:
  
-  * **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 and us the capability to check the [[rdms:data:integrity|integrity of your data]]. +  * **Automated checksum calculations of your data**: If you upload files to the RDMS, an automated checksum calculation for your files will be executed as a delayed rule. This guarantees that all your files have a checksum registered, which gives you and 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.+  * **Bundling/Unbundling via the web interface**: If you use the function to compress a folder to a tar archive or to decompress a 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.  You can observe the status of your rules via the second tab in the processes/jobs view. 
Line 39: Line 39:
 The RDMS process ID (highlighted in red) 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.  The RDMS process ID (highlighted in red) 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).+The example we show above is a delayed rule linked to the creation of a tar archive (data bundling). You will notice that below the first line (see 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&850 |}} {{ :rdms:webapp:rdms_procces_8.png?direct&850 |}}
  
-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 all 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.  +The priorities are set such that critical tasks, tasks initiated manually by the user, and tasks that are part of a [[..:workflows:|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.+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&850 |}} {{ :rdms:webapp:rdms_procces_9.png?direct&850 |}}