Rendre les choses trop faciles - Partie 2

Le système d'exploitation OpenVOS fournit une interface de programmation d'application (API) de haut niveau qui, dans l'ensemble, facilite la programmation du système. Mais parfois, cela devient trop facile - parce qu'un simple appel de sous-programme à une routine s$... peut cacher beaucoup de complexité. Les utilisateurs ne se rendent pas toujours compte que ce simple appel peut entraîner beaucoup de travail et peut causer des problèmes au système et à l'application.

Il s'agit du deuxième d'une série de messages irréguliers destinés à attirer votre attention sur les pièges que vous pouvez éviter dans vos modèles de demande.

Les maux des list_messages pour les files d'attente des serveurs

La commande list_messages dans OpenVOS est destinée à être utilisée avec les files d'attente qui font partie du produit de protection des transactions pour OpenVOS. StrataDOC pour OpenVOS montrera que cette commande "affiche des informations sur les messages dans une file d'attente donnée". Ainsi, lorsque les files d'attente commencent à se reconstituer en production, vous pourriez être tenté d'utiliser cette commande pour savoir combien de messages sont dans la file d'attente. L'option -totals_only ressemble exactement à ce qu'il faut. Une fois que vous aurez compris comment fonctionne cette commande, vous comprendrez pourquoi ce n'est pas un bon choix.

Fonctionnement de la commande list_messages

La commande attache un port au fichier et ouvre le port en tant que SERVER_TYPE (ou RECV_ONLY_SRV_TYPE pour une file d'attente de serveur à sens unique), et le met en mode no_wait_mode. Si la file d'attente est protégée contre les transactions, la commande lance une transaction de priorité -1, ce qui signifie qu'elle sera toujours perdante en cas de conflit, et lorsqu'elle se termine, elle appelle s$abort_transaction.

Ensuite, il commence au premier enregistrement de la file d'attente et appelle s$read_msg pour compter chaque enregistrement qu'il peut recevoir, puis il compte et/ou décharge l'enregistrement vers le port de sortie.

Pour afficher des informations sur chaque message, il doit rechercher des informations sur le module et le processus à l'origine du message.

Enfin, il imprime les totaux des documents qu'il a trouvés dans la file d'attente.

Problèmes liés à cette approche

Cette commande était destinée aux programmeurs de développement d'applications pour qu'ils examinent les messages pendant qu'ils sont dans la file d'attente afin de déterminer si le message est correctement formaté et contient les bons champs, s'il est mis en file d'attente avec la bonne priorité, s'il a été reçu ou non par un serveur, etc. Cependant, il existe de nombreuses restrictions et des données cachées/mal interprétées lorsque la commande est utilisée à d'autres fins :

• Pour obtenir des informations sur les messages dans une file d'attente, vous devez y avoir accès en exécution, en lecture ou en écriture. Si vous avez un accès en exécution ou en lecture à la file d'attente, vous pouvez obtenir des informations sur vos messages uniquement. Si vous avez un accès en écriture, vous pouvez obtenir des informations sur tous les messages.
• S'il s'agit d'une file d'attente de serveur, list_messages ne répertorie que les messages auxquels le serveur n'a pas encore répondu. Les messages qui ont reçu une réponse mais qui n'ont pas encore été retirés de la file d'attente par s$msg_receive_reply ne sont pas listés.
• La file d'attente pourrait être pleine (max_queue_depth) et ne plus accepter de nouveaux messages, mais list_messages pourrait afficher zéro message dans la file si tous les messages sont des réponses non reçues.
• Comme la commande list_messages apparaît comme un serveur de la file d'attente pendant qu'elle récupère les messages, elle peut tromper les clients et les autres processus de contrôle quant au nombre de serveurs desservant la file d'attente.
• La récupération des informations sur les modules et les processus des demandeurs peut nécessiter des transactions sur le réseau si les demandeurs sont sur un module différent.
• Chaque message nécessite un voyage dans le noyau pour le lire. Si la commande n'est pas exécutée à partir du module propriétaire de la file d'attente, une transaction réseau est alors nécessaire pour lire chaque message.
• Même si le paramètre -totals_only est spécifié, chaque message doit être lu pour être compté.
• La valeur affichée par -totals_only est UNIQUEMENT pour les messages qui sont soit mis en file d'attente pour un serveur, soit en cours de traitement par un serveur. Aucune information n'est affichée sur les réponses non reçues aux messages bidirectionnels du serveur qui sont encore dans la file d'attente, ce qui rend les valeurs de -totals_only trompeuses.
• Les données contenues dans les messages peuvent être des informations sensibles (par exemple, les numéros de compte de carte de crédit).

Une méthode différente

En 1990, une nouvelle API a été fournie : s$get_server_queue_info. Étant donné le nom du chemin d'une file d'attente, cette routine renvoie une structure avec

• Le type de file d'attente du serveur (à sens unique ou à double sens)
• Le nombre de messages
• Le nombre de messages non occupés
• Le plus grand nombre de messages
• Le nombre total de messages qui ont été traités.
• Le nombre maximum de messages configuré (max_queue_depth) pour cette file d'attente.

Cette routine présente de nombreux avantages par rapport aux list_messages :

• Un voyage dans le noyau et/ou à travers le réseau pour récupérer les informations de totaux.
• Prise en compte de toutes sortes de messages, y compris les réponses non encore reçues.
• Aucune perturbation de la file d'attente. L'en-tête de la file d'attente est verrouillé pendant quelques microsecondes, juste assez longtemps pour obtenir un ensemble cohérent de cinq compteurs à partir de l'en-tête de la file d'attente.
• Les informations peuvent être obtenues lorsque la file d'attente est ouverte en tant que demandeur.

commande check_queue_depth

Il y a de nombreuses années, j'ai écrit check_queue_depth, une commande qui utilise cette interface et qui permet non seulement d'afficher ces informations pour une ou plusieurs files d'attente, mais aussi de surveiller et d'avertir lorsque les seuils sont atteints.

files d'attente de vérification [-nombre de pour cent d'avertissements] [-nombre d'intervalles]
                         [-notifier nom_utilisateur] [-briefing] [-long]
                         [-ignore_invalid_type] [-syserr]
                         [-sortie_après_avertissement]

Le code source de la commande est disponible sur le site FTP public Stratus .

• Documentation http://ftp.stratus.com/vos/perf/check_queue_depth.txt
• Code source http://ftp.stratus.com/vos/perf/check_queue_depth.pl1

N'hésitez pas à l'utiliser, à l'améliorer et/ou à l'intégrer dans vos propres commandes de surveillance des applications.