Articles in this section

Interactive Report Viewer or Designer Sessions Fail Without Session Affinity

Published:
Updated:

Overview

In load-balanced environments, Report Viewer or Designer requests may fail when Session Affinity (Sticky Sessions) is not configured.

By default, the Report Viewer stores report processing information using an InMemory cache that is local to the Report Server instance handling the request. When subsequent requests are routed to a different node, the required report processing data may not be available.

To support non-sticky load balancing, configure Report Server to use the File cache provider and store cached report data in a shared AppData location accessible to all Report Server instances.

Symptoms

  • Report Viewer requests fail intermittently.
  • Report processing state is lost after page refresh or navigation.
  • Report rendering fails when requests are routed to different nodes.
  • Users experience inconsistent behavior in load-balanced deployments.
  • Report processing options do not function as expected across multiple nodes.

Cause

By default, report processing data is stored using the InMemory cache provider.

Since the cache exists only in the memory of the individual Report Server instance, it cannot be accessed by other nodes. As a result, deployments that do not use Session Affinity (Sticky Sessions) may encounter issues when subsequent requests are routed to different servers.

Solution

Step 1: Enable File-Based Report Cache

Navigate to:

UMS Settings → Configuration → reporting/config.xml

Add the following node inside the <ReportViewerFeatures> section:

<CacheStorage provider="File" itemtypes="Report" enableRequestLimiting="true"></CacheStorage>

Step 2: Configure Shared AppData Storage

When the File cache provider is enabled:

  • Report cache files are stored in the AppData location.
  • The AppData directory must be accessible from all Report Server nodes.
  • Report cache information becomes available across the deployment instead of remaining on a single node.

Traditional High Availability Deployment

  • Configure AppData on a shared network file system.
  • Ensure all Report Server nodes have read and write access.
  • Verify the shared storage remains accessible during failover events.

Kubernetes High Availability Deployment

  • Host AppData on a shared Persistent Volume.
  • When the File cache provider is enabled, report cache files are stored in the shared AppData location.
  • Since all pods access the same storage, cache information is available regardless of which pod processes the request.

Result

After enabling the File cache provider and configuring AppData on shared storage:

  • Report cache files are stored in a shared location.
  • All Report Server nodes can access the same cached report data.
  • Requests can be routed to any available node.
  • Load-balanced and High Availability deployments can operate without requiring Session Affinity (Sticky Sessions) for report cache access.

Reference

https://help.boldreports.com/enterprise-reporting/designer-guide/manage-content/reports/caching-report/

Was this article useful?
Like
Dislike
Help us improve this page
Please provide feedback or comments
Comments (0)
Access denied
Access denied