Processes and Jobs

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.

If you perform certain operations in the RDMS web interface, these get registered as processes. The status of these processes can be observed here.

Currently, the following operations are visible as processes:

1. Uploading of data via the web interface
2. Bundling operations (compress to tar or decompress)
3. Extraction of metadata
4. Different steps of the Archiving Workflow

By clicking on a listed process, you can get more details about it.

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

The RDMS is built on top of the data management software 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.

We use rules in several places in the RDMS, often as delayed rules. Important example 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/us the capability to check the 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.

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).

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 iCommands using the `iqstat` command, which shows the user's delayed rules that await execution.