Le système d'exploitation OpenVOS fournit une interface de programmation d'applications (API) de haut niveau qui, dans l'ensemble, facilite la programmation du système. Mais parfois, cela devient trop facile, car un simple appel de sous-programme à une routine s$… peut cacher une grande complexité. Les utilisateurs ne se rendent parfois pas compte que cet appel simple peut entraîner beaucoup de travail et causer des problèmes au système et à l'application.
Il s'agit du deuxième article d'une série irrégulière visant à attirer votre attention sur les pièges à éviter dans la conception de vos applications.
Les inconvénients de list_messages pour les files d'attente du serveur
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 indique que cette commande « affiche des informations sur les messages dans une file d'attente donnée ». Ainsi, lorsque les files d'attente commencent à s'accumuler en production, vous pourriez être tenté d'utiliser cette commande pour savoir combien de messages se trouvent dans la file d'attente. L'option –totals_only semble être exactement ce qu'il vous faut. Une fois que vous aurez compris le fonctionnement de cette commande, vous comprendrez pourquoi ce n'est pas un bon choix.
Fonctionnement de la commande list_messages
La commande associe 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 unidirectionnelle), puis le place en mode no_wait_mode. Si la file d'attente est protégée par transaction, la commande démarre une transaction avec la priorité -1, ce qui signifie qu'elle sera toujours perdue en cas de conflit, et lorsqu'elle se termine, elle appelle s$abort_transaction.
Ensuite, il commence par le premier enregistrement dans la file d'attente et appelle s$read_msg pour compter tous les enregistrements qu'il peut recevoir, puis compte et/ou transfère l'enregistrement vers le port de sortie.
Afin d'afficher les informations relatives à chaque message, il doit rechercher les informations concernant le module et le processus à l'origine du message.
Enfin, il imprime les totaux pour les enregistrements qu'il a trouvés dans la file d'attente.
Problèmes liés à cette approche
La commande était destinée aux programmeurs de développement d'applications afin qu'ils puissent consulter les messages pendant qu'ils se trouvaient dans la file d'attente afin de déterminer si le message était correctement formaté et contenait les champs appropriés, s'il était mis en file d'attente avec la bonne priorité, s'il avait été reçu ou non par un serveur, etc. Cependant, il existe de nombreuses restrictions et données cachées/trompeuses lorsque la commande est utilisée à d'autres fins :
- Pour obtenir des informations sur les messages d'une file d'attente, vous devez disposer d'un accès en exécution, en lecture ou en écriture à celle-ci. Si vous disposez d'un accès en exécution ou en lecture à la file d'attente, vous pouvez obtenir des informations uniquement sur vos messages. Si vous disposez d'un accès en écriture, vous pouvez obtenir des informations sur tous les messages.
- Si la file d'attente est une file d'attente serveur, list_messages répertorie uniquement les messages auxquels le serveur n'a pas encore répondu. Les messages auxquels une réponse a été apportée, mais qui n'ont pas encore été supprimés de la file d'attente par s$msg_receive_reply, ne sont pas répertoriés.
- La file d'attente peut être pleine (max_queue_depth) et ne plus accepter de nouveaux messages, mais list_messages peut afficher zéro message dans la file d'attente si tous les messages sont des réponses non reçues.
- Étant donné que la commande list_messages apparaît comme un serveur de la file d'attente pendant qu'elle récupère les messages, elle peut induire en erreur les clients et autres processus de contrôle quant au nombre de serveurs desservant la file d'attente.
- La récupération des informations relatives au module et au processus concernant les processus demandeurs peut nécessiter des transactions réseau si les demandeurs se trouvent sur un module différent.
- Chaque message nécessite un accès au noyau pour être lu. Si la commande n'est pas exécutée à partir du module propriétaire de la file d'attente, une transaction réseau est nécessaire pour lire chaque message.
- Même si –totals_only est spécifié, chaque message doit être lu pour être compté.
- La valeur affichée par –totals_only concerne UNIQUEMENT les messages qui sont soit mis en file d'attente pour un serveur, soit traités par un serveur. Aucune information n'est affichée concernant les réponses non reçues aux messages bidirectionnels en file d'attente qui sont toujours dans la file d'attente, ce qui rend les valeurs –totals_only trompeuses.
- Les données contenues dans les messages peuvent être des informations sensibles (par exemple, des numéros 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 chemin d'accès d'une file d'attente, cette routine renvoie une structure avec
- Le type de file d'attente du serveur (unidirectionnelle ou bidirectionnelle)
- 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.
- Nombre maximal de messages configuré (max_queue_depth) pour cette file d'attente.
Cette routine présente de nombreux avantages par rapport à list_messages :
- Un seul accès au noyau et/ou au réseau pour récupérer les informations globales.
- Prise en compte de tous les types 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 le temps nécessaire 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 plusieurs années, j'ai écrit check_queue_depth, une commande qui utilise cette interface et qui vous permet non seulement d'afficher ces informations pour une ou plusieurs files d'attente, mais aussi de surveiller et d'alerter lorsque les seuils sont atteints.
check_queue_depth queues [-warn_percent number] [-interval number] [ -notify user_name] [-brief] [-long] [ -ignore_invalid_type] [-syserr] [ -exit_after_warning]
Le code source de la commande est disponible sur le site FTP Stratus .
N'hésitez pas à l'utiliser, à l'améliorer et/ou à l'intégrer dans vos propres commandes de surveillance d'applications.