Dmitriy Kargapolov
Dmitriy Kargapolov
Race condition is possible since this happens not every time.
This happened recently in group of 3 nodes, result of ets:tab2list(locks_server_locks) is below: ``` node@A (leader): [{lock, [locks_leader, {asg_manager, asg_manager}], 8, , [{w, [{entry, , , 3, direct}]}, {w, [{entry,...
I've traced the issue in more details and found one stable pattern: node_A: set node_A a leader ... node_B: set node_B a leader ... node_C: set node_B an announced leader...
Currently `locks_leader` is getting info regarding its own leadership via lock notifications, but it does not use internal lock structures to check who is a new leader - it merely...
Regarding timeouts - this is what we do as a workaround in the app using `locks_leader` - when timeout happens (due to stuck in the `safe_loop`) - the app stops...
Hi, is there any chance to make a progress with this PR?
@fhunleth If you really like the proposed change, it is easy to make a progress. 1. You announce an "API breaking change" 2. Support last stable release "before breaking change"...
@rkallos It's much better now. Still, I'm wondering if we could go further, to use macros like these: ``` process_responses([], _State) -> ok; process_responses([{ExtRequestId, Reply} | T], #state { client...