Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Setting cache headers for CQSE 404 page

Avatar

Former Community Member

Hi,

Need help with figuring out a solution for an issue in our CQ environment. The scenario:

  1. Publish restarts in a not controlled way (maybe due to an OOM)
  2. Instance is still reachable via the Net.
  3. During startup a default 404 page is delivered from CQSE(?). This is before the "500 starting up"-phase.
  4. A visitor accesses the site during this short startup phase
  5. Startup 404 page is forwarded through dispatcher (where the default cache timeout is set to 1hr)
  6. 404 page is cached in CDN until purged

In normal circumstances 404s are forwarded to a non-existing page to trigger Sling error handling (so that the no-cache headers are set, which is done in the overlayed Sling error handler).
We do not want the 404's to be cached in our CDN.

One thought has been to modify the response headers in the dispatcher httpd.conf. Found a solution for Apache 2.4 (which unfortunately is not supported for our windows platform). I have not been able to find a similar solution for Apache 2.2.

Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"

What I am looking for is suggestions on how to catch this "startup" 404 page in the best possible way and modify it with no-cache response headers.

I know that it is kind of a corner case. In normal circumstances access to a server in startup mode has been disabled by removing access to the environment in our loadbalancer.
But unfortunately we have had problems with unexpected shutdowns lately (an area we also are focusing on).

Our setup: author (5.6.1) - publish (5.6.1) - dispatcher (Apache 2.2) - load balancer - cdn (Akamai) on a windows platform.

1 Accepted Solution

Avatar

Correct answer by
Level 10
  1. Configure dispatcher to serve stale content[1] & healthcheck.
  2. When publish instance is down, Block the dispatcher from seeing publish host until system is up by Sending a TCP Reset. Once instance is up then accept the traffic. (Your network team can help to write this small script)

Lastly take official help to find why publish restarts automatically & fix the actual issue.

[1]   http://helpx.adobe.com/experience-manager/kb/ServeStaleContentOnError.html

http://www.wemblog.com/2012/05/how-to-use-dispatcher-to-serve-cache.html

View solution in original post

3 Replies

Avatar

Correct answer by
Level 10
  1. Configure dispatcher to serve stale content[1] & healthcheck.
  2. When publish instance is down, Block the dispatcher from seeing publish host until system is up by Sending a TCP Reset. Once instance is up then accept the traffic. (Your network team can help to write this small script)

Lastly take official help to find why publish restarts automatically & fix the actual issue.

[1]   http://helpx.adobe.com/experience-manager/kb/ServeStaleContentOnError.html

http://www.wemblog.com/2012/05/how-to-use-dispatcher-to-serve-cache.html

Avatar

Employee Advisor

Hi,

your problem is step 2; if you are using a loadbalancer, you should configure it not to send requests to a non-working CQ instance. For this configure the loadbalancer's healtcheck URI to either a specially crafted page (or servlet, that's the preferred way) or a regular content page, and append a query string to it; this makes sure, that the dispatcher isn't caching the response. Then when your publish goes down, the loadbalancer isn't sending any request to it anymore.

Regards,
Jörg