Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-3148

Cassandra mailbox deletion cleanup

    XMLWordPrintableJSON

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.5.0
    • Fix Version/s: 3.6.0
    • Component/s: cassandra, mailbox
    • Labels:
      None

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              btellier Benoit Tellier
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: