Targeting Replication Agents based on Content Path

Hi @supportmember ,

Please check with your dispatcher configuration and verify what is?

/statfileslevel "0"

- statefile lelvel 0 - A single .stat file will be created at the root of the cache directory.
/.stat

- statefile lelvel 1 - .stat file at root of the cache and under each direct child directory.
/.stat
/content/.stat

- statefile level 2 - .stat file at root of cache and under each direct child directory and each of their  direct  child directories:
/.stat
/content/.stat
/content/foo/.stat
/content/bar/.stat 

in your case it looks "0" hence invalidating the files under root level ie. brand1, brand2 & brand3, you can setup specific configs for each of them respectively and that should solve your problem.

Adobe's recommended solution having multi-brands:

For Dispatcher Flush agents, the URI property is used only if you use path-based virtualhost entries to differentiate between farms. You use this field to target the farm to invalidate. For example, farm #1 has a virtual host of www.mysite.com/path1/* and farm #2 has a virtual host of www.mysite.com/path2/*. You can use a URL of /path1/invalidate.cache to target the first farm and /path2/invalidate.cache to target the second farm. For more information, see Using Dispatcher with Multiple Domains.

for more details please read these articles: 

1. https://www.google.com/search?q=aem+dispatcher+stat+file+level&rlz=1C5GCEM_enCA975CA975&oq=aem+statfile+leve&aqs=chrome.2.69i57j0i22i30j0i390l5.6165j1j7&sourceid=chrome&ie=UTF-8&safe=active&ssui=on
2. https://www.aemrules.com/2020/04/dispactherhacks-statfile.html

Hope that helps you!

Regards,

Santosh

Hi @supportmember ,

This is expected behavior as per your configurations. Let me explain why.

You are having multiple brands. Each brand is having one farm file and domain. These farm files are bind to brands using domain (using VirtualHost). Whenever any request comes from any brand domain. A brand specific farm file load as per domain for specific brand.

 For ex. - For brand1 you have fram1.farm and domain brand1.com, So whenever any request comes from brand1.com as per configuration farm1.farm load. It works in same way for other brands as well.

But when you publish any page, Cache invalidation required comes from author domain/IP and you did not define any farm for this request. So, this request will be routed to fallback/default farm. Or if you don’t have default/fallback farm, it will pick first farm in the available farms. In your case mainFarm may be your default/fallback farm as your configs.

Brand1.com ->farm1.farm -> brand1
Brand2.com ->farm2.farm -> brand1
Author.com->no farm file-> load mainFarm

One Possible Solution:

Add a specific farm file to invalidate cache and bind this to author domain/IP. So, whenever you publish any page, this farm will load and invalidate/delete cache as per configs. This is something adobe recommended. I will leave document link at end.

To prevent unexpected cache invalidation/delete
To prevent invalidate/delete for all level cache, you have to correctly set /statfileslevel to correct level. This is calculated from /docroot. Calculate as per your configuration.
Invalidation request from Dispatcher flush agent should already having CQ-Action-Scope:ResourceOnly in header. So, it will only invalidate/delete cache for published page/asset. If cache being invalidated from root to published page level then check CQ-Action-Scope in your request header. If you don't have then Check dispatcher flush agent configurations.

Go to 4th tab (Extended). Check HTTP Headers, you must see 3 entries pre-configured.

Document to handle multi brand/domain cache - https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/dispatcher-domains.html?lang=en

Document for cache configurations - https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html?lang=en#configuring-the-dispatcher-cache-cache

This answer is based on what did I understand from your question/details provided. If you have some additional configuration, behavior may be different.