Configuración del Conector

La configuración para un Conector puede establecerse en los archivos de configuración de IPF. Esta sección explica las diversas opciones de configuración disponibles para los distintos tipos de conectores, sus valores predeterminados, y el mecanismo de respaldo que le permite proporcionar solo una configuración parcial y utilizar, en su lugar, los valores predeterminados documentados a continuación.

Opciones de Configuración

Sending Connector s

Las opciones de configuración permitidas para un sending connector(send connector& conectores de solicitud-respuesta) son:

Nombre de la Propiedad

Descripción

Tipo

Valor Predeterminado

manual-start

Cuando se establece en false, el conector se inicia automáticamente después de la creación; de lo contrario, su método de inicio debe ser invocado manualmente.

Boolean

falso

queue-size

Tamaño de una cola de origen que puede ser utilizada para manejar la presión de retroceso, por ejemplo, situaciones de productores rápidos.

Entero

50

call-timeout

Duración máxima para esperar un acuse de recibo antes de completar la futura devuelta excepcionalmente con un TimeoutException.

Duración

30s

correlation-stage-timeout

Esta configuración evita que las respuestas retrasadas que intentan persistir en el almacén de correlación sean procesadas una vez que ha transcurrido el tiempo de espera de la llamada, lo que provocaría que se envíe un mensaje a pesar de un fallo de entrega que indica lo contrario. NOTA: Esto debe ser siempre menor que el call-timeout, se lanzará una excepción si este no es el caso y el inicio de la aplicación fallará si el call-timeout es menor que correlation-stage-timeout

Duración

5s

max-concurrent-offers

Número máximo de ofertas pendientes cuando el búfer está lleno.

Entero

500

parallelism

Número máximo de llamadas paralelas para send connector

Entero

500

parallelism-per-partition

Número máximo de envíos paralelos por UnitOfWorkId. Debe ser menor que parallelism.

Entero

1

throttle-count

Limita el rendimiento a un número específico de mensajes consumidos por unidad de tiempo. Cuando este valor está establecido, también debe proporcionarse la duración del estrangulador.

Entero

No establecido

throttle-duration

Se utiliza con 'throttle-count' para establecer la tasa máxima de consumo de mensajes. Para más detalles, consulte el Limitación de Mensajes documentación.

Duración

No establecido

configuraciones-de-resiliencia

Los ajustes de resiliencia para este conector, por favor consulte Configuraciones de resiliencia

Configuración De Resiliencia

Conectores de Recepción

La configuración permitida para un conector de recepción es:

Nombre de la Propiedad Descripción Tipo Valor Predeterminado

manual-start

Cuando se establece en false, el conector se inicia automáticamente después de su creación; de lo contrario, su método de inicio debe ser invocado manualmente.

Boolean

true

throttle-count

Si se establece el valor, limita el rendimiento a un número específico de mensajes consumidos por unidad de tiempo. Si está configurado. Si este valor está establecido, también debe establecerse la duración del estrangulador.

Entero

No establecido

throttle-duration

Si se establece, se utiliza junto con throttle-count para establecer la tasa máxima para consumir mensajes. Para más detalles, consulte doc.akka.io/japi/akka/2. 6/akka/stream/javadsl/Flow.html#throttle(int,java.time. Duration)

Duración

No establecido

mapping-parallelism

Si se establece, limita el número de concurrentes mapping operaciones ejecutadas sobre los mensajes consumidos.

Entero

número de procesadores disponibles

receiver-parallelism-type

Define la forma en que se manejan los mensajes en paralelo. Opciones disponibles:

  • ORDERED - Los mensajes se consumen en paralelo en el orden en que son recibidos, y se reconocen en el mismo orden.

  • ORDERED_PARTITIONED - los mensajes se consumen en paralelo en el orden en que son recibidos, y se reconocen en el mismo orden, pero el paralelismo para los mensajes que comparten el UnitOfWorkId está limitado a un grado configurable

  • UNORDERED - los mensajes se consumen en paralelo en el orden en que se reciben, y se reconocen en su orden de finalización, lo que puede afectar a algunos transportes (por ejemplo,Kafka)

Enum

ORDERED_PARTITIONED

receiver-parallelism

Si se establece, limita el número de mensajes mapeados que se permiten procesar de manera concurrente.

