Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Resource Resolver Leak

SagarVerliani
Level 2
Level 2

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-sear...
 
Also we are getting this error even when there is no Querybuilder API being hit.
 
Thanks!
 
1 Accepted Solution
markus_bulla_adobe
Correct answer by
Employee
Employee

Hi @SagarVerliani!

 

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, @Jörg_Hoh 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!

View solution in original post

3 Replies
Ritesh_Mittal
Community Advisor
Community Advisor

Hi @SagarVerliani ,

 

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

@SagarVerliani Please check below URL:

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

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
}

 

markus_bulla_adobe
Correct answer by
Employee
Employee

Hi @SagarVerliani!

 

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, @Jörg_Hoh 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!

View solution in original post