Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Introducing the AEM Dispatcher Optimizer Tool | AEM Community Blog Seeding




Introducing the AEM Dispatcher Optimizer Tool by Bruce Lefebvre


What defines an “optimal” Adobe Experience Manager (AEM) Dispatcher configuration? And if there really is such a thing, why not just print it here in place of this post? Better yet, prevent anyone from actually configuring the Dispatcher at all, and only support the optimal configuration!

Unfortunately, it’s not quite that simple. While the exact property values, number of farms and vhosts, and contents of the /filter set will vary between each AEM implementation, there does exist a common set of goals which all optimal Dispatcher setups seek to achieve. At a high level, an optimal configuration will:
1. Maximize the cache hit ratio of the public facing site
2. Reduce the impact of unexpected or malicious requests
3. Limit the effect of activations on the contents of the cache

At Adobe, we’ve been working on a tool to help you optimize your use of the Dispatcher in pursuit of these 3 goals. In this post I’ll be introducing you to the AEM Dispatcher Optimizer Tool, or DOT for short.

Read Full Blog

Introducing the AEM Dispatcher Optimizer Tool


Please use this thread to ask the related questions.


Topics help categorize Community content and increase your ability to discover relevant content.

1 Reply


Level 2

Even though we are following guideline from the dispatcher rule, still cloud manager scan reports an issue. Please share your thoughts here. Please find the rules for which cloud manager scan returns an error.


/0020 { /type "deny" /url "/content*" /selectors "*" }

/0021 { /type "allow" /method "GET" /url "/content*" /selectors '(sel1|sel2)' /extension '(html)' }





Have you tried running the DOT Maven Plugin on your codebase locally? Details can be found here:


There are additional details logged which may help us understand what's going on. For example, if there are 2 dispatcher.any files in the configuration, the DOT may be analyzing the wrong one, which could lead to it not picking up the changes you've made to the active configuration. If this is the case, look for the an entry in the logs similar to this:


[WARNING] More than 1 "dispatcher.any" file was found in repo url (count=2).  Using first file.
[INFO] Loading configuration from file.  File="code/aem-dot-example-project/src/dispatcher1/dispatcher.any"

If this is not the case, you can also find additional detail in the logs about where the issue was detected. For this rule, look for "DOTRules:Disp-7---selector-allow-list" in the logs:


[INFO] RuleId="DOTRules:Disp-7---selector-allow-list" Result="Fail" CheckElement="farm.filter" CheckCondition="FILTER_LIST_INCLUDES" CheckValue="Type=DENY,URL=/content*,Selectors=*" File="dispatcher.any:75"

Note the "File" location which is logged, and check that this filter set includes the rules you've shared above.




@nagarjunkool , I have asked "Bruce" (Author is this post) to assist you.


Level 3

Hi Team,


When running the dispatcher tool , we got below error :


Can you please let us know , if anything wrong with the below configuration


The Dispatcher publish farm filters should specify the allowed Sling suffix patterns in an allow list manner.


# Block use of all suffixes on any resource in /content
/0160 { /type "deny" /url "/content*" /suffix "*" }

# Suffix patterns which are needed on the server side can be added in an allow list manner
/0161 { /type "allow" /url "/content/shc/*" /suffix "/content/<project folder name>/*" /method "GET" }


The Dispatcher publish farm filters should specify the allowed Sling selectors in an allow list manner.

# Block use of all selectors on any resource in /content
/0150 { /type "deny" /url "/content*" /selectors "*" }

# Individual selectors which are needed on the server side can be added in an allow list manner
/0151 { /type "allow" /url "/content*" /selectors '(legit-selector|other-fine-selector)' /method "GET" }


Skipping unknown /filter level token. Token="*.1.json".


/0024 { /type "allow" /url "*/global-nav-tree*" /method "GET" /extension 'json' "*.1.json" } # allow one-level json requests for global navigation component


This is the code in our publish filter file not sure what is wrong with this.



Hi @niks1,


Looks to me like the issue is the inclusion of the text "*.1.json" in this line. If you would like to enable the use of the "1" selector, you could add a `/selectors` element to the rule. Details can be found here (look for "/selectors" on the page for examples):