parallel

Resumen

Descripción

El componente parallel permite la creación de una RBL compuesta por un conjunto de RBLs sobre el que se realizarán los chequeos. Dichos chequeos se harán en paralelo. Opcionalmente retornará inmediatamente si alguno de los chequeos retorna positivo.

Configuración

  • El valor de class debe de ser parallel.

  • Admite todos los tipos de recursos en el campo resources.

  • Es necesario emplear el campo contains definir las listas sobre los que realizará los chequeos.

  • Admite campos opcionales en opts.

Tabla 1. Campos opcionales de parallel
Opción Tipo de dato Explicación

reason

string

motivo que devolverá en caso de que resultado afirmativo

skiperrors

boolean

si una lista hija devuelve un error, continuará el chequeo.

first

boolean

devolverá la primera respuesta afirmativa que encuentre

Ejemplos de uso

Uso básico

Para crear una lista parallel es necesario definir el identificador, la clase parallel, los tipos de recurso que va a ofrecer (el componente soporta todos) y la opción estándar contains que contendrá las listas "hijas".

Para configurar adecuadamente una lista de tipo parallel, la única restricción existente es que todas las listas hijas deberán soportar al menos los recursos definidos en la lista padre o parallel.

Ejemplo de lista parallel
[
    {
        "id": "parallel1",
        "class": "parallel",
        "name": "example parallel",
        "resources": [
            "ip4"
        ],
        "contains": [
            {
                "id": "mock1",
                "class": "mock",
                "resources": [
                    "ip4",
                    "ip6"
                ],
                "source": "false",
                "opts": {
                    "reason": "mock1 response"
                }
            },
            {
                "id": "mock2",
                "class": "mock",
                "resources": [
                    "ip4"
                ],
                "source": "true",
                "opts": {
                    "reason": "mock2 response"
                }
            },
            {
                "id": "mock3",
                "class": "mock",
                "resources": [
                    "ip4"
                ],
                "source": "true",
                "opts": {
                    "reason": "mock3 response"
                }
            }
        ]
    }
]

En la configuración del ejemplo parallel1 se define una lista compuesta que soporta el tipo de recurso ip4 y contiene dos listas: la primera es la lista identificada por mock1 y soporta los tipos de recursos ip4 e ip6, y la segunda es la lista identificada por mock2 y que soporta el tipo de recurso ip4. Nótese que ambas listas hijas soportan el tipo de recurso ofrecido por la lista padre.

Para realizar el chequeo, la lista realizará en paralelo la ambas listas. En este ejemplo, siempre retornará la concatenación de las respuestas afirmativas (que podrá variar el orden):

$ xlistc 1.1.1.1
ip4,1.1.1.1: true,"mock3 response;mock2 response",0 (657.282µs)
Las listas de tipo parallel deberían usarse para chequeos múltiples que hagan uso de red o de operaciones en disco. Para chequeos locales en memoria, deberían usarse listas de tipo sequence ya que emplean menos recursos.

Uso avanzado

Además del uso por defecto, el componente ofrece soporte a las opciones de la tabla resumen Campos opcionales de parallel que pueden alterar su comportamiento.

Un modificador muy útil es el uso de first como puede verse en el siguiente ejemplo.

Ejemplo de lista parallel con modificador first
[
    {
        "id": "parallel2",
        "class": "parallel",
        "name": "example parallel",
        "resources": [
            "ip4"
        ],
        "contains": [
            {
                "id": "mock1",
                "class": "mock",
                "resources": [
                    "ip4",
                    "ip6"
                ],
                "source": "false",
                "opts": {
                    "reason": "mock1 response"
                }
            },
            {
                "id": "mock2",
                "class": "mock",
                "resources": [
                    "ip4"
                ],
                "source": "true",
                "opts": {
                    "reason": "mock2 response"
                }
            },
            {
                "id": "mock3",
                "class": "mock",
                "resources": [
                    "ip4"
                ],
                "source": "true",
                "opts": {
                    "reason": "mock3 response"
                }
            }
        ],
        "opts": {
            "first": true
        }
    }
]

Con esta lista, devolverá el primer resultado afirmativo, que podrá ser diferente en cada ocasión.

$ xlistc 1.1.1.1
ip4,1.1.1.1: true,"mock3 response",0 (596.715µs)
$ xlistc 1.1.1.1
ip4,1.1.1.1: true,"mock2 response",0 (587.02µs)
$ xlistc 1.1.1.1
ip4,1.1.1.1: true,"mock3 response",0 (702.055µs)
En general, si la latencia es importante y no es necesario chequear en todas las listas para calcular cualquier tipo de métrica, conviene usar parallel con el modificador first.

Como se ha indicado, la lista de tipo parallel chequea en todos los elementos que la componen, pero…​ ¿qué pasa si alguno de ellos retorna error?. Pues bien, el comportamiento por defecto es retornar el error. Si queremos que se ignore el error y se continúe chequeando en las demás listas, puede utilizarse la opción skiperrors. Esta opción ignorará cualquier error retornado en los chequeos.

Ejemplo de lista parallel con modificador skiperrors
[
    {
        "id": "parallel3",
        "class": "parallel",
        "resources": [
            "ip4"
        ],
        "contains": [
            {
                "id": "mock1",
                "class": "mock",
                "resources": [
                    "ip4",
                    "ip6"
                ],
                "source": "false",
                "opts": {
                    "reason": "mock1 response"
                }
            },
            {
                "id": "mock2",
                "class": "mock",
                "resources": [
                    "ip4"
                ],
                "source": "true",
                "opts": {
                    "reason": "mock2 response",
                    "fail": true
                }
            },
            {
                "id": "mock3",
                "class": "mock",
                "resources": [
                    "ip4"
                ],
                "source": "true",
                "opts": {
                    "reason": "mock3 response"
                }
            }
        ],
        "opts": {
            "skiperrors": true,
            "reason": "sequence3 response"
        }
    }
]
La opción skiperrors únicamente "enmascarará" los errores de chequeos, de esta forma la lista seguirá funcionando a pesar de posibles errores en alguna de sus listas hijas. Los pings tendrán el mismo comportamiento, es decir, que si existe un error en alguna de las listas hijas, el ping dará error. De este modo, se podrán detectar los errores y conocer del estado degradado del sistema.

La salida del Ejemplo de lista parallel con modificador skiperrors será la siguiente:

$ xlistc 1.1.1.1
ip4,1.1.1.1: true,"sequence3 response",0 (655.384µs)