[
https://issues.apache.org/jira/browse/IMAP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13639232#comment-13639232
]
Andrzej Rusin commented on IMAP-373:
------------------------------------
Eric,
We use jgroups, solely for James Events for MailboxListener propagation between
cluster members (dedicated IMAP and SMTP jameses and their "store backends").
Additionally, as a quick hack to partially overcome IMAP-371 I implemented in
the past a naive memcached caching of mailboxes, with "manual" invalidation
from respective code across my "store" (which is used by a webmail solution and
other things at the same time too). But that caching is nothing like any
elegant solution, hence my work on IMAP-373.
BTW, we were trying to use Hazelcast for Events propagation, but we ran into
"not explainable" "issues" with it (under load), that's why we switched to
jgroups with a possibly better result.
> 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]
