O Sistema Operacional OpenVOS fornece uma Interface de Programação de Aplicação (API) de alto nível que, de modo geral, facilita a programação do sistema. Mas às vezes, torna-se muito fácil - porque uma simples chamada de sub-rotina para uma rotina s$... pode esconder muita complexidade. Os usuários às vezes não percebem que a simples chamada pode resultar em muito trabalho e pode causar problemas para o sistema e para a aplicação.
Este é o segundo de uma série irregular de postos para chamar sua atenção para as armadilhas que você pode evitar em seus projetos de aplicação.
Os males da lista_mensagens para filas de servidores
O comando list_messages na OpenVOS destina-se a ser usado com filas de espera que fazem parte do produto de proteção de transações da OpenVOS. StrataDOC para OpenVOS mostrará que este comando "exibe informações sobre as mensagens em uma determinada fila". Assim, quando as filas começam a fazer backup em produção, você pode ser tentado a usar este comando para descobrir quantas mensagens estão na fila. A opção -totals_only se parece exatamente com o que é necessário. Assim que você entender como este comando funciona, você entenderá porque esta não é uma boa escolha.
Como funciona o comando list_messages
O comando anexa uma porta ao arquivo e abre a porta como um SERVER_TYPE (ou RECV_ONLY_SRV_TYPE para uma fila de servidor unidirecional), e a coloca em no_wait_mode. Se a fila estiver protegida por transação, então o comando inicia uma transação na prioridade -1, o que significa que sempre perderá se houver controvérsia, e quando termina, chama s$abort_transaction.
Em seguida, começa no primeiro registro em fila e passa a chamar s$read_msg e conta todos os registros que pode receber e depois conta e/ou descarta o registro para a porta de saída.
A fim de exibir informações sobre cada mensagem, é necessário procurar informações sobre o módulo e processo que originou a mensagem.
Finalmente, ele imprime totais para os registros que encontrou na fila.
Problemas com essa abordagem
O comando foi destinado aos programadores de desenvolvimento de aplicações para que utilizassem as mensagens enquanto as mensagens estivessem na fila para determinar se a mensagem estava formatada corretamente e continha os campos apropriados, se estava na fila com a prioridade correta, se tinha sido recebida ou não por um servidor, etc. No entanto, há muitas restrições e dados ocultos/dados enganosos quando o comando é usado para outros fins:
- Para obter informações sobre mensagens em uma fila, você deve ter acesso às mesmas, ler ou escrever. Se você tiver acesso de execução ou leitura à fila, você pode obter informações apenas sobre suas mensagens. Se você tiver acesso por escrito, você pode obter informações sobre todas as mensagens.
- Se a fila for uma fila do servidor, list_messages lista somente aquelas mensagens que ainda não foram respondidas pelo servidor. As mensagens que foram respondidas mas ainda não foram removidas da fila por s$msg_receiver_reply não são listadas.
- A fila pode estar cheia (max_queue_depth) e não aceitar mais mensagens novas, mas as mensagens da lista podem mostrar zero mensagens na fila se todas as mensagens não forem recebidas.
- Como o comando list_messages aparece como um servidor da fila enquanto está recuperando mensagens, ele pode enganar os clientes e outros processos de controle quanto ao número de servidores que servem a fila.
- A recuperação de informações do módulo e do processo sobre os processos do requerente pode exigir transações em rede se os requerentes estiverem em um módulo diferente.
- Cada mensagem requer uma viagem até o núcleo para ler a mensagem. Se o comando não for executado a partir do módulo que possui a fila, então é 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 enfileiradas para um servidor ou que estão sendo processadas por um servidor. Nenhuma informação é exibida sobre respostas não recebidas a mensagens em fila de dois sentidos do servidor que ainda estão na fila, fazendo com que os valores -totals_only sejam enganosos.
- Os dados nas mensagens podem ser informações sensíveis (por exemplo, números de conta de cartão de crédito).
Um método diferente
Em 1990, uma nova API foi fornecida: s$get_server_queue_info. Dado o caminho de uma fila, esta rotina retorna uma estrutura com
- O tipo de server_queue (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 configurado de mensagens (max_queue_depth) para esta fila.
Há muitas vantagens nesta rotina sobre as mensagens_de_lista:
- Uma viagem ao núcleo e/ou através da rede para recuperar as 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 é bloqueado por microssegundos, apenas o tempo suficiente para obter um conjunto consistente de cinco contadores a partir do cabeçalho da fila.
- As informações podem ser adquiridas quando a fila é aberta como requisitante.
check_queue_depth Command
Há muitos anos eu escrevi check_queue_depth, um comando que usa esta interface e você pode usá-la para não apenas exibir estas informações para uma ou mais filas, mas também permite o monitoramento e aviso quando os limites são atingidos.
check_queue_queue_depth queues [-warn_percent number] [-interval number] [-interval number
[-notificar nome_do_usuário] [-brief] [-long] [-long] [-nome_do_usuário
[-ignore_invalid_type] [-syserr]
[-exit_after_warning]
O código fonte para o comando está disponível no site FTP público Stratus.
- Documentação http://ftp.stratus.com/vos/perf/check_queue_depth.txt
- Código fonte http://ftp.stratus.com/vos/perf/check_queue_depth.pl1
Sinta-se livre para usá-lo, melhorá-lo e/ou incorporá-lo em seus próprios comandos de monitoramento de aplicação.
Empresa