Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

Can ACS Commons Dispatcher Flush UI agent invalidate cache for one author and two dispatchers setup ?

Avatar

Level 2

I would like to have dispatcher agent to be configured on prod author so that I can purge dispatcher cache from author. But our PROD is setup like one author two publishers and two dispatchers.

https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-ui/index.html


The documentation doesn't talk about two dispatchers here, so wanted to know if  we can clear both dispatchers cache from one dispatcher flush agent setup in author ?

Thank you!
Sagar Verliani

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

@SagarVerliani it's possible.. you need to have two dispatcher flush agents on author one for each dispatcher.. it works.

View solution in original post

4 Replies

Avatar

Correct answer by
Community Advisor

@SagarVerliani it's possible.. you need to have two dispatcher flush agents on author one for each dispatcher.. it works.

Avatar

Community Advisor

@SagarVerliani If you have 2 dispatcher flush agents and active , it will show up in the dispatcher flush UI when you flush action like below

Saravanan_Dharmaraj_0-1697842914344.png

 

Avatar

Community Advisor

Hello @SagarVerliani ,

Absolutely possible! We have being using a similar set up for years now.

As far as you have a replication agent for an environment, you can flush cache for that sever. The count does not matter. Benefit of this is, there is no change necessary, just add a replication agent with correct necessary info and you can start using it in no time.

This method can also be used when you add a Disaster recovery environment along with Production servers or you decide to add additional servers to the infrastructure.

 

Thanks 

Preetpal

Avatar

Level 2

Just be sure to disable those agents from reacting to normal replication requests.

They shall work be strictly in "on explicit demand" mode, otherwise you'll risk stale content race conditions (annoying and difficult to reproduce)