Hello,
We have AMS managed AEM. Whenever the code is merged, the build process is automatically initiated and the code is deployed to cloud manager QA and we then manually flush dispatcher cache. Is there a way, where we can automate the dispatcher flushing in non-production pipeline-QA?
Any suggestions are appreciated.
Thanks in advance!
Ram
Views
Replies
Total Likes
Refer below-
The following code implements a servlet that sends an invalidate request to Dispatcher. The servlet receives a request message that contains handle and page parameters. These parameters provide the value of the CQ-Handle header and the path of the page to recache, respectively. The servlet uses the values to construct the HTTP request for Dispatcher.
When the servlet is deployed to the publish instance, the following URL causes Dispatcher to delete the /content/geometrixx-outdoors/en.html page and then cache a new copy.
10.36.79.223:4503/bin/flushcache/html?page=/content/geometrixx-outdoors/en.html&handle=/content/geometrixx-outdoors/en/men.html
This example servlet is not secure and only demonstrates the use of the HTTP Post request message. Your solution should secure access to the servlet.
package com.adobe.example; import org.apache.felix.scr.annotations.Component; import org.apache.felix.scr.annotations.Service; import org.apache.felix.scr.annotations.Property; import org.apache.sling.api.SlingHttpServletRequest; import org.apache.sling.api.SlingHttpServletResponse; import org.apache.sling.api.servlets.SlingSafeMethodsServlet; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.apache.commons.httpclient.*; import org.apache.commons.httpclient.methods.PostMethod; import org.apache.commons.httpclient.methods.StringRequestEntity; @Component(metatype=true) @Service public class Flushcache extends SlingSafeMethodsServlet { @Property(value="/bin/flushcache") static final String SERVLET_PATH="sling.servlet.paths"; private Logger logger = LoggerFactory.getLogger(this.getClass()); public void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) { try{ //retrieve the request parameters String handle = request.getParameter("handle"); String page = request.getParameter("page"); //hard-coding connection properties is a bad practice, but is done here to simplify the example String server = "localhost"; String uri = "/dispatcher/invalidate.cache"; HttpClient client = new HttpClient(); PostMethod post = new PostMethod("https://"+host+uri); post.setRequestHeader("CQ-Action", "Activate"); post.setRequestHeader("CQ-Handle",handle); StringRequestEntity body = new StringRequestEntity(page,null,null); post.setRequestEntity(body); post.setRequestHeader("Content-length", String.valueOf(body.getContentLength())); client.executeMethod(post); post.releaseConnection(); //log the results logger.info("result: " + post.getResponseBodyAsString()); } }catch(Exception e){ logger.error("Flushcache servlet exception: " + e.getMessage()); } } }
Thanks Ankur, I have seen this code in adobe documentation. I want to flush the dispatcher content when a package is installed on publish instance. What could be the best possible solution? Is it a workflow launcher or event listener or something else?
Thanks,
Ram
Hi @RamTejaReddy When you say package is installed on the publish instance, are you talking about the code package or any kind of content package?
If it's a code package, then you can add a shell script in the Jenkins which can run after the deployment step and can flush the dispatcher cache based on the path that you have configured.
Thanks!
Please check below blog which has info on shell script and how to configure Jenkins job for auto cache clear.
https://aem6solutions.blogspot.com/2019/11/cache-clearance-in-dispatcher.html
Thanks
Hey @RamTejaReddy how do you flush the dispatcher manually? Can you sahre that info please?
Thanks in advance.
Hi @israel_sanchez you can manually flush the dispatcher cache by the following path in any environment: /etc/acs-commons/dispatcher-flush/complete-flush.html.
Hope this helps.
Thanks,
Ram
Views
Likes
Replies