Reintentos Automatizados
La recuperación de la 'implementación del cliente' puede tomar forma de una de dos maneras;
-
Reintentos de acción-intente la acción después si la transacción es state no ha cambiado en X segundos
-
Reactivaciones de acciones-vuelva a intentar la acción en la nueva fragmentación del clúster, y utilice un retroceso exponencial comenzando con la duración inicial de X segundos para cualquier transacción en un estado no terminal.state se intentará de nuevo.
Reintentos de Acción
| Reintentos de acción y Action Timeouts son aplicables únicamente a External Domains y no Domain Functions. Manejo de errores transitorios que pueden ocurrir en domain functions debe ser manejado en el código del adaptador. |
Los reintentos de acción se utilizan para evitar que las transacciones queden atascadas en un state, emitiendo reintentos si una acción no cambia state dentro de una duración aceptable (configurable).
| Los reintentos solo se cancelan para una solicitud/respuesta completada. Para más información, consulte la sección de Solicitudes de Conceptos. |
Interacción con Action timeouts
Para action timeouts ver Programación.
Timeouts normalmente resultaría en un nuevo state(Terminal) y por lo tanto no estaría sujeto a reintentos.
Cuando timeouts causar un nuevo state(no terminal) entonces se intentaría un nuevo intento en el ActionTimeout si permanece atascado en su state.
Configuración de reintento de acción
La configuración utiliza la política de configuración del ipf-scheduler(vea Programación para configuración y action timeouts).
Hay 3 elementos de configuración necesarios para reintentos de acción;
-
intervalo-inicial-de-reintento-la duración inicial entre reintentos, reintentos subsiguientes multiplicados por un factor de retroceso de 2, es decir, si la duración es 1 entonces 1, 2, 4, 8.
-
max-retries-el número máximo de reintentos a intentar, es decir, [inicial] + [máx-reintentos]. 0 reintentos desactivará efectivamente esta funcionalidad.
-
factor de jitter - El porcentaje de aleatoriedad a utilizar al reintentar acciones, el valor predeterminado es 0. 2.
Para todas las Acciones
application.conf
ipf flow {
Any. Any. Any.timeout-duration=10s
Any. Any. Any.initial-retry-interval=3s
Any. Any. Any.max-retries=2
Any. Any. Any.jitter-factor=0. 2
}
Para Acción Específica
application.conf
ipf flow {
Any. Any. Any.timeout-duration=10s
Flow1. State1. Action1.initial-retry-interval=3s
Flow1. State1. Action1.max-retries=2
}
Utilizar la configuración anterior crearía el siguiente efecto para Action1;
Lo siguiente asume que ActionTimeout conducirá a un terminal state, o al menos un cambio de state.
| Tiempo (t+segundos) | Estado | Acción |
|---|---|---|
0 |
State1 |
Acción1 |
3 |
State1 |
ActionRetry (Action1) |
6 |
Estado1 |
ActionRetry (Action1) |
10 |
Timeout (o lo que sea state ActionTimeout causa) |
ActionTimeout |
Revitalización de la Acción
La recuperación de acciones está diseñada para recuperar transacciones en un failed nodo. Se diferencian de los reintentos de Acción en el hecho de que solo se activan cuando el clúster se inicia o reinicia, un escenario no cubierto por los reintentos de Acción.
Revival utilizará reintentos de acción y continuará desde cualquier historial de intentos de reintento, es decir, si un comportamiento ya había intentado 1 de, digamos, los 2 intentos configurados, entonces solo se intentará 1 reintento.
El proceso de recuperación no intentará recuperar una transacción en estado INICIAL ni en ningún estado terminal. Esto se hizo para proteger al sistema de intentar recuperar en todos los fragmentos recién iniciados.
El proceso de reactivación no intentará la reactivación si el state ha cambiado antes de que la acción RevivalOffset (consulte la configuración) se complete, ya que la transacción ya no se considerará atascada.
La reactivación de la acción se basa en Akka señales de recuperación esto significa que una recuperación de state ocurrirá cuando suceda cualquiera de lo siguiente;
-
An Event El Comportamiento Sourced (ESB) se inicializa por primera vez.
-
Un ESB se reanuda después de haber sido pasivado (sucede automáticamente después de 120s por defecto).
-
Un ESB fue detenido por una excepción.
-
Un ESB se reequilibra y, por lo tanto,restarted en otro nodo
Configuración de Revitalización de Acción
Hay 2 configuraciones importantes requeridas para activar la reactivación;
-
recuerde-entidades-an Akka elemento de configuración que causa Akka para automáticamente restart fragmentos sobre un fragmento restart.https://doc.akka.io/docs/akka/current/cluster-sharding.html#remembering-entities[Ver akka docs].
-
acción-recuperación-retraso-un desplazamiento configurado como duración que se impone al sistema para permitir que cualquier acción cambie state antes de enviar solicitudes adicionales. Un desplazamiento de 0 desactivará esta funcionalidad.
application.conf
akka.cluster.sharding.remember-entities = on
application.properties
ipf.behaviour.config.action-recovery-delay=3s