As stated in TL-37 we would like to rely on a centralized blob cache service.
There are 2 main use cases for such a service:
- Avoid costly blob re-computation => Converter and Tiling caches
- Avoid re-fetching remote blobs => S3BinaryManager
This is indeed the cache semantic : "storing blobs locally for efficiency".
The S3BinaryManager already uses the LRUFileCache implementation to store blobs on the file sytem and asks them to the remote server if not found.
The Converter and Tiling caches are ad hoc and less reliable implementations.
=> Let's analyze and refactor the code of Converter and Tiling caches to extract a generic blob cache API exposed as a Nuxeo service, let's say BlobCacheService.
This API should be similar to the core CacheService and its default implementation should be based on the LRUFileCache.
- Don't hesitate to clean up the Converter and Tiling code.
- We should be able to declare a blob cache with:
- A name
- Proper GC
- We shoud be able to configure the file system storage location taking into account clustering, probably using a new nuxeo.clustershared.dir Framework property as the nuxeo.data.dir one.
- For Tiling the use case is slightly different, tiles are requested through the RET API a few seconds / minutes later.
- The TransientStore should be a client of the BlobCacheService.