Dispatcher è uno strumento di caching e/o bilanciamento del carico di Adobe Experience Manager che consente di realizzare un ambiente di authoring web veloce e dinamico. Per il caching, Dispatcher funziona come parte di un server HTTP, come Apache, allo scopo di memorizzare (o “memorizzare in cache”) la maggior parte del contenuto statico del sito web e di accedere al motore di layout del sito web il più raramente possibile. In un ruolo di bilanciamento del carico, Dispatcher distribuisce le richieste degli utenti (carico) tra le diverse istanze di AEM (rendering).
Per il caching, il modulo Dispatcher utilizza la funzionalità del server web che consente di gestire il contenuto statico. Dispatcher inserisce i documenti memorizzati in cache nella directory principale dei documenti del server web.
Dispatcher utilizza la funzionalità del server web che consente di gestire il contenuto statico. Dispatcher archivia i documenti memorizzati in cache nella directory principale dei documenti del server web. In Dispatcher sono disponibili due metodi principali per aggiornare il contenuto della cache quando vengono apportate modifiche al sito web.
Il bilanciamento del carico distribuisce le richieste degli utenti (carico) tra le diverse istanze AEM. L’elenco che segue descrive i vantaggi del bilanciamento del carico:
Per ulteriori dettagli, vedi la pagina Panoramica di Dispatcher
Puoi scaricare il più recente modulo Dispatcher dalla pagina Note sulla versione di Dispatcher.
Visita la pagina Installazione di Dispatcher.
Visita la pagina Configurazione di Dispatcher.
Per i passaggi dettagliati, vedi Utilizzo di Dispatcher con un’istanza Autore.
Puoi configurare CQ Dispatcher con più domini, purché i domini soddisfino le seguenti condizioni:
Per ulteriori informazioni, leggi Utilizzo di Dispatcher con più domini.
Puoi utilizzare la funzione connessioni permanenti, che garantisce che tutti i documenti di un utente vengano elaborati sulla stessa istanza di AEM. Questa funzione è importante, se utilizzi pagine e dati di sessione personalizzati. I dati vengono memorizzati nell’istanza. Pertanto, le successive richieste dello stesso utente devono ritornare a quell’istanza oppure i dati andranno persi.
Poiché le connessioni permanenti limitano la capacità di Dispatcher di ottimizzare le richieste, è opportuno utilizzare questo approccio solo se necessario. È possibile specificare la cartella che contiene i documenti “permanenti”, in modo da garantire che tutti i documenti di quella cartella vengano elaborati nella stessa istanza di ciascun utente.
Per la maggior parte delle pagine che utilizzano connessioni permanenti, devi disattivare il caching. In caso contrario, a tutti gli utenti viene visualizzata la stessa istanza della pagina, indipendentemente dal contenuto della sessione.
Per alcune applicazioni, può essere possibile utilizzare sia le connessioni permanenti che il caching. Ad esempio, se visualizzi un modulo che scrive i dati in una sessione, è possibile utilizzare le connessioni permanenti e il caching insieme.
Sì, se la macchina è sufficientemente potente. Tuttavia, si consiglia di installare Dispatcher e l’istanza di AEM Publish su macchine diverse.
In genere, l’istanza Publish risiede all’interno del firewall e Dispatcher risiede nella DMZ. Se decidi di installare l’istanza Publish e Dispatcher sulla stessa macchina fisica, accertati che le impostazioni del firewall vietino l’accesso diretto all’istanza Publish da reti esterne.
Sì. Ad esempio, se vuoi memorizzare in cache solo file GIF, specifica *.gif nella sezione cache del file di configurazione dispatcher.any.
Puoi eliminare i file dalla cache utilizzando una richiesta HTTP. Quando viene ricevuta la richiesta HTTP, Dispatcher elimina i file dalla cache. Dispatcher memorizza nuovamente in cache i file solo quando riceve dal client una richiesta per la pagina. Questa modalità di eliminazione dei file memorizzati in cache è appropriata per i siti web che hanno poche probabilità di ricevere richieste simultanee per la stessa pagina.
La richiesta HTTP ha la seguente sintassi:
POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
CQ-Handle: path-pattern
Content-Length: 0
Dispatcher elimina i file e le cartelle memorizzati in cache con nomi che corrispondono al valore dell’intestazione CQ-Handle. Ad esempio, il CQ-Handle /content/geomtrixx-outdoors/en
corrisponde ai seguenti elementi:
Tutti i file (con qualsiasi estensione) denominati en nella directory geometrixx-outdoors
Qualunque directory denominata _jcr_content
sotto la directory en (che, se esiste, contiene i rendering memorizzati in cache dei sottonodi della pagina)
La directory en verrà eliminata solo se CQ-Action
è Delete
o Deactivate
.
Per ulteriori dettagli su questo argomento, vedi Annullamento manuale della validità della cache di Dispatcher.
Visita la pagina Caching di contenuto protetto.
Visita le pagine Elenco di controllo di protezione di Dispatcher e Elenco di controllo di protezione di AEM.
jcr:content
modificato in jcr%3acontent
Domanda: di recente abbiamo riscontrato un problema a livello di Dispatcher, in cui una delle chiamate AJAX che stava richiamando dati dall’archivio CQ jcr:content
in Dispatcher è stata codificata come jcr%3acontent
causando un set di risultati errato.
Risposta: utilizza il metodo ResourceResolver.map()
per ottenere un URL “descrittivo” da usare/inviare per ottenere richieste da Dispatcher e anche risolvere il relativo problema di caching. Il metodo map() codifica i due punti :
in caratteri di sottolineatura e il metodo resolve() li decodifica nel formato leggibile SLING JCR. È necessario usare il metodo map() per generare l’URL utilizzato nella chiamata AJAX.
Ulteriori informazioni: https://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html#namespace-mangling
Visita la pagina Replica.
Vedi questo articolo per la risoluzione dei problemi che risponde alle seguenti domande:
Se le operazioni di eliminazione provocano il flush di Dispatcher, utilizza la soluzione suggerita in questo post di blog della community scritto da Sensei Martin.
È possibile utilizzare la funzione “replica a catena”. Quando questa funzione è abilitata, l’agente di Dispatcher Flush invia una richiesta di flushing nel momento in cui viene ricevuta una replica inviata dall’Autore.
Per abilitare questa funzione:
In che modo Dispatcher determina se un documento è aggiornato?
Per determinare se un documento è aggiornato, Dispatcher esegue le azioni sotto riportate:
Verifica se il documento è soggetto ad annullamento automatico della validità. Se non lo è, il documento viene considerato aggiornato.
Se il documento è configurato per l’annullamento automatico della validità, Dispatcher controlla se è più o meno recente dell’ultima modifica disponibile. Se è meno recente, Dispatcher richiede la versione corrente dall’istanza di AEM e sostituisce la versione nella cache.
Puoi definire se Dispatcher memorizza in cache un documento utilizzando il file di configurazione di Dispatcher, dispatcher.any
. Dispatcher confronta la richiesta con l’elenco dei documenti memorizzabili in cache. Se il documento non è incluso in questo elenco, Dispatcher richiede il documento dall’istanza di AEM.
La proprietà /rules
definisce quali documenti vengono memorizzati in cache in base al percorso del documento. Indipendentemente dalla proprietà /rules
, Dispatcher non memorizza mai in cache un documento nelle seguenti circostanze:
(?)
.Dispatcher archivia sul server web i file memorizzati in cache come se facessero parte di un sito web statico. Se un utente richiede un documento memorizzato in cache, Dispatcher verifica se questo documento esiste nel file system del server web. In caso affermativo, Dispatcher restituisce i documenti. In caso contrario, Dispatcher richiede il documento all’istanza AEM.
Dispatcher può memorizzare in cache i metodi GET o HEAD (per l’intestazione HTTP). Per ulteriori informazioni sul caching delle intestazioni di risposta, vedi la sezione Caching delle intestazioni di risposta HTTP.
Sì. In questi casi, assicurati che entrambe le istanze di Dispatcher possano accedere direttamente al sito web di AEM. Un’istanza di Dispatcher non può gestire le richieste provenienti da un’altra istanza di Dispatcher.