[JAMES-3882] Asynchronous deletions with DeletedMessageVault on top of Cassandra

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 3.8.0
• Component/s: cassandra, deletedMessageVault
• Assignee: Unassigned
• Reporter: Benoit Tellier
• Created: 10/Feb/23 15:32
• Updated: 14/Feb/23 00:12
• Resolved: 14/Feb/23 00:12

Description

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).

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...

The way to go

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

Issue Links

• links to: GitHub Pull Request #1436