Re: [jira] [Commented] (IMAP-373) Caching for Mailbox/Message Mappers

Tue, 23 Apr 2013 11:46:51 -0700 

Hi,
The disavantage of the cache living in its island (in its own server) is also that multiple different clients are susceptible to read/manipulate the same mailbox, giving incoherent and unexpected behaviour/erros. 


You can easily imagine that session1(client1/server1) mail move should 
also be seen by session2(client2/server2). If it does not, you may 
request a move in session2 of the same mail to another folder, and this 
will fail.



PS: just post your further comments on the jira so we can easily follow. 
Anyway, thx to jump in.


On 23/04/2013 14:25, [email protected] wrote:

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]






---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]























					Reply via email to