Processes/Jobs

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.

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 a ID. The ID can be used to correlated 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).

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

• 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 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 be also 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 via the web interface which allows you to correlate a job with its respective delayed rule. For example, in the screenshot above, you can see that the process ID is the same as the one in the screenshot above it which showed the related job.

Moreover, you can see here some more information of the kind of delayed rule (in the above example the creation of a tar archive). As well as its priority which is in this example 9 which indicates a delayed rule that will be executed with highest priority.

In contrast, the automated checksum calculations have a lower priority of 1 by default.

The priorities are set as such that the task that are executed from the web interface like tar creation or decompression, extraction of checksums, and the steps of the archiving workflow, are executed with a higher priority (meaning: earlier) then the automated checksum calculation. The reasons for that is that if a user uploads a folder with multiple thousand of files and the checksum calculation rules take highest priority, this might clog the whole queue for some time.

It is also possible to check the status of delayed rules via the CLI tool iCommands using the `iqstat` command which shows the users delayed rules that await execution.