Come configurare i timeout di inattività per le sessioni di modifica collaborativa

Collabora Online offre diverse impostazioni che potrebbero sembrare simili a un "timeout di inattività", ma in realtà controllano comportamenti differenti. Se un editor si oscura o smette di aggiornarsi mentre un utente sta ancora lavorando, è necessario regolare l'impostazione di inattività per singola visualizzazione. Se un documento rimane caricato dopo che tutti gli utenti hanno abbandonato la sessione, è necessario regolare il timeout per singolo documento. Se l'editor si disconnette effettivamente, prima di modificare i criteri di inattività di Collabora, è necessario verificare il timeout WebSocket del proxy inverso.

Il modello di configurazione attuale di Collabora Online prevede un timeout di inattività di 15 minuti per visualizzazione, un timeout di 5 minuti quando la scheda del browser non è attiva e un timeout di un'ora prima che un documento inattivo venga scaricato. Queste impostazioni predefinite possono variare a seconda della versione e del pacchetto, pertanto si consiglia di verificare la configurazione fornita con la versione installata prima di apportare modifiche. I valori riportati di seguito si riferiscono al modello attualmente utilizzato per questa guida e non sono una garanzia per ogni implementazione CODE o enterprise.

Scegli l'impostazione in base al comportamento desiderato

Collabora documenta i significati e le impostazioni predefinite nel suo attuale modello di configurazione coolwsd e nel riferimento di configurazione . Un timeout di inattività per vista non è la stessa cosa di chiudere un account o revocare l'accesso: oscura la vista e interrompe gli aggiornamenti. Un timeout per documento scarica un processo di documento inattivo; non è un timer che dovrebbe terminare una persona che sta attivamente modificando.

Punti di partenza consigliati

• Per evitare che le schede attive degli utenti si attenuino troppo presto, aumenta per_view.idle_timeout_secsl'intervallo di tempo predefinito a un valore misurato, ad esempio 1.800 secondi (30 minuti). Questo è un punto di partenza pratico, non una raccomandazione universale.
• Consenti agli utenti di passare da una scheda all'altra mantenendo attivo un documento: aumenta il limite per_view.out_of_focus_timeout_secsseparatamente. Non aumentarlo solo perché gli utenti sono inattivi in ​​una scheda attiva.
• Riduci l'utilizzo della memoria dopo l'abbandono dei documenti: lascia invariati i valori per visualizzazione e valuta la possibilità di ridurli per_document.idle_timeout_secs, dopo aver verificato che il documento sia effettivamente inattivo e che i salvataggi di archiviazione siano integri.
• Risolvi una disconnessione a tempo fisso: analizza il timeout WebSocket del proxy, dell'ingress o del bilanciatore di carico. La modifica dell'impostazione di oscuramento per vista non ripristinerà un WebSocket chiuso dal proxy.
• Mantieni i salvataggi frequenti: lascia i valori di salvataggio automatico e di inattività alle impostazioni attuali, a meno che tu non abbia un motivo specifico per modificarli.

Modifica le impostazioni in coolwsd.xml

Per un'installazione basata su pacchetti, individua il coolwsd.xmlfile attivo utilizzato dal servizio in esecuzione. I percorsi più comuni includono /etc/coolwsd/coolwsd.xml, ma variano a seconda della distribuzione e delle versioni precedenti. Non dare per scontato che la modifica di un file di esempio o di una copia montata non utilizzata modifichi il servizio in esecuzione.

Esegui il backup del file attivo, quindi modifica solo i valori pertinenti nelle sezioni esistenti <per_view>. <per_document>Ad esempio, questo estratto imposta un timeout di 30 minuti per gli utenti inattivi, un timeout di 15 minuti per le schede in background e uno scaricamento dei documenti inattivi di due ore:

<per_view>
    <idle_timeout_secs>1800</idle_timeout_secs>
    <out_of_focus_timeout_secs>900</out_of_focus_timeout_secs>
</per_view>
<per_document>
    <idle_timeout_secs>7200</idle_timeout_secs>
</per_document>

Questo è un estratto, non una configurazione di sostituzione completa. Conserva gli attributi, i commenti, l'annidamento e gli altri elementi presenti nel file fornito con la tua versione; alcune build prevedono attributi XML aggiuntivi. Se desideri modificare solo l'attenuazione quando la scheda rimane attiva, modifica solo il valore di inattività per vista. Aumentare contemporaneamente sia il valore per vista che il valore di scaricamento del documento rende più difficile capire quale impostazione ha risolto il problema.

Convalida il file XML utilizzando gli strumenti di configurazione supportati dalla tua implementazione, quindi riavvia o ricarica Collabora seguendo la procedura documentata per quel pacchetto. Controlla i log di avvio per individuare eventuali errori di analisi della configurazione e verifica che il processo in esecuzione abbia caricato il file previsto. Una modifica alle impostazioni non presente nel processo attivo non avrà alcun effetto.

Imposta le stesse opzioni in Docker o Kubernetes

Nell'immagine Docker di Collabora, gli amministratori solitamente passano le opzioni di configurazione utilizzando extra_paramsla --o:sintassi `option`. Il seguente valore in stile Compose illustra lo stesso esempio:

