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 nuevamente si el estado de la transacción no ha cambiado en X segundos

  • Reactivaciones de acciones-vuelva a intentar la acción en el fragmento del clúster recién iniciado, y utilice un retroceso exponencial comenzando con la duración inicial de X segundos. Cualquier transacción en un estado no terminal será reintentada.

Reintentos de Acción

Reintentos de acción y Action Timeouts son aplicables únicamente a External Domains y no Domain Functions. El manejo de errores transitorios que puedan ocurrir en las funciones de dominio debe ser gestionado en el código del adaptador.

Los reintentos de acción se utilizan para evitar que las transacciones permanezcan atascadas en un estado, emitiendo reintentos si una acción no cambia de estado 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 los tiempos de espera de acción

Para los tiempos de espera de acción, consulte Programación.

Timeoutsnormalmente resultaría en un nuevo estado (Terminal) y, por lo tanto, no estaría sujeto a reintentos.

Cuando los tiempos de espera causan un nuevo estado (no terminal), entonces se intentará un reintento en el ActionTimeout si permanece atascado en su estado.

Configuración de reintento de acción

La configuración utiliza la política de configuración del ipf-scheduler(vea Programación para la configuración y los tiempos de espera de acción).

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 estado terminal, o al menos a un cambio de estado.

Tiempo (t+segundos) Estado Acción

0

State1

Acción1

3

Estado1

ActionRetry (Action1)

6

Estado1

ActionRetry (Action1)

10

Tiempo de espera (o cualquier estado que cause ActionTimeout)

ActionTimeout

Revitalización de la Acción

La recuperación de acciones está diseñada para recuperar transacciones en un nodo fallido. Se diferencian de los reintentos de acciones en el hecho de que solo se activan cuando el clúster se inicia o reinicia, un escenario no cubierto por los reintentos de acciones.

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 estado ha cambiado antes de que el actionRevivalOffset (consulte la configuración) se haya completado, ya que la transacción ya no se considerará atascada.

La reactivación de la acción se basa en Akka las señales de recuperación esto significa que ocurrirá una recuperación del estado 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 redistribuye y, por lo tanto, se reinicia en otro nodo.

Configuración de la Revitalización de Acciones

Hay 2 configuraciones importantes requeridas para activar la reactivación;

  • recuerde-entidades-an Akka elemento de configuración que causa Akka para reiniciar automáticamente los fragmentos tras un reinicio de fragmento.https://doc.akka.io/docs/akka/current/cluster-sharding.html#remembering-entities[Consulte la documentación de akka].

  • acción-retraso-recuperación-un desplazamiento configurado como duración que se impone al sistema para permitir que cualquier acción cambie de estado 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