Entero

número de procesadores disponibles

receiver-parallelism-per-partition

Solo se aplica si receiver-parallelism-type está configurado para ORDERED_PARTITIONED. Si se establece, limita el número de mensajes mapeados por UnitOfWorkId que se permiten procesar de manera concurrente. Debe ser menos que receiver-parallelism.

Entero

1

resiliency-settings

Las configuraciones de resiliencia para este conector, por favor consulte Configuraciones de resiliencia

Configuración De Resiliencia

Configuraciones de resiliencia

Tanto la configuración del conector de envío como la del conector de recepción permiten definir la configuración de resiliencia utilizando un bloque de 'resiliency-settings'. La mayoría de las propiedades en este bloque se utilizan para establecer los valores de configuración para Resilience4j.https://resilience4j.readme.io/docs/retry#create-and-configure-retry[reintentar] y interruptor automático configuración, que se utiliza para envolver llamadas con ruptura de circuito, respaldo o enrutamiento, y reintentos. Tenga en cuenta que, dado que algunas configuraciones de Resilience4j pueden entrar en conflicto entre sí, no todos los parámetros de esta biblioteca están expuestos en este bloque de configuración. Además, algunos de los valores predeterminados de Resilience4j han sido anulados en este bloque para alinearse mejor con los requisitos de un IPF application.

Nombre de la Propiedad Descripción Tipo Equivalente de Resilience4j Valor Predeterminado Configuración

habilitado

Permite activar o desactivar la resiliencia

Boolean

n/a

verdadero

sí

número-mínimo-de-llamadas

Determina el número mínimo de llamadas (dentro de un período de ventana deslizante) que deben realizarse antes de que el interruptor de circuito pueda calcular la tasa de error para determinar la salud del transporte.

Entero

número Mínimo De Llamadas

1

sí

intentos-máximos

Determina el número máximo de reintentos que se pueden realizar. Tenga en cuenta que esto incluye el primero failed intento.

Entero

maxAttempts

1

sí

tiempo-de-intento

Cuánto tiempo esperar para que un intento único se complete antes de fallarlo.

Duración

n/a

30s

sí

restablecer-tiempo-de-espera

Cuánto tiempo esperar mientras está en la ABIERTO state antes de pasar a HALF_OPEN e intentar cerrar el circuito.

Duración

waitDurationInOpenState

1s

sí

duración-inicial-de-espera-para-reintentos

Cuánto tiempo esperar antes de reintentar. Esto establece la duración inicial y puede aumentar en los intentos de reintento sucesivos debido al multiplicador de retroceso.

Duración

Una mitad de la función Intervalo.

1s

sí

multiplicador-de-retroceso

Cada reintento sucesivo esperará la duración de espera anterior multiplicada por el multiplicador de retroceso.

Entero

Segunda mitad de la función intervalo.

2

sí

reintentar-en-fallo-cuando

Dada una excepción lanzada por el código decorado, devuelve un booleano para determinar si se debe reintentar. Esto es para evitar reintentar en excepciones donde múltiples intentos no resolverán la falla.

Boolean

n/a

verdadero

sí

reintentar-sobre-resultado-cuando

Dado un resultado exitoso, es decir, que no se lanzó ninguna excepción, devuelve un booleano para determinar si se debe reintentar. Esto se utiliza para activar reintentos basados en el objeto devuelto del código decorado en un conector receptor.

Boolean

reintentarEnResultado

falso

sí

fallar-después-de-intentos-máximos

Un booleano para habilitar o deshabilitar el lanzamiento de MaxRetriesExceededException cuando el Retry ha alcanzado el maxAttempts configurado, y el resultado aún no cumple con el retryOnResultPredicate.

Boolean

fallar Después De Max Intentos

falso

sí

umbral-tasa-fallo

Cuando la tasa de fallos es igual o mayor que el umbral, el CircuitBreaker transiciona a abierto y comienza a interrumpir las llamadas.

Doble

umbralTasaDeFallo

50

sí

umbral-de-tasa-de-llamadas-lentas

El CircuitBreaker considera una llamada como lenta cuando la duración de la llamada es mayor que slowCallDurationThreshold. Cuando el porcentaje de llamadas lentas es igual o mayor que el umbral, el CircuitBreaker transiciona a abierto y comienza a interrumpir las llamadas.

