BREAKING NEWS: Exadel named a Leader in this Forrester Agile Software Development Service Providers report... Learn more!  

AEM is constantly evolving, offering more new features with each new release. But, with so many new features, sometimes new platform features can affect existing home-grown functionality, even when they don’t seem to be related to each other.

Here’s an example. One day, after migrating to AEM 6.4, one of our public services available at /services/acme/myservice.json stopped working, and the following message appeared in the logs:

After some investigation it appeared that:

  • The issue happens after AEM has performed an online revision cleanup
  • The issue goes away after an AEM server restart

In fact a Sling Servlet behind /services/acme/myservice.json was referencing and using the com.acme.www.service.impl.MyServiceImpl service. We searched through the log files and found the following messages related to that MyServiceImpl service:

When we checked the MyServiceImpl code, we saw this anti-pattern:

As you can see above, a resource resolver was created once upon component activation and was alive while the component was alive. That caused the idle session issue (see the stack trace above). The long-lived resource resolver was referencing a segment that was altered by online revision cleanup. Therefore, the subsequent calls of the perform() method of MyServiceImpl were causing the “Segment not found” error that we noted at the beginning of this post.

As a response, we followed the best practice of creating a resource resolver when it’s required and closing it when it’s not needed anymore. So, we refactored MyServiceImpl to look like this:


For more information about handling the lifecycle of resource resolvers, please see our previous post on Creating a Helper to Close Sling Resource Resolver Instances.

NEW! Want to test new technologies like blockchain, AI, mobile, chatbot, and machine learning models? Learn about our Innovation Lab.