james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Charles (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (IMAP-193) UIDNEXT generation is a big performance killer and should get reworked
Date Thu, 23 Sep 2010 12:19:32 GMT

    [ https://issues.apache.org/jira/browse/IMAP-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913998#action_12913998
] 

Eric Charles commented on IMAP-193:
-----------------------------------

back again.

With the auto_increment to generate UID (for JPA), we may fall in the pitfall described on

One drawback of this approach is described in "IMAP4 Implementation Recommendations" http://www.rfc-editor.org/rfc/rfc2683.txt

   Some server implementations have attempted to make UIDs unique across
   the entire server.  This is inadvisable, in that it limits the life
   of UIDs unnecessarily.  The UID is a 32-bit number and will run out
   in reasonably finite time if it's global across the server.  If you
   assign UIDs sequentially in one mailbox, you will not have to start
   re-using them until you have had, at one time or another, 2**32
   different messages in that mailbox.  In the global case, you will
   have to reuse them once you have had, at one time or another, 2**32
   different messages in the entire mail store.  Suppose your server has
   around 8000 users registered (2**13).  That gives an average of 2**19
   UIDs per user.  Suppose each user gets 32 messages (2**5) per day.
   That gives you 2**14 days (16000+ days = about 45 years) before you
   run out.  That may seem like enough, but multiply the usage just a
   little (a lot of spam, a lot of mailing list subscriptions, more
   users) and you limit yourself too much.


> UIDNEXT generation is a big performance killer and should get reworked
> ----------------------------------------------------------------------
>
>                 Key: IMAP-193
>                 URL: https://issues.apache.org/jira/browse/IMAP-193
>             Project: JAMES Imap
>          Issue Type: Improvement
>    Affects Versions: 0.1
>            Reporter: Norman Maurer
>            Assignee: Norman Maurer
>             Fix For: 0.2
>
>
> In the store api we generate the uid for a new message and guaranteer that the Mailbox.getLastUid()
method will return this value after it is stored. For this we save the message and the mailbox
and use for example a row lock (in jpa land) for this to get rid of ghost-reads etc. 
> This is a big performance killer and is not needed at all. In the rfc its clearly stated
that the used uid for the next saved message must just be equal or bigger then the UIDNEXT
value. 
> From rfc:
>         Note: The next unique identifier value is intended to
>         provide a means for a client to determine whether any
>         messages have been delivered to the mailbox since the
>         previous time it checked this value.  It is not intended to
>         provide any guarantee that any message will have this
>         unique identifier.  A client can only assume, at the time
>         that it obtains the next unique identifier value, that
>         messages arriving after that time will have a UID greater
>         than or equal to that value.
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message