El sistema operativo OpenVOS proporciona una interfaz de programación de aplicaciones (API) de alto nivel que, en general, facilita la programación del sistema. Sin embargo, en ocasiones resulta demasiado fácil, ya que una simple llamada a una subrutina s$... puede ocultar una gran complejidad. Los usuarios a veces no se dan cuenta de que una simple llamada puede suponer mucho trabajo y causar problemas al sistema y a la aplicación.
Esta es la segunda entrega de una serie irregular de publicaciones destinadas a llamar su atención sobre los errores que puede evitar en el diseño de sus aplicaciones.
Los inconvenientes de list_messages para las colas del servidor
El comando list_messages de OpenVOS está diseñado para utilizarse con colas que forman parte del producto de protección de transacciones para OpenVOS. StrataDOC para OpenVOS muestra que este comando «muestra información sobre los mensajes de una cola determinada». Por lo tanto, cuando las colas comienzan a acumularse en producción, es posible que se sienta tentado a utilizar este comando para averiguar cuántos mensajes hay en la cola. La opción –totals_only parece justo lo que se necesita. Una vez que comprenda cómo funciona este comando, entenderá por qué no es una buena opción.
Cómo funciona el comando list_messages
El comando adjunta un puerto al archivo y abre el puerto como SERVER_TYPE (o RECV_ONLY_SRV_TYPE para una cola de servidor unidireccional), y lo coloca en modo no_wait_mode. Si la cola está protegida por transacciones, el comando inicia una transacción con prioridad -1, lo que significa que siempre perderá si hay conflicto, y cuando termina llama a s$abort_transaction.
A continuación, comienza por el primer registro de la cola y procede a llamar a s$read_msg y a contar todos los registros que puede recibir, y luego cuenta y/o descarga el registro al puerto de salida.
Para mostrar información sobre cada mensaje, es necesario buscar información sobre el módulo y el proceso que originó el mensaje.
Por último, imprime los totales de los registros que ha encontrado en la cola.
Problemas con ese enfoque
El comando estaba destinado a los programadores de desarrollo de aplicaciones para que pudieran examinar los mensajes mientras estos se encontraban en la cola y determinar si estaban formateados correctamente y contenían los campos adecuados, si se habían puesto en cola con la prioridad correcta, si habían sido recibidos por un servidor, etc. Sin embargo, existen muchas restricciones y datos ocultos o engañosos cuando el comando se utiliza para otros fines:
- Para obtener información sobre los mensajes de una cola, debe tener acceso de ejecución, lectura o escritura a la misma. Si tiene acceso de ejecución o lectura a la cola, solo podrá obtener información sobre sus mensajes. Si tiene acceso de escritura, podrá obtener información sobre todos los mensajes.
- Si la cola es una cola de servidor, list_messages solo muestra los mensajes a los que el servidor aún no ha respondido. Los mensajes a los que se ha respondido pero que aún no han sido eliminados de la cola por s$msg_receive_reply no se muestran.
- La cola podría estar llena (max_queue_depth) y no aceptar más mensajes nuevos, pero list_messages podría mostrar cero mensajes en la cola si todos los mensajes son respuestas no recibidas.
- Dado que el comando list_messages aparece como un servidor de la cola mientras recupera mensajes, puede confundir a los clientes y otros procesos de control en cuanto al número de servidores que prestan servicio a la cola.
- La recuperación de información sobre el módulo y el proceso de los solicitantes puede requerir transacciones de red si los solicitantes se encuentran en un módulo diferente.
- Cada mensaje requiere un viaje al núcleo para leerlo. Si el comando no se ejecuta desde el módulo propietario de la cola, se requiere una transacción de red para leer cada mensaje.
- Incluso si se especifica –totals_only, cada mensaje debe leerse para ser contado.
- El valor mostrado por –totals_only es SOLO para mensajes que están en cola para un servidor o que están siendo procesados por un servidor. No se muestra información sobre respuestas no recibidas a mensajes de cola de servidor bidireccionales que aún se encuentran en la cola, lo que hace que los valores de –totals_only sean engañosos.
- Los datos contenidos en los mensajes pueden ser información confidencial (por ejemplo, números de cuentas de tarjetas de crédito).
Un método diferente
En 1990, se proporcionó una nueva API: s$get_server_queue_info. Dada la ruta de acceso de una cola, esta rutina devuelve una estructura con
- El tipo de cola del servidor (unidireccional o bidireccional)
- El número de mensajes
- El número de mensajes no ocupados
- El mayor número de mensajes
- El número total de mensajes que se han procesado.
- El número máximo de mensajes configurado (max_queue_depth) para esta cola.
Esta rutina tiene muchas ventajas con respecto a list_messages:
- Un viaje al núcleo y/o a través de la red para recuperar la información total.
- Consideración de todo tipo de mensajes, incluidas las respuestas aún no recibidas.
- No se interrumpe la cola. El encabezado de la cola se bloquea durante microsegundos, el tiempo justo para obtener un conjunto coherente de cinco contadores del encabezado de la cola.
- La información se puede obtener cuando se abre la cola como solicitante.
Comando check_queue_depth
Hace muchos años escribí check_queue_depth, un comando que utiliza esta interfaz y que puede utilizarse no solo para mostrar esta información para una o varias colas, sino también para supervisar y avisar cuando se alcanzan los umbrales.
check_queue_depth colas [-warn_percent número] [-interval número] [ -notify nombre_usuario] [-brief] [-long] [ -ignore_invalid_type] [-syserr] [ -exit_after_warning]
El código fuente del comando está disponible en el sitio FTP Stratus .
Siéntete libre de utilizarlo, mejorarlo y/o integrarlo en tus propios comandos de supervisión de aplicaciones.