[
https://issues.apache.org/jira/browse/JAMES-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17101313#comment-17101313
]
Benoit Tellier commented on JAMES-3148:
---------------------------------------
https://github.com/linagora/james-project/pull/3286 contributed this.
See related ADR
https://github.com/apache/james-project/blob/master/src/adr/0029-Cassandra-mailbox-deletion-cleanup.md
> Cassandra mailbox deletion cleanup
> ----------------------------------
>
> Key: JAMES-3148
> URL: https://issues.apache.org/jira/browse/JAMES-3148
> Project: James Server
> Issue Type: New Feature
> Components: cassandra, mailbox
> Affects Versions: 3.5.0
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.6.0
>
>
> Cassandra is used within distributed James product to hold messages and
> mailboxes metadata.
> Cassandra holds the following tables:
> - mailboxPathV2 + mailbox allowing to retrieve mailboxes informations
> - acl + UserMailboxACL holds denormalized information
> - messageIdTable & imapUidTable allows to retrieve mailbox context
> information
> - messageV2 table holds message matadata
> - attachmentV2 holds attachment for messages
> - References to these attachments are contained within the attachmentOwner
> and attachmentMessageId tables
>
> Currently, the deletion only deletes the first level of metadata. Lower level
> metadata stay unreachable. The data looks
> deleted but references are actually still present.
> Concretely:
> - Upon mailbox deletion, only mailboxPathV2 & mailbox content is deleted.
> messageIdTable, imapUidTable, messageV2,
> attachmentV2 & attachmentMessageId metadata is left undeleted.
> - Upon mailbox deletion, acl + UserMailboxACL is not deleted.
> - Upon message deletion, only messageIdTable & imapUidTable content is
> deleted. messageV2, attachmentV2 &
> attachmentMessageId metadata is left undeleted.
> This jeopardize efforts to regain disk space and privacy, for example through
> blobStore garbage collection.
> We need to cleanup Cassandra metadata. They can be retrieved from dandling
> metadata after the delete operation had been
> conducted out. We need to delete the lower levels first so that upon failures
> undeleted metadata can still be reached.
> This cleanup is not needed for strict correctness from a MailboxManager point
> of view thus it could be carried out
> asynchronously, via mailbox listeners so that it can be retried.
> Mailbox listener failures leads to eventBus retrying their execution, we need
> to ensure the result of the deletion to be
> idempotent. This might have consequences on the blobStore garbage collection
> design.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
