Differenze tra le versioni di "Configurazione Callback"

Da wiki.maggioli.it.
Jump to navigation Jump to search
imported>Root
imported>Root
(Nuova pagina: ==Configurazione del sottosistema di callback== ===Introduzione=== Il sottosistema di callback fornisce l'infrastruttura a tutte le applicazioni della suite per inviare messaggi in te...)
Riga 2: Riga 2:


===Introduzione===
===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.
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 dei permessi 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.
Senza questo meccanismo, il client sarebbe abbandonato a se stesso e sarebbe costretto ad
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.
esseffuare 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 letti al ciclo di polling
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.  
Per risolvere questo problema il sottosistema di callback forza ogni client a fare una chiamata
 
al server. Tale chiamata resta "attiva" sul server e non torna finchè non ci sono messaggi
'''''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.''
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.


===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 però situazioni in cui un messaggio resta "inceppato", da qui è possibile rimuoverlo.
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.
Se però ci sono situazioni in cui un messaggio resta "inceppato", da qui è possibile rimuoverlo.


===Configurazione===
===Configurazione===
Il sottosistema di callback permette di essere configurato sotto vari aspetti. Qui di seguito viene spiegato il significato dei vari parametri disponibili:
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====
====Ritardo minimo tra i roudtrip====
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.
Il default è 0ms, quindi la chiamata successiva avviene immediatamente.
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 roudtrip 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 deve effettuare prima di chiamare nuovamente il server alla fine del processo dei messaggi ricevuti.  
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 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).
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 (default 15000ms) prima della cancellazione.


====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 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.''

Versione delle 19:32, 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 dei permessi eccetera.

Senza questo meccanismo, il client sarebbe abbandonato a se stesso e sarebbe costretto ad esseffuare 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 letti al ciclo di polling 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 chiamata al server. Tale chiamata resta "attiva" 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.

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. Se però ci sono 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 roudtrip

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 roudtrip 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 deve effettuare prima di chiamare nuovamente il server alla fine del processo 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 (default 15000ms) prima della cancellazione.

Timeout attesa passiva messaggi

Estratto da "https://wiki.maggioli.it/index.php?title=Configurazione_Callback&oldid=14223"