AEM Tip: Learning from a “Segment not found” ErrorAEM Tip: Learning from a “Segment not found” Error

Tech Tips

6 min read

Modern abstract sculpture with geometric shapes casting a shadow on a blue background.

Table of Contents

Tags

#AEM

#AEM Tips

#Apache Sling

#Digital Marketing Technology

Share

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:

‍

11.09.2018 17:59:24.403 *ERROR* [12.345.6.7 [1536688764343] GET /services/acme/myservice.json HTTP/1.1] org.apache.jackrabbit.oak.segment.SegmentNotFoundExceptionListener Segment not found: e851f378-0da9-4f99-a34b-2d2e036a40b1. SegmentId age=344865269ms,segment-generation=GCGeneration{generation=7,fullGeneration=2,isCompacted=false}
org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment e851f378-0da9-4f99-a34b-2d2e036a40b1 not found

‍

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:

‍

11.09.2018 18:57:05.949 *WARN* [qtp1796865675-2034] org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been idle for 23 minutes and might be out of date. Consider using a fresh session or explicitly refresh the session.
java.lang.Exception: The session was created here:
       at org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.(RefreshStrategy.java:170) [org.apache.jackrabbit.oak-jcr:1.8.2]
       at org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:285) [org.apache.jackrabbit.oak-jcr:1.8.2]
       at org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:226) [org.apache.jackrabbit.oak-jcr:1.8.2]
       at org.apache.jackrabbit.oak.jcr.session.SessionImpl.impersonate(SessionImpl.java:275) [org.apache.jackrabbit.oak-jcr:1.8.2]
       at com.adobe.granite.repository.impl.CRX3SessionImpl.impersonate(CRX3SessionImpl.java:149) [com.adobe.granite.repository:1.4.88]
       at org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:201) [org.apache.sling.jcr.base:3.0.4]
       at com.adobe.granite.repository.impl.SlingRepositoryImpl.createServiceSession(SlingRepositoryImpl.java:135) [com.adobe.granite.repository:1.4.88]
       at org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:171) [org.apache.sling.jcr.base:3.0.4]
       at org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:381) [org.apache.sling.jcr.base:3.0.4]
       at org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:116) [org.apache.sling.jcr.resource:3.0.8]
       at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:304) [org.apache.sling.jcr.resource:3.0.8]
       at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:76) [org.apache.sling.jcr.resource:3.0.8]
       at org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticate(ProviderManager.java:161) [org.apache.sling.resourceresolver:1.5.34]
       at org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.getOrCreateProvider(ProviderManager.java:87) [org.apache.sling.resourceresolver:1.5.34]
       at org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticateAll(ProviderManager.java:129) [org.apache.sling.resourceresolver:1.5.34]
       at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.createControl(ResourceResolverImpl.java:138) [org.apache.sling.resourceresolver:1.5.34]
       at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:100) [org.apache.sling.resourceresolver:1.5.34]
       at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:94) [org.apache.sling.resourceresolver:1.5.34]
       at org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:263) [org.apache.sling.resourceresolver:1.5.34]
       at org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getServiceResourceResolver(ResourceResolverFactoryImpl.java:96) [org.apache.sling.resourceresolver:1.5.34]
       at com.acme.www.service.impl.MyServiceImpl.activate(MyServiceImpl.java:99) [com.acme.www.web-services:1.23.4.5]

‍

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

‍

@Reference
private ResourceResolverFactory resourceResolverFactory;
 
@Activate
protected void activate(final ComponentContext componentContext) {
    try {
        //Resource Resolver is created on a component activation
        this.resourceResolver = resourceResolverFactory.getServiceResourceResolver(resourceResolverParams);
        ...
    } catch (Exception e) {
        ...
    }
}
 
public void perform() {
    this.resourceResolver.resolve(...);
}

‍

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:

‍

@Reference
private ResourceResolverFactory resourceResolverFactory;
 
@Activate
protected void activate(final ComponentContext componentContext) {
    //Resource Resolver creation was removed from here
    ...
}
 
private void perform() {
    try (ResourceResolver resourceResolver = resourceResolverFactory.getServiceResourceResolver(...)) {
        resourceResolver.resolve(...);
    } catch (Exception e) {
        ...
    }
}

‍

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.

‍

Author: Denis Glushkov

‍

Resource Hub

Our Latest Stories & Industry Insights

View Resource Hub

Rogério Pedro on Empathy, Collaboration, and Career Growth

5 min read

November 2, 2026

Verification Engineering: Code Is Cheap, Proof Is The Product

12 min read

November 2, 2026

Women in Exadel: Let's Talk About Leadership, AI, and the Human Side of Technology

10 min read

October 29, 2026

Legacy Modernization With AI Agents: Build the Test Baseline First

5 min read

October 28, 2026

Building a Bidirectional IoT System

7 min read

October 27, 2026

5 Things Senior Engineers Get Wrong About AI

5 min read

October 26, 2026
Two people sitting at a table with a laptop.

Let’s make your next project faster, safer, smarter.

Get In Touch