Microsoft.AspNetCore.Session.DistributedSession Session cache read exception

[aveeraldsinha]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have configured Distributed Cache using REDIS and Dataprotection but when I am running the app in scaled environment it is giving me below errors. Need your support to look into this.

---

2024-03-09 08:48:44.941,"2024-03-09 16:48:44.941 +08:00 e5e29a2ab66b4aa188578f250325e65e [Error] [Microsoft.AspNetCore.Session.DistributedSession] Session cache read exception, Key:""ff314f7a-127f-78f4-e6f5-b503202aaac6"" 61 StackExchange.Redis.RedisTimeoutException: Timeout performing HMGET (5000ms), next: HMGET Customerfca13f05-6a5d-fb18-2c09-b2c3e396421f, inst: 40, qu: 0, qs: 40, aw: False, bw: SpinningDown, rs: ReadAsync, ws: Idle, in: 121263, in-pipe: 0, out-pipe: 0, last-in: 0, cur-in: 0, sync-ops: 4747, async-ops: 10808, serverEndpoint: vpce--.vpce-svc-.ap-s.vpce.amazonaws.com:***9, conn-sec: 1751.74, aoc: 1, mc: 1/1/0, mgr: 10 of 10 available, clientName: ip-10-189-87-109(SE.Redis-v2.6.104.40210), IOCP: (Busy=0,Free=1000,Min=2,Max=1000), WORKER: (Busy=22,Free=32745,Min=2,Max=32767), POOL: (Threads=22,QueuedItems=29,CompletedItems=136489), v: 2.6.104.40210 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)"
2024-03-09 08:48:44.941, at Microsoft.AspNetCore.Session.DistributedSession.Load()

---

39dae03f0f74f47b4749d6cd948addc [Error] [Microsoft.AspNetCore.Session.SessionMiddleware] Error closing the session. 64 StackExchange.Redis.RedisTimeoutException: Timeout awaiting response (outbound=2KiB, inbound=0KiB, 5004ms elapsed, timeout is 5000ms), command=HMGET, next: EXPIRE CustomerServicePortal9d0ab6d8-461e-1707-d985-481d86911696, inst: 0, qu: 0, qs: 24, aw: False, bw: SpinningDown, rs: ReadAsync, ws: Idle, in: 65232, in-pipe: 0, out-pipe: 0, last-in: 0, cur-in: 0, sync-ops: 4761, async-ops: 10836, serverEndpoint: vpce-.vpce--01741219cbb89a867.ap--1.vpce.amazonaws.com:****, conn-sec: 1758.27, aoc: 1, mc: 1/1/0, mgr: 10 of 10 available, clientName: ip-10-189-87-109(SE.Redis-v2.6.104.40210), IOCP: (Busy=0,Free=1000,Min=2,Max=1000), WORKER: (Busy=21,Free=32746,Min=2,Max=32767), POOL: (Threads=23,QueuedItems=45,CompletedItems=136576), v: 2.6.104.40210 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)

---

I am using the below configurations as per the order defined in Microsoft documentation:

AddDistributedCache(builder.Configuration)
AddDataProtection(builder.Configuration)
.AddSession(options =>
{
options.IdleTimeout = TimeSpan.FromMinutes(appAuthenticationConstantsOptions.SessionTimeoutInMinutes);

            options.Cookie.HttpOnly = true;
            options.Cookie.IsEssential = true;
            options.Cookie.Path = appAuthenticationConstantsOptions.RootUrl;
            options.Cookie.SameSite = SameSiteMode.Strict;

            options.Cookie.SecurePolicy = 1;
        })

app.UseSession();

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

6.0

Anything else?

No response

[aveeraldsinha]

DISTRBUTED CACHE IMPLEMENTATION USING REDIS

[mgravell]

Hi there; is this an "always fails" scenario, or is this intermittent / occasional? I'm guessing the latter, based on the 29minutes uptime here? it looks like a simple timeout; reality is that timeouts do happen in distributed systems, and it is very hard to pinpoint exactly where the failure occurred. The "in" is non-zero, which might be indicative of the tail end of a large data transfer, but it isn't large enough to concern me. In any Redis timeout, the single most important tool is slowlog at the server, to see if there are any long-running server-side operations that may have stalled things, but a number of things can cause timeouts. Additionally, the SE.Redis folks (in this case "me, but in a different hat") are actively overhauling some IO bottlenecks which may improve some scenarios (but I can't know whether this is a relevant one)