Package Replication does not clearing the dispatcher cache for its filters. | Community
Skip to main content
VitthalaShiva
VitthalaShiva
Level 2
September 5, 2018
Solved

Package Replication does not clearing the dispatcher cache for its filters.

  • September 5, 2018
  • 5 replies
  • 5130 views

I have set up the dispatcher with Publish Instance and publishing a page from Author to Publish is clearing clearing the cached page on dispatcher, but if I am activating any package from author to publish does not clear its filters from the dispatcher cache. i.e. I have a package with the filter "/etc/designs/PROJECT_NAME/site/example.js, and the same file is cached on at the dispatcher. If I am replicating a package from the Author, then in Dispatcher log, I am able to see

[DATE_TIME] [I] [pid 8240 (tid 640)] Activation detected: action=Activate [/etc/packages/PROJECT_NAME/BUNDLE_NAME-1.0.76.zip]

[DATE_TIME] [I] [pid 8240 (tid 640)] Touched c:\Apache2\htdocs\.stat.

    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 joerghoh

    if you encounter this issue only when deploying the JS and CSS package, I would recommend to use versioned clientlibs. Because then it doesn't matter if the dispatcher is invalidated or not; as soon as new JS or CSS files are dropped on publish, the URL to the clientlibs will change (different selector). And then the old files are no longer referenced and used. Then the only remaining task is to clean up the directory on the dispatcher every once in a while to reclaim disk space.

    Jörg

    5 replies

    joerghoh
    Adobe Employee
    joerghohAdobe Employee
    Adobe Employee
    September 5, 2018

    When you activate packages, the publish does not send invalidation requests for the content of the package. That's default behavior.

    (Anyway, activating deployment packages via replication is hardly best practice, because you cannot control the order. Typically it will cause a restart of bundles on all publishs at the same time, causing iussues with the availability of your site(s).)

    Jörg

      Jitendra_S_Toma
      Jitendra_S_Toma
      Level 10
      September 5, 2018

      Hi,

      it is a problematic if package invalidate pages however May I know what is your use case? And what is the need for that?

        Nisha_Nivedita
        Adobe Employee
        Nisha_NiveditaAdobe Employee
        Adobe Employee
        September 5, 2018

        I see that you mention stat file is touched, if thats the case is the etc/design..* filter  getting invalidated on accessing it on publisher.Also how does your invalidate section look like , can you paste here?

        Having said so, agree with Jörg code/templates should be a part of build process not activating as packages.

          VitthalaShiva
          VitthalaShivaAuthor
          Level 2
          September 6, 2018

          Hi All,

          The use case is, we have near to 10 publish instances and I was thinking to upload the packages only to the author instance and replicate the same, so our UI (css and JS for the end user) has a different package, so that doubt is if we are replicating the UI package from author to publish instance, does AEM publish instance triggers the dispatcher flush for the UI package filters to clear the JS and CSS cache.

          Our JS and CSS is under /etc/designs/PROJECT_NAME.

          joerghoh
          Adobe Employee
          joerghohAdobe EmployeeAccepted solution
          Adobe Employee
          September 6, 2018

          if you encounter this issue only when deploying the JS and CSS package, I would recommend to use versioned clientlibs. Because then it doesn't matter if the dispatcher is invalidated or not; as soon as new JS or CSS files are dropped on publish, the URL to the clientlibs will change (different selector). And then the old files are no longer referenced and used. Then the only remaining task is to clean up the directory on the dispatcher every once in a while to reclaim disk space.

          Jörg

            M
            msanz-gihsa
            March 23, 2020

            Hi @joerghoh,

            What should we do if we are Adobe Marketing cloud customers? I know you said we have to version de libs but, how should we clean up space at the dispatchers? Also, if I am testing some stuff, I cannot be continously versioning my lib and given that minification is really buggy at the publisher, which is yet another topic to bring up in another thread... how should I delete these files?

            i.e.

            sudo rm /var/www/html/content/****/etc.clientlibs/****/clientlibs/clientlib-base.min.js [sudo] password for ****: Sorry, user **** is not allowed to execute '/bin/rm /var/www/html/content/****/etc.clientlibs/****/clientlibs/clientlib-base.min.js' as root on ****-stage2-dispatcher1westeurope.

            This is kindof a bug at Adobe, feels pretty dissapoining that cache clearing is not working as expected...

            Thanks!

            Mariano

            Terms & ConditionsAccessibility statement

            Loading footer...