Hey guys, Just throwing out an alternative. We have a load balancer that can enforce sticky IMAP sessions. So each of our servers has a simplistic Guava cache using cache loaders. The disadvanatage of course is that if a server goes down the rest of the traffic now goes to the remaining servers and their info must be reloaded.
Roy On Tue, Apr 23, 2013 at 2:03 AM, Eric Charles (JIRA) < [email protected]> wrote: > * Replies will be sent through Spamex to [email protected] > * For additional info click -> http://www.spamex.com/i/?v=23469590 > > > [ > https://issues.apache.org/jira/browse/IMAP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638820#comment-13638820] > > Eric Charles commented on IMAP-373: > ----------------------------------- > > Awesome Andrzej. > > As distributed cache, Hazelcast is my favorite. > Did you implement your own distributed cache on top of lower-level > multicast communication of do you use an existing library for this? > > Thx again for all your goodies, > > 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 > > > > 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] > >
