2010-10-26 23 views
4

J'ai des problèmes avec les utilisateurs qui perdent des données de session en passant par un formulaire de demande. Il semble qu'ils perdent l'état de la session à mi-chemin des formulaires de demande. (Projet ASP.NET 4.0 WebForms, IIS 6.0)Session expirant après 20 minutes: inactif ou non

La session est stockée hors processus dans le serveur d'état de sorte qu'il ne s'agit pas de modifications de configuration, de recyclage de domaine, etc. AFAIK.

<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" timeout="20" /> 

J'utilise l'authentification par formulaire, l'expiration de glissement fonctionne correctement comme vous pouvez le voir ci-dessous l'enregistrement - Vous pouvez voir l'heure d'expiration du billet est correct et être prolongé comme exprected.

<authentication mode="Forms"> 
    <forms loginUrl="~/Login.aspx" /> 
</authentication> 

J'ai activé la journalisation personnalisée pour essayer de dépister ce problème. Sur chaque Session_Start feu dans global.asax Je note quelque chose, et je note aussi quelque chose chaque fois que quelqu'un charge le formulaire de demande ou clique sur 'Suivant' pour passer d'une section à l'autre (dans un MultiView) quand ils passent par le formulaire d'application.

Voici deux exemples de personnes qui perdent leur état de session. Le journal commence par la date et l'heure de l'entrée du journal, puis quelques mots. La deuxième date/heure entre parenthèses (après le libellé) est la date/heure d'expiration du cookie FormsAuthentication tel que dérivé de CType(ctx.User.Identity, FormsIdentity).Ticket.Expiration.ToString

La journalisation enregistre également l'adresse IP et l'ID de session de l'utilisateur. J'ai enlevé ces derniers avant de les coller ici, je peux confirmer que l'adresse IP et l'identification de session sont les mêmes pour toutes les entrées de journal.

Exemple 1:

 
**[26/10/2010 13:07] Session started []** 
[26/10/2010 13:11] Application form first Page_Load [26/10/2010 13:31:19] 
[26/10/2010 13:13] App form next clicked, current index is 1 (vwSection1) [26/10/2010 13:31:19] 
[26/10/2010 13:14] App form next clicked, current index is 2 (vwSection2) [26/10/2010 13:31:19] 
[26/10/2010 13:15] App form next clicked, current index is 3 (vwSection3) [26/10/2010 13:31:19] 
[26/10/2010 13:20] App form next clicked, current index is 5 (vwSection4) [26/10/2010 13:31:19] 
[26/10/2010 13:20] App form next clicked, current index is 6 (vwSection5) [26/10/2010 13:31:19] 
[26/10/2010 13:20] App form next clicked, current index is 7 (vwMonitoring) [26/10/2010 13:31:19] 
[26/10/2010 13:21] App form next clicked, current index is 8 (vwInformation) [26/10/2010 13:31:19] 
[26/10/2010 13:22] Application form first Page_Load [26/10/2010 13:41:22] 
[26/10/2010 13:25] App form next clicked, current index is 1 (vwSection1) [26/10/2010 13:41:22] 
[26/10/2010 13:26] App form next clicked, current index is 2 (vwSection2) [26/10/2010 13:41:22] 
[26/10/2010 13:26] App form next clicked, current index is 3 (vwSection3) [26/10/2010 13:41:22] 
[26/10/2010 13:28] App form next clicked, current index is 5 (vwSection4) [26/10/2010 13:41:22] 
[26/10/2010 13:28] App form next clicked, current index is 6 (vwSection5) [26/10/2010 13:41:22] 
[26/10/2010 13:28] App form next clicked, current index is 7 (vwMonitoring) [26/10/2010 13:41:22] 
[26/10/2010 13:28] App form next clicked, current index is 8 (vwInformation) [26/10/2010 13:41:22] 
**[26/10/2010 13:28] Session started [26/10/2010 13:41:22]** 
[26/10/2010 13:31] Application form first Page_Load [26/10/2010 13:51:24] 
[26/10/2010 13:31] App form next clicked, current index is 1 (vwSection1) [26/10/2010 13:51:24] 
[26/10/2010 13:32] App form next clicked, current index is 2 (vwSection2) [26/10/2010 13:51:24] 
[26/10/2010 13:32] App form next clicked, current index is 3 (vwSection3) [26/10/2010 13:51:24] 
[26/10/2010 13:32] App form next clicked, current index is 5 (vwSection4) [26/10/2010 13:51:24] 
[26/10/2010 13:32] App form next clicked, current index is 6 (vwSection5) [26/10/2010 13:51:24] 
[26/10/2010 13:32] App form next clicked, current index is 7 (vwMonitoring) [26/10/2010 13:51:24] 
[26/10/2010 13:32] App form next clicked, current index is 8 (vwInformation) [26/10/2010 13:51:24] 

