[
https://issues.apache.org/jira/browse/IGNITE-29173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov resolved IGNITE-29173.
----------------------------------------
Fix Version/s: 2.20
Release Note:
Added `kill lock` control.sh command.
Added locks control after jobs and services execution.
Resolution: Fixed
[~nizhikov], thanks for the review! Merged to master.
> Kill lock command
> -----------------
>
> Key: IGNITE-29173
> URL: https://issues.apache.org/jira/browse/IGNITE-29173
> Project: Ignite
> Issue Type: New Feature
> Reporter: Aleksey Plekhanov
> Assignee: Aleksey Plekhanov
> Priority: Major
> Fix For: 2.20
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In some scenarios explicit cache locks can leak. For example, an application
> may call cache.lock(key).lock() without a matching lock.unlock() (a missing
> or skipped
> unlock() in user code, an exception thrown between acquiring the lock and
> releasing it, etc.). In such a case the lock is never released.
> There is currently no way to remove such a lock:
> - the lock is not bound to a transaction, so neither KILL TRANSACTION
> nor TransactionMXBean can help;
> - existing KILL subcommands (scan, sql, continuous, all, ...) do not
> cover explicit cache locks.
> Add a new management command to the control utility that allows an
> administrator to forcibly cancel an explicit cache lock identified by its
> lock ID (XID):
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
