Resource Resolver Leak | Community
Skip to main content
Level 2
June 15, 2021
Solved

Resource Resolver Leak

  • June 15, 2021
  • 3 replies
  • 2078 views

Hi All,

 

We are facing this warning message multiple times in our 6.5.6 AEM environment. 

 

11.01.2018 01:03:18.878 *INFO* [Apache Sling Resource Resolver Finalizer Thread] org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl Unclosed ResourceResolver was created here
 
From version 6.3 Adobe had recommended this workaround Solution (url given below), I just want to know if this is still a known bug like do we have any update for this in recent Service Packs.
https://helpx.adobe.com/bg/experience-manager/kb/Unclosed-ResourceResolver-warnng-at-com-day-cq-search-impl-builder-QueryBuilderImpl.html
 
Also we are getting this error even when there is no Querybuilder API being hit.
 
Thanks!
 
This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by MarkusBullaAdobe

Hi @user21583!

 

The INFO level log message that you have posted is a warning mechanism of AEM to bring resource resolvers to your attention that are not correctly handled (specifically: not closed properly). The source of that unclosed resource resolver can usually be spotted in the stack trace that follows. Please refer to the stack trace after "Unclosed ResourceResolver was created here:" in your log file to start your analysis of the root cause of the unclosed resource resolver.

 

While there have been issues with actual AEM product code not correctly handling and closing resource resolvers in the past (as mentioned in the KB article that you are referencing), I'm not aware of any know issues with latest versions of AEM. In my experience, most of these cases are somehow (directly or indirectly) caused by custom project code. If your analysis points to AEM product code as a source of the improper handling of a resource resolver, please create a support ticket so that our customer care and engineering teams can check.

 

How to handle resource resolvers correctly?

Please refer to the Sling API and this thread for more information on how to correctly handle (e. g. open and close) resource resolvers.

From the API documentation:

A Resource Resolver has a life cycle which begins with the creation of the Resource Resolver using any of the factory methods and ends with calling the close() method. It is very important to call the close() method once the resource resolver is not used any more to ensure any system resources are properly clean up.

From the thread (answer by @feike_visser1) :

Follow the rule "You open a resourceResovler / Session, You Close it". 

If this is not the case, leave it...

 

Also, @joerghoh covers this in his blog post on CQ development patterns (see "2nd pattern: Ownership: You open it — you close it.") and as mentioned by @bhuwan_b he recommends to leverage the try-with-resource pattern in another article.

 

Hope that helps!

3 replies

Ritesh_Mittal
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
June 15, 2021

Hi @user21583 ,

 

If you use Try-with-Resource for ResoureResolver then you will not get such warnings, else you need to close that in finally block.

 

try (ResourceResolver resolver = resourceResolverFactory.getServiceResourceResolver(…)) {
// ResourceResolver will be closed automatically ater this
}

 

Bhuwan_B
Community Advisor
Community Advisor
June 15, 2021

@user21583 Please check below URL:

https://cqdump.joerghoh.de/2018/11/14/try-with-resource-or-i-will-never-forget-to-close-a-resource-resolver/

In Java 7 the idiom “try-with-resource”  has been introduced in the java world. It helps to never forget to close a resource. And since Sling9 (roughly 2016) the ResourceResolver interface implements the AutoCloseable marker interface, so the try-with-resource idiom can be used.

That means, that you can and should use this approach:

try (ResourceResolver resolver = resourceResolverFactory.getServiceResourceResolver(…)) {
// do something with the resolver
// no need to close it explicitly, it's closed automatically
}

 

MarkusBullaAdobe
Adobe Employee
MarkusBullaAdobeAdobe EmployeeAccepted solution
Adobe Employee
June 15, 2021

Hi @user21583!

 

The INFO level log message that you have posted is a warning mechanism of AEM to bring resource resolvers to your attention that are not correctly handled (specifically: not closed properly). The source of that unclosed resource resolver can usually be spotted in the stack trace that follows. Please refer to the stack trace after "Unclosed ResourceResolver was created here:" in your log file to start your analysis of the root cause of the unclosed resource resolver.

 

While there have been issues with actual AEM product code not correctly handling and closing resource resolvers in the past (as mentioned in the KB article that you are referencing), I'm not aware of any know issues with latest versions of AEM. In my experience, most of these cases are somehow (directly or indirectly) caused by custom project code. If your analysis points to AEM product code as a source of the improper handling of a resource resolver, please create a support ticket so that our customer care and engineering teams can check.

 

How to handle resource resolvers correctly?

Please refer to the Sling API and this thread for more information on how to correctly handle (e. g. open and close) resource resolvers.

From the API documentation:

A Resource Resolver has a life cycle which begins with the creation of the Resource Resolver using any of the factory methods and ends with calling the close() method. It is very important to call the close() method once the resource resolver is not used any more to ensure any system resources are properly clean up.

From the thread (answer by @feike_visser1) :

Follow the rule "You open a resourceResovler / Session, You Close it". 

If this is not the case, leave it...

 

Also, @joerghoh covers this in his blog post on CQ development patterns (see "2nd pattern: Ownership: You open it — you close it.") and as mentioned by @bhuwan_b he recommends to leverage the try-with-resource pattern in another article.

 

Hope that helps!