FileLockBasedLockChecker error attempting to release locks held by other processes

[marksantos]

To control which CPUs a specific-process can be pinned to in a multi-process affinity-enabled environment, the setting affinity.reserved can be specified to reserve specific CPUs per application.

When running multiple-applications with different reserved CPUs - the following error message can occur

ERROR FileLockBasedLockChecker - Cannot release lock for id XX as don't have it!

This seems to be due to ThreadAffinity checking the state of ALL lockfiles before checking which lockfiles are actually associated with the application's reserved CPUs:

final boolean canReserve(boolean specified) {

        // (1) Processes lockfiles...
        if (!LockCheck.isCpuFree(cpuId))
            return false;

        // (2) ....only checks reserved status here
        if (!specified && !reservable) return false;

        ...

As lock files for ALL processes using the library are stored in java.io.tmpdir by default - applications incorrectly process lockfiles reserved for other applications during step (1) and the error message results.

Minor issue with high loglevel (ERROR)

Version: affinity-3.2.1

[RobAustin]

Thanks for this very detailed description. Would you be able to issue a pull request to fix this ?

…

On 18 Jul 2020, at 18:10, Mark Santos ***@***.***> wrote:  To control which CPUs a specific-process can be pinned to in a multi-process affinity-enabled environment, the setting affinity.reserved can be specified to reserve specific CPUs per application. When running multiple-applications with different reserved CPUs - the following error message can occur ERROR FileLockBasedLockChecker - Cannot release lock for id XX as don't have it! This seems to be due to ThreadAffinity checking the state of ALL lockfiles before checking which lockfiles are actually associated with the application's reserved CPUs: final boolean canReserve(boolean specified) { // (1) Processes lockfiles... if (!LockCheck.isCpuFree(cpuId)) return false; // (2) ....only checks reserved status here if (!specified && !reservable) return false; ... As lock files for ALL processes using the library are stored in java.io.tmpdir by default - applications incorrectly process lockfiles reserved for other applications during step (1) and the error message results. Minor issue with high loglevel (ERROR) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[JerryShea]

@marksantos that was a somewhat delayed close ;)