Session ASP.NET a expiré - ID de l'événement 1309

Question

Quelques détails rapides:

Je cours ASP.NET 4.0.30319.0 sur IIS6. J'ai hébergé un site Web qui contient un ReportViewer depuis un certain temps maintenant (~ 3 ans). En avril, je suis passé à la version 4.0 et les choses se sont bien déroulées pendant quelques mois.

Maintenant, je commence à voir soudainement des exceptions de Session Timeout se produire sur les pages qui hébergent le ReportViewer. L'Observateur d'événements a consigné un grand nombre de ces événements, et il est plutôt aléatoire lorsqu'il s'agit d'afficher la page. En cliquant une fois sur la page, vous pouvez voir le rapport généré. Actualiser et l'erreur se produit. Actualiser à nouveau et il retourne ...

J'ai parcouru de nombreux forums essayant de comprendre le problème - la plupart semblent recommander de modifier les paramètres du serveur SQL (que je n'utilise pas), en changeant le AsyncRendering = "False", modifier les paramètres du pool d'applications ou le délai d'attente. Je suis réticent à changer tout cela, comme cela a fonctionné il y a une semaine, sans ce problème.

court d'une mise à jour de Windows, ou quelqu'un qui fait un changement au serveur sans ma connaissance, je suis d'idées ...

Mise à jour

J'ai essayé de plus en plus le virtuel au maximum mémoire, dans le pool d'applications, qui n'a pas fonctionné.

Answer 1

J'ai presque le même problème, après la mise à niveau vers .NET 4.0 et Report Viewer 2010. J'ai fait les deux mises à jour en même temps, maintenant je ne suis pas sûr de savoir qui est à blâmer. Dans mon cas, l'actualisation fonctionne, mais les utilisateurs gardent la page ouverte pendant la nuit, puis cliquez sur Actualiser le lendemain matin, lorsque la session est déjà perdue. Notre piscine d'applications recycle chaque nuit.

Je crois que le visualiseur de rapports est censé maintenir la session en vie, mais ce n'est pas le cas. Il n'y a aucune demande d'aucune sorte de la visionneuse de rapport. Il perd ensuite son état stocké lorsque la session se termine, soit par l'expiration de la session, soit par le recyclage de l'application. J'utilise également InProc, j'ai essayé de le changer, mais la visionneuse de rapports ne fonctionnait pas avec State Server. Je vais essayer à nouveau plus tard, de s'éloigner d'InProc.

Voir le modèle question.

Je ne l'ai pas encore mis en production, mais j'ai donné une page personnalisée aux pages aspx avec les rapports, et je vais vérifier si la session a vraiment expiré. Il recharge essentiellement la page de rapport, au lieu de faire de la publication où elle attend la 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()); 
       } 
      } 
     }