La presente documentazione ha lo scopo di dare le principali indicazioni su come vadano gestiti i principali malfunzionamenti del server (HighWay/eXtraWay) in particolare quando essi mostrino di non rispondere più alle sollecitazioni dei client.
Dal momento che le casistiche possono essere particolarmente varie questo documento non può che dare le principali linee guida. Al lettore il compito di comprendere quali indicazioni applicare sulla base dei sintomi rilevati.
Iniziamo quindi a compiere un necessario distinguo: il problema che si rileva può aver luogo dopo aver effettuato un'interruzione dei servizi esistenti ma può anche presentarsi al primo avvio (in assoluto o il primo dopo un reboot della macchina). Va da se che verranno indicate verifiche da compiere che hanno senso solo prima della riesecuzione dei servizi.
Il documento ha l'intenzione di riferirsi ad entrambe i tipi di installazioni (Win32 e Unix). La dove venissero date indicazioni dipendenti dalla piattaforma ciò verrà indicato esplicitamente. Parimenti le principali indicazioni sono riferite al server eXtraWay. Il server HighWay non ha significative differenze, qualora esse dovessero presentarsi verranno evidenziate.
Partiamo quindi dall'iportesi che il server sia in esecuzione e che una o più istanze di esso non siano disponibili, ovvero non rispondano come richiesto. In condizioni normali il server eXtraWay ha un comportamento che potremmo definire connesso. Esso viene contattato da un client il quale mantiene attiva la connessione col server sino al termine della sua vita utile. Altri servizi, come ad esempio il servizio HTTP, sono invece basati su un dialogo che è composto da continue connessioni, esecuzioni delle operazioni in tempi contenuti ed interruzione delle connessioni per procedere, in seguito, a nuove aperture, esecuzioni e così via.
Come abbiamo detto, il comportamento del server eXtraWay è invece diverso. Quello che ci si deve quindi aspettare da esso è che attenda comandi sul socket connesso e sullo stesso renda le proprie risposte.
Vediamo quindi, partendo da quest'ipotesi, cosa può essere rilevato.
In primo luogo il client potrebbe non riuscire più a prendere contatto col server, vale a dire, il socket connesso con il quale si effettuava il dialogo risulta rotto. Ciò comporta che il server dal lato opposto è presumibilmente andato in errore e che questo ha causato la chiusura della comunicazione.
Solitamente questa condizione di malfunzionamento richiede esclusivamente che la connessione venga ripristinata dal client in quanto non c'è motivo di ritenere che il server Master non sia comunque in ascolto e disponibile a costituire una nuova connessione.
Qualora la connessione non venisse ripristinata alla successiva richiesta si ha evidenza del fatto che il problema affligge anche il server Master. In questo caso è necessario verificare che le licenze non risultino effettivamente tutte occupate e che al contempo il servizio sia ancora attivo.
Quando il server risulti disattivo o non più rispondente alle sollecitazioni di un client può essere necessario intervenire con un'interruzione dei servizi ed una loro riattivazione. Anche quest'operazione può nascondere delle problematiche di ripartenza.
Di seguito i dettagli di tutti gli aspetti principali del tema trattato.
Come detto in più occasioni, il server è abilitato per un certo numero di licenze. Questo comporta che il server consentirà un pari numero di connessioni con altrettanti client, indipendentemente da quanti operatori possono avvalersi di ogni singolo client. Chiaramente il server non consente di compiere più connessioni di quelle ammesse rifiutandole e lasciando una traccia nel proprio file di log. (Interpretazione dei Logs)
In generale, comunque, è possibile stabilire quante siano le connessioni attualmente attive avvalendosi del comando...
netstat -a
...eventualmente coadiuvato dal comando grep...
netstat -a | grep 4859
...dove 4859 è il numero della porta utilizzata dal server eXtraWay.
Per gli altri numeri di porta confrontare Elenco dei numeri di porta Tcp/Udp utilizzati dai programmi HighWay/eXtraWay.
L'elenco ottenuto mostra quante siano le connessioni pendenti e da quali IP Address esse provengano.
-v.Il numero delle connessioni pendenti non può superare il numero delle licenze ma dall'analisi dell'IP Address delle macchine client si può comprendere se risultino pendenti delle connessioni che non hanno più motivo di esistere. In tal caso alcuni client potrebbero legittimamente volersi connettere senza trovare disponibilità di licenze libere per un errore del server. Si da il caso, infatti, che esistano condizioni in cui il server subisce l'interruzione della connessione col client senza che questo gli risulti evidente. La connessione viene quindi considerata ancora aperta ed attiva senza quindi che il server abbia alcun motivo valido per ritenerla interrotta.
Una volta stabilito se esistono connessioni che risultino erroneamente attive si può provvedere alla loro eliminazione secondo questi metodi:
Le procedure descritte, se ci si deve avvalere dell'interruzione dei servizi, possono scaturire in un ulteriore caso: la mancata ripartenza dei servizi. Come accennato all'inizio, questo caso può verificarsi sia in condizioni come questa ripartenza, sia alla prima attivazione del server.
In questi casi è molto probabile che il problema vada ricercato nella presenza della porta del server ancora impegnata a causa della chiusura presumibilmente irregolare dei servizi. (Vds. Socket Impegnato) Questa condizione è rilevabile tramite il comando...
netstat -a
... già descritto in precedenza. Da tale comando si dovrebbe identificare la presenza di un socket in condizione di chiusura. Essa può essere rappresentata da uno stato di CLOSE_WAIT o di TIME_WAIT.
Torna a Indice delle voci