Gestione del ciclo di vita del factory di connessione gestito di CM Server

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.


Feedback