Open nickminutello opened 11 years ago
@nickminutello Thanks for this.
Couple of questions.
os.hostname()
? The docs don't say anything about error conditions when fetching the hostname.unknown-hostname
? Is that a possibility?unknown-caller-id
.(now - timestamp)
in the console.log be useful?Rest looks fine, though I shall break these up into multiple commits. Also, tests broken. Will fix. Thanks again.
Also. The unknown-hostname and unknown-caller-id also handle the case when the lock value happens to be undefined (e.g. the lock has been deleted after the call to .setnx has failed)
Make sense?
just to add: had a long, long, long troubleshooting session where it ended up that this was the issue (timeout && my callbacks and promise chains not completing). very hard to track down.
i'd suggest even creating an error condition/handler that is triggered when timeout occurs and may optionally be handled in its own function/etc. perhaps like:
lock(lockName, timeout, callback(), timeoutHandler())
to summarize: i wish there was a way to receive a notification & react appropriately to a timeout condition
Any update on this issue? I'm evaluating this library and would love a way to be notified when the callback times out for debugging purposes
It is a really old issue, created long before I join the project. I don't think anybody is working on this anymore. If you think that is interesting and valuable, pull request or discussion are welcome :rocket:
I have found that when trying to diagnose issues with lock timeouts in a multi-process/multi-host environment, it was kind of essential to know "who" took the lock that timed out (that way you can then know where to start looking as to why that lock timed out).
To do this I made the lock value slightly more sophisticated than a timeout value - I added the host/pid.
I cant do a pull-request - but I can paste the code here: (this has a configurable delay patch mixed in too)