At times I get this error on creation of new page or page refresh. Below is the Error details...
...
com.day.cq.wcm.core.impl.WCMDebugFilter Exception: org.apache.sling.api.SlingException: Cannot get DefaultSlingScript: Resource resolver is already closed.
Caused by: org.apache.sling.api.SlingException: Cannot get DefaultSlingScript: Resource resolver is already closed.
Caused by: java.lang.IllegalStateException: Resource resolver is already closed.
...
Any pointers?
Thank you in advance.
-Anuj Varshney
Solved! Go to Solution.
Views
Replies
Total Likes
Hi
I was reading an article, and got some information related to your problem.
//
Do not share nodes, resources and pages between threads and requests.
You might run into the case, that you need to share data between multiple threads or requests. A simple example for this is HTTP-Session or a cache which stores data you need to share between multiple or all incoming requests.
In such cases do not store nodes, pages or DAM assets or any other object based on a node or a resource in that cache. Each of these objects belongs to a certain session (or resource resolver instance), and they are not valid anymore if this session is logged out or if the resource resolver is closed; if you still try to execute methods on them, you will run into exceptions.
If you want to share such data, share objects which are not bound to any Session. So instead of putting pages in there, put the path to the page there instead. If you need the page again then, just use your own ResourceResolver, resolve it to a resource and adapt it to a page. You still can run into access control issues, if the second resources resolver does not see that node due to ACL constraints. In such a case you should think about your application design.
Another article as a reference link :- http://tech.ethomasjoseph.com/2015/09/sling-who-is-closing-my-jcr-session.html
//you should rely on Sling objects as much as possible, rather than relying directly on the JCR objects. But at those cases (e.g. writing to a repository) when you will have to directly rely on the JCR repository you will have to still use the JCR Session, its recommended that you directly get the JCR session from the Sling repository, and not adapt it from the ResourceResolver, IF you do not intend to use the ResourceResolver directly.
I hope this would help you.
Thanks and Regards
Kautuk Sahni
Views
Replies
Total Likes
Hi,
can you please post the stacktraces as well?
Thanks,
Jörg
Views
Replies
Total Likes
You're closing the resource resolver and then either the system or custom code is trying to use the session out of it.
Views
Replies
Total Likes
Hi Anuj,
Are you getting this error while creating page OOB or via a custom page create service ? Also can you provide us more details from log on this error
Views
Replies
Total Likes
Hi Ambuj,
This issue occurs when you are trying to use the session / resource resolver which is already closed and instead of creating a new session, you are trying to refer an old object.
--
Views
Replies
Total Likes
Hi
I was reading an article, and got some information related to your problem.
//
Do not share nodes, resources and pages between threads and requests.
You might run into the case, that you need to share data between multiple threads or requests. A simple example for this is HTTP-Session or a cache which stores data you need to share between multiple or all incoming requests.
In such cases do not store nodes, pages or DAM assets or any other object based on a node or a resource in that cache. Each of these objects belongs to a certain session (or resource resolver instance), and they are not valid anymore if this session is logged out or if the resource resolver is closed; if you still try to execute methods on them, you will run into exceptions.
If you want to share such data, share objects which are not bound to any Session. So instead of putting pages in there, put the path to the page there instead. If you need the page again then, just use your own ResourceResolver, resolve it to a resource and adapt it to a page. You still can run into access control issues, if the second resources resolver does not see that node due to ACL constraints. In such a case you should think about your application design.
Another article as a reference link :- http://tech.ethomasjoseph.com/2015/09/sling-who-is-closing-my-jcr-session.html
//you should rely on Sling objects as much as possible, rather than relying directly on the JCR objects. But at those cases (e.g. writing to a repository) when you will have to directly rely on the JCR repository you will have to still use the JCR Session, its recommended that you directly get the JCR session from the Sling repository, and not adapt it from the ResourceResolver, IF you do not intend to use the ResourceResolver directly.
I hope this would help you.
Thanks and Regards
Kautuk Sahni
Views
Replies
Total Likes
Views
Likes
Replies