You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Nguyễn Việt Đức (Jira)" <se...@james.apache.org> on 2020/04/07 02:59:00 UTC

[jira] [Created] (JAMES-3135) Write a CassandraDumbBlobStoreCache

Nguyễn Việt Đức created JAMES-3135:
--------------------------------------

             Summary: 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


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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org