20

Ecco il mio ambiente: IIS7.5 su Win 7, .NET 4, App Pool integratoIE doppia postback si blocca IIS 7 in modalità pipeline gestite integrato quando la sessione si accede

web.config

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
</configuration> 

Test.aspx

<%@ Page Language="C#" %> 

<!DOCTYPE html> 
<script runat="server"> 
    protected void OnAction(object sender, EventArgs e) 
    { 
     int count; 
     status.Text = (int.TryParse(status.Text, out count) ? count + 1 : 0).ToString(); 

     Session["test"] = count; 
    } 
</script> 

<html xmlns="http://www.w3.org/1999/xhtml"> 
<head runat="server"> 
    <title>IIS Session Hang Test</title> 
    <script> 
     var mutiPostback = function() { 
      var e = document.getElementById('LinkButton1'); 
      e.click(); 
      e.click(); 
     }; 
    </script> 
</head> 
<body> 
    <form id="Form1" method="post" runat="server"> 
     <asp:ScriptManager runat="server" ID="SM"> 
     </asp:ScriptManager> 
     <asp:UpdatePanel ID="UpdatePanel1" runat="server"> 
      <Triggers> 
       <asp:AsyncPostBackTrigger ControlID="LinkButton1"/> 
      </Triggers> 
      <ContentTemplate> 
       <asp:Label runat="server" ID="status" /> 
      </ContentTemplate> 
     </asp:UpdatePanel> 
     <input type="button" id="button1" onclick="mutiPostback();" value="MultiPostback"/> 
     <div style="display: none"> 
      <asp:Button ID="LinkButton1" runat="server" OnClick="OnAction" Text="Click" /> 
     </div> 
    </form> 
</body> 
</html> 

Sì, il postback multipla è intenzionale, notiamo questo comportamento causerà molti richiesta bloccato in RequestAcquireState e, in definitiva evitare eventuali nuove richieste accettate dal server. Tuttavia, questo problema è osservabile solo in IE e non su Chrome o FF.

Per testare, facendo continuamente clic sul pulsante più postback. Questo aggiornerà il numero dello stato. Sarai quindi in grado di osservare che il numero smette di aumentare quando si utilizza IE, ad indicare il problema bloccato della richiesta.

sono stato in grado di produrre questo problema con i seguenti IIS e le versioni di IE:

versioni di IIS testati

  1. 7.5.7600.16385 su Windows Server 2008 R2 con .Net 4.5 installata
  2. 7.5.7600.16385 su Windows 7 Pro con .Net 4.5 installata

versione di IE testati

  1. 9.0.8112.16421 su Windows 7 Pro
  2. 8.0.7600.16385 su Windows Server 2008 R2
  3. 6.0.3790.3959 su Windows Server 2003 SP2

Un'anomalia ho osservato, è che quando si accede a IIS locale , 8.0.7600.16385 su Windows Server 2008 R2 NON causa questo problema di blocco. Ma se utilizzo il browser per accedere a un IIS remoto, il problema può essere riprodotto. Mentre su IE 9 posso riprodurre il problema indipendentemente se IIS è su remoto o locale.

Ecco uno screenshot di come appare la richiesta impiccata nell'elenco delle richieste per il processo di lavoro.

Stuck Requests ora abbiamo trovato un paio di modi per aggirare questo problema, ma nessuno sono accettabili nella nostra situazione:

  1. Rimuovere/Commenta fuori uso sessione.
  2. Modifica pool di applicazioni in modalità classica.

NOTA: abbiamo anche scoperto che anche se non utilizziamo direttamente Session come mostrato nell'esempio, il problema si verifica ancora. IE: se aggiungiamo un Global.asax.cs e aggiungiamo un gestore di eventi Session_Start vuoto, la richiesta verrà comunque bloccata in RequestAcquireState.

Qualcuno ha idea del perché questo sta accadendo e come possiamo risolvere questo problema che sembra accadere solo in modalità di pipeline gestita integrata?

+0

Non riesco a ripeterlo su IIS7.5 su Win7 x64. L'apppool è il pool di applicazioni predefinito? Il sito web è il sito web predefinito? – rene

+0

Questo esempio di codice che hai fornito ti consente di riprodurre il problema? Lo chiedo perché ha funzionato bene per me. Infatti, utilizzando il monitoraggio della rete negli strumenti di sviluppo di IE, viene chiaramente mostrata l'interruzione della seconda richiesta, che probabilmente non sta accadendo nel tuo caso, quindi il problema. Inoltre, non dovrebbe essere IIS 7.5 - Non penso che si possa ottenere IIS 7 per Windows 7. –

+0

