2015-02-03 6 views
5

Die Skalierung der Webanwendung über mehrere Instanzen ist einer der größten Vorteile der azure Cloud. Um die Unterstützung mehrerer VMs für unsere Web-Rollen-Cloud-Anwendung zu erreichen, implementieren wir Azure Redis Cache. Wir verwenden den RedisSessionStateProvider-Provider für die Verwaltung des Sitzungsstatus. Im Folgenden sind die Konfigurationseinstellungen für die Sitzungsverwaltung in der Datei web.config aufgeführt.Sitzungstimeout gleitet nicht im Azure Redis Cache-Sitzungsstatusanbieter

<authentication mode="Forms"> 
    <forms loginUrl="~/Login" slidingExpiration="true" timeout="20" defaultUrl="~/Default" /> 
</authentication> 
<sessionState timeout="20" mode="Custom" customProvider="MySessionStateStore"> 
    <providers> 
    <add name="MySessionStateStore" type="Microsoft.Web.Redis.RedisSessionStateProvider" 
     host = "dummy.redis.cache.windows.net" 
     port = "6380" 
     accessKey = "dummysecretkey" 
     ssl = "true" 
     throwOnError = "true" 
     retryTimeoutInMilliseconds = "5000" 
     databaseId = "0" 
     applicationName = "" 
     connectionTimeoutInMilliseconds = "5000" 
     operationTimeoutInMilliseconds = "1000" 
     connectionString = ""/> 
    </providers> 

Unser Problem ist, dass Session-Timeout nicht mit dem Benutzerpostbacks erweitert, um 10:00 Uhr unsere Benutzer meldet sich die Anwendung annehmen, dann seine Sitzungsdaten in absoluten 10.20 abläuft. Wenn Nutzer Postbacks um 10:15 Uhr abgeben, sollte die Sitzung um 10:35 Uhr enden, aber dies geschieht nicht, sie endet um 10:20 Uhr morgens.

Im Folgenden finden Sie den Code in Click-Ereignis des Login-Button

protected void Button1_Click(object sender, EventArgs e) 
{ 
    FormsAuthentication.SetAuthCookie(TextBox1.Text.Trim(), true); 
    ConnectionMultiplexer connection = ConnectionMultiplexer.Connec("dummy.redis.cache.windows.net,ssl=true,password=dummysecretkey"); 
    IDatabase cache = connection.GetDatabase(); 
    Session["UserName"] = TextBox1.Text; 
    Response.Redirect("Default.aspx"); 
} 

ich schätzen würde, wenn es mich wissen lassen konnte, was getan werden muss, um Session-Timeout in Gleit-Modus zu gelangen. Mit besten Grüßen,

H. R Yadav

Antwort

3

Vielen Dank für die Meldung des Problems. Wir haben eine neue Version des RedisSessionStateProvider NuGet-Pakets veröffentlicht, das den oben genannten Fehler behebt.

https://www.nuget.org/packages/Microsoft.Web.RedisSessionStateProvider/1.5.0

EDIT: Wir haben ein weiteres Problem mit diesem gefunden. ASP.NET ruft ResetItemTimeout nicht für AJAX-Anforderungen auf, und es wird die Verantwortung für andere Sitzungszustandsmethoden übernommen, das Sitzungszeitlimit zu verschieben. Wir haben diesen Fehler behoben und ein neues NuGet-Paket veröffentlicht: https://www.nuget.org/packages/Microsoft.Web.RedisSessionStateProvider/1.6.5

Lassen Sie uns wissen, ob dies Ihr Problem löst oder nicht?

+1

Vielen Dank für die Veröffentlichung der neuen Version. Jetzt habe ich kein Problem mit Session Timeout. Jedes Postback erweitert das Zeitlimit der Sitzung wie gewünscht. Ich frage mich, wie ihr diesen Fehler verpasst habt, da es ein sehr häufiges Problem für alle sein wird, die den Sitzungsstatus im Redis-Cache behalten? –

+1

Es hat früher nicht existiert. Es war eine Regression von einem anderen Fixpunkt. Danke für die Berichterstattung. –

+0

Dieses Problem besteht weiterhin. Ich verwende 1.6.3 –

0

Sie haben den Schlüssel selbst zurücksetzen (nachdem Sie es laden):

bool KeyExpire(RedisKey key, DateTime? expiry, CommandFlags flags = CommandFlags.None); 
bool KeyExpire(RedisKey key, TimeSpan? expiry, CommandFlags flags = CommandFlags.None); 
+0

Müssen wir Taste zurückgesetzt auf jeder Abrufoperation ausgeführt auf Session-Variablen des Gleitens? Wenn dies der Fall ist, wie verwalten wir den Ablauf von Variablen auf Anwendungsebene, die von allen Benutzern gemeinsam genutzt werden, und Variablen auf Sitzungsebene, die nur für Benutzer gelten? –

+0

Ich benutze überhaupt keinen sessionState. Aber AFAIK muss den Schlüssel bei jeder Abrufoperation zurücksetzen, um einen "gleitenden" Cachemechanismus zu erhalten, da redis ihn noch nicht bereitstellt. –

+0

Wie würden Sie dann Sitzungsdaten und Anwendungs- levelvariablen des Benutzers verwalten? –

2

löste ich das Problem Ablauf einschließlich den folgenden Zeilen in global.ascx.cs

protected void Application_AcquireRequestState() 
{ 
    if (HttpContext.Current.Session != null) 
    { 
     RedisSessionStateProvider redis = new RedisSessionStateProvider(); 
     redis.ResetItemTimeout(HttpContext.Current, HttpContext.Current.Session.SessionID); 
    } 
} 
+0

Können Sie bitte angeben, wie Sie den Sitzungsstatus konfigurieren und verwenden? Dieses Problem sollte nicht mit dem neuesten nugget-Paket auftreten. –

+0

Vielen Dank für die Meldung dieses Problems. ASP.NET ruft ResetItemTimeout nicht für AJAX-Anforderungen auf, und es wird die Verantwortung für andere Sitzungszustandsmethoden übernommen, das Sitzungszeitlimit zu verschieben. Wir haben diesen Fehler behoben und ein neues NuGet-Paket veröffentlicht: https://www.nuget.org/packages/Microsoft.Web.RedisSessionStateProvider/1.6.5 Lassen Sie uns wissen, ob dies Ihr Problem löst oder nicht? –

Verwandte Themen