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

Inserting item with sub-millisecond expiration time causes problems on get (redis backend) #159

Closed
ahockersten opened this issue Jun 5, 2017 · 2 comments
Milestone

Comments

@ahockersten
Copy link
Contributor

ahockersten commented Jun 5, 2017

I think I have found a corner case in the Redis code that causes problems where items are inserted with really low durations.

Consider the following code:

var item = new CacheItem<object>("foo", "bar", sliding ExpirationMode.Absolute, TimeSpan.FromTicks(1));
cache.Put(item);

This will enter CacheItem's constructor, where TimeSpan will be checked if it is > 0 at CacheItem.cs line 133

if (ExpirationMode != ExpirationMode.Default && ExpirationMode != ExpirationMode.None && ExpirationTimeout <= TimeSpan.Zero)
{
    throw new ArgumentOutOfRangeException(nameof(timeout), "Expiration timeout must be greater than zero if expiration mode is defined.");
}

When cache items are stored into Redis, their duration is converted into a millisecond value (RedisCacheHandle.cs line 833 and other places). If this value is lower than 1 ms, this will end up being stored as 0. Later, inside GetCacheItemAndVersion() in RedisCacheHandle.cs, at line 499+, CacheItem's constructor is called with this value, which is now 0, which causes the constructor to throw an exception.

I am unsure what the fix for this is, else I would submit a proper patch for it. I will gladly submit a patch if we can figure out what the fix should be.

@MichaCo
Copy link
Owner

MichaCo commented Jun 5, 2017

@ahockersten question is, why would you want to store items in Redis for less than 1 millisecond? That wouldn't do anything as the transport from client to server might already takes longer ;)

In general, this is an intentional limitation. The fact that the exception occurs later when the cache item gets retrieved is not really friendly. I'll add a check that expiration timeout is at least 1ms.

@ahockersten
Copy link
Contributor Author

Oh I agree, it was an issue in my code that it was saving things with a sub-millisecond duration, which I have now fixed. :) In this case it was caused by subtracting two datetimes that sometimes happened to be very close to each other in time.

Thank you for the prompt response, and the bugfix.

@MichaCo MichaCo added this to the 1.2.0 milestone Jun 5, 2017
ahockersten added a commit to ahockersten/CacheManager that referenced this issue Jun 6, 2017
@MichaCo MichaCo modified the milestones: 1.1.0, 1.2.0 Jun 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants