views:

156

answers:

1

Hi All,

Some quick details:

I'm running ASP.NET 4.0.30319.0 on IIS6. I've been hosting a website that contains a ReportViewer for quite some time now (~3 years). In April, I upgraded to the 4.0 runtime, and things ran smoothly for a couple of months.

Now, I'm suddenly starting to see quite a Session Timeout exceptions occur on the pages hosting the ReportViewer. The Event Viewer has many many of these events logged, and it's rather hit or miss when it comes to actually being able to view the page. Hitting the page once, you can see the generated report. Refresh, and the error occurs. Refresh again and it returns...

I've scoured many forums trying to figure out the issue - most seem to recommend changing SQL server settings (which I'm not using), changing the AsyncRendering="False", changing the Application Pool settings, or the timeout. I'm reluctant to change any of these, as it has worked only a week ago, without this issue.

Short of a Windows Update, or someone making a change to the server without my knowledge, I'm out of ideas...

Update

I've tried increasing the maximum virtual memory, in the app pool, which didn't work.

A: 

I have almost the same problem, after upgrading to .NET 4.0 and Report Viewer 2010. I did both upgrades at the same time, now I'm not sure who's to blame. In my case, refresh does work, but the users keep the page open during the night, then click on refresh the next morning, when the session is already lost. Our app pool recycles every night.

I believe the report viewer is supposed to keep the session alive, but it doesn't. There's no request of any kind from the report viewer. It then loses it's stored state when the session ends, either by session expiration or app recycling. I'm also using InProc, I tried to change it, but the report viewer did not work with State Server. I will try again at a later time, to move away from InProc.

See my similar question.

I haven't put it into production yet, but I gave the aspx pages with the reports a custom page to derive from, and I will check there if the session has actually timed out. It basically reloads the report page, instead of doing postback where it expects the session.

if (Context.Session != null)
        {
            //Tested and the IsNewSession is more advanced then simply checking if 
            // a cookie is present, it does take into account a session timeout, because 
            // I tested a timeout and it did show as a new session
            if (Session.IsNewSession)
            {
                // If it says it is a new session, but an existing cookie exists, then it must 
                // have timed out (can't use the cookie collection because even on first 
                // request it already contains the cookie (request and response
                // seem to share the collection)
                string cookieHeader = Request.Headers["Cookie"];
                if ((null != cookieHeader) && (cookieHeader.IndexOf("ASP.NET_SessionId") >= 0))
                {
                    Response.Redirect(Request.Url.ToString());
                }
            }
        }
Niels Schultz