Expand my Community achievements bar.

SOLVED

Repository exception in com.day.cq.tagging.impl.JcrTagImpl

Avatar

Level 3

Hi all,

 

Gettting the below exception from one of the servlet. This is only happening on publish instance.

Not sure why this is happening.

 

17.05.2024 15:39:57.127 *INFO* [192.168.65.1 [1715940596900] GET /bin/pall/menu.html HTTP/1.1] com.pall.dotcom.service.utils.filters.TaxonomyPageFilter cache key:class=com.pall.dotcom.service.models.PallTaxonomyPage,path=/content/pall/type/en/biotech-cellculture
17.05.2024 15:39:57.127 *ERROR* [192.168.65.1 [1715940596900] GET /bin/pall/menu.html HTTP/1.1] com.day.cq.tagging.impl.JcrTagImpl Could not retrieve node path
javax.jcr.RepositoryException: This session has been closed.
at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.checkAlive(SessionDelegate.java:371) [org.apache.jackrabbit.oak-jcr:1.60.0.T20240131102219-0cde853]
at org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:83) [org.apache.jackrabbit.oak-jcr:1.60.0.T20240131102219-0cde853]
at org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34) [org.apache.jackrabbit.oak-jcr:1.60.0.T20240131102219-0cde853]
at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:675) [org.apache.jackrabbit.oak-jcr:1.60.0.T20240131102219-0cde853]
at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:226) [org.apache.jackrabbit.oak-jcr:1.60.0.T20240131102219-0cde853]
at org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:113) [org.apache.jackrabbit.oak-jcr:1.60.0.T20240131102219-0cde853]
at org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:145) [org.apache.jackrabbit.oak-jcr:1.60.0.T20240131102219-0cde853]
at org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:112) [org.apache.jackrabbit.oak-jcr:1.60.0.T20240131102219-0cde853]
at com.day.cq.tagging.impl.JcrTagImpl.getPath(JcrTagImpl.java:278) [com.day.cq.cq-tagging:5.13.28]
at com.day.cq.tagging.impl.JcrTagImpl.toString(JcrTagImpl.java:754) [com.day.cq.cq-tagging:5.13.28]
at java.base/java.lang.String.valueOf(String.java:2951)
at java.base/java.util.Arrays.toString(Arrays.java:5113)
at com.pall.dotcom.service.models.PallPageContent.toString(PallPageContent.java:263) [com.pall.dotcom.pall-corp-aem:0.0.1.SNAPSHOT]

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Level 3

The issue was that Dev publisher was trying to read tags from /etc path although there were no tags in /etc and we had tags under /content/cq:tags path. Then for resolving this, we added the below JcrTagManagerFactoryImple config json through code to disable the /etc path tag reading by setting legacySupport.enable as false.

 

com.day.cq.tagging.impl.JcrTagManagerFactoryImpl

 

"validation.enabled":true,

"legacySupport.enabled":false

 

This resolved the issue and environment started picking tags from /content/cq:tags path.

View solution in original post

4 Replies

Avatar

Level 10

Hi @pardeepg4829047 ,

The exception you're encountering, javax.jcr.RepositoryException: This session has been closed., typically indicates that the JCR session being used to access repository data has been closed prematurely. This can happen due to various reasons, such as session timeouts, explicit closure of the session, or issues with session management.

Here are a few steps you can take to troubleshoot and potentially resolve this issue:

  1. Session Management:

    • Review the code where JCR sessions are being obtained and used. Ensure that sessions are being properly managed, i.e., being opened when needed, used, and then closed appropriately.
    • Make sure that no session is being used after it has been closed.
  2. Session Timeout:

    • Check if there's a session timeout configured in your application or server settings. Sessions should be closed before they time out to prevent this exception.
  3. Exception Handling:

    • Implement proper exception handling in your code to catch and handle exceptions related to JCR sessions. This can help in identifying the root cause of the session closure.
  4. Logging:

    • Enable debug logging for JCR-related classes or packages. This can provide more detailed information about the sequence of events leading up to the session closure and help pinpoint the issue.
  5. Review Custom Code:

    • Look into any custom code (like the PallPageContent class mentioned in the stack trace) that interacts with JCR sessions or tagging functionality. Ensure that it's handling sessions correctly and not causing premature closure.
  6. Environment Differences:

    • Since the issue is specific to the publish instance, compare the configuration and environment settings between your author and publish instances. There might be differences in session management or resource availability that could be causing the problem.
  7. Vendor Support:

    • If you're unable to identify the issue or resolve it based on the above steps, consider reaching out to the vendor's support team for assistance. They might be able to provide further insights or solutions specific to your setup.

By investigating these areas, you should be able to diagnose the cause of the session closure and take appropriate actions to address it.

Avatar

Community Advisor

The answer is in the logs,

com.day.cq.tagging.impl.JcrTagImpl Could not retrieve node path

 

So in this case, either your repository does not have the correct permissions in the publisher to find the cq:tag node, OR, the tag just never exists.


Avatar

Level 3

Hi Brian,

 

The tags exist under /content/cq:tags.

 

Also, the same code is working fine in local publisher and able to read the tags with no issues.

The issue is coming, when we are moving the code to AEMaaCS Dev environment. In Dev environment, on author the code is working but on publisher, this issue is coming. Do we need any additional steps or permissions in publish environment on cloud for tags ?

 

Thanks,

Pardeep

Avatar

Correct answer by
Level 3

The issue was that Dev publisher was trying to read tags from /etc path although there were no tags in /etc and we had tags under /content/cq:tags path. Then for resolving this, we added the below JcrTagManagerFactoryImple config json through code to disable the /etc path tag reading by setting legacySupport.enable as false.

 

com.day.cq.tagging.impl.JcrTagManagerFactoryImpl

 

"validation.enabled":true,

"legacySupport.enabled":false

 

This resolved the issue and environment started picking tags from /content/cq:tags path.