Differenze tra le versioni di "Configurazione Callback"
imported>Root |
imported>Root |
||
(7 versioni intermedie di uno stesso utente non sono mostrate) | |||
Riga 4: | Riga 4: | ||
Il sottosistema di callback fornisce l'infrastruttura a tutte le applicazioni della suite per inviare messaggi in tempo reale dal server al client. Esistono svariate tipologie di messaggi, ad esempio una notifica di nuove attivita' da parte del workflow, oppure un messaggio popup dall'amministratore, oppure ancora messaggi di chat, notifiche di permessi o di export terminati eccetera. | Il sottosistema di callback fornisce l'infrastruttura a tutte le applicazioni della suite per inviare messaggi in tempo reale dal server al client. Esistono svariate tipologie di messaggi, ad esempio una notifica di nuove attivita' da parte del workflow, oppure un messaggio popup dall'amministratore, oppure ancora messaggi di chat, notifiche di permessi o di export terminati eccetera. | ||
Senza questo meccanismo, il client sarebbe costretto ad effettuare un polling continuo sul server per vedere se ci sono "delle | Senza questo meccanismo, il client sarebbe costretto ad effettuare un polling continuo sul server per vedere se ci sono "delle novità". La soluzione del polling (test periodico) e' di difficile utilizzo all'atto pratico, in quanto eventi che potenzialmente sono di immediata necessità verrebbero ricevuti al controllo successivo la produzione dell'evento, cosa che può accadere anche dopo parecchi secondi. | ||
Non | Non è possibile effettuare un polling troppo frequente in quanto il sommarsi delle chiamate di molteplici client (soprattutto quando ce ne sono parecchi attivi) a frequenza elevata causa un collasso del server. | ||
Per risolvere questo problema il sottosistema di callback forza ogni client a fare una singola chiamata al server. Tale chiamata resta "attiva" (o appesa) sul server e non torna | Per risolvere questo problema il sottosistema di callback forza ogni client a fare una singola chiamata al server. Tale chiamata resta "attiva" (o appesa) sul server e non torna finchè non ci sono messaggi per il client chiamante. La chiamata "appesa" non sovraccarica assolutamente il server, ma necessita di un canale di comunicazione costantemente aperto dal client al server. | ||
'''''Nota:''' La soluzione inversa, e | '''''Nota:''' La soluzione inversa, e cioè una chiamata effettuata dal server verso il client quando sono disponibili dei nuovi messaggi non è proponibile a causa dei problemi introdotti dalle infrastrutture di rete (firewall, router ecc) che potenzialmente impediscono al server di conoscere l'indirizzo reale del client.'' | ||
===Manutenzione base messaggi=== | ===Manutenzione base messaggi=== | ||
Il pannello di manutenzione della base messaggi fornisce una visione dei messaggi che sono attualmente "parcheggiati" nel database in attesa di lettura da parte dei client. Normalmente non serve interagire con questo pannello dato che i messaggi prima o poi verranno letti dai client oppure rimossi dal garbage collector. Se ci sono | Il pannello di manutenzione della base messaggi fornisce una visione dei messaggi che sono attualmente "parcheggiati" nel database in attesa di lettura da parte dei client. Normalmente non serve interagire con questo pannello dato che i messaggi prima o poi verranno letti dai client oppure rimossi dal garbage collector. Se ci sono però situazioni in cui un messaggio resta "inceppato", da qui è possibile rimuoverlo. | ||
===Configurazione=== | ===Configurazione=== | ||
Riga 19: | Riga 19: | ||
====Ritardo minimo tra i roundtrip==== | ====Ritardo minimo tra i roundtrip==== | ||
Il roundtrip e' la chiamata che il client effettua al server per ottenere i nuovi messaggi. Potenzialmente un roundtrip potrebbe durare anche ore se non ci sono messaggi disponibili per il client. Quando un messaggio viene inviato al client, il suo roundtrip termina ed i nuovi messaggi vengono tornati al client. Il client li processa e, una volta terminata questa operazione, si prepara per un nuovo roundtrip sul server. Questo parametro regola l'attesa passiva che il client effettua prima di chiamare nuovamente il server alla fine dell'esame dei messaggi ricevuti. | Il roundtrip e' la chiamata che il client effettua al server per ottenere i nuovi messaggi. Potenzialmente un roundtrip potrebbe durare anche ore se non ci sono messaggi disponibili per il client. Quando un messaggio viene inviato al client, il suo roundtrip termina ed i nuovi messaggi vengono tornati al client. Il client li processa e, una volta terminata questa operazione, si prepara per un nuovo roundtrip sul server. Questo parametro regola l'attesa passiva che il client effettua prima di chiamare nuovamente il server alla fine dell'esame dei messaggi ricevuti. | ||
Il default | Il default è 0ms, quindi la chiamata successiva avviene immediatamente. | ||
====Ritardo cancellazione messaggi==== | ====Ritardo cancellazione messaggi==== | ||
Quando un messaggio viene letto dal client viene successivamente messo in lista di cancellazione. La cancellazione non avviene subito | Quando un messaggio viene letto dal client viene successivamente messo in lista di cancellazione. La cancellazione non avviene subito perchè, a seconda della tipologia di messaggio, potrebbe interessare anche altri client. Quindi, per assicurarsi che tutti i client interessati abbiano il tempo di ricevere il messaggio si effettua una attesa prima della cancellazione. Il default è 15000ms (15 secondi). | ||
====Timeout attesa passiva messaggi==== | ====Timeout attesa passiva messaggi==== | ||
A seconda dell'installazione effettuata, le chiamate di roundtrip potrebbero passare attraverso un Web Server (es: Apache). Normalmente i Web Server non permettono chiamate di durata molto elevata, quindi se il client non riceve mai messaggi esiste la | A seconda dell'installazione effettuata, le chiamate di roundtrip potrebbero passare attraverso un Web Server (es: Apache). Normalmente i Web Server non permettono chiamate di durata molto elevata, quindi se il client non riceve mai messaggi esiste la possibilità che la connessione venga chiusa in modo brutale, generando quindi un errore. In questo caso è opportuno impostare un timeout di attesa passiva ragionevolmente inferiore al timeout del Web Server in modo che la chiamata venga terminata d'iniziativa dell'application server e il client provveda ad effettuarne immediatamente una nuova, evitando in questo modo il troncamento brutale della connessione. Il valore di default è 0ms, quindi i roundtrip possono essere di durata illimitata. | ||
====Intervallo minimo tra i garbage collection==== | ====Intervallo minimo tra i garbage collection==== | ||
Periodicamente il sottosistema di callback effettua una pulizia automatica delle tabelle dei messaggi eliminando quelli che per varie ragioni non sono | Periodicamente il sottosistema di callback effettua una pulizia automatica delle tabelle dei messaggi eliminando quelli che per varie ragioni non sono più significativi oppure non verranno mai ricevuti (ad esempio perchè la sessione di lavoro a cui si riferiscono è nel frattempo termiata). L'intervallo di default tra questi garbage collection è 900000ms (15 minuti). E' possibile alterare questo parametro, ma per farlo è necessario agire sul file di configurazione '''sicraweb.server.config.xml'''. | ||
Dopo aver alterato il parametro | Dopo aver alterato il parametro è necessario riavviare l'application server. | ||
'''''Nota:''' E' possibile, impostando il valore 0 (zero) disattivare il garbage collector del callback ma questa soluzione | '''''Nota:''' E' possibile, impostando il valore 0 (zero) disattivare il garbage collector del callback ma questa soluzione è sconsigliata in quanto si rischia di accumulare una grande quantità di dati nel database senza possibilità di cancellazione.'' |
Versione attuale delle 19:58, 13 nov 2009
Configurazione del sottosistema di callback
Introduzione
Il sottosistema di callback fornisce l'infrastruttura a tutte le applicazioni della suite per inviare messaggi in tempo reale dal server al client. Esistono svariate tipologie di messaggi, ad esempio una notifica di nuove attivita' da parte del workflow, oppure un messaggio popup dall'amministratore, oppure ancora messaggi di chat, notifiche di permessi o di export terminati eccetera.
Senza questo meccanismo, il client sarebbe costretto ad effettuare un polling continuo sul server per vedere se ci sono "delle novità". La soluzione del polling (test periodico) e' di difficile utilizzo all'atto pratico, in quanto eventi che potenzialmente sono di immediata necessità verrebbero ricevuti al controllo successivo la produzione dell'evento, cosa che può accadere anche dopo parecchi secondi. Non è possibile effettuare un polling troppo frequente in quanto il sommarsi delle chiamate di molteplici client (soprattutto quando ce ne sono parecchi attivi) a frequenza elevata causa un collasso del server.
Per risolvere questo problema il sottosistema di callback forza ogni client a fare una singola chiamata al server. Tale chiamata resta "attiva" (o appesa) sul server e non torna finchè non ci sono messaggi per il client chiamante. La chiamata "appesa" non sovraccarica assolutamente il server, ma necessita di un canale di comunicazione costantemente aperto dal client al server.
Nota: La soluzione inversa, e cioè una chiamata effettuata dal server verso il client quando sono disponibili dei nuovi messaggi non è proponibile a causa dei problemi introdotti dalle infrastrutture di rete (firewall, router ecc) che potenzialmente impediscono al server di conoscere l'indirizzo reale del client.
Manutenzione base messaggi
Il pannello di manutenzione della base messaggi fornisce una visione dei messaggi che sono attualmente "parcheggiati" nel database in attesa di lettura da parte dei client. Normalmente non serve interagire con questo pannello dato che i messaggi prima o poi verranno letti dai client oppure rimossi dal garbage collector. Se ci sono però situazioni in cui un messaggio resta "inceppato", da qui è possibile rimuoverlo.
Configurazione
Il sottosistema di callback permette di essere configurato sotto vari aspetti. Qui di seguito viene spiegato il significato dei vari parametri disponibili:
Ritardo minimo tra i roundtrip
Il roundtrip e' la chiamata che il client effettua al server per ottenere i nuovi messaggi. Potenzialmente un roundtrip potrebbe durare anche ore se non ci sono messaggi disponibili per il client. Quando un messaggio viene inviato al client, il suo roundtrip termina ed i nuovi messaggi vengono tornati al client. Il client li processa e, una volta terminata questa operazione, si prepara per un nuovo roundtrip sul server. Questo parametro regola l'attesa passiva che il client effettua prima di chiamare nuovamente il server alla fine dell'esame dei messaggi ricevuti. Il default è 0ms, quindi la chiamata successiva avviene immediatamente.
Ritardo cancellazione messaggi
Quando un messaggio viene letto dal client viene successivamente messo in lista di cancellazione. La cancellazione non avviene subito perchè, a seconda della tipologia di messaggio, potrebbe interessare anche altri client. Quindi, per assicurarsi che tutti i client interessati abbiano il tempo di ricevere il messaggio si effettua una attesa prima della cancellazione. Il default è 15000ms (15 secondi).
Timeout attesa passiva messaggi
A seconda dell'installazione effettuata, le chiamate di roundtrip potrebbero passare attraverso un Web Server (es: Apache). Normalmente i Web Server non permettono chiamate di durata molto elevata, quindi se il client non riceve mai messaggi esiste la possibilità che la connessione venga chiusa in modo brutale, generando quindi un errore. In questo caso è opportuno impostare un timeout di attesa passiva ragionevolmente inferiore al timeout del Web Server in modo che la chiamata venga terminata d'iniziativa dell'application server e il client provveda ad effettuarne immediatamente una nuova, evitando in questo modo il troncamento brutale della connessione. Il valore di default è 0ms, quindi i roundtrip possono essere di durata illimitata.
Intervallo minimo tra i garbage collection
Periodicamente il sottosistema di callback effettua una pulizia automatica delle tabelle dei messaggi eliminando quelli che per varie ragioni non sono più significativi oppure non verranno mai ricevuti (ad esempio perchè la sessione di lavoro a cui si riferiscono è nel frattempo termiata). L'intervallo di default tra questi garbage collection è 900000ms (15 minuti). E' possibile alterare questo parametro, ma per farlo è necessario agire sul file di configurazione sicraweb.server.config.xml. Dopo aver alterato il parametro è necessario riavviare l'application server.
Nota: E' possibile, impostando il valore 0 (zero) disattivare il garbage collector del callback ma questa soluzione è sconsigliata in quanto si rischia di accumulare una grande quantità di dati nel database senza possibilità di cancellazione.