Skip to main content
this-that-the-otter
this-that-the-otter
Level 4
Oct 13, 2026 6:08 PM UTC
Question

AEM LTS (flush agents)

I’m practicing an upgrade from AEM 6.5.21 on-prem Java 11 to AEM LTS (6.6.3) on-prem Java 21 - things seem to have gone pretty smoothly, my replication agents (on author) test successfully and I can replicate pages to the publish instance. 

 

I was looking at my flush agent setup and trying to replicate it from the author to a publish instance and it did not replicate (the UI just spun). 

 

I checked enabled for this agent and on saving the flush agent, this appears in the author log: 

 

13.10.2026 12:14:42.136 *INFO* [sling-oak-observation-20] com.day.cq.replication.impl.ConfigManagerImpl Configuration for agent at /etc/replication/agents.publish/<agent-name> is not active.

 

I can deactivate the flush agent but activate just hangs. 

I tried reverting to Java 17 on the LTS instance but that did not change things.

I am going to try packaging the agent for install on publish the instance.

Installing as a package seems to be working? Not fully tested but the view log and test links in agent config on the publish instance seem to work. Is this expected in the newer AEM?

Thanks for any assistance.

 

    5 replies

    this-that-the-otter
    this-that-the-otterAuthor
    Level 4
    Oct 13, 2026 9:10 PM UTC

    Cache invalidation seems to be working with the package installed flush agent directly to the publish instance (but replication of flush agent from author to publish did not succeed). It seems to be new AEM behavior? 

    Translate
    social_portfolio81db
    Level 2
    Oct 14, 2026 12:56 AM UTC

    ​@this-that-the-otter 


    This is not a documented change in 6.5 LTS. It still runs through activating the flush agent from author, and there’s not change to this in terms of the agent behaviour.

    The “not active” log line looks harmless to me. agents.publish configs are meant to run on publish, so author reporting them as inactive seems normal.

    The hanging Activate is probably a separate issue. I’d check the default agent’s queue on author for a stuck item, and make sure its transport user can write to /etc/replication/agents.publish on publish. Page replication working only proves it can write under /content.

    Can you share a sample of the author error.log and the default agent’s debug log from the moment you click Activate to debug further?

    Translate
    this-that-the-otter
    this-that-the-otterAuthor
    Level 4
    Oct 14, 2026 12:50 PM UTC

     Thanks for your reply, my default replication is using the administrator account (I know this is not a good practice) - in any case - these are the permissions on the publish instance for administrator:

     

     

    Here is what it looks like when I try to replcate www1 flush agent from author (I has successfully deactivated prior): 

     

     

    My default replication has no queue while the above is “Loading...” - 

     

     

    Refreshing the failed activation cancels the “Loading...” animation.

     

    The default agent’s view log shows nothing, the test connection succeeds. 

     

    This is the same finding on the publish instance when clicking view log (empty) and test connection (success) debug links for the package installed publish flush agent.

     

    The only thing appearing in the log while activating the flush agent is: 

     


    ==> /apps/author/crx-quickstart/logs/request.log <==
    14/Oct/2026:08:44:48 -0400 [5179] -> GET /home/users/K/KO4kUiGiAtqeHTSIJ8pJ.permissions.json?path=%2Fetc%2Freplication%2Fagents.publish%2Fwww1&currentNodeOnly=true&_charset_=utf-8&cq_ck=1791981888930 HTTP/1.1
    14/Oct/2026:08:44:48 -0400 [5179] <- 200 application/json 3ms

    ==> /apps/author/crx-quickstart/logs/access.log <==
    10.27.128.20 - admin 14/Oct/2026:08:44:48 -0400 "GET /home/users/K/KO4kUiGiAtqeHTSIJ8pJ.permissions.json?path=%2Fetc%2Freplication%2Fagents.publish%2Fwww1&currentNodeOnly=true&_charset_=utf-8&cq_ck=1791981888930 HTTP/1.1" 200 203 "https://dev/miscadmin" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/155.0.0.0 Safari/537.36"

     

    Translate
    social_portfolio81db
    Level 2
    Oct 14, 2026 5:21 PM UTC

    ​@this-that-the-otter ,

    Thanks for the details. Since your default agent uses admin and its queue stays empty while the spinner runs, I don’t think this is publish permissions or the transport. The only request in your log is the permissions.json lookup, so the Activate call may not be leaving the UI at all. I’d check the browser console and Network tab while you click Activate. To take the UI out of the picture, try making a post call with cmd=activate and path=/etc/replication/agents.publish/www1 to /bin/replicate.json on author, or use Activate Tree under /miscadmin. If that works, it’s a UI issue. If it also hangs, a thread dump during the hang would help.

    Translate
    this-that-the-otter
    this-that-the-otterAuthor
    Level 4
    Oct 15, 2026 3:01 PM UTC

    ​@social_portfolio81db I don’t see any unusual stuff in browser console or network tab upon clicking activate of the flush agent from author and during the spinning ui … I was able to replicate it via curl.

    Translate
    Terms & ConditionsAccessibility statement

    Loading footer...