Expand my Community achievements bar.

SOLVED

Dispatcher statfileslevel and Cache flush mechanism

Avatar

Level 3

Hi Community Experts,

Recently while going through the dispatcher flush mechanism, I felt for our scenario the OOTB mechanism is not completely suitable. Please correct me, if my understanding is wrong.

My understanding (After doing an end to end setup):

  1. Whenever any file is getting activated from author to publisher instance, dispatcher flush agent will be called and this will create/touch a zero kb file named as ".stat" under the webserver's docroot.
  2. The above said stat file will be created/touched under as many as levels based on the value specified against statfileslevel.
  3. When any page is being requested via dispatcher from a browser, then the requested page's time stamp will be compared against the stat file's time stamp. If the stat file is latest, then the request will be served from publisher. Else the cached version will be sent as a response.

Our scenario:

As per our business requirement, we have a listing page as well as detail pages. For instance please find the below paths:

  1. /content/my-project/en/home
  2. /content/my-project/en/home/article-listing
  3. /content/my-project/en/home/article-listing/article-detail-1
  4. /content/my-project/en/home/article-listing/article-detail-2
  5. ...
  6. /content/my-project/en/home/article-listing/article-detail-50

For the above structure, when author activates any one of the article-detail page, then the cache flush is happening for all the detail page, ideally which is not required. For an update in 1 page, 49 other page's cache is also getting flushed upon request, even when there are no changes happened to those 49 pages (as the stat file to be compared is located at the same level).

Is there any specific statfileslevel value which I can tweak to avoid the above behavior? Else am I missing anything?

Thanks!

Dinesh kumar L.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hello Dinesh,

Why cant you use "CQ-Action-Scope: ResorceOnly"

replication-agent-config-cq-action-scope-resourceonly.png

View solution in original post

4 Replies

Avatar

Correct answer by
Community Advisor

Hello Dinesh,

Why cant you use "CQ-Action-Scope: ResorceOnly"

replication-agent-config-cq-action-scope-resourceonly.png

Avatar

Level 3

You can increase the statfileslevel to deep level. Then only that page alone will be flushed. And write some custom code(EventListener) to flush the listing page.

Avatar

Level 3

Hi Shashi,

Thanks for your reply. We were trying multiple ways to achieve this requirement. Yes we can make use of "CQ-Action-Scope: ResorceOnly" and using ACS common's dispatcher flush rule for clearing listing page or any other dependent page's cache.

Thanks,

Dinesh Kumar L

Avatar

Level 3

Hi Chandu,

Thanks for your pointers. Increasing the statfileslevel will not help much in our scenario, as all the detail pages are located at same level and it will refer a single stat file always.

Thanks,

Dinesh Kumar L