La actividad “CheckPoint” salva el estado y datos de la
instancia de proceso en disco para, en caso de fallo del motor de BW, poder recuperar el estado en el punto del último
checkpoint salvado. Los checkpoints se utilizan para recuperar el estado de
las instancias de procesos en caso de fallo de motor por una excepción no
controlada o por una parada del motor desde TIBCO Administrator o TIBCO Hawk.
El comportamiento normal de BW en caso de fallo del engine
es el de recuperar la ejecución de todas la instancias de proceso que estaban
en ejecución desde el último “CheckPoint” especificado. Si no hay
“CheckPoint” especificado se recuperan las instancias desde la actividad de
inicio.
1.1.1 Casos de Uso
- Recuperación controlada después de caídas del motor
- Detección de duplicados
1.1.2 Configuración
1.1.2.1 Configuración
Campos de la pestaña de configuración:
- Name. Nombre de la actividad.
- Description: Breve descripción de la actividad
1.1.2.1 Input
Por medio de la actividad “CheckPoint” se puede detectar si se está procesando más de una vez un evento. Configurando la pestaña “Input” es posible detectar y descartar el procesamiento duplicado de eventos ya sea en una nueva instancia de proceso o en una instancia recuperada (después de un fallo del engine).
En el campo “duplicateKey” se especifica un valor que debe ser único para cada instancia de proceso. Este será el valor por el cual se determine la existencia o no de eventos duplicados, por tanto debe escogerse un valor de entrada de la tarea “Start” del proceso cuyo valor sea único para cada evento.
Es posible colocar varias actividades “CheckPoint” en el
proceso, pero el valor de “duplicateKey” debe ser el mismo para todas las
actividades “checkPoint” de una instancia de proceso.
Procedimiento de detección de procesos duplicados:
1.
Recepción del mensaje de entrada y arranque de
la instancia de proceso.
2.
Ejecución de las actividades del proceso hasta
la primera actividad de “CheckPoint”. Fijación de un valor en “duplicateKey”,
3.
El motor de BW chequea la lista de valores de
“duplicateKey”
a.
Si ninguna otra instancia de proceso ha guardado
el mismo valor de “duplicateKey” entonces se almacena el valor y se completa la
actividad de “CheckPoint”
b.
Si alguna otra instancia ha almacenado
previamente el valor de “duplicateKey” se termina el proceso y se lanza una
excepción “DuplicateException”.
1.1.3 Detalles de Diseño
Detalles del comportamiento de la actividad de CheckPoint dependiendo del escenario en que se utilice.1.1.3.1 Tolerancia a Fallo y Balanceo de Carga
En caso de configurar BW en FT (Foult Tolerante) o LB (Load
Balance) no encontramos en un escenario con múltiple motores de BW ejecutando
las instancias de los procesos.
La información de checkpoint se puede almacenar en base de
datos o sistema de ficheros. En el caso de tener múltiples engines de BW
ejecutándose en paralelo en diferentes máquinas es necesario almacenar la información
en base de datos.
1.1.3.2 Detección de Duplicados
En el caso de que el evento/mensaje que produce la creación
de una instancia de proceso necesite de confirmación para indicar que ha sido
tratado, después de la detección del duplicado hay que confirmar el mensaje
para que no se vuelva a tratar. El siguiente diagrama muestra esta situación:
Para tener más control sobre la detección de duplicados
tenemos varias propiedades del motor de BW:
- bw.engine.dupKey.enabled. Valor por defecto ‘true’ indicando que se realiza detección de duplicados. Valor ‘false’ para no realizar detección de duplicados.
- bw.engine.dupKey.timeout.minutes. Tiempo que permanecen almacenadas las claves duplicadas.
- -1. Por tiempo indefinido
- 0. Se elimina en cuanto se detecta un duplicado.
- bw.engine.dupKey.pollPeriod.minutes. Periodo de polling para las dupkey expiradas.
1.1.3.3 Llamadas a Procesos
La
actividad de CheckPoint salva el estado completo de la instancia de proceso. En
el caso de llamada a procesos dentro de un proceso tenemos dos posibilidades:
La
primera y por defecto, el subproceso se ejecuta en la misma instancia de
proceso, por tanto, la ejecución de una actividad de CheckPoint en el subproceso
guarda también el estado del proceso padre.
La
segunda opción es la de “spawn”. En este caso el subproceso se ejecuta en una
nueva instancia por lo que la ejecución de una actividad de CheckPoint en el
proceso hijo no almacena el estado del proceso padre.
La
opción de Spawn está disponible en la llamada al subproceso.
1.1.3.4 Arranque de proceso con http Request
Cuando se produce una caída del motor de BW se cierra el socket para la tarea “http Request” que produce el arranque del proceso, por lo tanto, la actividad de CheckPoint debe estar después de la tarea “http Response”. En caso contrario, al intentar hacer “http Response” se produce una excepción por no poder responder al Request.
1.1.3.5 Tareas de Confirmación
Tener
en consideración los procesos cuyo arranque se corresponde con un
evento/mensaje que requiere de confirmación para indicar que se ha procesado.
Para este tipo de procesos tenemos dos situaciones:
2. colocar la actividad de CheckPoint después de la actividad de confirmación del evento/mensaje. En este caso la caída y re-arranque del motor de BW no produce que se arranque una nueva instancia de proceso para el evento/mensaje puesto que fue confirmado antes de la actividad de CheckPoint.
1.1.3.6 Fichero .tra
En el
fichero .tra del engine se puede activar/desactivar la recuperación desde
checkpoint a través de la propiedad:
bw.engine.autoCheckpointRestart={true|false}
1.1.3.7 Fallo en instancia de proceso
El
comportamiento por defecto cuando una instancia de proceso falla es que se
elimine la información de los checkpoints. Para modificar este comportamiento y
posibilitar la recuperación de instancias de procesos que han fallado desde los
checkpoints definidos tenemos la propiedad:
bw.engine.enableJobRecovery={false|true}
No hay comentarios:
Publicar un comentario