Quello che osservo nel monitoraggio della rete di strumenti di sviluppo IE, è che la prima richiesta verrà interrotta, la seconda richiesta procederà, ma non tornerà. Il problema potrebbe non apparire al primo tentativo, quindi continua a fare clic sul pulsante per osservare il problema, aggiornerò la domanda originale. – BlueFox

risposta

4

una buona notizia! Sembra che il problema del blocco delle sessioni sia stato risolto dopo l'installazione .Net 4.5.1

Ho aggiornato la mia macchina di prova 7.5.7600.16385 su Windows Server 2008 R2 con .Net 4.5 installato su 4.5.1 e il problema è andato via !

8

Dalla tua descrizione sembra un deadlock IIS quando tenta di acquisire l'oggetto di sessione per la richiesta. Non cercherò un motivo nei browser perché questo può essere solo un problema lato server. E probabilmente uno su cui non puoi fare molto. Se si tratta di un deadlock, allora si tratta di un problema dipendente dalla temporizzazione multi-thread. Quindi se diversi browser inviano richieste con tempi leggermente diversi, si ottengono risultati diversi. Inoltre, se esegui i browser localmente o in remoto, ottieni tempi leggermente diversi. Lo svuotamento della sessione non aiuta perché il problema riguarda l'acquisizione della sessione. Disabilitare completamente la sessione aiuta, perché la sessione non è stata acquisita affatto. Il passaggio da AppPool a Classic è utile perché ha un'implementazione diversa della gestione delle sessioni che non ha il deadlock. Per verificare l'ipotesi, puoi provare a inserire un ritardo artificiale tra i postback sul lato client. Ciò creerà diverse condizioni temporali e dovrebbe influire sul problema.

Devo dire che si tratta solo di speculazioni basate sulla descrizione e sulla mia esperienza con IIS. Ti suggerirei di cambiare AppPool in Classic perché il lato negativo delle prestazioni non è così grande.

+0

+1 buona risposta. Brutto problema –

+0

Avevo un problema di deadlock simile a questo. Sono passato dal pool di app predefinito a ASP.NET v4.0 e sono andato via. – Zoidberg

5

Ho avuto un problema simile sul mio sito. Nel mio caso avevo una pagina che conteneva un numero di griglie che ciascuna chiamava un webservice asmx per recuperare i propri dati. Se l'utente si è allontanato dalla pagina prima che tutte le richieste web fossero state completate, la sessione dell'utente potrebbe diventare molto lenta (almeno un paio di minuti per caricare una pagina), ma le sessioni degli altri utenti non sarebbero state influenzate dalla lentezza. Per me, il problema è iniziato quando ho installato .NET 4.5 sul server.

Ho trovato una pagina qui: http://forums.asp.net/t/1888889.aspx/1?Question+regarding+a+possible+bug+within+NET+4+5 che parla di questo problema noto con .NET 4.5. Il bug può essere attivato se il sito utilizza la modalità integrata e il browser si disconnette durante l'attesa di una pagina che sta utilizzando la sessione ASP.NET. (Vedi il post per maggiori dettagli).

Credo che la causa del doppio postback potrebbe far sì che il browser interrompa una delle richieste, quindi sembra che ciò si applicherebbe. Inoltre, io e altri abbiamo notato che il bug sembra essere più comunemente visto quando si usa IE (anche se questa è solo una coincidenza - non è un bug di IE)

Il post descrive anche una soluzione alternativa (aggiustando l'impostazione uploadReadAheadSize in il web.config) e questa soluzione ha risolto il problema per me.

+0

Sì; sembra un problema che abbiamo riscontrato (http://stackoverflow.com/questions/11250167/how-can-i-debug-sessionstatemodule-request-aquire-state-taking-100-seconds-on). Sembra un bug ASP.NET; probabilmente il numero 6 menzionato qui: http://support.microsoft.com/kb/2828841/en-us –

1

Si noti che questo è uguale al post Stackoverflow ->ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress.

Questa sembra essere una regressione in ASP.NET 4.5. Il team ASP.NET sta lavorando su una patch, ma esiste una soluzione temporanea (vedere il post sopra indicato).

Se non si riesce ad attendere l'aggiornamento generale pubblico, è possibile contattare l'assistenza clienti Microsoft per le richieste di hotfix. Segui semplicemente il normale processo di apertura di un caso di supporto. Ad esempio, file online https://support.microsoft.com/oas/default.aspx?&gprid=548&&st=1&wfxredirect=1&sd=gn o supporto chiamate http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone. Potrebbe essere necessario pagare anticipatamente un importo minimo, ma è possibile ottenere il rimborso in base alle politiche di assistenza clienti. Basta chiedere al servizio di assistenza clienti di contattare netfx45compat in Microsoft dot com per ottenere un rapido contesto su questo problema.

Grazie Varun Gupta (.NET Framework compatibilità)

Problemi correlati