james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrzej Rusin (JIRA)" <server-...@james.apache.org>
Subject [jira] [Updated] (IMAP-373) Caching for Mailbox/Message Mappers
Date Tue, 23 Apr 2013 20:03:17 GMT

     [ https://issues.apache.org/jira/browse/IMAP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Andrzej Rusin updated IMAP-373:

    Attachment: IMAP-373-v1.patch

Initial version for review if it makes any sense.
> Caching for Mailbox/Message Mappers
> -----------------------------------
>                 Key: IMAP-373
>                 URL: https://issues.apache.org/jira/browse/IMAP-373
>             Project: James Imap
>          Issue Type: Bug
>          Components: Mailbox
>            Reporter: Andrzej Rusin
>            Assignee: Eric Charles
>         Attachments: IMAP-373-v1.patch
> Because of reasons similar to IMAP-371 the performance of James Imap suffers when there
are many clients.
> The core issue is that the Mailbox/Message Mappers methods implementations can be potentially
quite expensive, yet in many cases their result is "constant" for the input arguments, when
the underlying data does not change. This makes them a good candidate for caching.
> Another issue is that some of the methods are possibly needlessly called mutiple times
inside a single request, and this is in focus of IMAP-371.
> The cache can be implemented for example using Decorator pattern on top of the existing
Mailbox/Message Mappers.
> In the first step caching may involve MailboxMapper.findMailboxByPath, next steps may
be some simple yet potentially expensive aspects of MessageMapper like countMessagesInMailbox(),
countUnseenMessagesInMailbox(), getLastUid(), getHighestModSeq()
> Because we have notifications that are fired when something happens to Mailboxes and
Messages, it should be quite easy to invalidate stale cache entries. The invalidation can
be registered as a global listener the AbstractDelegatingMailboxListener.
> So: the general caching Mailbox/Message Mappers implementation would be abstract, and
there needs to be a concrete implementation too. 
> For concrete implementation it would be nice to use something like guava Cache built
with CacheBuilder with some nice options like proper TTL, size etc. The guestion is whether
guava is license-compatible with James.
> What do you think about it?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

View raw message