Exemple 2:

 
**[24/10/2010 17:44] Session started []** 
[24/10/2010 17:50] Application form first Page_Load [24/10/2010 18:10:13] 
[24/10/2010 18:00] App form next clicked, current index is 1 (vwSection1) [24/10/2010 18:20:40] 
**[24/10/2010 18:07] Session started [24/10/2010 18:20:40]** 
[24/10/2010 18:08] App form next clicked, current index is 2 (vwSection2) [24/10/2010 18:20:40] 
[24/10/2010 18:10] App form next clicked, current index is 2 (vwSection2) [24/10/2010 18:20:40] 
[24/10/2010 18:10] App form next clicked, current index is 1 (vwSection1) [24/10/2010 18:30:42] 
[24/10/2010 18:10] App form next clicked, current index is 1 (vwSection1) [24/10/2010 18:30:52] 
[24/10/2010 18:10] App form next clicked, current index is 1 (vwSection1) [24/10/2010 18:30:58] 
[24/10/2010 18:12] Application form first Page_Load [24/10/2010 18:31:35] 
[24/10/2010 18:12] App form next clicked, current index is 1 (vwSection1) [24/10/2010 18:31:35] 
[24/10/2010 18:13] App form next clicked, current index is 2 (vwSection2) [24/10/2010 18:31:35] 
[24/10/2010 18:13] App form next clicked, current index is 2 (vwSection2) [24/10/2010 18:31:35] 
[24/10/2010 18:16] App form next clicked, current index is 3 (vwSection3) [24/10/2010 18:31:35] 
[24/10/2010 18:16] App form next clicked, current index is 5 (vwSection4) [24/10/2010 18:31:35] 
[24/10/2010 18:17] App form next clicked, current index is 6 (vwSection5) [24/10/2010 18:31:35] 
[24/10/2010 18:18] App form next clicked, current index is 7 (vwMonitoring) [24/10/2010 18:31:35] 
[24/10/2010 18:18] App form next clicked, current index is 8 (vwInformation) [24/10/2010 18:31:35] 

Vous pouvez voir dans le premier exemple que la session a commencé initialement à 13h07, mais a également commencé à 13h28.

Vous pouvez voir dans le deuxième exemple que la session a démarré à 17:44 et a redémarré à 18:07.

Je comprends que ces délais sont de 20 minutes après le début de la session. Mais la session était et non inactif. Vous pouvez voir que ce n'était pas inactif à cause du reste du journal. En cliquant sur « Suivant » dans le formulaire de demande obtient quelque chose d'un objet hors de l'état de la session

Dim m As Member = StateManager.CurrentMember 

puis obtient/définit les propriétés de « m ». Donc, pour moi, il semble que même si l'utilisateur n'est pas inactif et accède à ses variables de session, il perd toujours ses sessions exactement 20 minutes après avoir commencé. Notez que dans ma page de base (dont toutes les pages héritent, la page de base hérite de System.Web.UI.Page), j'ai maintenant commencé à écrire l'actuelle milliseconde dans l'état de la session, donc je suis constamment en train d'écrire en session.

L'utilisateur perd son état de session car StateManager.CurrentMember (qui correspond à HttpContext.Current.Session("CurrentMember")) renvoie null. Cela donne ensuite une exception non gérée lorsque j'essaie de l'attacher à un contexte d'infrastructure Contexte de données - de sorte que les utilisateurs voient ma page générique de gestion des erreurs.

