[jira] [Comment Edited] (JAMES-2805) Top level implementation of the DeletedMessageVault

["Tellier Benoit (JIRA)" <se...@james.apache.org>]

    [ https://issues.apache.org/jira/browse/JAMES-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16871037#comment-16871037 ] 

Tellier Benoit edited comment on JAMES-2805 at 6/24/19 10:38 AM:
-----------------------------------------------------------------

I created the tasks for the tasks we plan to tackle in the very near future.

Note that to complete this work we will also need:

 - Implement DeletedMessageVault::delete. There are some interactions with deduplication that can happen in the blobStore. We thus decided to postpone this task to gain some better insights. A temporary acceptable step might be to just delete the meta-data.Another alternative might be to delete all the deletedMessages sharing the same blob. Anyway this topic needs further discussions.
 - Webadmin Task for moving old data in mail repository to new vault (for those who already tried thius feature, we should allow a migration)
 - CassandraBlobStore should deal with containers - the proposed table structure needs review and further discussions.



was (Author: btellier):
 - https://issues.apache.org/jira/browse/JAMES-2806 intend to allow the BlobStore caller to specify a bucketName

> Top level implementation of the DeletedMessageVault
> ---------------------------------------------------
>
>                 Key: JAMES-2805
>                 URL: https://issues.apache.org/jira/browse/JAMES-2805
>             Project: James Server
>          Issue Type: Improvement
>            Reporter: Tellier Benoit
>            Priority: Major
>
> While working on the deletedMessageVault, we targeted in MAILBOX-381 a first implementation on top of MailRepositories
> That decision was unfortunate as then one can browse the content of the deletedMessageVault vault through webAdmin.
> Thus we decided to implement DeletedMessageVault as a separate component.
> That component has the following considerations:
>  - Should have a low storage cost
>  - Cold storage and delays upon reads are acceptable as one does not expect a restore/export to be fast
>  - Find an efficient way to implement retention (deleting too old emails) without a full scan
> We decided to provide an implementation above the blobStore and a metaData store (cassandra)
> Retention will be implemented with object storage buckets (one month = 1 bucket). We could then simply delete a bucket when all the mails it contains are older than the retention period.
> Querying the deleteMessageVault will first be done with a full scan. Later enhancement can be done by providing a per-bucket (immutable) Lucene index - once the bucket is no longer the latest one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org