DistributedCache ApplicationConfigurationDto Time Out #10232

3 Answer(s)

• 

  0

  AI-Bot created 12 hours ago

  Support Team ABP Agent

  1. Solution Your log shows StackExchange.Redis timing out on HMGET while ABP is trying to read the cached ApplicationConfigurationDto (the /api/abp/application-configuration pipeline). These timeouts are almost always infrastructure/configuration issues around Redis connectivity, load, or client timeout settings rather than ABP code defects. Apply the following, in order:

  • Verify Redis health and networking

    • Ensure the Redis endpoint is reachable from the app containers/VMs (latency, packet loss, firewall/NAT).
    • Check Redis CPU, slowlog, and INFO stats for command latency or blocking operations.
    • If running in containers/K8s, confirm there’s no DNS flap or intermittent network policy drops.

  • Increase StackExchange.Redis timeouts conservatively

    • In appsettings.json (or environment), add a Redis configuration string with larger timeouts: { "Redis": { "Configuration": "10.166.0.97:6379,abortConnect=false,connectRetry=5,connectTimeout=10000,syncTimeout=10000,responseTimeout=10000,keepAlive=60,allowAdmin=false" } } Notes:
    • responseTimeout (v2.6+) is preferred; syncTimeout applies to some paths. Keep both aligned.
    • connectRetry and connectTimeout help on transient network issues.
    • keepAlive helps long-lived connections in some networks.

  • Use ABP’s Redis integration package and set a key prefix

    • Ensure the Web (and Auth/Tiered) projects reference:
      • Volo.Abp.Caching.StackExchangeRedis
    • Configure distributed cache and a clear key prefix to avoid collisions: public override void ConfigureServices(ServiceConfigurationContext context) { Configure<AbpDistributedCacheOptions>(options => { options.KeyPrefix = "MyApp:"; // important in multi-app/shared-redis }); }

  • Consider lowering load from Application Configuration

    • ApplicationConfigurationDto is read on app start for every client. If you have many concurrent clients or large DTO customizations:
      • Enable sliding/absolute expiration on the cache for that DTO to reduce Redis pressure: Configure<AbpDistributedCacheOptions>(options => { options.GlobalCacheEntryOptions.SlidingExpiration = TimeSpan.FromMinutes(10); });
      • Avoid heavy custom logic inside your overridden AbpApplicationConfigurationAppService.GetAsync that triggers multiple DB or cache calls per request; pre-aggregate, cache sub-parts, or compute once and cache with a reasonable TTL.
      • If you added custom data (like module permission maps), cache them separately with GetOrAddAsync and short TTLs, then compose the DTO from cached pieces.

  • Prevent cache operations from being cancelled by request aborts

    • If frontends sometimes cancel requests (navigation, timeouts), that cancellation token may bubble into Redis calls. Consider isolating cancellation tokens for cache access: public class NoCancelTokenProvider : ICancellationTokenProvider, ISingletonDependency { public CancellationToken Token => CancellationToken.None; public IDisposable Use(CancellationToken cancellationToken) => NullDisposable.Instance; private sealed class NullDisposable : IDisposable { public static readonly NullDisposable Instance = new(); public void Dispose() { } } }
    • Or wrap hot cache calls with CancellationToken.None explicitly in your own logic where safe.

  • Check thread pool starvation and blocking code

    • Your log shows WORKER Busy=99 and queued items, which can exacerbate Redis timeouts under load.
    • Audit for synchronous blocking (Result/Wait) on async methods, long GC pauses, or CPU saturation.
    • Ensure ASP.NET Core ThreadPool Min/Max are not overly constrained.

  • Use connection multiplexing correctly across tiered services

    • Every tier (AuthServer, API Host, Blazor Server) should point to the same Redis with the same configuration and not create unnecessary separate multiplexer instances per scope. The default DI registrations already share a singleton; avoid manual new ConnectionMultiplexer per request.

  • As a last resort, raise the retry budget and use resilient Redis

    • If the environment is noisy, consider Redis Cluster/Replica, co-locate app and Redis to reduce latency, or provision higher SKU (cloud) to reduce server-side stalls.

  Example minimal configuration in WebModule: [DependsOn(typeof(AbpCachingStackExchangeRedisModule))] public class MyWebModule : AbpModule { public override void ConfigureServices(ServiceConfigurationContext context) { Configure<AbpDistributedCacheOptions>(options => { options.KeyPrefix = "MyApp:"; options.GlobalCacheEntryOptions.SlidingExpiration = TimeSpan.FromMinutes(10); }); } }

  2. Sources

  • StackExchange.Redis client timeout causes and mitigations:
    • https://stackexchange.github.io/StackExchange.Redis/Timeouts
  • ABP Distributed Cache and Redis integration source:
    • https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.Caching/Volo/Abp/Caching/DistributedCache.cs

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Save Cancel
• 

  0

  heshengli created 12 hours ago

  这个应用，有很多人使用，且页面长期打开使用不关闭

  Save Cancel
• 

  0

  maliming created 11 hours ago

  Support Team Fullstack Developer

  你好

  你可以将超时时间调大一些试试呢. 这大概率是Redis服务器无法处理导致超时

  Save Cancel