Velen van ons zijn wellicht de situatie tegengekomen waarin de dispatcher een oude codeversie gebruikt. Dit artikel beschrijft hoe u dit kunt voorkomen, terwijl u de cachingmogelijkheden van de dispatcher benut.
Invalidatie is een mechanisme voor het identificeren van verouderde gecachete bronnen. Er zijn hulpmiddelen voor automatische invalidatie en handmatige invalidatie. Laten we de initiële configuratie instellen voor de invalidatiesectie van het dispatcher-configuratiebestand, vervolgens leren hoe invalidatie op een laag niveau werkt, en tenslotte terugkeren naar het analyseren van invalidatiehulpmiddelen. Maar eerst de basisprincipes.
Wat is Dispatcher-cache in AEM?
De Dispatcher is een caching- en load-balancing tool van AEM die gecachete bestanden op de webserver opslaat op dezelfde manier als een statische website. Zodra een cachebaar document wordt opgevraagd, controleert de Dispatcher of dat document bestaat in het bestandssysteem van de webserver:
- Als het document in de cache staat, retourneert de Dispatcher het bestand.
- De Dispatcher vraagt het document op bij de AEM-instantie als het niet in de cache staat.
Het serveren van de gegevens vanuit de cache van de Dispatcher vermindert de belasting op AEM publish-instanties.
/cache
{
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
}
}
Hoe de Dispatcher-cache te wissen?
Er zijn minstens 3 manieren om de Dispatcher-cache te wissen:
- Via flush agents op Author en/of op Publishes
- Handmatige flush
- Aangepaste code om de flush via programmering uit te voeren
Initiële instellingen van de invalidatiesectie
Laten we nu komen tot het ongeldig maken van gecachete pagina’s vanuit AEM. Het /invalidate block binnen de /cache-sectie bepaalt welke gecachete bestanden automatisch ongeldig kunnen worden gemaakt wanneer inhoud wordt bijgewerkt. De volgende configuratie maakt bijvoorbeeld alle HTML-pagina’s ongeldig:
/cache
{
/invalidate
{
/0000 { /glob "*" /type "allow" }
}
}
Bij automatische invalidatie verwijdert de dispatcher geen gecachete bestanden na het bijwerken van inhoud, maar controleert de geldigheid ervan wanneer ze opnieuw worden opgevraagd. Documenten in de cache die niet automatisch worden geïnvalideerd, blijven in de cache totdat ze worden verwijderd tijdens inhoudsupdates. Laten we als voorbeeld toestaan dat de hele cache automatisch wordt geïnvalideerd:
Herstart de httpd-server na het bijwerken van de /invalidate-sectie om de nieuwe wijzigingen toe te passen.
Ongeldig maken in detail
De Dispatcher gebruikt standaard speciale lege bestanden met de naam “.stat” op een laag niveau. De parameter /statfileslevel “0” is standaard ingesteld, wat betekent dat slechts één stat-bestand, gelegen in de root van de htdocs map, wordt gebruikt. Als het tijdstip van wijziging van het stat-bestand later is dan het tijdstip van wijziging van de resource, beschouwt de dispatcher een dergelijke resource als verouderd of ongeldig.
We hebben bijvoorbeeld deze gecachete resources na het aanvragen van de pagina http://localhost/content/geometrixx/en/products.html :
Laten we deze ongeldig maken door een low-level stat-bestandmechanisme toe te passen. Maak een leeg bestand aan met de naam “.stat” in de root van uw htdocs-directory:
U zult zien dat het tijdstip van de wijziging van het stat-bestand later is dan het tijdstip van de gecachete resources. Voor de dispatcher betekent dit dat alle resources verouderd zijn. Dit is een low-level mechanisme voor ongeldigmaking. Als we http://localhost/content/geometrixx/en/products.html opnieuw bezoeken na het aanmaken van dit stat-bestand, zullen de aangevraagde gecachete resources worden bijgewerkt:
Dit voorbeeld illustreert een ongeldigmakingspatroon met de standaardparameter /statfileslevel “0”. Laten we eens kijken hoe we de ongeldigmaking gedetailleerder kunnen afstemmen met de /statfileslevel parameter.
Instellen van /statfileslevel
U kunt de /statfileslevel eigenschappen van het dispatcher-configuratiebestand gebruiken om gecachete bestanden selectief ongeldig te maken op basis van hun pad. Er zijn enkele regels voor het mechanisme van de /statfileslevel-eigenschappen:
- De dispatcher creëert .stat-bestanden in elke map, beginnend bij de docroot en tot het niveau dat u specificeert. Het niveau van de docroot-map is 0.
- Wanneer u een bestand bijwerkt, vindt de dispatcher een map die zich op het statfileslevel-niveau bevindt en maakt alle bestanden in die map ongeldig, evenals alle bestanden die daaronder binnen die map liggen.
- Als het niveau van het bijgewerkte bestand lager is dan de statfileslevel, dan worden alleen de bestanden van de map die het bijgewerkte bestand bevat, ongeldig gemaakt, maar de bestanden die daaronder binnen deze map liggen, blijven geldig.
- Bij het bijwerken van een bestand, worden alle bestanden van de corresponderende map en hoger tot en met het rootniveau ongeldig.
Laten we een paar voorbeelden bekijken om de regels van de /statfileslevel-eigenschap beter te begrijpen. Onze standaard demo-case, waarbij /statfileslevel “0” is, ziet er als volgt uit:
Er is slechts één stat-bestand in de docroot-rootmap. En het verantwoordelijkheidsgebied of de reikwijdte van dit stat-bestand zal de gehele bestandsboom van onze docroot zijn. Als een bestand in de boom een wijzigingsdatum heeft die ouder is dan de wijzigingsdatum van het stat-bestand, zal de dispatcher dit bestand als ongeldig beschouwen.
Als we /statfileslevel “4” instellen, werkt de ongeldigmaking als volgt:
Stat-bestanden bestaan binnen alle niveaus van 0 (root) tot 4.
Een stat-bestand op een niveau lager dan 4 heeft een reikwijdte of verantwoordelijkheidsgebied alleen voor de map die het bevat. Als een stat-bestand in de map content/geometrixx/en nieuwer is dan een bestand uit deze map, dan is dit bestand ongeldig, maar alle bestanden uit andere mappen worden bepaald door andere stat-bestanden.
Alleen stat-bestanden met de waarde statfileslevel (in ons geval is het niveau 4) hebben de reikwijdte of het verantwoordelijkheidsgebied van de gehele onderliggende boom, beginnend bij de map die zo’n stat-bestand bevat en zich uitstrekkend tot de lagere niveaus van de bestandsboom.
Dus als een stat-bestand in de map content/geometrixx/en/products een recentere wijzigingstijd heeft dan enig bestand in de onderliggende bestandsboom, inclusief de products-map, beschouwt de dispatcher dit bestand als ongeldig. Validatie van alle bestanden die zich niet in deze boom bevinden, wordt bepaald door andere stat-bestanden.
Automatische ongeldigmaking en Dispatcher flush agent AEM
Om invalidatie te automatiseren, kunt u ‘authoring’ of ‘publish’ flush-agents inschakelen. We raden aan de publish flush agent te gebruiken voor een betrouwbaardere automatische invalidatie, aangezien het gebruik van de authoring flush agent de volgende problemen kan veroorzaken:
- De dispatcher moet toegankelijk zijn voor de AEM-server van de auteur. Als uw netwerk (bijv. vanwege een firewall) zo is ingesteld dat toegang tussen beide wordt geweigerd, werkt automatische invalidatie niet.
- Publicatie en cache-invalidatie vinden gelijktijdig plaats. Een gebruiker kan een pagina onmiddellijk opvragen nadat deze uit de cache is verwijderd, maar voordat de pagina is gepubliceerd. In deze situatie retourneert AEM de oude pagina, en de dispatcher cachet deze opnieuw en beschouwt deze nu als geldig. Dit probleem treft voornamelijk grote sites.
De public flush agent bevindt zich op: http://localhost:4503/etc/replication/agents.publish/flush.html
Om uw publish flush agent in te schakelen, klikt u op de knop “Bewerken” en vinkt u het selectievakje “Ingeschakeld” aan:
Werk de URI-poort bij op het tabblad Transport en stel de waarde in op 80:
Sla uw updates op en u zult zien dat de publish flush agent is geactiveerd:
Handmatige invalidatieverzoeken
U kunt de volgende verzoeken versturen om uw gecachete bronnen handmatig te invalideren:
- om gecachete bestanden te verwijderen
POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
CQ-Handle: path-pattern
Content-Length: 0
- om bestanden te verwijderen en opnieuw te cachen
POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
Content-Type: text/plain
CQ-Handle: path-pattern
Content-Length: numchars in bodypage_path0
Page_path1
…
Page_pathn
Samenvatting
Hierdoor hebben we kunnen achterhalen hoe deze dingen werken:
- Lage-niveau invalidatiemechanisme;
- Flush agents voor automatische invalidatie nadat pagina’s zijn gepubliceerd;
- Handmatige invalidatievragen.
Meer gedetailleerde en nuttige documentatie is beschikbaar op de volgende pagina’s:
http://docs.adobe.com/docs/en/dispatcher/disp-config.html
http://docs.adobe.com/docs/en/dispatcher/page-invalidate.html
Veelgestelde vragen
Hoe wis je de dispatcher cache in AEM?
Er zijn minstens 3 manieren om de Dispatcher-cache in AEM te wissen:
- Via flush agents op Author en/of op Publishes
- Handmatige flush
- Aangepaste code om de flush via programmering uit te voeren
Wat is dispatcher cache in AEM?
De Dispatcher is een AEM-caching- en load-balancingtool die gecachte bestanden op de webserver opslaat op dezelfde manier als een statische website.
Hoe controleer je Dispatcher-logs in AEM?
De Dispatcher-logs worden beheerd binnen de configuratie van de Dispatcher-module. Afhankelijk van je configuratie kan dit ofwel een apart .conf-bestand zijn in /etc/httpd/conf.d of binnen hetzelfde bestand als de Dispatcher vhost-configuratie.
Wat is het verschil tussen cache flush en invalidate in AEM?
Volgens de documentatie betekenen zowel flush als invalidatie hetzelfde.
“Om de Dispatcher-cache te invalideren (of te flushen) zonder een pagina te activeren, kun je een HTTP-verzoek naar de dispatcher sturen.”
Maar men kan gerust zeggen dat invalidatie een HTTP-aanroep is naar de Dispatcher om de gecachte bron als ongeldig te markeren (hetzelfde gebeurt wanneer de TTL van de bron verloopt). Terwijl flush meestal invalidatie betekent die wordt geactiveerd vanuit de Author-/Publish-instantie wanneer de content wordt gepubliceerd.
