Benoit Tellier created JAMES-3882:
-------------------------------------

             Summary: Asynchronous deletions with DeletedMessageVault on top of 
Cassandra
                 Key: JAMES-3882
                 URL: https://issues.apache.org/jira/browse/JAMES-3882
             Project: James Server
          Issue Type: Improvement
          Components: cassandra, deletedMessageVault
            Reporter: Benoit Tellier
             Fix For: 3.8.0


h3. Problem statement

Because the deleted message vault needs to work with *any* backend in order to 
copy content of deleted messages into the vault, this copy must happen prior 
actual message deletion in order to have access to it. There's no real 
alternative at this level of abstraction.

Copying data into the vault is a slow process that is thus done synchronously, 
and incurs a slow down of the deletion that is visible to the end user. Mail 
clients can delete a *large* volume of mails at once, eg when deleting a 
mailbox, exhacerbating this problem.

To my own experience, this matters of fact renders the Deleted Message Vault 
unusable in real world deployment (with IMAP).

h3. Solution proposal

With the Cassandra mailbox we can do better.

Read 
https://github.com/apache/james-project/blob/master/src/adr/0029-Cassandra-mailbox-deletion-cleanup.md
 

TLDR the cassandra mailbox only kills the first level of metadata referencing 
the content, but the content is still readable from DB, not exposed to the 
user, and asynchronously removed.

We can piggy back the DeletedMessageVault onto this asynchronous cleanup within 
Cassandra base apps to move content copy upon deletion out of the critical path.

 -> This process will no longer be time sensitive as it will be carried out 
asynchronously...
 -> Leverages retries empowered by the mailbox listener sub system thus 
enhancing the resilience of the deleted message vault...

h3. The way to go

I would be interested to put together a proposal code change setting this up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

Reply via email to