[
https://issues.apache.org/jira/browse/JAMES-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3135.
---------------------------------
Resolution: Fixed
https://github.com/linagora/james-project/pull/3273 contributed this.
> Write a CassandraDumbBlobStoreCache
> -----------------------------------
>
> Key: JAMES-3135
> URL: https://issues.apache.org/jira/browse/JAMES-3135
> Project: James Server
> Issue Type: Improvement
> Reporter: Nguyễn Việt Đức
> Priority: Major
>
> Location: {{blob-store-cassandra}} maven project.
>
> {{interface BlobStoreCache { Publisher<Void> cache(BlobId blobId, byte[]
> data); Publisher<Void> cache(BlobId blobId, InputStream data);
> Publisher<byte[]> read(BlobId); Publisher<byte[]> delete(BlobId);}}}
> *DOD* Write a {{Cassandra}} implementation of it.
> * The cache is responsible of caching only small input, below a configurable
> threshold. Calling {{cache}} on a too big input should result in nothing
> being stored. (default 8kb)
> * Failure handling:
> ** Circuit breaking: if retrieving the content takes more than
> {{blobStore.cache.timeout}} (default to 50ms) then return empty which will
> result in reading the main data store
> ** Ignore errors: return empty.
> GC grace period for this table should be set to 0
> ConsistencyLevel ONE
> API + contract test + implementation
> ----
> Why a cache:
> * We don't want to read the blobStore for small input as it comes with high
> latency.
> * eg headers
> Why Cassandra: distributed on disk storage without "yet another strategy"
> Limitation:
> * Replication factor. Should we consider a dedicated 'cache' keyspace with a
> replicationFactor of one
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
