The Diskcache plugin of Imageresizer ignores the modified date of images retrieved with AzureReader2

Question

When I upload a new version of an image (with the same name, but with a new Last Modified property) to Azure Storage, the resized version called via the URL API does not update.

The new image shows up when viewed directly from this URL: [redacted].blob.core.windows.net/xlenz/modified-test.jpg

But when I look at the resized cached version I still get the old version: [redacted].com/cloud/xlenz/modified-test.jpg?width=700

Last-Modified: Thu, 08 May 2014 09:22:46 GMT
ETag: "ddf1d8129f6acf1:0"
Content-Type: image/jpeg
Cache-Control: public

Requesting a new uncached version of the image does show the new version: [redacted].com/cloud/xlenz/modified-test.jpg?width=800

Last-Modified: Thu, 08 May 2014 10:12:20 GMT
ETag: "a28693ffa56acf1:0"
Content-Type: image/jpeg
Cache-Control: public

When I FTP a new version of the image directly to the site, the resized version called via the URL API does update: [redacted].com/modified-test.jpg?width=700

I know the problem is with DiskCache and not AzureReader2, because when I disable DiskCache via <diskCache enabled="false" /> the problem goes away.

Is this a bug in the DiskCache plugin? Does the DiskCache not look at the Last Modified date of files in Azure Blob Storage?

I'm using the latest 3.4.2 versions of ImageResizer, ImageResizer.Plugins.AzureReader2 and ImageResizer.Plugins.DiskCache.

The diagnostics page output: https://gist.github.com/anonymous/e104f8127969cedf92fd

Answer 1

When caching is disabled, each request downloads a new copy of the source image from Azure.

To provide last-modified date based invalidation, you would have to check with Azure on each request (or cache metadata based on yet more expiry rules).

AzureReader2 does not let DiskCache access the modified date of azure blobs, as this would make even cached image access quite slow. Network latency is not to be trifled with :)

When working with blob or remote storage, the best invalidation strategy is none at all - treat blobs as immutable. This doesn't mean you can't update the reponses for existing image URls — it just means you'll have to maintain a rewrite table somewhere.

Answer 2

Looking at S3Reader2 (the equivalent plugin for Amazon S3 storage) I have come to the conclusion that it is not a bug, but a missing feature.

S3Reader2 has a 'checkForModifiedFiles' configuration setting:

If true, S3Reader will check for updated source files on S3 when a cached file is requested. The metadata is cached for an hour after it is last accessed (configurable by code). If false, S3 will never be checked for newer versions of cached files, reducing latency costs by 50%. Defaults to false.

That is exactly what I was looking for in AzureReader2!

I have added this as a feature request on the official ImageResizer UserVoice site: http://resizer.uservoice.com/forums/108373-image-resizer/suggestions/5900800-add-checkformodifiedfiles-configuration-setting-l

Please add your vote!

As a temporary workaround (while we wait for a fix) we'll add the current date to the ImageResizer requests that go to the images that are (partially) updated daily.

UPDATE 2015-02-26: @nathanael-jones wrote on http://resizer.uservoice.com/forums/108373-image-resizer/suggestions/5900800-add-checkformodifiedfiles-configuration-setting-l: "This functionality is complete, and present in the V4 and develop branch on GitHub."

Thanks for voting!