Sous-système de traitement des événements ordonnés
Le sous-système de traitement des événements ordonnés permet de s'assurer que l'ordre approprié est conservé lors du traitement des événements, comme une liaison ou une annulation de liaison. Le sous-système fournit une façade à un pool de threads et dispose des mêmes paramètres personnalisables que d'autres outils, comme le sous-système de traitement des événements. A ce stade, ce pool ne gère que les évaluations de présence qui sont déclenchées par des événements de liaison ou d'annulation de liaison.
Les paramètres décrits dans le tableau suivant sont destinés à limiter l'encombrement mémoire lorsque le système est surchargé. En cas de dépassement des valeurs définies, les objets commenceront à basculer l'état isReporting sur false, quel que soit l'état de l'appareil (pour plus d'informations, consultez le tableau ci-dessous).
|
Paramètre
|
Description
|
|
Nbre min. de threads alloués au pool de traitement des événements
|
Nombre minimal de threads alloués. Ce paramètre correspond également à la taille initiale du pool de threads. Si les threads devient inactifs, ils sont nettoyés pour que le nombre de ressources corresponde au nombre défini.
|
|
Nbre max. de threads alloués au pool de traitement des événements
|
Nombre maximal de threads à allouer. En cas de charge élevée, le pool sera redimensionné de façon dynamique jusqu'au nombre maximal défini.
|
|
Nombre max. d'entrées dans la file d'attente avant l'ajout d'un nouveau thread de travail
|
Nombre maximal de tâches (évaluations de présence) prêtes à être traitées immédiatement avant que le pool ne soit redimensionné.
|
|
Nbre max. de tâches bloquées pour garantir l'exécution dans l'ordre
|
Nombre maximal de tâches (évaluations de présence) pouvant être mises en file d'attente, en attendant qu'une évaluation précédente soit effectuée sur le même appareil.
|
Notez que les trois premiers paramètres sont partagés par le sous-système de traitement des événements.
Le sous-système se distingue par deux motifs de blocage d'une tâche :
• Le nombre de threads de travail disponibles est insuffisant pour traiter toutes les évaluations en temps réel lorsqu'elles surviennent. Le paramètre "Nombre max. d'entrées dans la file d'attente avant l'ajout d'un nouveau thread de travail" vous permet de limiter la probabilité que cette situation se produise.
• Les mêmes appareils peuvent également clignoter, nécessitant de nombreuses évaluations. Si une évaluation risque de ne pas être terminée avant le prochain événement de liaison/d'annulation de liaison, l'évaluation suivante sera mise en attente le temps que la première évaluation s'achève. Le paramètre "Nbre max. de tâches bloquées pour garantir l'exécution dans l'ordre" détermine le nombre d'évaluations pouvant être interrompues de cette façon.
Si la limite du paramètre "Nombre max. d'entrées dans la file d'attente avant l'ajout d'un nouveau thread de travail" est dépassée, une tentative de redimensionnement du pool de threads sera effectuée. Si le redimensionnement réussit, le nouveau thread de travail viendra en soutien pour traiter la file d'attente d'évaluations.
Si le redimensionnement est impossible en raison de la limite du paramètre "Nbre max. de threads" ou lorsque la limite du paramètre "Nbre max. de tâches bloquées pour garantir l'exécution dans l'ordre" est dépassée, le pool de threads refusera l'évaluation. En cas d'évaluation refusée, l'appareil est immédiatement réputé comme n'émettant pas d'informations de reporting, et ce, sans qu'aucune opération de traitement supplémentaire ne soit effectuée.
Dans les environnements haute disponibilité, la propriété isReporting peut ne pas se comporter comme prévu, car dans le contexte haute disponibilité, les requêtes AlwaysON sont routées à tour de rôle par le serveur de connexion. Par conséquent, les événements BIND/UNBIND seront exécutés par différents noeuds ou files d'attente.