Mutexes not released when process stopped?

[kirstyannepollock]

Hi. I have noticed recently that it seems as though the mutexes in my app are no longer released when the process is paused or stopped. Perhaps / probably it is a misunderstanding on my part, but I wonder if you could clarify.

Is it the case that they ARE released, but only AFTER the lockTimeout has expired? (I am not explicitly setting refreshInterval, so that will remain the default)

I have quite long lockTimeouts, in some cases hours, maybe that is why I can't see the lock released.

Is there a way to make the lock release immediately on a process crash or stop?

[swarthy]

Hi! Yes, by default mutex releases after lockTimeoutms since last refresh (which performs every refreshIntervalms).
So if you have lockTimeout = 1h (if refreshInterval is not specified then it will be 48m) and then process crashes then lock will be released after [12m, 1h] (depends on how long time ago last refresh was performed).
For example:
lockTimeout = 1h
refreshInterval (by default) = 1h * 0.8 = 48m
[08:00] Mutex acquired. // If refresh will not be called, mutex will be released at 09:00
[08:48] Lock refreshed. // Now, if process will crash before next refresh, mutex will be released at 09:48
[09:36] Lock refreshed. // Release delayed to 10:36
[10:12] Process crashed.
[10:36] Mutex released (after 1h since last refresh, and since 24m after process crash)

If you want to decrease the delay before auto-release after process crash then you should decrease lockTimeout. lockTimeout can be interpreted as "how long mutex must be locked, before owner will refresh it again?/how long mutex must be locked while process freezed and cant refresh it?" and refreshInterval can be interpreted as "how often delay mutex auto-release". You can set refreshInterval = 1m and lockTimeout = 10m if you guarante what your process will not sleep/freeze at least once per 10-1=9m and will perform refresh

[kirstyannepollock]

Alexander,Thanks for that detailed explanation. I'll see if I can juggle the parameters to get the behaviour I'd like, in combination with a small structural rethink of our services.I'll let you know how it works out in the coming week. KirstyOn 25 Apr 2020 13:06, Alexander Mochalin <notifications@github.com> wrote: Hi! Yes, by default mutex releases after lockTimeoutms since last refresh (which performs every refreshIntervalms). So if you have lockTimeout = 1h (if refreshInterval is not specified then it will be 48m) and then process crashes then lock will be released after [12m, 1h] (depends on how long time ago last refresh was performed). For example: lockTimeout = 1h refreshInterval (by default) = 1h * 0.8 = 48m [08:00] Mutex acquired. // If refresh will not be called, mutex will be released at 09:00 [08:48] Lock refreshed. // Now, if process will crash before next refresh, mutex will be released at 09:48 [09:36] Lock refreshed. // Release delayed to 10:36 [10:12] Process crashed. [10:36] Mutex released (after 1h since last refresh, and since 24m after process crash) If you want to decrease the delay before auto-release after process crash then you should decrease lockTimeout. lockTimeout can be interpreted as "how long mutex must be locked, before owner will refresh it again?/how long mutex must be locked while process freezed and cant refresh it?" and refreshInterval can be interpreted as "how often delay mutex auto-release". You can set refreshInterval = 1m and lockTimeout = 10m if you guarante what your process will not sleep/freeze at least once per 10-1=9m and will perform refresh —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[swarthy]

Ok! Feel free to reopen issue if have any questions!