Setting cache headers for CQSE 404 page | Community
Skip to main content
A
Anonymous
October 16, 2015
Solved

Setting cache headers for CQSE 404 page

  • October 16, 2015
  • 3 replies
  • 849 views

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Sham_HC
  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

3 replies

Sham_HC
Sham_HCAccepted solution
Level 10
October 16, 2015
  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

joerghoh
Adobe Employee
joerghohAdobe Employee
Adobe Employee
October 16, 2015

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

A
Anonymous
October 16, 2015

Thx

Will investigate this approach.

Terms & ConditionsAccessibility statement

Loading footer...