Doble

umbralDeTasaDeLlamadasLentas

100

sí

umbral-de-duración-de-llamada-lenta

Configura el umbral de duración por encima del cual las llamadas se consideran lentas y aumenta la tasa de llamadas lentas.

Duración

umbral De Duración De Llamada Lenta

60000ms

sí

duración-máxima-de-espera-en-medio-abierto-state

Cuando se establece en 0 ms, en realidad no se está configurando; cualquier otro tiempo establecerá realmente la variable.

Duración

maxWaitDurationInHalfOpenState.

0ms

sí

número-permitido-de-llamadas-en-medio-abierto-state

Configura el número de llamadas permitidas cuando el CircuitBreaker está medio abierto.

Entero

número Permitido De Llamadas En Estado Semi Abierto

10

sí

tamaño-de-ventana-deslizante

Configura el tamaño de la ventana deslizante que se utiliza para registrar el resultado de las llamadas cuando el CircuitBreaker está cerrado.

Entero

tamaño Ventana Deslizante

100

sí

tipo-de-ventana-deslizante

Si la ventana deslizante es COUNT_BASED, se registran y agregan las últimas llamadas de tamaño slidingWindowSize. Si la ventana deslizante es TIME_BASED, se registran y agregan las llamadas de los últimos slidingWindowSize segundos.

TipoVentanaDeslizante

tipoVentanaDeslizante

CONTAR_BASED

sí

transición-automática-de-abierto-a-medio-abierto

Si se establece en verdadero, significa que el CircuitBreaker pasará automáticamente de abierto a medio abierto.state y no se necesita una llamada para activar la transición. Se crea un hilo para monitorear todas las instancias de CircuitBreakers y trasladarlas a HALF_OPEN una vez que transcurre waitDurationInOpenState. En cambio, si se establece en falso, la transición a HALF_OPEN solo ocurre si se realiza una llamada, incluso después de que transcurre waitDurationInOpenState. La ventaja aquí es que ningún hilo monitorea el state de todos los Interruptores Automáticos.

Boolean

transición Automática De Abierto AHalf Open Habilitada

verdadero

sí

reintentar-scheduler-tamaño-del-grupo-de-hilos

Determina cuántos hilos el reintento scheduler puede usar.

Entero

n/a

número de procesadores disponibles

no

redirigir-mensajes-en-fallo

Dado un resultado de fallo, devuelve un booleano para determinar si se deben re-enviar los mensajes a la cola.

Boolean

n/a

Llamadas retryOnFailureWhen predicado o valor de retry-on-failure-when

no

retryExceptions

Debe especificar la ruta completa de la clase y el nombre de la clase para que funcione correctamente, por ejemplo,java.lang. String. También debe ser una clase que extienda java.lang. Excepción

Lista<String> en la configuración. Lista<Class<Throwable>>

retryExceptions y recordExceptions.

null

no

ignoreExceptions

Debe especificar la ruta completa de la clase y el nombre de la clase para que funcione correctamente, por ejemplo,java.lang. String. También debe ser una clase que extienda java.lang. Excepción

Lista<String> en la configuración. Lista<Class<Throwable>>

ignoreExceptions

[]

no

reintentar-al-enviar-resultado-cuando

Dado un resultado exitoso, es decir, no se lanzó ninguna excepción, devuelve un booleano para determinar si se debe reintentar. Esto se utiliza para activar reintentos basados en el objeto devuelto del código decorado en un sending connector. Un ejemplo de dónde esto puede ser útil es si un HTTP el servidor responde con un éxito http código de respuesta a una solicitud, pero el cuerpo de la respuesta contiene detalles de error que indican que puede ser necesario reintentar.

Boolean

retryOnResult.

Devuelve verdadero cuando el DeliveryOutcome devuelto es un fallo y retryOnFailureWhen devuelve verdadero para la excepción que causó el fallo.

no

registrar Excepción

Configura un Predicado que evalúa si una excepción debe ser registrada como un fallo y, por lo tanto, aumentar la tasa de fallos. El Predicado debe devolver verdadero si la excepción debe contar como un fallo. El Predicado debe devolver falso si la excepción debe contar como un éxito, a menos que la excepción sea ignorada explícitamente por ignoreExceptions(Class[]) o ignoreException(Predicate).

