Il sistema operativo OpenVOS fornisce una Application Programming Interface (API) di alto livello che nel complesso rende facile la programmazione del sistema. Ma a volte diventa troppo facile - perché una semplice chiamata di subroutine ad una routine s$... potrebbe nascondere molta complessità. Gli utenti a volte non si rendono conto che la semplice chiamata può comportare molto lavoro e potrebbe causare problemi al sistema e all'applicazione.
Questo è il secondo di una serie irregolare di post per richiamare la vostra attenzione sulle insidie che potreste evitare nei vostri progetti di applicazione.
I mali di list_messages per le code dei server
Il comando list_messages in OpenVOS è destinato ad essere utilizzato con le code che fanno parte del prodotto di protezione delle transazioni per OpenVOS. StrataDOC per OpenVOS mostrerà che questo comando "visualizza le informazioni sui messaggi in una data coda". Quindi quando le code iniziano a fare il backup in produzione, potreste essere tentati di usare questo comando per scoprire quanti messaggi ci sono in coda. L'opzione -totals_only appare proprio come quello che serve. Una volta capito come funziona questo comando, capirete perché non è una buona scelta.
Come funziona il comando list_messages
Il comando allega una porta al file e apre la porta come SERVER_TYPE (o RECV_ONLY_SRV_TYPE per una coda di server a senso unico), e la mette in modalità no_wait_mode. Se la coda è protetta dalla transazione, allora il comando avvia una transazione a priorità -1, il che significa che perderà sempre se c'è contesa, e quando finisce chiama s$abort_transaction.
Successivamente inizia dal primo record in coda e procede a chiamare s$read_msg e contare ogni record che è in grado di ricevere e poi conta e/o scarica il record sulla porta di uscita.
Per visualizzare le informazioni su ogni messaggio, deve cercare informazioni sul modulo e sul processo che ha originato il messaggio.
Infine, stampa i totali per i record che ha trovato nella coda.
Problemi con questo approccio
Il comando era destinato ai programmatori di sviluppo di applicazioni da usare per guardare i messaggi mentre i messaggi erano in coda per determinare se il messaggio era formattato correttamente e conteneva i campi appropriati, era in coda con la giusta priorità, se era stato ricevuto o meno da un server, ecc. Tuttavia, ci sono molte restrizioni e dati nascosti/mischiati quando il comando viene usato per altri scopi:
- Per ottenere informazioni sui messaggi in una coda, è necessario avervi accesso in esecuzione, lettura o scrittura. Se avete accesso in lettura o in esecuzione alla coda, potete ottenere informazioni solo sui vostri messaggi. Se avete accesso in scrittura, potete ottenere informazioni su tutti i messaggi.
- Se la coda è una coda di server, list_messages elenca solo i messaggi che non hanno ancora ricevuto risposta dal server. I messaggi a cui è stata data risposta ma che non sono stati ancora rimossi dalla coda da s$msg_receive_reply non sono elencati.
- La coda potrebbe essere piena (max_queue_depth) e non accettare più nuovi messaggi, ma i list_messages potrebbero mostrare zero messaggi nella coda se tutti i messaggi sono risposte non ricevute.
- Poiché il comando list_messages appare come server della coda mentre recupera i messaggi, potrebbe ingannare i client e altri processi di controllo sul numero di server che servono la coda.
- Il recupero delle informazioni del modulo e del processo sui processi dei richiedenti potrebbe richiedere transazioni di rete se i richiedenti si trovano su un modulo diverso.
- Ogni messaggio richiede un viaggio nel kernel per leggere il messaggio. Se il comando non viene eseguito dal modulo che possiede la coda, allora è necessaria una transazione di rete per leggere ogni messaggio.
- Anche se -totals_only è specificato, ogni messaggio deve essere letto per essere contato.
- Il valore visualizzato da -totals_only è SOLO per i messaggi che sono in coda per un server o che vengono elaborati da un server. Non vengono visualizzate informazioni sulle risposte non ricevute ai messaggi bidirezionali della coda del server che sono ancora in coda, rendendo fuorvianti i valori di -totals_only.
- I dati contenuti nei messaggi possono essere informazioni sensibili (ad es. numeri di conto della carta di credito).
Un metodo diverso
Nel 1990 è stata fornita una nuova API: s$get_server_queue_info. Dato il percorso di una coda, questa routine restituisce una struttura con
- Il tipo di server_queue (unidirezionale o bidirezionale)
- Il numero di messaggi
- Il numero di messaggi non impegnativi
- Il maggior numero di messaggi
- Il numero totale di messaggi che sono stati elaborati.
- Il numero massimo di messaggi configurati (max_queue_depth) per questa coda.
Ci sono molti vantaggi rispetto ai list_messages:
- Un viaggio nel kernel e/o attraverso la rete per recuperare le informazioni totali.
- Considerazione di tutti i tipi di messaggi, comprese le risposte non ancora ricevute.
- Nessuna interruzione della coda. L'intestazione della coda è bloccata per microsecondi, giusto il tempo necessario per ottenere un insieme coerente di cinque contatori dall'intestazione della coda.
- Le informazioni possono essere acquisite quando la coda viene aperta come richiedente.
controllo_queue_di_profondimento Comando
Molti anni fa ho scritto check_queue_depth, un comando che utilizza questa interfaccia e si può usare non solo per visualizzare queste informazioni per una o più code, ma anche per monitorare e avvertire quando vengono raggiunte le soglie.
check_queue_queue_depth code [-numero_di_avvertimento_percentuale] [-numero_di_intervallo]
[-notificare il nome_utente] [-brief] [-lungo].
[-ignore_invalido_tipo] [-syserr]
[-Esci_dopo_l'avviso]
Il codice sorgente del comando è disponibile sul sito FTP pubblico Stratus .
- Documentazione http://ftp.stratus.com/vos/perf/check_queue_depth.txt
- Codice sorgente http://ftp.stratus.com/vos/perf/check_queue_depth.pl1
Sentitevi liberi di usarlo, migliorarlo e/o incorporarlo nei vostri comandi di monitoraggio delle applicazioni.