How to aggregate Multi thread process execution in one launch

Overview

Starting version 5 Report Portal Client supports multi-process launch enabled by default. The feature joins reporting from every Report Portal Client running on a single physical or virtual machine into one launch. The feature uses file system to synchronize.

Configuration

These properties are responsible for the feature control in the reportportal.properties file. All of the are optional, so that means if a client doesn't find them it will use default values.

The feature is enabled by default.

Property name	Type	Default value	Description
rp.client.join	Boolean	true	Enable / Disable multi-process launch join mode
rp.client.join.lock.file.name	String	reportportal.lock	A name of a main lock file, can be an absolute path. A client which managed to obtain that lock count itself as a primary launch process. It rewrites synchronization file with its launch ID.
rp.client.join.sync.file.name	String	reportportal.sync	A name of a launch ID synchronization file, can be an absolute path. Each client waits for a lock on that file to get a launch ID (first line) and write its own ID to the end of the file.
rp.client.join.file.wait.timeout.ms	Integer	60000	A synchronization file wait timeout in milliseconds.

Limitations

1. The functionality does not work under WSL (Windows Subsystem for Linux). It looks like two separate processes have their own representation of file-system during runs, which synchronize only after processes exit. All of them count itself as a primary process.

Implementation logic

Description

ReportPortal client creates two files using rp.client.join.lock.file.name (lock file) property and rp.client.join.sync.file.name (sync file) property. Which actually might be file system paths. The first process, which will be able to lock on Sync and Lock file count itself as 'primary' process and writes self UUID into Sync file (overrides if it already exists). After that Primary process releases Sync file but continues hold Lock file to not allow any other become primary. All other (secondary) processes which were unable to obtain lock on Lock file use Sync as Launch UUID source.

Additionally each Secondary writes self UUID into Sync file and deletes it after it is finished. The last Secondary process left deletes Sync file.

Sequence diagram

title Parallel run locking

Thread 1->reportportal.sync:Create+Write
Thread 1<--reportportal.sync: File lock
Thread 1->reportportal.lock:Create+Write
Thread 1<--reportportal.lock: File lock
Thread 2-#redxreportportal.sync:Create+Write\n\nerror: File already exists
Thread 1->Thread 1: Generate UUID
Thread 2->Thread 2: Poll 'reportportal.sync'
Thread 1->reportportal.sync:File clean
Thread 1->reportportal.sync:Write Launch / Thread UUID
Thread 1<--reportportal.sync:Release lock
Thread 2->reportportal.sync: Write lock
Thread 2<--reportportal.sync: File lock
Thread 2<--reportportal.sync:Read Launch UUID
Thread 2->reportportal.sync:Write Thread ID
Thread 2<--reportportal.sync: Release lock
rbox over Thread 2,Thread 1: Launch passed
Thread 1->reportportal.sync:Write lock
Thread 2-#redxreportportal.sync:Write lock\n\nerror: File already locked
Thread 2->Thread 2: Poll 'reportportal.sync'
Thread 1->reportportal.sync:Remove self Thread ID
Thread 1<--reportportal.sync:Release lock
Thread 1<--reportportal.lock:Release lock
Thread 1->reportportal.lock:Remove file
Thread 2->reportportal.sync: Write lock
Thread 2->reportportal.sync:Remove self Thread ID
alt There are no Thread IDs left
Thread 2->reportportal.sync: Remove file
else Still contains other Thread IDs
Thread 2<--reportportal.sync: Release lock
end