Qu'est-ce qu'un ResourceResolver Sling ?
Comment le ResourceResolver de Sling associe le contenu JCR à des Resources, pourquoi il doit être fermé, et comment les fuites se produisent dans AEM.
Un ResourceResolver est l’API Apache Sling permettant de résoudre un chemin
(ou une requête) en un Resource. Il s’appuie sur une Session JCR et
constitue le principal moyen par lequel le code AEM lit et écrit du contenu.
Pourquoi il doit être fermé
Chaque ResourceResolver obtenu depuis un ResourceResolverFactory enveloppe
une session JCR active. Si vous ne le fermez pas, la session sous-jacente —
et les ressources qu’elle détient (verrous, caches, listeners) — reste active
jusqu’à ce que le ramasse-miettes s’en aperçoive, ce qui sur une instance
author ou publish très sollicitée peut représenter des milliers de sessions
perdues et, à terme, une OutOfMemoryError.
try (ResourceResolver resolver = resolverFactory.getServiceResourceResolver(params)) {
Resource page = resolver.getResource("/content/we-retail/us/en");
// travailler avec la resource
} // resolver.close() est appelé automatiquement
Récupérez toujours un ResourceResolver dans un bloc try-with-resources (ou
un finally équivalent). C’est la cause la plus fréquente de fuites de
ressources dans le code AEM personnalisé.
Où cela se produit
- Des jobs planifiés (services
Runnable/Scheduler) qui créent un resolver mais ne le ferment jamais sur un chemin de retour anticipé. - Des Sling Models qui stockent un resolver comme champ au lieu d’en emprunter un par requête.
- Des gestionnaires d’événements qui ouvrent un resolver dans une boucle au lieu d’en réutiliser un seul.