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

Redis not setting a key for a large ttl number #6800

Closed
sullyvannunes opened this issue Jan 22, 2020 · 6 comments
Closed

Redis not setting a key for a large ttl number #6800

sullyvannunes opened this issue Jan 22, 2020 · 6 comments

Comments

@sullyvannunes
Copy link

I am learning about TTL and trying some examples. But when I set a specific large number the key is not created (or at least it is deleted so fast) like below.

127.0.0.1:6379> set sullyvan nunes EX 10000000000000000
OK
127.0.0.1:6379> get sullyvan
(nil)

It is worth to point out a larger and a fewer number works fine.

127.0.0.1:6379> set sullyvan nunes EX 100000000000000000
OK
127.0.0.1:6379> get sullyvan
"nunes"
127.0.0.1:6379> set sullyvan nunes EX 1000000000000000
OK
127.0.0.1:6379> get sullyvan
"nunes"

I am using macOS Mojave 10.14.6 and Redis-cli version: 5.0.7

Could someone help me to understand this behavior?

@patpatbear
Copy link
Contributor

patpatbear commented Jan 22, 2020

@sullyvannunes this is caused by long long overflow, not an issue, you should specify smaller TTL.

TTL is represented by long long MILLISECOND inside redis, set sullyvan nunes EX 100000000000000000 means sullyvan will be expired 100000000000000000 SECONDS, i.e. 100000000000000000000 milliseconds, which exceeds range of LONG_LONG_MAX 9223372036854775807.

@filipecosta90
Copy link
Contributor

filipecosta90 commented Jan 22, 2020

@sullyvannunes this is caused by long long overflow, not an issue, you should specify smaller TTL.

TTL is represented by long long MILLISECOND inside redis, set sullyvan nunes EX 100000000000000000 means sullyvan will be expired 100000000000000000 SECONDS, i.e. 100000000000000000000 milliseconds, which exceeds range of LONG_LONG_MAX 9223372036854775807.

hi there @patpatbear if we specify the expire time in milliseconds this will never happen due to the overflow guard on getLongLongFromObjectOrReply->getLongLongFromObject->string2ll
See example bellow

127.0.0.1:6379> SET a b PX 9223372036854775806
OK
127.0.0.1:6379> SET a b PX 9223372036854775807
(error) ERR value is not an integer or out of range
127.0.0.1:6379> SET a b EX 9223372036854775807
OK

The issue here is that we dont check for overflow when we internally convert from seconds to milliseconds. #6801 fixes it.

@patpatbear
Copy link
Contributor

@filipecosta90 @sullyvannunes , oops , i missed the range check.

@sullyvannunes
Copy link
Author

got it! Thanks @filipecosta90 @patpatbear

@oranagra
Copy link
Member

oranagra commented Nov 9, 2020

why would someone want to expire a key in 317097919 years?

@oranagra
Copy link
Member

fixed by #8287

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