Predicado<Throwable>

registrar Excepción

null

no

ignoreException

Configura un Predicado que evalúa si una excepción debe ser ignorada y no contar como un fallo ni como un éxito. El Predicado debe devolver verdadero si la excepción debe ser ignorada. El Predicado debe devolver falso si la excepción debe contar como un fallo.

Predicado<Throwable>

Configuración Predeterminada

Todos los conectores vienen con un conjunto de configuración base predefinido que se utilizará si no se anula en el momento de la construcción del conector.

La configuración predeterminada se proporciona a continuación y coincide con la definida en la sección anterior.

ipf.connector {
  default-receive-connector {
    manual-start = true
    receiver-parallelism-type = ORDERED_PARTITIONED
    receiver-parallelism-per-partition = 1
    resiliency-settings = ${ipf.connector.default-resiliency-settings}
  }

  default-send-connector {
    manual-start = false
    call-timeout = 30s
    queue-size = 50
    max-concurrent-offers = 500
    parallelism = 500
    parallelism-per-partition = 1
    send-message-association = true
    resiliency-settings = ${ipf.connector.default-resiliency-settings}
  }
  # Inherit everything from default-send-connector and then override some of the resiliency settings
  default-rr-send-connector = ${ipf.connector.default-send-connector} {
    resiliency-settings {
      reroute-messages-on-failure = false
      minimum-number-of-calls = 10
    }
  }
  default-resiliency-settings {
    enabled = true
    minimum-number-of-calls = 1
    max-attempts = 1
    attempt-timeout = 30s
    attempt-timeout = ${?ipf.connector.default-send-connector.call-timeout}
    reset-timeout = 1s
    initial-retry-wait-duration = 1s
    backoff-multiplier = 2
    retry-on-failure-when = true
    retry-on-result-when = false
    fail-after-max-attempts = false
    failure-rate-threshold = 50
    slow-call-rate-threshold = 100
    slow-call-duration-threshold = 60000ms
    max-wait-duration-in-half-open-state = 0ms
    permitted-number-of-calls-in-half-open-state = 10
    sliding-window-size = 100
    sliding-window-type = COUNT_BASED
    automatic-transition-from-open-to-half-open = true
    retry-exceptions = []
    ignore-exceptions = []
  }
}

Uso de la Configuración

Al construir un conector, es posible anular estas propiedades proporcionando un configRoot. Cuando se proporcione, el conector utilizará esto configRoot como base de las propiedades a utilizar. Así que, por ejemplo, si construimos un conector como:

var sendConnector = new SendConnector. Builder<String, String>("TestConnector")
    .withActorSystem(actorSystem) (1)
    .withConfigRoot("test-config") (2)
    .build();

Aquí estamos suministrando ambos:

1 el ActorSystem
2 la raíz de configuración-un valor de cadena.

Estamos informando a nuestro conector que nuestra raíz de configuración aquí es test-config. Lo que esto significa es que donde en nuestra configuración de conector predeterminada, el send connector los valores predeterminados están en ipf.connector.default-send-connector, aquí utilizaremos test-config como la configuración principal y luego ipf.connector.default-send-connector como la opción de respaldo.

Para ilustrar esto, suponga que configuramos el archivo de configuración de la siguiente manera:

test-config {
    parallelism = 700
    manual-start = false
}

Aquí estamos definiendo nuevos valores de configuración para el paralelismo y el inicio manual. Podríamos haber proporcionado igualmente los valores de configuración para las otras propiedades. Al suministrar solo estos dos, nuestro conector tendrá:

  1. A parallelism de 700

  2. Una configuración de inicio manual en falso.

  3. Todas las demás propiedades se heredan de la configuración predeterminada, por lo que, por ejemplo, el tamaño de la cola se establecerá en 50.

También podemos proporcionar anulaciones a los ajustes de configuración en el constructor a través de nuestro java código. Así que, por ejemplo, considere la siguiente configuración:

var sendConnector = new SendConnector. Builder<String, String>("TestConnector")
    .withActorSystem(actorSystem)
    .withParallelism(700)
    .withManualStart(false)
    .build();

Esto llevaría a que se construya el mismo conector de acuerdo con nuestra implementación de configuración.