Reintentos automatizados
La recuperación de la 'client implementation' puede tomar forma de dos maneras:
-
Action retries: reintentar la action si el estado de la transacción no ha cambiado en X segundos
-
Action revivals: reintentar la action en un cluster shard recién iniciado y, usando un backoff exponencial empezando con la duración inicial de X segundos, cualquier transacción en un estado no terminal será reintentada.
Action Retries
| Action Retries y Action Timeouts solo aplican a External Domains y no a Domain Functions. El manejo de errores transitorios que pueden ocurrir en domain functions debería manejarse en el código del adapter. |
Los action retries se usan para evitar que las transacciones permanezcan atascadas en un estado, emitiendo reintentos si una action no cambia de estado dentro de una duración aceptable (configurable).
| Los reintentos solo se cancelan para una request/response que sea completing. Para más información consulta la sección Requests en Concepts. |
Interacción con Action timeouts
Para action timeouts ver Scheduling.
Los timeouts normalmente resultarían en un nuevo estado (Terminal) y, por lo tanto, no estarían sujetos a reintentos.
Cuando los timeouts causan un nuevo estado (no terminal), entonces se intentará un reintento sobre ActionTimeout si permanece atascado en su estado.
Configuración de Action Retry
La configuración utiliza la política de configuración de ipf-scheduler (ver Scheduling para configuración y action timeouts).
Hay 3 elementos de configuración necesarios para action retries:
-
initial-retry-interval: la duración inicial entre reintentos; los reintentos subsiguientes se multiplican por un factor de backoff 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; p. ej., [initial] + [max-retries]. 0 reintentos desactivará efectivamente esta funcionalidad.
-
jitter-factor: el porcentaje de aleatoriedad a usar al reintentar acciones; el valor por defecto es 0.2.
Para todas las Actions
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 una Action 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
}
Usando la configuración anterior se crearía el siguiente efecto para Action1:
Lo siguiente asume que ActionTimeout llevará a un estado terminal, o al menos a un cambio de estado.
| Time (t+seconds) | State | Action |
|---|---|---|
0 |
State1 |
Action1 |
3 |
State1 |
ActionRetry (Action1) |
6 |
State1 |
ActionRetry (Action1) |
10 |
Timeout (or whatever state ActionTimeout causes) |
ActionTimeout |
Action Revival
Action revival está diseñado para recuperar transacciones en un nodo que ha fallado. Se diferencia de Action retries en que solo se dispara cuando el cluster se inicia o reinicia, un escenario no cubierto por Action retries.
Revival utilizará action retries y continuará desde el histórico de intentos de reintento; es decir, si un behaviour ya había intentado 1 de, digamos, los 2 intentos configurados, entonces solo se intentará 1 reintento.
El proceso de revival no intentará recuperar una transacción en INITIAL o en estados terminales. Esto fue para proteger el sistema de intentar recuperar en todos los shards recién iniciados.
El proceso de revival no intentará la recuperación si el estado ha cambiado antes de que se complete actionRevivalOffset (ver configuración), ya que la transacción ya no se considerará atascada.
Action revival se basa en señales de recuperación de Akka; esto significa que ocurrirá una recuperación de estado cuando ocurra cualquiera de lo siguiente:
-
Se inicializa por primera vez un Event Sourced Behaviour (ESB)
-
Un ESB es revivido después de haber sido pasivado (sucede automáticamente después de 120s por defecto)
-
Un ESB fue terminado por una excepción
-
Un ESB es reequilibrado y por lo tanto reiniciado en otro nodo
Configuración de Action Revival
Hay 2 configuraciones importantes requeridas para activar el revival:
-
remember-entities: un elemento de configuración de Akka que hace que Akka reinicie automáticamente shards al reiniciar un shard. Ver docs de Akka.
-
action-recovery-delay: un offset configurado como duración que se impone al sistema para permitir que cualquier action cambie de estado antes de enviar solicitudes adicionales. Un offset de 0 desactivará esta funcionalidad.
application.conf
akka.cluster.sharding.remember-entities = on
application.properties
ipf.behaviour.config.action-recovery-delay=3s