Skip to content

CircuitBreaker

La libreria Infra.EventBus.IbmMQ cuenta con una nueva funcionalidad la cual nos permite dejar de recibir mensajes en caso de alguna dependencia (Downstream service) falle. An algunos casos el procesamiento de un evento depende totalmente de una dependencia, por ejemplo: almacenar el evento en una base de datos, realizar una llamada a una API externa, etc. En estos casos se puede dar la particularidad de que nuestas dependencias podrían fallar por completo, lo que resultaría en el rechazo de todos los mensajes entrantes y la saturacion de la cola BOQ. Para estos casos en conveniente utilizar un CircuitBreaker que nos permitira dejar de recibir mensajes mientras el corte en nuestra dependencia exista y volver todo a la normalidad cuando detectemos que nuestra dependencia esta nuevamente en linea.

Activar o desactivar el CircuitBreaker

El detalle del patron circuitbreaker se puede ver aqui. Para poder controlar el circuito tenemos 2 metodos:

  • Isolate(): Abre el circuito.
  • Reset(): Cierra el circuito.

Estos metodos estan disponibles dentro del parametro context que recibe el metodo Handle en casa manejador de eventos. Ej:

public async Task Handle(EnvioNoEntregado @event, IConsumeContext context)
{
    // Abre el circuito
    context.CircuitBreaker.Isolate();
    // cierra el cicuito
    context.CircuitBreaker.Reset();
}

En una correcta implementacion, deberiamos llamar al metodo Isolate() si detectamos que nuestra dependencia tiene un problema y vemos comprometido el procesamiento de los mensajes. Al llamar al metodo, el circuito se abre, y el mensaje entregado al handler no se confirma (Se realiza un rollback de la recepcion del mensaje). Luego de esto la libreria entregara ese ultimo mensaje cada cierta cantidad de segundo configurados en la propiedad SleepDurationBetweenRetriesInSeconds del archivo de configuracion (default 15 segundos), hasta que se llame al metodo Reset() para cerrar el circuito y que vuelva todo a la normalidad. Se asume que el mensaje entregado al momento del reset se proceso correctamente, por lo cual no se volvera a entregar. Una vez cerrado el circuito los mensajes empezaran a llegar con normalidad. Durante el periodo del corte, el metodo HandlerError no se invocara en el handler.