asp classic - Response.Flush en Classic ASP que causa puertos TIME_WAIT
asp-classic connections (1)
Resulta que la conexión TIME_WAIT no tenía nada que ver con la base de datos, solo tenía una respuesta.flush abre una nueva conexión desde el servidor web al cliente, y esa es la conexión que da como resultado conexiones TIME_WAIT. No he encontrado una forma de evitarlo y, por lo tanto, estoy limitando la respuesta. Enjuague para circunstancias especiales, de lo contrario no se sonrojaría.
Recientemente me di cuenta de este problema: https://blogs.msdn.microsoft.com/spike/2008/09/17/nested-recordset-and-the-portsocket-in-time_wait-problem-by-example/
Donde si abre un conjunto de registros, luego usa la conexión para otra cosa con el conjunto de registros aún abierto, el servidor web abre un nuevo puerto para hablar con el DB, y luego coloca inmediatamente ese puerto en el estado TIME_WAIT.
He estado revisando el sitio para solucionarlo (cerrando conjuntos de registros antes de que la conexión se reutilice, funciona) pero noté algo extraño.
Cuando la página tiene un "Response.Flush", no importa lo que haga, provoca que se use un puerto adicional y luego se lo coloca en el estado inútil TIME_WAIT. Esto puede conducir a un caso grave de agotamiento del puerto.
CÓDIGO DE MUESTRA:
<%@ Language=VBScript %>
<html>
<head>
</head>
<body>
<%
response.flush
set cnn = server.CreateObject("adodb.connection")
CNN.cursorlocation=3
cnn.open [YOUR CONNECTION STRING]
set rs=server.createobject("adodb.recordset")
set rs=cnn.execute("select top 1 * from [YOUR TABLE]")
cnn.close
set cnn=nothing
%>
</body>
</html>
Para verificar el tiempo de espera, puede ejecutar:
netstat -nao | find /i "[YOUR DB IP]" /c
a través del símbolo del sistema en el servidor web. Suponiendo que se trata de un sistema de prueba, debería ver inmediatamente las conexiones temporales de time_wait desde su servidor web a su servidor de base de datos. Elimine la descarga, y esto se detiene.
Google no ha ayudado, abierto a cualquier sugerencia.
Entorno: IIS 7.5, ASP clásico, SQL Server 2008.
EDITAR:
También probé esto según los comentarios:
Set cmd = Server.CreateObject("ADODB.Command")
With cmd
''No need to handle connection let ADODB.Command create and destory it.
.ActiveConnection = sqlcnnstr1
.CommandType = 1
.CommandText = "select top 1 * from [YOUR_TABLE]"
Set rs = .Execute()
If Not rs.EOF Then data = rs.GetRows()
Call rs.Close()
Set rs = Nothing
End with
Set cmd = Nothing
Todavía el mismo problema. Con la conexión adicional, sin conexión, sin la misma conexión.
EDIT 2 Resulta que no tiene nada que ver con la base de datos. Si tiene SOLO una respuesta.flush, nada más, eso ya causa una conexión adicional, desde IIS hasta el cliente , por lo que he estado mirando el error de las cosas.
La pregunta ahora es si puede salirse con la suya sin tener respuesta. El enjuague genera una conexión adicional de IIS al cliente.