Content Update Vs Auto-Invalidation

[vdhim23]

Hi

Can someone explain about auto-invalidation and content update, In content-update cache files deletes if content gets modify but in auto-invalidation it doesn't deletes from cache so how caching happens in case of auto-invalidation.Also docs says "if it is older, the Dispatcher retrieves the current version from the AEM instance" in case of auto-invalidation.

Thanks

[Jörg_Hoh]

What's your exact usecase? I am not sure, what you mean with "auto-invalidation".

Jörg

[Sham_HC]

I believe Document referred is http://dev.day.com/docs/en/cq/current/deploying/dispatcher.html

With automatic invalidation, Dispatcher does not delete cached files after a content update, but checks their validity comparing with .stat timestamp when the page are next requested.

[Paul_McMahon]

The to two different methods impact different content. So let's walk through and example with two paths:

1. /content/mysite/en/products
2. /content/mysite/en/services

Let's say that you activate /content/mysite/en/products. The content update logic from dispatcher will for example remove /content/mysite/en/products.html and /content/mysite/en/products.thumb.jpg, but no other files are impacted by the content update logic - only files starting with /content/mysite/en/products (but none of the files in any sub-directories). 

If you for example configure to auto-invalidate .html files then /content/mysite/en/services.html will be invalidated, but not removed. In fact if you stat file level set to zero all HTML files on your site will be invalidated (except /content/mysite/en/products.html which was removed by the content update process). This invalidation happens by touching the stat file (which exists in the docroot if you have the stat file level set to zero). 

So when the next request for /content/mysite/en/products.html comes in dispatcher sees that the file is missing and sends the request back to publish. When the next request for /content/mysite/en/services.html comes dispatcher compares the last modified timestamp on the services.html file with the last modified timestamp on the stat file and because the statfile timestamp is newer than the services.html timestamp it sends the request back to the publish server, and on the way back out services.html is replaced with the newly generated version. This process allows all the .html files to be effectively cleared on an activation immediately, rather waiting while a process actually deletes all the files. ,

[vdhim23 · Accepted solution]

orotas wrote...

The to two different methods impact different content. So let's walk through and example with two paths:

1. /content/mysite/en/products
2. /content/mysite/en/services

Let's say that you activate /content/mysite/en/products. The content update logic from dispatcher will for example remove /content/mysite/en/products.html and /content/mysite/en/products.thumb.jpg, but no other files are impacted by the content update logic - only files starting with /content/mysite/en/products (but none of the files in any sub-directories). 

If you for example configure to auto-invalidate .html files then /content/mysite/en/services.html will be invalidated, but not removed. In fact if you stat file level set to zero all HTML files on your site will be invalidated (except /content/mysite/en/products.html which was removed by the content update process). This invalidation happens by touching the stat file (which exists in the docroot if you have the stat file level set to zero). 

So when the next request for /content/mysite/en/products.html comes in dispatcher sees that the file is missing and sends the request back to publish. When the next request for /content/mysite/en/services.html comes dispatcher compares the last modified timestamp on the services.html file with the last modified timestamp on the stat file and because the statfile timestamp is newer than the services.html timestamp it sends the request back to the publish server, and on the way back out services.html is replaced with the newly generated version. This process allows all the .html files to be effectively cleared on an activation immediately, rather waiting while a process actually deletes all the files. ,

Thanks for explanation.

[vdhim23]

orotas wrote...

The to two different methods impact different content. So let's walk through and example with two paths:

1. /content/mysite/en/products
2. /content/mysite/en/services

Let's say that you activate /content/mysite/en/products. The content update logic from dispatcher will for example remove /content/mysite/en/products.html and /content/mysite/en/products.thumb.jpg, but no other files are impacted by the content update logic - only files starting with /content/mysite/en/products (but none of the files in any sub-directories). 

If you for example configure to auto-invalidate .html files then /content/mysite/en/services.html will be invalidated, but not removed. In fact if you stat file level set to zero all HTML files on your site will be invalidated (except /content/mysite/en/products.html which was removed by the content update process). This invalidation happens by touching the stat file (which exists in the docroot if you have the stat file level set to zero). 

So when the next request for /content/mysite/en/products.html comes in dispatcher sees that the file is missing and sends the request back to publish. When the next request for /content/mysite/en/services.html comes dispatcher compares the last modified timestamp on the services.html file with the last modified timestamp on the stat file and because the statfile timestamp is newer than the services.html timestamp it sends the request back to the publish server, and on the way back out services.html is replaced with the newly generated version. This process allows all the .html files to be effectively cleared on an activation immediately, rather waiting while a process actually deletes all the files. ,

Can you advice about statfile. File got create after configuring the dispatcher .stat. it contains the value 1. It doesn't have any timestamp, is this correct or there can be something wrong.

[Jörg_Hoh]

The timestamp is a part of the metadata of the file and not contained within the file. Basically the content of the file doesn't care, just its presence and the last-modified timestamp matter.

Jörg