[
https://issues.apache.org/jira/browse/IMAP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642930#comment-13642930
]
Andrzej Rusin commented on IMAP-373:
------------------------------------
Eric,
Thank you for committing it.
The compilation problems can be quickly resolved and I will do that.
API strategy: Those additional MailboxByPathCache/MailboxMetadataCache
interfaces were intended just to make the CachingMessageMapper and
CachingMailboxMapper clearly separate from the underlying caches. I believe the
interfaces also convey the purpose of it.
Other option would be to make the current CachingMessageMapper and
CachingMailboxMapper abstract on the cacheable methods, and let descendants
decide what to do there. But it does not introduce substantial improvement.
If you have a better idea for that, let me know. I am open to any suggestions.
Regards,
Andrzej
> 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: [email protected]
For additional commands, e-mail: [email protected]