Toutes les idées ont été appréciées.

+0

Salut bgs264, avec le journal existant pourriez-vous écrire aimablement ce que la valeur de Session.IsNewSession est pendant l'événement Session_Start? Je suis intéressé par sa valeur lors de ce redémarrage de la Session. Je doute de quelque part que la session se termine brusquement. –

+0

Est-il possible que la session ne soit renouvelée que sur "Formulaire d'application en premier Page_Load" et non sur les clics de bouton? –

+0

Est-ce que cela arrive sur localhost pendant le débogage? Ce n'est pas un environnement à charge équilibrée qui nécessite des sessions persistantes, n'est-ce pas? Mettez-vous d'énormes objets dans l'état de la session et atteignez les limites de la mémoire? Le recyclage du pool d'applications déclenche-t-il le redémarrage d'une application? – batwad

Répondre

1

Vous indiquez que vous utilisez FormsAuthentication. Avez-vous l'attribut d'expiration glissant défini sur true?

http://msdn.microsoft.com/en-us/library/1d3t3c61(v=VS.100).aspx

+0

Merci pour votre réponse. L'expiration de glissement n'est pas spécifiée, donc elle est passée à la valeur par défaut de true. L'utilisateur n'est pas déconnecté et invité à se connecter à nouveau, il ne fait que perdre des données de session. Vous pouvez voir que l'expiration glissante fonctionne correctement à partir du journal - regardez le dernier horodatage sur les lignes qui montre l'heure d'expiration du ticket - ceci est étendu de manière appropriée mais session_start se déclenche toujours à nouveau. Mettra à jour mon Q. – bgs264

0

La seule fois que je voyais quelque chose comme cela se produise était quand j'avais localhost référencé dans le code.

Bien que vous ayez dit que c'est dans un autre serveur quelque part, j'imagine qu'un rafraîchissement de l'AppPool perdrait la référence à l'information de session, et par conséquent en créerait un autre. Une façon d'essayer ceci est d'aller à IIS et de configurer, l'actualisation du pool se produira avec beaucoup plus d'erreurs, provoquant un scénario d'actualisation possible et vous pourriez alors trouver ce dont vous avez besoin. Essayez-le et faites le moi savoir.

+0

Merci de répondre, je suis assuré que les paramètres IIS sont tous corrects et que le processus de travail est seulement configuré pour recycler à 5h du matin tous les jours et pas toutes les XXX minutes. Le pool d'applications est configuré pour être recyclé lorsqu'il est inactif pendant 20 minutes ou plus. mais comme il n'est pas inactif, il ne devrait pas être recyclé, sauf si IIS a besoin d'être réinstallé ou quelque chose comme ça. Je l'ai résolu avec une solution de contournement, en supprimant les variables de session et en effectuant un aller-retour en DB à la place. – bgs264

+0

Il existe de nombreuses autres raisons de recycler le pool d'applications, l'une d'entre elles est chaque fois qu'une erreur est lancée par votre application ou toute autre application sur le même pool, elle ajoute un compteur, puis un seuil le pool d'applications recycle. La clé dans tout cela est qu'il n'a pas besoin d'être votre application. – Oakcool

+0

Une autre raison qui est venue à l'esprit est que si vous modifiez la structure du site Web pendant son exécution, c'est-à-dire que vous supprimez un dossier, le pool d'applications est recyclé. – Oakcool

0

Le délai d'expiration du pool d'applications IIS par défaut est de 20 minutes. Cela peut aider: MSDN

+0

Merci pour votre réponse, votre lien montre "processus de travail d'arrêt après 20 minutes d'inactivité" - Ce défaut devrait être bien - Le processus de travail n'est pas arrêté ou je verrais cela sur les e-mails de surveillance de santé. Peut-être que IIS est cassé et doit être réinstallé. J'ai résolu avec une solution de contournement pour supprimer les variables de session et faire des allers-retours DB basés sur une variable viewstate, donc c'est ok maintenant, merci pour la réponse. – bgs264