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