[
https://issues.apache.org/jira/browse/IMAP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642813#comment-13642813
]
Eric Charles commented on IMAP-373:
-----------------------------------
Hi Andzej,
I have taken your patch, made a few changes (maven pom + compilation issues)
and have committed in trunk.
The main impact for now is that I had to make the
MailboxSessionMapperFactory.create* abstract methods public
+ public MailboxMapper<Integer> createMailboxMapper(MailboxSession session)
+ public MessageMapper<Integer> createMessageMapper(MailboxSession session)
+ public SubscriptionMapper createSubscriptionMapper(Mai
This is not ideal, but not a big deal IMHO.
I have put some TODO(eric) for the 3 other ones (stub implementation to make it
compile, but need to be further implemented/fixed).
Type mismatch: cannot convert from CachingMessageMapper<Id> to
MailboxMapper<Id> CachingMailboxSessionMapperFactory.java
/apache-james-mailbox-caching/src/main/java/org/apache/mailbox/caching line 33
Java Problem
The constructor CachingMessageMapper<Id>(MessageMapper<Id>,
MailboxByPathCache<Id>) is undefined
CachingMailboxSessionMapperFactory.java
/apache-james-mailbox-caching/src/main/java/org/apache/mailbox/caching line 27
Java Problem
The constructor CachingMessageMapper<Id>(MailboxMapper<Id>,
MailboxMetadataCache<Id>) is undefined
CachingMailboxSessionMapperFactory.java
/apache-james-mailbox-caching/src/main/java/org/apache/mailbox/caching line 33
Java Problem
If you svn up, you will be able to further work on that module.
About the API and strategy, I wonder why we need those additional
MailboxByPathCache/MailboxMetadataCache interfaces.
Wouldn't the cache be just a Decorator around the existing API?
Thx again, Eric
> 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]
