-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
killing a process not always remove all mnesia transaction locks causing few orphaned locks held for forever #9581
Comments
Hi, I've added a testcase to otp based on your example, but didn't managed to reproduce it yet (probably wasn't lucky enough). Please check if that's what you meant to test. |
HI, I have just re-produced the issue. To re-produce the issue. you need the following structure of nested mnesia transaction
(4n1@icap600cx)23> rpc:multicall(mnesia,system_info,[held_locks]). logs from Node 3 which was processing the transaction and killed by timer $ grep -r "<0.17444.1>" logs from clustered node 4. There are thousands of times the transactions are restarts because of the orphaned lock that has been leftover by one of the killed process. $ grep -r "<8110.17444.1>" let me know anything I can be any help of you. |
accidentally closed. Reopened. |
You need 4 nodes N1, N2 -> site1 and N3,N4 -> site2 test_table -> N1, N2 test_table -> N3, N4 new code ->
|
you need to run the above code from node1 and node3 at the same time. |
When killing multiple processes by a timer:kill_after(Ttimeout, kill) and the each process consist of mnesia transaction of a clustered database tables with write lock doesn't always release the locks upon getting EXIT signal from the Pid being killed itself. Some held locks are seen hung around from clustered node (peer) not the node where the process being killed with Pid starting non-zero number.
To reproduce, we need a at least two nodes mnesia cluster database table and from one node, create a process which will write data to a clustered table within a transaction. before the transaction statement, start a timer:exit_after(Timeout, kill). Set the timeout value to 1ms.
spawn this process inside a loop for 1000 times.
example
After the execution, some held locks are seen hung for forever.
Expected behavior
All locks should have been release upon killing the process which consists of the mnesia transactions.
Affected versions
Tested from OTP 25 onwards - same results
The text was updated successfully, but these errors were encountered: