Dispatcher statfileslevel and Cache flush mechanism | Community
Skip to main content
D
Dineshkumar_L
Level 3
October 29, 2018
Solved

Dispatcher statfileslevel and Cache flush mechanism

  • October 29, 2018
  • 4 replies
  • 2845 views

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.

    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 Shashi_Mulugu

    Hello Dinesh,

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

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

    4 replies

    Shashi_Mulugu
    Community Advisor
    Shashi_MuluguCommunity AdvisorAccepted solution
    Community Advisor
    October 29, 2018

    Hello Dinesh,

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

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

    chandu_t
    chandu_t
    Level 3
    October 29, 2018

    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.

    D
    Dineshkumar_LAuthor
    Level 3
    October 30, 2018

    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

    D
    Dineshkumar_LAuthor
    Level 3
    October 30, 2018

    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

      Terms & ConditionsAccessibility statement

      Loading footer...