Skip to content
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

Unreliable lock/extend functions do not ever resolve/reject #83

Closed
Sieabah opened this issue Dec 10, 2020 · 2 comments
Closed

Unreliable lock/extend functions do not ever resolve/reject #83

Sieabah opened this issue Dec 10, 2020 · 2 comments
Labels

Comments

@Sieabah
Copy link

Sieabah commented Dec 10, 2020

I have no idea how to replicate this issue because it happens completely randomly with no reliable way to make it occur. However it was immediately fixed when downgrading to 3.1.2. So my intuition is about an optimization between 4.0-4.2. I've also tried this on both redis 5 & 6 with no difference in behavior.

My guess is it has something to do with a premature optimization of whether or not to send the locking script with the request on this commit.

While I'm sure this is a great optimization for those that happen to be acquiring hundreds of thousands of locks and rapidly extending them multiple thousands of times per second (or to save a few $ on bandwidth). It seems there may be a potential miss whether the cache is reliable enough to use. From my experience trying to debug this library I have had the lock sometimes work and sometimes arbitrarily stop working. Same with extend, it would work with ioredis but not node redis then all of a sudden neither one worked, then ioredis would work but node redis wouldn't. I thought it was prefixes at first because of this issue. Having removed the prefixes and tried a bunch of different mutations of node redis and ioredis with varying degrees of options it seems prefixes and many options are completely transparent to redlock (as it should).

As I said before, I'd love to give a nice example of what is actually broken with evidence it's specifically the evalsha, but I cannot in any way get this to reliably execute after the evalsha optimization has been included. Which leads me to believe that change is not properly handled the errors. Anyone else running into perpetual locks never terminating or extend functions never resolving/rejecting I'd throw out trying to downgrade to 3.1.2, 4.0.0, or 4.1.0 to see if it resolves your issue.

@malpower
Copy link

here i got some clue.
when i pass a very small number to extend method, it won't return, i tried negative numbers, 0, and <10 numbers, and by using those numbers as parameter, the extend function won't return.

@mike-marcacci
Copy link
Owner

These are great observations, and appears to largely be resolved in the newest version (in that they throw errors, instead of hanging).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants