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. Pero a veces, se vuelve demasiado fácil - porque una simple llamada de subrutina a una rutina s$... puede esconder mucha complejidad. Los usuarios a veces no se dan cuenta de que la simple llamada puede resultar en mucho trabajo y podría causar problemas para el sistema y la aplicación.
Este es el segundo de una serie irregular de posts para llamar su atención sobre los escollos que pueden evitar en sus diseños de aplicación.
Los males de list_messages para colas de servidores
El comando list_messages en OpenVOS está pensado para ser usado con colas que forman parte del producto de protección de transacciones para OpenVOS. StrataDOC para OpenVOS mostrará que este comando "muestra información sobre los mensajes de una cola determinada". Así que cuando las colas empiecen a retroceder en producción, podrías estar tentado de usar este comando para averiguar cuántos mensajes hay en la cola. La opción -totals_only se parece a lo que se necesita. Una vez que entiendas cómo funciona este comando, entenderás por qué no es una buena opción.
Cómo funciona el comando list_messages
El comando adjunta un puerto al archivo y lo abre como SERVER_TYPE (o RECV_ONLY_SRV_TYPE para una cola de servidores de una dirección), y lo pone en modo no_espera. Si la cola está protegida por una transacción, entonces el comando inicia una transacción con prioridad -1, lo que significa que siempre perderá si hay contención, y cuando termina llama a s$abort_transaction.
Luego comienza en el primer registro en la cola y procede a llamar a s$read_msg y cuenta cada registro que es capaz de recibir y luego cuenta y/o vuelca el registro al puerto de salida.
Para poder mostrar información sobre cada mensaje, tiene que buscar información sobre el módulo y el proceso que originó el mensaje.
Finalmente, imprime los totales de los registros que encontró en la cola.
Problemas con ese enfoque
El comando estaba destinado a que los programadores de desarrollo de aplicaciones lo utilizaran para mirar los mensajes mientras éstos estaban en la cola para determinar si el mensaje tenía el formato adecuado y contenía los campos apropiados, si estaba en la cola con la prioridad adecuada, si había sido recibido o no por un servidor, etc. Sin embargo, hay muchas restricciones y datos ocultos o engañosos cuando el comando se utiliza para otros fines:
- Para obtener información sobre los mensajes en una cola, debes tener acceso de ejecución, lectura o escritura. Si tienes acceso de ejecución o de lectura a la cola, sólo puedes obtener información sobre tus mensajes. Si tienes acceso de escritura, puedes obtener información sobre todos los mensajes.
- Si la cola es una cola del servidor, list_messages sólo lista los mensajes que aún no han sido contestados por el servidor. 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 listan.
- 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.
- Debido a que el comando list_messages aparece como un servidor de la cola mientras está recuperando mensajes, podría engañar a los clientes y a otros procesos de control en cuanto al número de servidores que sirven a la cola.
- La recuperación de información de módulos y procesos sobre los procesos de los solicitantes podría requerir transacciones en red si los solicitantes están en un módulo diferente.
- Cada mensaje requiere un viaje al núcleo para leer el mensaje. Si el comando no se ejecuta desde el módulo que posee la cola, entonces se requiere una transacción de red para leer cada mensaje.
- Incluso si se especifica -totals_only, cada mensaje debe ser leído para ser contado.
- El valor mostrado por -totals_only es SÓLO para los mensajes que están en cola para un servidor o están siendo procesados por un servidor. No se muestra información sobre las respuestas no recibidas a los mensajes de la cola del servidor de dos vías que aún están en la cola, lo que hace que los valores de -totals_only sean engañosos.
- Los datos que figuran en los mensajes pueden ser información confidencial (por ejemplo, los números de cuenta de las tarjetas de crédito).
Un método diferente
En 1990, se proporcionó una nueva API: s$get_server_queue_info. Dada la ruta de una cola, esta rutina devuelve una estructura con
- El tipo de cola del servidor (de una o dos vías)
- 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 han sido procesados.
- El número máximo configurado de mensajes (max_queue_depth) para esta cola.
Esta rutina tiene muchas ventajas sobre los mensajes de la lista:
- Un viaje al núcleo y/o a través de la red para recuperar la información de los totales.
- Consideración de todo tipo de mensajes, incluidas las respuestas aún no recibidas.
- No hay interrupción de la cola. El encabezado de la cola se bloquea por microsegundos, lo suficiente para obtener un conjunto consistente de cinco contadores del encabezado de la cola.
- La información se puede adquirir 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 ser utilizado no sólo para mostrar esta información para una o más colas, sino que también permite monitorear y advertir cuando se alcanzan los umbrales.
colas de profundidad de la cola de espera [-número de aviso] [-número de intervalo]
[-notificar nombre_de_usuario] [-breve] [-largo]
[-ignore_invalid_type] [-syserr]
[-exit_after_warning]
El código fuente del comando está disponible en el sitio FTP público Stratus .
- Documentación http://ftp.stratus.com/vos/perf/check_queue_depth.txt
- Código fuente http://ftp.stratus.com/vos/perf/check_queue_depth.pl1
Siéntase libre de usarlo, mejorarlo y/o incrustarlo en sus propios comandos de monitoreo de aplicaciones.