O sistema operacional OpenVOS fornece uma interface de programação de aplicativos (API) de alto nível que, em geral, facilita a programação do sistema. Mas, às vezes, torna-se fácil demais, pois uma simples chamada de sub-rotina para uma rotina s$... pode esconder muita complexidade. Os usuários às vezes não percebem que a chamada simples pode resultar em muito trabalho e causar problemas para o sistema e o aplicativo.
Esta é a segunda de uma série irregular de publicações para chamar sua atenção para as armadilhas que você pode evitar em seus projetos de aplicativos.
Os males do list_messages para filas de servidor
O comando list_messages no OpenVOS destina-se a ser usado com filas que fazem parte do produto de proteção de transações para OpenVOS. O StrataDOC para OpenVOS mostra que esse comando “exibe informações sobre as mensagens em uma determinada fila”. Portanto, quando as filas começarem a acumular-se na produção, você pode ficar tentado a usar esse comando para descobrir quantas mensagens estão na fila. A opção –totals_only parece ser exatamente o que você precisa. Depois de entender como esse comando funciona, você entenderá por que essa não é uma boa escolha.
Como funciona o comando list_messages
O comando anexa uma porta ao arquivo e abre a porta como SERVER_TYPE (ou RECV_ONLY_SRV_TYPE para uma fila de servidor unidirecional) e a coloca em no_wait_mode. Se a fila for protegida por transação, o comando inicia uma transação com prioridade -1, o que significa que ela sempre perderá se houver conflito e, quando terminar, chamará s$abort_transaction.
Em seguida, ele começa no primeiro registro da fila e prossegue chamando s$read_msg e contando todos os registros que consegue receber e, então, conta e/ou descarrega o registro na porta de saída.
Para exibir informações sobre cada mensagem, é necessário procurar informações sobre o módulo e o processo que originaram a mensagem.
Por fim, ele imprime os totais dos registros encontrados na fila.
Problemas com essa abordagem
O comando foi criado para que os programadores de desenvolvimento de aplicativos pudessem visualizar as mensagens enquanto elas estavam na fila, a fim de determinar se estavam formatadas corretamente e continham os campos adequados, se estavam na fila com a prioridade correta, se haviam sido recebidas por um servidor, etc. No entanto, existem muitas restrições e dados ocultos/enganosos quando o comando é usado para outros fins:
- Para obter informações sobre as mensagens em uma fila, você deve ter acesso de execução, leitura ou gravação a ela. Se você tiver acesso de execução ou leitura à fila, poderá obter informações apenas sobre suas mensagens. Se você tiver acesso de gravação, poderá obter informações sobre todas as mensagens.
- Se a fila for uma fila do servidor, list_messages lista apenas as mensagens que ainda não foram respondidas pelo servidor. As mensagens que foram respondidas, mas ainda não foram removidas da fila pelo s$msg_receive_reply, não são listadas.
- A fila pode estar cheia (max_queue_depth) e não aceitar mais novas mensagens, mas list_messages pode mostrar zero mensagens na fila se todas as mensagens forem respostas não recebidas.
- Como o comando list_messages aparece como um servidor da fila enquanto recupera mensagens, ele pode enganar os clientes e outros processos de controle quanto ao número de servidores que atendem à fila.
- A recuperação de informações sobre o módulo e o processo dos solicitantes pode exigir transações de rede se os solicitantes estiverem em um módulo diferente.
- Cada mensagem requer uma viagem ao kernel para ser lida. Se o comando não for executado a partir do módulo proprietário da fila, será necessária uma transação de rede para ler cada mensagem.
- Mesmo que –totals_only seja especificado, cada mensagem deve ser lida para ser contada.
- O valor exibido por –totals_only é APENAS para mensagens que estão na fila de um servidor ou sendo processadas por um servidor. Nenhuma informação é exibida sobre respostas não recebidas para mensagens bidirecionais na fila do servidor que ainda estão na fila, tornando os valores –totals_only enganosos.
- Os dados nas mensagens podem ser informações confidenciais (por exemplo, números de contas de cartão de crédito).
Um método diferente
Em 1990, foi fornecida uma nova API: s$get_server_queue_info. Dado o nome do caminho de uma fila, esta rotina retorna uma estrutura com
- O tipo de fila do servidor (unidirecional ou bidirecional)
- O número de mensagens
- O número de mensagens não ocupadas
- O maior número de mensagens
- O número total de mensagens que foram processadas.
- O número máximo de mensagens configurado (max_queue_depth) para esta fila.
Há muitas vantagens nessa rotina em relação ao list_messages:
- Uma viagem ao kernel e/ou pela rede para recuperar informações totais.
- Consideração de todos os tipos de mensagens, incluindo respostas ainda não recebidas.
- Sem interrupção da fila. O cabeçalho da fila fica bloqueado por microssegundos, apenas o tempo suficiente para obter um conjunto consistente de cinco contadores do cabeçalho da fila.
- As informações podem ser obtidas quando a fila é aberta como solicitante.
Comando check_queue_depth
Há muitos anos, escrevi o check_queue_depth, um comando que usa essa interface e que você pode usar não apenas para exibir essas informações para uma ou mais filas, mas também para monitorar e alertar quando os limites forem atingidos.
check_queue_depth filas [-percentagem_de_aviso número] [-intervalo número] [nome_do_usuário] [-breve] [-longo] [-ignorar_tipo_inválido] [-syserr] [-sair_após_aviso]
O código-fonte do comando está disponível no site FTP público da Stratus.
- Documentação http://ftp.stratus.com/vos/perf/check_queue_depth.txt
- Código-fon tehttp://ftp.stratus.com/vos/perf/check_queue_depth.pl1
Sinta-se à vontade para usá-lo, aprimorá-lo e/ou incorporá-lo em seus próprios comandos de monitoramento de aplicativos.