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 "Benoit Tellier (Jira)" <se...@james.apache.org> on 2023/02/10 15:33:00 UTC

[jira] [Created] (JAMES-3882) Asynchronous deletions with DeletedMessageVault on top of Cassandra

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