[jira] [Commented] (MAILBOX-75) CachingUidProvider MAY reuse previous used uid after restart

["Eric Charles (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MAILBOX-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040158#comment-13040158 ] 

Eric Charles commented on MAILBOX-75:
-------------------------------------

Damn it, we missed that case!

Storing lastUid on each append is going to be lower the performance.
I wonder if we could find a way to work with a "minimalLastUid" only on Expunge.
Let's say that on each expunge, the expunged uid is stored in this minimalLastUid (if larger than previous minimal one...).

After, on startup, it's the same as now, except:
- the lazily calculated lastUid is lower than the minimalLastUid, we put the minimalLastUid in the cache
- the lazily calculated lastUid is higer than the minimalLastUid, we put the lastUid in the cache

This would allow to spare some update on mailbox (though we still need to lock).

In my case, I mainly work with filters on my inbox, so doing much expunge on inbox, but never expunging mails on other folders, so this could give some gain.

I wonder if this approach worth the pain?


> CachingUidProvider MAY reuse previous used uid after restart
> ------------------------------------------------------------
>
>                 Key: MAILBOX-75
>                 URL: https://issues.apache.org/jira/browse/MAILBOX-75
>             Project: James Mailbox
>          Issue Type: Bug
>          Components: jcr mailbox, jpa mailbox, maildir mailbox, store
>    Affects Versions: 0.2
>            Reporter: Norman Maurer
>            Assignee: Norman Maurer
>            Priority: Critical
>             Fix For: 0.3
>
>
> The CachingUidProvider does lazy fetch the "highest" uid of all messages stored in the mailbox on first request of the lastUid for a mailbox or if the nextUid is requested. This works well if there were never emails in the mailbox but MAY fail otherwise..
> The problem happens if you for example append 2 messages to the mailbox which get the uids 1 and 2 assigned and then expunge the message with uid 2. As long as the server is not restarted everything works well, but if you do so and a new message will get append it will reuse the uid 2 for it as uid 1 is the last known for it. This is strictly disallowed.
> See RFC 3501:
>    A 32-bit value assigned to each message, which when used with the
>    unique identifier validity value (see below) forms a 64-bit value
>    that MUST NOT refer to any other message in the mailbox or any
>    subsequent mailbox with the same name forever.  Unique identifiers
>    are assigned in a strictly ascending fashion in the mailbox; as each
>    message is added to the mailbox it is assigned a higher UID than the
>    message(s) which were added previously.  Unlike message sequence
>    numbers, unique identifiers are not necessarily contiguous.
> So even if this will hit the performance we need to store the lastUid everytime we do an append to be sure we don't run in any problems

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org