Hi Everyone,
I am developing an AEM component on AEMaaCS instance (headful approach).
I need to get content fragment data and display it on the page using the AEM component in headful architecture. I am using Sling model to make a call to graphql endpoint.
I used Apache libraries HttpGet, CloseableHttpClient to make a GET call to graphql endpoint.
The code works fine in local AEM instance but on AEMaaCS, it gives a "read timed out" error while making the graphql call.
Any help in resolving this issue?
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
ERROR Error in Response: Read timed out
java.net.SocketTimeoutException: Read timed out
at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:278)
Views
Replies
Total Likes
Hi @grandhip ,
The “read timed out” error happens because AEM as a Cloud Service blocks or limits direct HTTP calls from backend Java code (like with HttpClient) to its own GraphQL endpoint for security and performance reasons. This works locally, but in the cloud, these calls often get blocked, delayed, or don’t go through.
What you should do:
Switching to these supported methods will make your component work smoothly on AEMaaCS.
Thanks,
Vishal
Views
Replies
Total Likes
Hi @VishalKa5 ,
The reason for leaning towards graphql endpoint instead of AEM APIs like Content Fragment API is because.
1. The JSON schema is nested 3-4 levels deep and iteration logic with the nested CFs is more complicated to handle.
2. We have a headless app that uses the graphql endpoint for same content so we want to be maintain sync between headless vs headful (AEM) apps.
Thank you,
Pavan
Views
Replies
Total Likes
Hi @grandhip
Please try this below ways:
Your problem: AEMaaCS blocks your Java code from making HTTP calls back to itself. It's a security thing in the cloud.
Best fix: Don't use HttpClient at all. Instead, use AEM's built-in GraphQL Java client or Content Fragment APIs that work internally without HTTP calls.
Quick alternative: If you must keep your current approach, increase your timeout settings to 30+ seconds and make sure you're calling the GraphQL endpoint using an internal path (not the full external URL). AEMaaCS is just slower than local.
If nothing works: You'll need to configure "Advanced Networking" in Cloud Manager to allow your environment to make these calls, but that's overkill for this use case.
Bottom line: Switch from HttpClient to AEM's internal GraphQL client libraries. Same queries, same results, but works properly in the cloud.
Thank you
Views
Replies
Total Likes
Reason your GraphQL call works locally but times out on AEMaaCS is probably because making HTTP calls to your own AEM instance from within AEM (like using `CloseableHttpClient` to call the GraphQL endpoint) isn’t really supported in the cloud setup. AEMaaCS runs in a containerized, secure environment, and internal HTTP calls can run into network restrictions — which is likely maybe why you're seeing that read timed out error.
What You Can Do Instead
Since you're building a headful component (not a headless app), you probably don’t need to call GraphQL from the backend at all. A better approach is to use the Content Fragment API directly in your Sling Model. This lets you work with content fragments without making a network call, and it’s much more efficient in AEMaaCS.
Adobe provides a full Java API for working with Content Fragments. You can find the official documentation here:
Content Fragment Java API – AEM 6.5 - https://developer.adobe.com/experience-manager/reference-materials/6-5/javadoc/com/adobe/cq/dam/cfm/...
You can use this API (com.adobe.cq.dam.cfm) to directly read structured content, elements, and metadata from the content fragment in your Sling Model — no need to call the GraphQL endpoint.
Instead of calling GraphQL, your model could:
This way, everything stays in-process and fast, and you're not depending on a fragile network call that might get blocked or timeout in the cloud using the Content Fragment API (com.adobe.cq.dam.cfm).
Views
Replies
Total Likes
Hi @BrianKasingli ,
The reason for implementing graphql endpoint instead of AEM APIs like Content Fragment API is because.
1. The JSON schema is nested 4 levels deep and iteration logic with the nested CFs is more complicated to handle.
2. We have a headless app that uses the graphql endpoint for same content so we want to be maintain sync between headless vs headful (AEM) apps.
Views
Replies
Total Likes
Hello @grandhip
For headful (WCM/Sites) components, you can also access Content Fragments using the Sling Models API :
For Example :
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/sites/administer...
If you want to expose fragment data as JSON, build a Sling Model Exporter :
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/dev...
GraphQL API can be used from *external* clients needing headless content delivery :
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/sites/administer...
Views
Replies
Total Likes
Hi @muskaanchandwani ,
I am aware that the graphql is meant for headless but is there any limitation that it cannot be used in headful (AEM components)?
I haven't see any official documentation around the limitation of graphql with in AEM headful architecture.
The reasons for implementing graphql endpoint instead of AEM APIs like Content Fragment API is because.
1. The JSON schema is nested 4 levels deep and iteration logic with the nested CFs is more complicated to handle.
2. We have a headless app that uses the graphql endpoint for same content so we want to be maintain sync between headless vs headful (AEM) apps.
Thank you,
Pavan
Views
Replies
Total Likes
Views
Likes
Replies