mvc application example asp net c#

AppFabric no se recupera bien desde el reinicio

Question

Bien, he implementado con éxito AppFabric, y todo estaba funcionando bien hasta que comenzamos a recibir una excepción intermitente en el sitio web:

ErrorCode <ERRCA0017>: SubStatus <ES0007>: hay una falla temporal. Vuelva a intentarlo más tarde. (La solicitud falló porque el servidor está en estado acelerado).

Al principio, sospeché que el servidor se estaba quedando sin memoria (estado acelerado), pero finalmente llegué a la conclusión de que ese no era el problema. En el registro de eventos, encontré que DistributedCacheService.exe se bloqueaba de vez en cuando, y me llevó a un método simple para volver a producir el error en mi entorno de desarrollo local:

• Inicie el sitio web, agregue algunas cosas al caché.
• Reinicie "AppFabric Caching Service".
• ... y empiezo a recibir el error.

Si hago un Get-CacheClusterHealth ANTES de reiniciar el servicio, se ve algo como esto:

NamedCache = MyCacheName
Healthy = 100,00
UnderReconfiguration = 0,00
NotPrimary = 0,00
NoWriteQuorum = 0,00
Throttled = 0,00

Después de reiniciar:

Unallocated named cache fractions
---------------------------------
NamedCache = MyCacheName
Unallocated fraction = 100,00

Mientras obtengo ese resultado de Get-CacheClusterHealth , el sitio falla. Por lo que puedo decir, se corrige después de un tiempo (más de 10 minutos).

¿Hay alguna manera de hacer que AppFabric vuelva a ponerse de pie más rápido?

Answer 1

En resumen, la respuesta es no.

El tiempo que tarda un clúster en reiniciar aumenta a medida que agrega nodos adicionales, lo que me lleva a pensar que se trata de un proceso de sincronización de nodos que lleva tiempo.

La excepción es que tu vista es efectivamente el nodo appfabric que ingresa a un estado acelerado. Entrará en el estado de aceleración dependiendo de cómo tenga las marcas de agua alta / baja establecidas en el nodo. Creo que, de forma predeterminada, la marca de agua máxima es del 90% después de esta fecha, comenzará a expulsar los elementos que se describen en la política de desalojo que se establece en la memoria caché. En general, debe utilizar LRU (al menos recientemente utilizado), pero si la caché aún no puede ejecutarse dentro de los límites establecidos, se acelerará para no bajar el servidor.

Su aplicación se beneficiaría si pudiera manejar dichos eventos con elegancia. Si tiene todos los nodos enumerados en la configuración del clúster de su aplicación, entonces su aplicación debe pasar al siguiente nodo en el próximo intento de obtener datos. Usamos un ciclo de reintento buscando la falla temporal y reintentando 3 veces. Si después de 3 veces el error persiste, iniciamos sesión y devolvemos nulo, no una excepción. Esto permite que la aplicación intente acceder a un nodo diferente o permita que el tiempo del nodo problemático se recupere:

 private object WithRetry(Func<object> method)
{
int tryCount = 0;
bool done = false;
object result = null;
do
{
try
{
result = method();
done = true;
}
catch (DataCacheException ex)
{
if (ex.ErrorCode == DataCacheErrorCode.KeyDoesNotExist)
{
done = true;
}
else if ((ex.ErrorCode == DataCacheErrorCode.Timeout ||
ex.ErrorCode == DataCacheErrorCode.RetryLater ||
ex.ErrorCode == DataCacheErrorCode.ConnectionTerminated)
&& tryCount < MaxTryCount)
{
tryCount++;
LogRetryException(ex, tryCount);
}
else
{
LogException(ex);
done = true;
}
}
}
while (!done);
return result;
}

Y eso nos permite hacer lo siguiente:

private void AF_Put(string key, object value)
{
WithRetry(() => defaultCache.Put(key, value));
}

o:

private object AF_Get(string key)
{
return WithRetry(() => defaultCache.Get(key));
}

Answer 2

Este mismo problema / similar ocurrió con uno de los proyectos en los que trabajé. Después de dos semanas de rascarnos la cabeza e intentar todo infructuosamente para que nuestros servicios WCF se ejecutaran (en Azure), terminamos llamando a Microsoft.

Los técnicos de Microsoft nos proporcionaron una secuencia de comandos (Power) Shell que se ejecuta desde el tiempo de ejecución del sitio que hace un mantenimiento más saludable de AppFabric ... El script tenía cosas que no había visto en los libros de Azure, pero ¡hizo el trabajo correctamente!

Gracias