John Gallardo's Weblog : rsExecutionNotFound

Scaling out the Viewer Control and rsExecutionNotFound

jgalla — Fri, 08 Aug 2008 19:26:14 GMT

One of the criteria that the report server uses to match the provided SessionID with a stored report is that the SessionID has to be provided by the same user that initially created the session. Usually, this is the case. Someone browses the report in IE, they click around to paginate or expand toggles, and things just work because they are the same user they were when they initially ran the report.

Sometimes though, things go wrong.

One way that this can happen is when you are hosting the ASP.Net Viewer Control in your own application and you are not impersonating the incoming user all the way to the backend report server. This is a totally supported configuration, however there is a little caveat that you have to keep in mind. Since the report server requires that the user names match across session retrievals, you have to ensure that the viewer control is impersonating the same user. Sounds easy, right? Well not so fast if you are using a machine specific account for your application pool which is hosting the viewer control. The specific topology that can get you into trouble is something like the following:

In this scenario you have the following:

Client machines accessing multiple web frontends hosting the report viewer control via a load balancer.
The web frontend machines are using a machine-specific account to communicate with the report server (for example they are using the builtin NETWORK SERVICE account).
You are not impersonating the incoming user in the viewer control when accessing the backend report server.

The sequence of operations that can lead to trouble are:

The initial request from ClientA is routed to MachineA.
The viewer control in MachineA instantiates a session with the report server. Since the $MachineA credentials are sent, the session is associated with this user. Keep in mind at this point the report server actually has no idea that there is some other logical user beyond the web frontend that is actually making the request.
The user views the first page of the report, and navigates to the second page.
The request for the second page is actually routed to MachineB by the load balancer.
The viewer control in MachineB attempts to load the user session, however this fails since the request to the report server is actually from $MachineB user and not the original $MachineA user. The report server generates an rsExecutionNotFound error and returns that, resulting in an error being displayed to the user.

There are a couple of ways to address this problem:

Architect your application such that you can flow credentials from the client all the way to the report server. -- Or --
Ensure that your web frontend nodes can impersonate the same user when accessing the report server regardless of which machine the request is routed to (so use something like domain credentials to access the report server).

Aggregating rsExecutionNotFound Posts

jgalla — Thu, 01 Feb 2007 20:34:00 GMT

The posts about things dealing with rsExecutionNotFound seem to be what people find most interesting these days. In order to aggregate the posts into one place, I will be adding links that deal with this error here.

Maybe I will add a tag as well...

Careful when using rc:Toolbar=false

jgalla — Thu, 01 Feb 2007 02:47:00 GMT

I'm in the middle of reinstalling Visual Studio, and so I thought I would share an interesting story from a couple of weeks ago. An internal customer (Microsoft-speak for some other team at Microsoft) of Reporting Services was encountering seemingly random rsExecutionNotFound errors when navigating around their application. Of course, things like this are never random and there was a perfectly good explanation. After digging through their application for a little while, and with the help of Fiddler, I stumbled upon the problem. They were rendering the same report in two different contexts, one of them was specifying rc:Toolbar=false, and the other wasn't. Basically, their call to the report server looked something like this in the two places:

http://reports/reportserver/?/myreport&rs:Command=Render&rc:Toolbar=false

http://reports/reportserver/?/myreport&rs:Command=Render

Now, there is actually a subtle little problem with rendering using rc:Toolbar=false against the ReportServer virtual directory. When this happens in a default installation, the Report Server sends a cookie back to IE to identify the session. This cookie is then passed back to the report server to load up the appropriate snapshot, parameter, data source information, etc to view subsequent pages and images from the report. What would happen is the user would navigate to the page where the report being rendered w/rc:Toolbar=false was sitting, which would give IE the cookie. The user would navigate away from the page, and eventually head to the page where rc:Toolbar=false was not specified. However, even in this case if the cookie is there, we try to use it to load the user session, which would fail because the session had timed out in the time between the two requests. The user would be greeted with an "Execution Not Found" error message and would have to close and restart IE to get things working again.

The moral? Don't render against the ReportServer virtual directory using rc:Toolbar=false unless you really know what you are doing, because it is tricky to get right. If you want to render using the ReportServer virutal directory (so you don't have to roll your own Report Viewer Control ASP.Net application) then you should build a stylesheet which removes the toolbar, and use that.

Session Timeout during execution

jgalla — Wed, 11 Oct 2006 23:14:00 GMT

Reporting Services has a notion of a user session. This is not the same as ASP.Net's notion of a user session, and in fact the two are completely orthogonal to each other. SSRS's session maintains information about which report a user is looking at, the data that is in that report (we call this a snapshot), the interactivity state (what items are shown/hidden), parameter state, etc... These sessions are aged out based on the last time they were accessed. For most scenarios where you use the viewer control, you should never have to worry about sessions because it will automatically ping the SSRS web server to keep the user's session alive.

However, there is one scenario where the ping doesn't work, and that is during the inital report execution. The problem is that while the report is being executed, the user's session is locked (as we are populating the user's temporary snapshot) and the keepalive from the viewer control will be blocked. Normally, this is not a problem because report executions aren't supposed to take a long time and quite often they finish before the session timeout hits. Unfortunately, there are some cases where reports (for whatever reason) take an incredibly long time to execute. What happens in this case is that the user's session is aged out while the report is being executed, resulting in all sorts of strange behavior.

Fortunately, there exists a couple of solutions:

Reduce the time it takes to run the report. Generally this involves simplifying the report or moving some of the aggregation/sorting to the database layer (RDBMSs are generally better at this than we are).
Consider running the report offline. Try creating a schedule by which the report is executed during off-hours, and users only see this snapshot of the data. This can greatly improve execution performance for large reports which involve lots of grouping/sorting in the report server.
Consider delivering the reports via a subscription. Probably your user doesn't want to leave IE sitting open for two hours waiting for a report to render. It is too easy to accidently close the window and now he or she is back at square one. If you have a report which takes hours to generate, consider creating a subscription and delivering the report to the person via email or a file share.

If none of these solutions really work for you, then as a last resort you can modify the SessionTimeout and SessionAccessTimeout system properties. You should configure these values to be no less than the time it takes to render your largest report. Here is a sample script for rs.exe which will set these values for you:

Public Sub Main()
    Dim props() as [Property]
    props = new [Property] () { new [Property](), new [Property]() }
    
    props(0).Name = "SessionTimeout"
    props(0).Value = timeout
    
    props(1).Name = "SessionAccessTimeout"
    props(1).Value = timeout
    
    rs.SetSystemProperties(props)
End Sub

You can run this script with the following command:

rs -i sessionTimeout.rss -s http://localhost/reportserver -v timeout="6000"

The timeout is expressed in seconds, so this example sets the SessionTimeout and SessionAccessTimeouts to about an hour and a half. Note that you should do this with caution, keeping a session around longer than necessary can cause your ReportServerTempDB database to grow larger since temporary session snapshots will not be aged out as often.