Questo argomento descrive le attività di gestione del ciclo di vita di CM Server.
CM Server utilizza due factory di connessione gestiti J2C (uno per ClearCase
e uno per ClearQuest) per avviare e controllare i processi del server di backend che
comunicano con i prodotti principali ClearCase e ClearQuest. I processi ONCRPC
di backend (processi ccrpc per ClearCase e processi cqrpc per ClearQuest)
svolgono il ruolo di ponte fra i componenti J2EE e Websphere di CM Server
e i componenti principali di ClearCase e ClearQuest.
CM Server esegue una serie di attività in background che contribuiscono alla gestione e
al controllo del ciclo di vita completo di ogni processo del server ONCRPC di backend avviato;
non è richiesto l'intervento di alcun amministratore per abilitare l'esecuzione di tali attività.
Esiste un'attività generica del ciclo di vita che effettua la gestione del ciclo
di vita non specifica del prodotto e attività specifiche del prodotto che controllano i comportamenti
degli oggetti server di backend ClearCase e ClearQuest. Ogni attività utilizza attributi
MBean configurabili per contribuire a regolare il numero e la longevità degli oggetti server
attivi, conservare la capacità del sistema di far fronte al carico di lavoro
ed evitare il degrado delle prestazioni causato dal consumo eccessivo di risorse.
Consultare Impostazione attributi MBean disponibili per informazioni sugli attributi MBean
e la relativa modalità di configurazione.
Gestione del ciclo di vita del factory di connessione gestito
L'attività
di gestione del ciclo di vita generica influenza tutti i processi ONCRPC di backend creati
dai factory di connessione. Tale attività viene avviata dall'interno del CM Server
all'avvio iniziale del CM Server. L'attività viene eseguita ogni due minuti
ed è responsabile della verifica del corretto funzionamento del processo di
backing di ogni server ONCRPC di backend e della ripulitura di
ciò che rimane dei processi del server terminati.
Ogni volta
che l'attività viene eseguita, acquisisce un elenco di gestioni degli oggetti
server di backend avviate
da CM Server, contrassegnate come RUNNING. Ogni oggetto server di backend viene
sottoposto a test per accertare che sia in esecuzione un processo di backing funzionante. Per ogni processo di backend
che risulti malfunzionante, viene avviata la ripulitura dell'oggetto server
come segue (i messaggi di log registrano tali eventi):
- L'oggetto server viene contrassegnato come non-funzionante, affinché non venga attribuito alcun
nuovo lavoro al server.
- Viene accodata la notifica di ripulitura MBean e nell'arco di cinque secondi tale notifica
viene ricevuta in modo asincrono e viene effettuato tutto il lavoro di ripulitura sull'oggetto
server non funzionante.
- L'oggetto server viene rimosso dall'elenco degli oggetti server del factory di connessione gestito
padre
- Viene annullata la registrazione dell'MBean associato a tale server.
L'attività successiva acquisisce un elenco aggiornato dei server in stato STOPPING (i server
inattivi vengono contrassegnati in questo modo). Viene controllato il processo di backing
di ogni oggetto server che è rimasto nello stato STOPPING per almeno 30 secondi
per accertare che il processo sia stato effettivamente arrestato. Se il processo
dell'oggetto server non è stato arrestato, viene arrestato in modo forzato e rimosso
dall'elenco di server del factory. I server che non sono rimasti nello stato STOPPING
per almeno 30 secondi vengono lasciati nell'elenco di server del factory e verranno controllati
all'esecuzione successiva di questa attività.
Attività di gestione del ciclo di vita del factory di connessione gestito
specifiche del prodotto
Oltre all'attività di gestione del ciclo di vita generica, un'attività
indipendente ClearCase e un'attività indipendente ClearQuest controllano la gestione del
ciclo di vita, specifica del prodotto, dei rispettivi processi del server di backend.
Il server
oncrpc di backend ClearQuest (noto come processo cqrpc) è un processo multithreaded;
di norma, è sempre esiguo il numero di processi cqrpc in esecuzione. Il server oncrpc di backend ClearCase (noto come processo ccrpc)
è un processo a thread singolo; di norma sono sempre numerosi i processi di questo tipo
in esecuzione. I factory di connessione gestiti specifici del prodotto utilizzano attributi
MBean configurabili per contribuire a regolare il numero e la longevità dei processi attivi,
conservare la capacità del sistema di far fronte al carico di lavoro, evitando
il degrado delle prestazioni causato dal consumo eccessivo di risorse.
Alcuni attributi
MBean chiave vengono utilizzati per regolare il numero di processi ccrpc da abilitare;
potrebbe essere necessario modificare le impostazioni predefinite di tali parametri in base al
tipo di sistema su cui è installato CM Server come anche all'utilizzo del
server previsto, in base al caricamento e alla capacità:
- L'attributo MBean CcServerFactoryMBean.serverThresholdCount è il
numero soglia dei server CCRPC che una volta raggiunto eseguirà il trigger
della gestione del ciclo di vita seriale all'interno del factory di connessione gestito di ClearCase.
- L'attributo MBean CcServerFactoryMBean.maxServerCount è
il numero massimo di server CCRPC che è possibile creare contemporaneamente
all'interno del factory di connessione gestito di ClearCase.
- L'attributo MBean CcServerFactoryMBean.maxServersPerCredential
impedisce alle applicazioni client di creare troppi thread per singola sessione
utente.
È possibile regolare tali valori utilizzando il programma di utilità
della riga comandi wsadmin. Consultare Impostazione attributi MBean disponibili per informazioni sugli attributi MBean
e la relativa modalità di configurazione. Parametri come le dimensioni della memoria,
la velocità del processore e altri attributi di sistema determinano come impostare
questi e altri valori CcServerFactoryMBean.
Quando CM Server riceve una richiesta ClearCase
da un client, si tenta di acquisire un server di backend per elaborare
la richiesta. I seguenti controlli seriali vengono effettuati a ogni richiesta
ricevuta:
- Nell'elenco di oggetti server ClearCase viene effettuata la ricerca
di un server non occupato che elabori la richiesta. Un oggetto server
viene considerato occupato se sta già
elaborando un'altra richiesta. Se un oggetto server esistente
non è occupato e corrisponde alle credenziali della richiesta, la richiesta viene
elaborata da tale oggetto server.
- Se nessuno degli oggetti server esistenti corrisponde alle credenziali o gli oggetti server esistenti
sono occupati, è necessario creare e associare alla richiesta un nuovo oggetto server;
questa operazione può essere effettuata solo se il factory di connessione gestito ne ha la capacità, come
riportato di seguito:
- Se è stato raggiunto il numero CcServerFactoryMBean.maxServersPerCredential di server ccrpc
o il numero CcServerFactoryMBean.maxServerCount di server ccrpc,
il thread utente assegnato per l'elaborazione della richiesta
client entra in un loop di tipo "attendi-e-ripeti"; per acquisire un server verrà effettuato un numero di tentativi equivalente al valore di TeamServerMBean.maxProcureServerAttempts
durante un intervallo massimo, in secondi, equivalente al valore di TeamServerMBean.procureServerInterval.
- Se non è possibile acquisire un server, la richiesta client viene rifiutata. (In caso contrario,
viene creato un nuovo oggetto server e assegnato alla richiesta.)
Oltre ai controlli seriali effettuati all'arrivo di ogni richiesta,
descritti in precedenza, un'attività di gestione del ciclo di vita, specifica di ClearCase, di background, esegue
la seguente sottoattività:
A intervalli di due minuti viene creato un elenco di tutti i server ccrpc che sono stati inattivi per un tempo, in secondi, equivalente al valore di
CcServerFactoryMBean.idleServerInterval
o più e ogni server dell'elenco viene arrestato normalmente, come descritto di seguito:
- L'istanza del server viene posta in stato STOPPING affinché non venga attribuito
alcun nuovo lavoro a tale server.
- Viene accodata una notifica TERMINATE MBean e nell'arco di cinque secondi
tale notifica viene ricevuta in modo asincrono e viene effettuata tutta la ripulitura
dell'oggetto server.
- Viene inviato un messaggio RPC di arresto al processo del server ccrpc e l'istanza del server
viene impostata sullo stato STOPPED.
- L'ora corrente viene registrata e salvata nell'istanza del server affinché
l'attività CheckServer generica visualizzi la durata dello stato
STOPPED del server.
- L'istanza dell'oggetto server viene rimossa dall'elenco di server del factory
di connessione.
- Viene annullata la registrazione dell'MBean associato a tale server.
La
gestione del ciclo di vita di ClearQuest si compone di un'attività in background che viene eseguita
a intervalli di due minuti, nonché di alcuni controlli in foreground, per richiesta client, effettuati
durante l'elaborazione delle richieste. I controlli vengono effettuati per determinare
se sono stati raggiunti eventuali limiti di risorse critici:
- Se viene abilitato il riavvio basato sul tempo (ossia, se il valore corrispondente a CqServerFactoryMBean.recycleServerLifetimeLimit è
superiore a zero e qualsiasi oggetto server cqrpc è stato in esecuzione almeno
durante tale periodo di tempo), l'oggetto server cqrpc viene contrassegnato come pronto al riavvio.
- Una volta completata una richiesta client, viene effettuato un controllo per determinare se l'oggetto
server cqrpc ha elaborato almeno un numero di chiamate
RPC equivalente al valore di CqServerFactoryMBean.recycleServerOncrpcCallLimit. In caso affermativo, l'oggetto server cqrpc viene contrassegnato come pronto per il riavvio.
- Quando viene ricevuta una richiesta client e il numero di sessioni è aumentato,
viene effettuato un controllo per determinare se l'oggetto server cqrpc ha creato almeno un numero di sessioni HTTP pari al valore equivalente a CqServerFactoryMBean.recycleServerHttpSessionLimit. In caso affermativo, l'oggetto server cqrpc viene contrassegnato come pronto per il riavvio; in
questo caso viene avviato un nuovo oggetto server cqrpc per gestire la richiesta in entrata.
Il
factory di connessione gestito di ClearQuest riavvia gli oggetti server cqrpc
invece di chiuderli (come fa il factory di connessione gestito di ClearCase
per gli oggetti server ccrpc che non sono più necessari). Ciò dipende dal fatto che
gli oggetti server cqrpc possono contenere elementi come, ad esempio, query o record
non ancora sottoposti a commit; in questo modo viene concesso un periodo di tolleranza a eventuali
lavori in sospeso da sottoporre a commit.
Il riavvio degli oggetti server cqrpc consiste in:
- L'oggetto server viene posto in stato STOPPING (noto anche come
stato RECYCLING) affinché non venga attribuito alcun nuovo lavoro a tale server.
- Viene accodata una notifica RECYCLE MBean. La notifica viene ricevuta in modo
asincrono nell'arco di cinque secondi; eventuali sessioni in sola lettura (READ-ONLY) associate all'oggetto server
vengono contrassegnate per essere riassociate a un nuovo oggetto server quando arriva
la successiva richiesta per tale sessione.
Alle sessioni in cui è in corso
una transazione in lettura-scrittura (READ-WRITE) (ossia, una transazione che prevede di sottoporre a commit una query
o un record) è consentito un intervallo massimo, in secondi, equivalente al valore di CqServerFactoryMBean.recyclingPeriod
per sottoporre a commit il lavoro in sospeso. Una volta sottoposto a commit il lavoro o
una volta raggiunto il valore di CqServerFactoryMBean.recyclingPeriod, l'oggetto server
viene posto in stato STOPPED, il processo di backing viene chiuso
e l'oggetto server viene rimosso dall'elenco di server del factory di connessione
gestito di ClearQuest.