[
https://issues.apache.org/jira/browse/JAMES-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3882.
---------------------------------
Resolution: Fixed
> 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
> Priority: Major
> Fix For: 3.8.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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
