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

[VitthalaShiva]

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.

[Jörg_Hoh]

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]

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]

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]

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.

[Jörg_Hoh · Accepted solution]

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

[msanz-gihsa]

Hi @Jörg_Hoh,

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

[Jörg_Hoh]

Invalidating the cache should suffice.