Esther Weidauer

> - timestamp1 (original image, as stated in meta-file) can be ignored for cache-decision > - timestamp2 (ts of generating image-cache-object) take the stat-modified-timestamp and check > (timestamp2 + max-age)...

After thinking about it some more: using stat-mtime for the timestamp of the cache items is actually a regression and could severely reduce performance. I'll revert that change and publish...

To fix the original issue here: Can you provide the configuration for the alias that you're using? Specifically the `headers` section?

Make sure that the garbage collector config is not set to 'immediate' for target files (the default value). Set it to 'cache'. Otherwise the GC will clear the generated images...

The test image is also quite old. It has an mtime from 2015 so it has definitely exceeded a max-age of 3600. Just to make sure, I also tried setting...

The correct syntax for that alias config would be: ```yml alias: local base_file_path: "/srv/www/devbox.local/data/files" fallback_base_file_paths: - "/srv/www/devbox.local/data/temp_files" headers: Cache-Control: "public, max-age=86400" ``` Because there was actually no alias configured this...

But does it still lead to accumulating locks?

And is there a source image and a set of parameters that reproduce this bug?

The cache layer should not interfere with other HTTP caching proxies since converjon obeys and passes along the relevant HTTP headers. Are you having problems with the caching itself or...

Is this still relevant or can I close it?