[
https://issues.apache.org/jira/browse/JAMES-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3679.
---------------------------------
Resolution: Fixed
> Solve tombstones warning for mailbox recent table
> -------------------------------------------------
>
> Key: JAMES-3679
> URL: https://issues.apache.org/jira/browse/JAMES-3679
> Project: James Server
> Issue Type: Improvement
> Components: mailbox
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We noticed tombstone warnings on some tables namely firstunseen,
> mailboxrecent and (less) messageidtable.
> mailbox recent table is used to keep track of recent emails within a mailbox
> in order to fasten SELECT (and avoid full reads of messageidtable). The
> behaviour is to generally to clean up entries straight after reading them.
> Hence we only have a few recent emails, but keep tumbstones for 10 days,
> hence selets often have to cross many tumbstone.
> However this property is interesting: if we can afford some false positives,
> then we could aggressively decrease gc_grace_period to 0. This would cause
> tumbstones to be disposed of at the first compaction, significantly reducing
> their impact. The downside is that mis-synchronisation might lead to entries
> re-appearing once deleted. Which is likely acceptable on some rare occasion
> for mailbox recent. And such entries would eventually be cleaned up (as
> recent entries are removed on SELECT)
> We experimented gc_grace_period = 0 on one of our production plateform and no
> longer see warnings for mailboxrecent table hance wanted to share this here.
> Yet this approach can not be applied for other tables (firstunseen /
> messageidtable)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
