Redis | Caching failed for GetItem (Part 2) #50

[bettes914]

Hoping for a fix for https://github.com/silentbobbert/EFCache.Redis/issues/50

[silentbobbert]

Hi there Bart

By "round", in your caching policy, you could alter the date time offsets to be fixed times - eg 2025-02-20T15:00:00.000Z - you could create logic to set the expiry to 3pm each day. Then the number of ticks will always be identical, for every cached item. 3pm is "round" because the minutes, seconds, ms etc etc are zeroed out. The chance that your query hits the cache at exactly 3pm, are pretty small, almost zero.

If you had some sort of batch or scheduled service updating the cache, you might want your items to expire at a fixed time like that. Maybe a better fix might be to make the method EntryExpired non-static, and make it abstract so that you could override the implementation?

Thoughts? Ian

On Thu, 20 Feb 2025 at 08:34, bettes914 @.***> wrote:

@.**** commented on this pull request.

In EFCache.Redis/RedisCache.cs https://github.com/silentbobbert/EFCache.Redis/pull/51#discussion_r1963077553 :

@@ -138,7 +138,7 @@ public bool GetItem(string key, out object value)

     private void EnsureDatabase() => _database = _database ?? _redis.GetDatabase();

•    private static bool EntryExpired(CacheEntry entry, DateTimeOffset now) => entry.AbsoluteExpiration < now || (now - entry.LastAccess) > entry.SlidingExpiration;
  

•    private static bool EntryExpired(CacheEntry entry, DateTimeOffset now) => entry.AbsoluteExpiration <= now || (now - entry.LastAccess) > entry.SlidingExpiration;
  

Hey Robert

I agree, the odds are against me. That's why I waited so long because I had the same reaction. But we have a lot of database access and it does not happen a lot. The internet tells me that it is probably caused by a negative value, a zero or an overflow.

But, I hope that you agree that if it happens that entry.AbsoluteExpiration == now, then my proposed change will prevent an exception.

I don't really understand what you mean with a fixed "round" datetimeoffset. Our caching policy is this image.png (view on web) https://github.com/user-attachments/assets/07e52869-3eb4-4993-96ba-ec815a63366f

If you need more info, don't hesitate to ask

— Reply to this email directly, view it on GitHub https://github.com/silentbobbert/EFCache.Redis/pull/51#discussion_r1963077553, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY3NBAU5NANHUPBUMKZL6L2QWHQFAVCNFSM6AAAAABXOJ2Q6WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDMMRZGA3DMOBSGQ . You are receiving this because you commented.Message ID: @.***>

[bettes914]

Hi Robert,

In my opinion is the solution that you propose just a way to hide the problem. A rounded date is not better or worse than another absolute expire date.

But your proposal, will only hit the absolute expire date (potentially setting TTL to zero) once a day. With my settings, it will reach an absolute expire date (potentially setting TTL to zero) 48 times a day.

I also think that cached data, that is needed constantly, will have the problem. The code will try to update the TTL constantly, so reaching the potential zero TTL Cached data that is rarely needed will be invalidated by the sliding expiration if it is accessed again.

Let's make a deal (I am very stubborn ;-) ) Lets try the fix that I propose. Maybe it is just a fix for a theoretical problem, maybe it solves my problem. If it does not solve my problem I will change the absolute expire date in now + 1 day. Because we recycle the redis cache every day at 03:00 we will never hit that TTL 0 issue again.

[silentbobbert]

Hey Bart

I was not suggesting that you use a "rounded" date, I was saying other users of the package may find it useful to do so, for different use cases.

I think you should test your fix yourself in your environment. I do not have access to the problem you are facing, and I dont want to take code changes without some proof it will actually improve the package.

I no longer actually use this package myself, and when I did, my use case was "light weight" so i didnt hit the issues any of the reporters of the other bugs/PRs had seen for real.

Let me know how you get on with testing in your environment.

Thanks Ian

On Fri, 21 Feb 2025 at 08:32, bettes914 @.***> wrote:

Hi Robert,

In my opinion is the solution that you propose just a way to hide the problem. A rounded date is not better or worse than another absolute expire date.

But your proposal, will only hit the absolute expire date (potentially setting TTL to zero) once a day. With my settings, it will reach an absolute expire date (potentially setting TTL to zero) 48 times a day.

I also think that cached data, that is needed constantly, will have the problem. The code will try to update the TTL constantly, so reaching the potential zero TTL Cached data that is rarely needed will be invalidated by the sliding expiration if it is accessed again.

Let's make a deal (I am very stubborn ;-) ) Lets try the fix that I propose. Maybe it is just a fix for a theoretical problem, maybe it solves my problem. If it does not solve my problem I will change the absolute expire date in now + 1 day. Because we recycle the redis cache every day at 03:00 we will never hit that TTL 0 issue again.

— Reply to this email directly, view it on GitHub https://github.com/silentbobbert/EFCache.Redis/pull/51#issuecomment-2673900975, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY3NBA4K5JI5XKNKQL7U3D2Q3QATAVCNFSM6AAAAABXOJ2Q6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZTHEYDAOJXGU . You are receiving this because you commented.Message ID: @.***> [image: bettes914]bettes914 left a comment (silentbobbert/EFCache.Redis#51) https://github.com/silentbobbert/EFCache.Redis/pull/51#issuecomment-2673900975

Hi Robert,

In my opinion is the solution that you propose just a way to hide the problem. A rounded date is not better or worse than another absolute expire date.

But your proposal, will only hit the absolute expire date (potentially setting TTL to zero) once a day. With my settings, it will reach an absolute expire date (potentially setting TTL to zero) 48 times a day.

I also think that cached data, that is needed constantly, will have the problem. The code will try to update the TTL constantly, so reaching the potential zero TTL Cached data that is rarely needed will be invalidated by the sliding expiration if it is accessed again.

Let's make a deal (I am very stubborn ;-) ) Lets try the fix that I propose. Maybe it is just a fix for a theoretical problem, maybe it solves my problem. If it does not solve my problem I will change the absolute expire date in now + 1 day. Because we recycle the redis cache every day at 03:00 we will never hit that TTL 0 issue again.

— Reply to this email directly, view it on GitHub https://github.com/silentbobbert/EFCache.Redis/pull/51#issuecomment-2673900975, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY3NBA4K5JI5XKNKQL7U3D2Q3QATAVCNFSM6AAAAABXOJ2Q6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZTHEYDAOJXGU . You are receiving this because you commented.Message ID: @.***>

[bettes914]

Hi Ian,

It looks like I cannot convince you that my PR is solving a (potential) bug. Proofing that my fix is working will be difficult and will give me a extra work.

So, I am going for plan B. Setting the absolute expire date for a day, combined with a daily recycle will have the effect that the TTL never reaches zero. And if my errors disappear, well, I let you know.