-
Notifications
You must be signed in to change notification settings - Fork 326
expiration of lock_key should be relative #144
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
Comments
Makes sense. Can you open a PR for this? |
It is difficult for me because I'm not familiar with github. |
Ok, I'll fix this today. Thanks for the report! |
Does anyone have a patch for this? |
See #149 |
Thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Memcached uses monotonic clock if available, and it differs from the clock outside of it. The difference may be very large when memcached is running long time. In such cases, specifying expiration time as absolute time does not work as expected.
For example, the clock of our memcached running about 2 years are about 1 hour ahead. As a result, session lock does not work properly because expire parameter of lock (= time() + max_execution_time(30s) + 1) is past from the point of view of memcached, and therefore the lock expires immediately.
This problem can be avoided by specifying expiration parameter as number of seconds starting from current time, not absolute Unix time.
The text was updated successfully, but these errors were encountered: