internet explorer - iis7 - La doble devolución de IE cuelga IIS 7 en modo de canalización administrada integrada cuando se accede a la sesión
iis security settings (4)
¡Buenas noticias! Parece que el problema de bloqueo de sesión se resolvió después de instalar .Net 4.5.1
¡Actualicé mi máquina de prueba 7.5.7600.16385 en Windows Server 2008 R2 con .Net 4.5 instalado a 4.5.1 y el problema desapareció!
Aquí está mi entorno: IIS7.5 en Win 7, .NET 4, App Pool Integrated
web.config
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
</configuration>
Prueba.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í, la devolución múltiple es intencional, notamos que este comportamiento causará muchas solicitudes bloqueadas en RequestAcquireState y, en última instancia, evitará que el servidor acepte nuevas solicitudes. Sin embargo, este problema solo se puede observar en IE y no en Chrome o FF.
Para probar, continuamente haga clic en el botón de devolución de datos múltiple. Esto actualizará el número de estado. Entonces podrá observar que el número deja de aumentar cuando se usa IE, lo que indica el problema de la solicitud atascada.
Pude producir este problema con las siguientes versiones de IIS e IE:
Versiones de IIS probadas
- 7.5.7600.16385 en Windows Server 2008 R2 con .Net 4.5 instalado
- 7.5.7600.16385 en Windows 7 Pro con .Net 4.5 instalado
Versión IE probada
- 9.0.8112.16421 en Windows 7 Pro
- 8.0.7600.16385 en Windows Server 2008 R2
- 6.0.3790.3959 en Windows Server 2003 SP2
Una anomalía que observé es que al acceder a IIS local, 8.0.7600.16385 en Windows Server 2008 R2 NO causa este problema de bloqueo. Pero si uso el navegador para acceder a un IIS remoto, entonces el problema se puede reproducir. Mientras que en IE 9 puedo reproducir el problema independientemente de si IIS está en remoto o local.
Aquí hay una captura de pantalla de cómo se ve la solicitud colgada en la lista de solicitudes para el proceso de trabajo.
Ahora hemos encontrado algunas maneras de solucionar este problema, pero ninguna es aceptable en nuestra situación:
- Eliminar / comentar el uso de la sesión.
- Cambie el grupo de aplicaciones al modo clásico.
NOTA: también descubrimos que incluso si no usamos Sesión directamente como se muestra en el ejemplo, el problema continúa. IE: si agregamos un Global.asax.cs y agregamos un controlador de eventos Session_Start vacío, la solicitud aún se bloqueará en RequestAcquireState.
¿Alguien tiene una idea de por qué sucede esto y cómo podemos resolver este problema que parece que solo ocurre en el modo de canalización administrada integrada?
Desde su descripción, parece que los puntos muertos de IIS cuando intenta adquirir el objeto de sesión para su solicitud. No estaría buscando una razón en los navegadores porque esto solo puede ser un problema del lado del servidor. Y probablemente uno no puede hacer mucho al respecto. Si es un punto muerto, entonces es un problema dependiente de la sincronización de múltiples subprocesos. Por lo tanto, si diferentes navegadores envían solicitudes con tiempos ligeramente diferentes, obtendrás resultados diferentes. Además, si ejecuta los navegadores local o remotamente, obtendrá tiempos ligeramente diferentes. Vaciar la sesión no ayuda porque el problema está en la adquisición de la sesión. Deshabilitar la sesión completamente ayuda, porque la sesión no se adquiere en absoluto. El cambio de AppPool a Classic ayuda porque tiene una implementación diferente de la administración de sesiones que no tiene el punto muerto. Para probar la hipótesis, puede intentar insertar un retraso artificial entre las devoluciones en el lado del cliente. Esto creará diferentes condiciones de tiempo y debería afectar el problema.
Debo decir que estas son solo especulaciones basadas en su descripción y mi experiencia con IIS. Te sugiero que cambies el AppPool a Classic porque la desventaja de rendimiento no es tan grande.
Tenga en cuenta que este es el mismo que el de post -> ManagedPipelineHandler para un AJAX POST se bloquea si un usuario de IE9 se aleja de una página mientras esa llamada estaba en curso .
Esto parece ser una regresión en ASP.NET 4.5. El equipo de ASP.NET está trabajando en un parche, pero hay una solución temporal (consulte la publicación mencionada anteriormente).
Si no puede esperar a una amplia actualización pública, puede ponerse en contacto con el servicio de atención al cliente de Microsoft para solicitar una revisión. Simplemente siga el proceso regular de apertura de un caso de soporte. Por ejemplo, envíe un archivo en línea https://support.microsoft.com/oas/default.aspx?&gprid=548&&st=1&wfxredirect=1&sd=gn o llame al soporte http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone . Es posible que deba pagar una cantidad mínima por adelantado, pero puede obtener un reembolso según las políticas de atención al cliente. Simplemente solicite al profesional de soporte al cliente que se comunique con netfx45compat en Microsoft com. Com para obtener un contexto rápido sobre este problema.
Gracias Varun Gupta (compatibilidad con .NET Framework)
Tuve un problema similar en mi sitio. En mi caso, tenía una página que contenía una serie de cuadrículas que cada una de ellas llamaba un servicio web de asmx para recuperar sus datos. Si el usuario navegó fuera de la página antes de que se hubieran completado todas las solicitudes web, entonces la sesión de ese usuario podría ser muy lenta (al menos un par de minutos para cargar una página), pero las sesiones de otros usuarios no se verían afectadas por la lentitud. Para mí, el problema comenzó cuando instalé .NET 4.5 en el servidor.
Encontré una página aquí: http://forums.asp.net/t/1888889.aspx/1?Question+regarding+a+possible+bug+within+NET+4+5 que habla de que esto es un problema conocido con .NET 4.5. El error se puede desencadenar si el sitio usa el modo integrado y el navegador se desconecta mientras espera una página que está usando la sesión ASP.NET. (Ver post para más detalles).
Creo que su caso de doble devolución de datos podría hacer que el navegador abandone una de las solicitudes, por lo que parece que esto se aplicaría. Además, yo y otros hemos notado que el error parece ser más común cuando se usa IE (aunque esto es solo una coincidencia, no es un error de IE)
La publicación también describe una solución (ajustando la configuración de uploadReadAheadSize en web.config), y esa solución solucionó el problema para mí.