extra_params=--o:per_view.idle_timeout_secs=1800 --o:per_view.out_of_focus_timeout_secs=900 --o:per_document.idle_timeout_secs=7200

Utilizzare questa opzione solo se l'immagine e il grafico di distribuzione lo supportano extra_params. Per Kubernetes, Helm o un'installazione gestita dall'operatore, inserire le opzioni nel campo di configurazione supportato del grafico o della risorsa personalizzata anziché modificare un file container generato. Quando si modificano le variabili d'ambiente in Compose, ricreare o ridistribuire il servizio in modo che i nuovi valori raggiungano il container; un semplice riavvio potrebbe riutilizzare la configurazione del container esistente.

Non impostare la stessa opzione in posizioni contrastanti, ad esempio sia in un file XML montato che in un parametro di ambiente, senza prima verificare le regole di precedenza per quella versione. Dopo la ridistribuzione, esaminare i log di avvio del container e la configurazione attiva. Il repository del codice sorgente del progetto Collabora e la documentazione di distribuzione corrispondente alla versione sono i riferimenti appropriati quando i nomi delle opzioni o il comportamento del container differiscono.

Verificare separatamente i timeout del proxy inverso.

L'editor di Collabora utilizza i WebSocket per la comunicazione continua con il browser. Un proxy può chiudere un WebSocket altrimenti valido anche se i timeout di documenti e visualizzazioni di Collabora sono impostati su valori molto più lunghi. In tal caso, gli utenti potrebbero visualizzare un messaggio di disconnessione, una richiesta di riconnessione o un editor che smette di ricevere aggiornamenti anziché una semplice visualizzazione attenuata.

Confronta il timeout di lettura/invio del proxy, l'eventuale timeout di inattività del load balancer in ingresso o nel cloud e il comportamento di sessione previsto da Collabora. I timeout devono essere compatibili lungo l'intero percorso. La guida alle impostazioni del proxy di Collabora include esempi di configurazione del proxy WebSocket e di connessioni a lunga durata. Applica le indicazioni appropriate al tuo proxy e alla tua versione specifici; non copiare ciecamente un vecchio blocco Nginx in un proxy diverso o in un percorso non correlato.

Un indizio utile è il modello di errore. Se gli utenti vedono solo l'icona di visualizzazione inattiva, esaminate i log per_view. Se tutti gli utenti si disconnettono all'incirca nello stesso momento, controllate i log del proxy e del bilanciatore di carico a quel timestamp. Se un documento si chiude solo dopo che tutti i partecipanti hanno abbandonato, il timeout per documento è più rilevante.

Testa un timeout alla volta

1. Annota i valori correnti della configurazione attiva e indica la versione di Collabora e il metodo di implementazione utilizzati.
2. Apri un documento di prova con due utenti o due sessioni del browser in modo da poter osservare sia la visualizzazione attiva che quella inattiva.
3. Modifica solo il timeout corrispondente al sintomo. Ad esempio, per evitare l'attenuazione della luminosità in una scheda attiva ma silenziosa, regola per_view.idle_timeout_secssolo il timeout.
4. Riavvia o ridistribuisci utilizzando il metodo supportato, quindi verifica che il nuovo valore venga visualizzato nella configurazione attiva o nei log di avvio.
5. Attendi oltre la soglia precedente. Verifica se la visualizzazione continua a oscurarsi, se il secondo utente continua a ricevere aggiornamenti e se le modifiche vengono salvate correttamente.
6. Chiudi tutte le visualizzazioni del documento di prova e osserva se il documento inattivo si scarica entro l'intervallo previsto.
7. Controlla i log di Collabora e del proxy per individuare eventuali chiusure di WebSocket, errori di analisi XML, salvataggi non riusciti o arresti di processo imprevisti.

Non testare la modifica su un documento di produzione non salvato. Verifica che i file modificati vengano salvati nel backend di archiviazione prima di consentire lo scaricamento di un processo di documento inattivo. Se il problema si verifica solo con le modifiche non salvate, controlla gli errori di salvataggio automatico e di archiviazione come un problema separato, anziché prolungare ogni timeout.

Trovare un equilibrio tra praticità, utilizzo delle risorse e affidabilità.

Timeout più lunghi per singola visualizzazione sono più adatti ai team che rivedono i documenti in pausa o lavorano su più schede del browser. Valori più brevi possono far sì che le visualizzazioni inattive smettano di aggiornarsi prima, riducendo l'attività in background, ma possono interrompere un utente che sta ancora visualizzando il documento. Il timeout per singolo documento è una scelta di gestione delle risorse a sé stante: aumentandolo, i documenti non utilizzati rimangono caricati più a lungo, mentre riducendolo potrebbe essere necessario un nuovo caricamento al ritorno dell'utente.

Per la maggior parte delle implementazioni, modificate il minor numero possibile di impostazioni necessarie per riprodurre il comportamento osservato. Mantenete gli intervalli di salvataggio, impostate una finestra di inattività ragionevole per ogni vista per il team, mantenete intenzionale il timeout della scheda in background e regolate i limiti del proxy WebSocket solo quando i log o i tempi indicano un problema a livello di connessione. Ricontrollate il modello di configurazione della versione installata dopo gli aggiornamenti, poiché le impostazioni predefinite e quelle supportate possono cambiare.