[
https://issues.apache.org/jira/browse/IMAP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed IMAP-373.
-------------------------------
Resolution: Abandoned
We removed a long time ago the unmaintained untested mailbox/caching
sub-project.
> 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
> Priority: Major
> 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 was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
